2010-03-24 21 views
5

Chúng tôi có một bảng hàng nghìn hàng chỉ có 2 cột, một khóa chính và cột thứ hai giữ trạng thái. Vấn đề là chúng ta cần phải trạng thái này sẽ được nhân rộng trên 3 vị trí vật lý tại Mỹ (khoảng 2000 dặm), trong thời gian thực gần hoặc càng nhanh càng thực tế càng tốt qua mạng. Bất kỳ vị trí nào trong số 3 vị trí đều có thể cập nhật trạng thái cho một hàng nhất định trong bảng này, chúng sẽ được nhân rộng trong thời gian thực gần với 2 vị trí còn lại.Giải pháp cơ sở dữ liệu trong bộ nhớ với bản sao thời gian thực nhanh nhất

Có cơ sở dữ liệu trong bộ nhớ nguồn mở hoặc thương mại có trọng lượng nhẹ có thể giúp chúng tôi đạt được những gì chúng tôi đang cố gắng thực hiện hay không. Ổn định đĩa không quan trọng ở đây.

Trả lời

4

Kiểm tra Redis. Đây là số Replication Howto.

Ngoài ra, nếu bạn quyết định rằng DB hoàn toàn không cần phải ở trong bộ nhớ, nó chỉ cần được nhanh chóng, bạn có thể muốn xem xét CouchDB. Nó có thể làm sao chép liên tục, mà về bản chất là tức thời, và tất cả các nút đều là các bậc thầy. Nó có cơ chế phát hiện và giải quyết xung đột tốt. This blog post là một giới thiệu tuyệt vời về khả năng sao chép CouchDB mới nhất và lớn nhất.

+1

Ông có thể sử dụng CouchDB (hoặc MongoDB) trên hệ thống tệp trong bộ nhớ như tmpfs trên linux miễn là databae phù hợp với bộ nhớ ... – Filipe

1

Mặc dù không có hỗ trợ nhân rộng được tích hợp sẵn, bạn có thể sử dụng triggers với cơ sở dữ liệu trong bộ nhớ SQLite. Trong trình kích hoạt, hãy sử dụng custom function để truyền đạt các thay đổi cho các trang web khác.

1

Bạn có thể muốn xem Altibase. Họ nói rằng họ có cơ sở dữ liệu bộ nhớ trong nhanh nhất thế giới. Họ nói rằng họ nhanh gấp 5 đến 10 lần so với hầu hết các bộ nhớ trong DBMS và họ cũng có bản dùng thử miễn phí trên trang web.

0

Tôi thực thi một SQL phức tạp có hơn 6000 hàng 10000 lần trong Máy chủ Websphere của tôi. Tổng số lần thực hiện thuần là như thế:

  Derby (In Memory) Oracle(standard DB) SQLite (In Memory) HSQLDb (In Memory) 
      nano sec. second nano sec. second nano sec. second nano sec. second 
1. try 58000000 0,058 6149976000 6,1 1141988000 1,14 999403000 1,00 
2. try 78560000 0,078 5268477000 5,2 1182621000 1,18 1338705000 1,34 
3. try 58849000 0,058 5200898000 5,2 1133003000 1,13 2239527000 2,24 
4. try 60901000 0,06 5435216000 5,4 1205442000 1,21 1370711000 1,37 
5. try 58798000 0,058 6501929000 6,5 1186734000 1,19 1001800000 1,00 
6. try 62928000 0,062 5913053000 5,9 1224470000 1,22 1066736000 1,07 
7. try 71171000 0,071 5111207000 5,1 1200769000 1,20 1304524000 1,30 
8. try 66913000 0,066 5517989000 5,5 1173495000 1,17 1299230000 1,30 
9. try 58777000 0,058 7209555000 7,2 1179013000 1,18 1031795000 1,03 
10. try 75299000 0,075 5356514000 5,3 1182715000 1,18 1368461000 1,37 
average 65019600 0,064 5766481400 5,7 1181025000 1,18 1302089200 1,30 

Tôi rõ ràng là so sánh Derby, SQLite và HSQLDB. Oracle không phải là một db trong bộ nhớ. Nhưng tôi đặt nó là kết quả của bảng bởi vì để hiển thị sự khác biệt tốc độ giữa một db trong bộ nhớ và db bình thường.

PS: Trong kết quả SQLite và HSQLDB không ổn định. Vì vậy, tôi chọn 10 kết quả ổn định trong 100 lần thử. Đôi khi HSQLDB nhanh hơn SQLite. Tôi nghĩ rằng hiệu suất của họ là như nhau.

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