Có ai có kinh nghiệm với MonetDB không? Hiện tại, tôi có một cơ sở dữ liệu MySQL đang phát triển quá lớn và các truy vấn đang trở nên quá chậm. Theo mô hình định hướng cột, chèn sẽ chậm hơn (mà tôi không nhớ chút nào), nhưng việc truy xuất dữ liệu trở nên rất nhanh. Tôi có cơ hội nhận được hiệu suất truy xuất dữ liệu nhiều hơn chỉ bằng cách chuyển sang MonetDB không? MonetDB có đủ trưởng thành không?Có đáng thử MonetDB không?
Trả lời
Bạn có cơ hội cải thiện hiệu suất của ứng dụng của mình. Tuy nhiên, lợi ích là phụ thuộc phần lớn vào khối lượng công việc của bạn, kích thước của cơ sở dữ liệu và phần cứng của bạn. MonetDB được phát triển/điều chỉnh theo hai giả định chính:
- Khối lượng công việc của bạn là phân tích, tức là bạn có nhiều nhóm và các loại tương tự.
- Quan trọng hơn nữa: tập dữ liệu nóng của bạn (dữ liệu bạn thực sự làm việc) phù hợp với bộ nhớ chính của hệ thống. MonetDB không có trình quản lý bộ đệm riêng nhưng dựa trên hệ điều hành để xử lý đĩa I/O. Kể từ khi hệ điều hành (đặc biệt là các cửa sổ nhưng Linux quá) đôi khi rất câm về trao đổi đĩa có thể trở thành một vấn đề (đặc biệt là cho các kết nối mà hết bộ nhớ).
Đối với sự trưởng thành, có thể có nhiều ý kiến hơn về những người sinh sống trên hành tinh này. Cá nhân, tôi tìm thấy nó đủ trưởng thành nhưng tôi là thành viên của nhóm phát triển và, do đó, thiên vị. Nhưng MonetDB là một dự án nghiên cứu vì vậy nếu bạn có một ứng dụng thú vị, chúng tôi muốn nghe về nó và xem chúng tôi có thể giúp đỡ hay không.
Một số mô tả thêm: giả sử bảng của tôi có các lĩnh vực này (tên, birth_date, social_security_id, drivers_licence_id, annual_income), tôi muốn để có thể làm điều này: select * from người nơi name> "M" và birth_date giữa DATE1 và DATE2 và annual_income từ 10 đến 100; VÀ tôi muốn có thể SORT theo bất kỳ trường nào trong số này. Tất cả các phạm vi này đang giết chết hiệu suất nếu bảng phát triển thực sự lớn. Tôi có cảm giác MonetDB không thể giúp đỡ nhiều trong trường hợp này nhưng nếu có cơ hội nhỏ, tôi sẽ thử. – martincho
Vâng, tôi muốn nói rằng phụ thuộc vào kích thước của kết quả trung gian của bạn (ví dụ, số lượng các bộ đủ điều kiện đối với từng điều kiện). Nếu ID của họ (số nguyên 64 bit bên trong) vừa với bộ nhớ chính, bạn sẽ ổn. Nếu không, nó vẫn có thể thực hiện một cách rõ ràng nếu bạn bỏ qua 'order by'.Một điều cần lưu ý về MonetDB là tất cả các hoạt động được thực hiện rất hiệu quả nhưng tất cả các kết quả trung gian được thực hiện trong bộ nhớ chính (hoặc đĩa có khả năng) có thể giết hiệu suất nếu bạn không có đủ RAM. Tôi muốn nói rằng bạn có thể thử MonetDB. – Holger
"Fit in RAM" được nén hoặc không nén? Tôi có nghĩa là, tôi sẽ có RAM đủ để phù hợp với tất cả các nội dung của thư mục "dbfarm"? (nói về một cơ sở dữ liệu với một bảng lớn). Cảm ơn – GBrian
Câu trả lời tất nhiên phụ thuộc vào tải trọng của bạn, nhưng kinh nghiệm của tôi cho đến nay dường như để cho biết rằng về mọi thứ đều nhanh hơn trong MonetDB hơn tôi đã nhìn thấy trong MySQL. Ngoại lệ sẽ là kết nối, mà không chỉ có vẻ chậm, nhưng dường như hoàn toàn không hoạt động tại pipelining vì vậy bạn sẽ cần phải có bộ nhớ đệm để xử lý những bộ nhớ lớn. Điều đó nói rằng kinh nghiệm của tôi với gia nhập trong MySQL đã không chính xác được sao, hoặc, vì vậy tôi đoán kỳ vọng của bạn có thể thấp. Nếu bạn thực sự muốn thực hiện tốt tham gia, tôi có thể khuyên bạn nên SQL Server hoặc tương tự; đối với các truy vấn khác mà bạn đề cập trong các nhận xét tiếp theo, MonetDB sẽ tuyệt vời. Ví dụ, với một bảng với khoảng 2 triệu hàng trong đó, tôi có thể nằm trên một cột (trong đó có khoảng 800 nghìn hàng trong phạm vi) và thứ tự bởi một cột khác và kết quả hạn chế được xử lý và trả về trong 25ms. Hiệu suất của các loại truy vấn đó dường như giảm dần theo quy mô, nhưng điều đó sẽ cho bạn một hương vị cho những gì bạn có thể mong đợi ở quy mô đó.
Tôi nên cảnh báo rằng mô hình đồng thời lạc quan có thể loại bỏ những người chỉ tiếp xúc với đồng thời bi quan (hầu hết mọi người). Tôi muốn nghiên cứu nó trước khi tự hỏi tại sao một số cam kết của bạn không theo tải đồng thời.
Tôi sẽ nói hầu hết mọi người đều quen thuộc với mô hình OCC vì hầu hết các ORM đều làm điều đó. Đồng thời bi quan và MVCC mặt khác hầu hết mọi người không quen thuộc với nó (MySQL không hỗ trợ ban đầu nó và hầu hết các ứng dụng web phi doanh nghiệp đều không có giao dịch và một số ORMS thậm chí không hỗ trợ khóa hàng/bảng). –
Bất kỳ benchmark so sánh MonetDB chống Hyperdex, Aerospike, DynamoDB, Voldermort, VoltDB hoặc ExtremeDB? – skan
Chỉ cần tự hỏi nếu bạn đã thử MonetDB? Nếu hiệu suất tốt cho bạn? – carfield