2009-11-17 31 views
15

Có ai đã sử dụng TokuDB storage engine cho MySQL không?MySQL: Có ai đã sử dụng công cụ lưu trữ TokuDB không?

Trang web sản phẩm tuyên bố có tăng hiệu suất 50x so với các công cụ lưu trữ MySQL khác (ví dụ: Innodb, MyISAM, v.v.). Dưới đây là các khiếu nại về hiệu suất http://tokutek.com/downloads/tokudb-performance-brief.pdf

Điều này có đúng không?

Bất kỳ trải nghiệm cá nhân nào với công cụ lưu trữ này được sử dụng với MySQL?

Trả lời

4

Tôi có cùng một câu hỏi. Tôi đã tìm thấy một sự so sánh khá phong nha của TokuDB chống InnoDB

http://www.pythian.com/news/5139/testing-tokudb-faster-and-smaller-for-large-tables/

Tuy nhiên, tôi đang quan tâm trong bất kỳ kinh nghiệm khác mà những người khác có thể đã có với TokuDB hoặc bất kỳ công cụ lưu trữ tương tự khác cho MySQL.

Một xem xét ở đây http://www.mysqlperformanceblog.com/2009/04/28/detailed-review-of-tokutek-storage-engine/

26

Nếu bạn đang lưu trữ các đốm màu như hình ảnh sau đó không sử dụng tokudb. Nó có giới hạn kích thước hàng nhỏ hơn.

Nếu bạn có dữ liệu trên 100 triệu hàng, hãy sử dụng tokudb.

Nếu bạn nhạy cảm với tốc độ UPDATE, không sử dụng tokudb. Nó có chèn rất nhanh nhưng so với innodb, tốc độ UPDATE chậm hơn và đặc biệt nếu bạn sử dụng các câu lệnh INSERT ON DUPLICATE.

Nếu bạn đang lưu trữ các mục nhập nhật ký, hãy sử dụng tokudb.

Nếu bạn muốn thu nhỏ mức sử dụng dữ liệu của myisam/innnodb xuống hơn 5x, sau đó sử dụng tokudb. Cá nhân tôi đã xác nhận rằng cây fractal + dữ liệu nén phụ trợ của họ cực kỳ hiệu quả về mặt không gian.

Quy tắc chung, sử dụng công cụ tốt nhất cho công việc. Tokudb thổi bay innodb và myisam ra khỏi vùng biển trong các tình huống cụ thể nhưng không phải là một công cụ thay thế db chung cho mọi thứ dưới bầu trời.

+4

Hoàn toàn đồng ý. Chúng tôi có ba cơ sở dữ liệu - hai cơ sở dữ liệu khoảng 1,5TB và 40GB. Chúng tôi đã di chuyển hai phần lớn sang TokuDB và đã bị thổi bay đi bởi nó - chúng tôi đang thấy hơn 15 nghìn truy vấn mỗi giây (một nửa trong số đó là chèn/cập nhật) trên phần cứng khá bình thường. Thêm vào bảo trì lược đồ trực tuyến (bổ sung/giảm cột, tạo chỉ mục/giọt) và nó là hiện tượng. Điều đó nói rằng, @Xing là đúng về việc sử dụng đúng công cụ cho công việc - chúng tôi đã để lại db nhỏ hơn trên InnoDB, vì chúng tôi thấy rằng nó hoạt động tốt hơn cho khối lượng công việc nhỏ hơn. Chúng tôi đã chạy TokuDB khó khăn trong sản xuất trong 6 tháng, và không có vấn đề gì. –

7

Mặc dù TokuDB chậm trên CẬP NHẬT như đã nhận xét ở trên, nhưng nó cực kỳ nhanh trên REPLACE. Thông thường, bạn có thể thay thế UPDATEs bằng REPLACE INTO. Tôi sử dụng TokuDB trên các bảng lên đến 18 tỷ hàng và không có gì khác đến gần, nhanh hơn 100 lần so với innodb cho chèn ngẫu nhiên trên các bảng lớn.

+2

làm thế nào về lựa chọn? –

+5

Một sự thay thế bán buôn của CẬP NHẬT VỚI REPLACE INTOS gần như chắc chắn sẽ phá vỡ cơ sở dữ liệu của bạn - nếu REPLACE INTO thiếu một số cột, chúng sẽ được đặt lại về giá trị mặc định của chúng! Hãy tưởng tượng nếu bảng của bạn có cột đếm tham chiếu cần giữ lại giá trị của nó - thì REPLACE INTO sẽ đặt nó về 0. BOOM! – DroidOS

Các vấn đề liên quan