Tại sao tokyo bạo chúa làm chậm theo cấp số nhân ngay cả sau khi điều chỉnh bnum?

Question

Có ai đã sử dụng thành công Nội các Tokyo/Tokyo Tyrant với bộ dữ liệu lớn không? Tôi đang cố tải lên một biểu đồ con của nguồn dữ liệu Wikipedia. Sau khi đạt khoảng 30 triệu bản ghi, tôi nhận được số mũ chậm lại. Điều này xảy ra với cả cơ sở dữ liệu HDB và BDB. Tôi đã điều chỉnh tỷ lệ bnum thành 2-4x số lượng bản ghi dự kiến ​​cho trường hợp HDB chỉ với một tốc độ tăng nhẹ. Tôi cũng đặt xmsiz thành 1GB hoặc hơn nhưng cuối cùng tôi vẫn đánh một bức tường.

Có vẻ như Tokyo Tyrant cơ bản là một cơ sở dữ liệu bộ nhớ và sau khi bạn vượt quá xmsiz hoặc RAM của bạn, bạn sẽ có cơ sở dữ liệu không thể sử dụng được. Có ai khác gặp vấn đề này trước đây không? Bạn có thể giải quyết nó không?

Answer 1

Tôi nghĩ rằng tôi có thể đã nứt thế này, và tôi đã không nhìn thấy giải pháp này bất cứ nơi nào khác. Trên Linux, thường có hai lý do khiến Tokyo bắt đầu chậm lại. Cho phép đi qua thủ phạm thông thường. Đầu tiên, nếu bạn đặt bnum của bạn quá thấp, bạn muốn nó ít nhất bằng một nửa số lượng các mục trong băm. (Ưu tiên hơn nữa.) Thứ hai, bạn muốn thử đặt xmsiz của bạn gần với kích thước của mảng thùng. Để có được kích thước của mảng bucket, chỉ cần tạo một db rỗng với đúng bnum và Tokyo sẽ khởi tạo tệp với kích thước phù hợp. (Ví dụ, bnum = 200000000 là khoảng 1,5 GB cho một db trống.)

Nhưng bây giờ, bạn sẽ nhận thấy rằng nó vẫn chậm lại, mặc dù xa hơn một chút. Chúng tôi nhận thấy rằng mẹo này là để tắt journalling trong hệ thống tập tin - vì lý do nào đó các journalling (trên ext3) gai như kích thước tập tin băm của bạn phát triển vượt quá 2-3GB. (Cách chúng tôi nhận ra đây là các đột biến trong I/O không tương ứng với các thay đổi của tệp trên đĩa, cùng với các cụm CPU daemon của kjournald)

Đối với Linux, chỉ cần tháo gắn và đặt lại phân vùng ext3 làm ext2. Xây dựng db của bạn, và remount như ext3. Khi journalling đã bị vô hiệu hóa, chúng tôi có thể xây dựng kích thước khóa có kích thước 180M mà không gặp vấn đề gì.

Answer 2

Tôi bắt đầu làm việc trên một giải pháp để thêm sharding to tokyo nội gọi là Shardy.

http://github.com/cardmagic/shardy/tree/master

Answer 3

Cửa hàng khóa-giá trị của Nội các Tokyo thực sự tốt. Tôi nghĩ mọi người gọi nó chậm vì họ sử dụng cửa hàng giống như bàn của Tokyo.

Nếu bạn muốn lưu trữ dữ liệu tài liệu sử dụng mongodb hoặc một số công cụ nosql khác.

Answer 4

Tokyo quy mô tuyệt vời !! Nhưng bạn phải đặt bnum và xmsiz của bạn một cách thích hợp. bnum phải lớn hơn 0,25 đến 4 lần so với hồ sơ bạn dự định lưu trữ. xmsiz phải khớp với kích thước của BNUM. Cũng đặt opts = l nếu bạn dự định lưu trữ nhiều hơn 2GB.

Xem bài đăng của Greg Fodor ở trên về việc nhận được giá trị cho kích thước của xmsiz. Hãy lưu ý rằng khi đặt xmsiz giá trị bằng byte.

Cuối cùng, nếu bạn đang sử dụng băm dựa trên đĩa, điều rất quan trọng là tắt nhật ký trên hệ thống tệp mà dữ liệu tokyo tồn tại. Điều này đúng với Linux, Mac OSX và có lẽ Windows mặc dù tôi chưa thử nghiệm ở đó.

Nếu nhật ký được bật, bạn sẽ thấy hiệu suất giảm mạnh khi bạn tiếp cận 30+ triệu hàng. Khi nhật ký tắt và các tùy chọn khác đặt Tokyo là một công cụ tuyệt vời.