Đừng để quy mô không gian (hơn 1000 thiết bị) đánh lừa bạn về quy mô tính toán và / hoặc quy mô lưu trữ. Một vài chục lần chèn 35 byte mỗi giây là một khối lượng công việc nhỏ đối với bất kỳ DBMS chính thống nào, ngay cả khi chạy trên phần cứng cấp thấp. Tương tự như vậy, 142 triệu bản ghi mỗi tháng chỉ theo thứ tự của 1 ~ 10 gigabyte dung lượng lưu trữ mỗi tháng, không có bất kỳ nén nào, bao gồm cả chỉ số.
Trong bình luận câu hỏi của bạn, bạn nói:
"Tất cả là về độ tin cậy, khả năng mở rộng và tốc độ. Điều rất quan trọng là giải pháp mở rộng quy mô dễ dàng (MongoDB autosharding?) Chỉ cần đưa vào nhiều nút hơn và tốc độ cũng rất quan trọng
Độ tin cậy? Bất kỳ DBMS chính thống nào cũng có thể đảm bảo điều này (giả sử ý bạn là nó sẽ không làm hỏng dữ liệu của bạn và nó sẽ không bị hỏng - hãy xem phần thảo luận của tôi về định lý CAP ở cuối câu trả lời này). Tốc độ? Ngay cả với một máy duy nhất, khối lượng công việc này gấp 10 ~ 100 lần không phải là vấn đề. Khả năng mở rộng? Với tốc độ hiện tại, dữ liệu của cả năm, không được nén, thậm chí được lập chỉ mục đầy đủ, sẽ dễ dàng nằm gọn trong 100 gigabyte dung lượng đĩa (tương tự như vậy, chúng tôi đã thiết lập tốc độ chèn không phải là vấn đề).
Do đó, tôi không thấy có nhu cầu rõ ràng nào về một giải pháp kỳ lạ như NoSQL, hoặc thậm chí là cơ sở dữ liệu phân tán - một cơ sở dữ liệu quan hệ đơn giản, cũ như MySQL sẽ ổn. Nếu bạn lo lắng về việc chuyển đổi dự phòng, chỉ cần thiết lập một máy chủ dự phòng trong cấu hình master-slave. Nếu chúng ta đang nói gấp 100 hoặc 1000 lần tỷ lệ hiện tại, chỉ cần phân vùng theo chiều ngang một vài trường hợp dựa trên ID của thiết bị thu thập dữ liệu ( tức là {phân vùng index} ={device id} modulo {số lượng phân vùng}).
Hãy nhớ rằng rời khỏi giới hạn an toàn và thoải mái của thế giới cơ sở dữ liệu quan hệ có nghĩa là từ bỏ cả mô hình đại diện của nó và bộ công cụ phong phú . Điều này sẽ làm cho việc "khai thác dữ liệu phức tạp" của bạn trở nên khó khăn hơn nhiều - bạn không chỉ cần đưa dữ liệu vào cơ sở dữ liệu mà còn phải lấy nó ra.
Tất cả những điều đó đang được nói, MongoDB và CouchDB rất đơn giản để triển khai và làm việc. Chúng cũng rất thú vị và sẽ khiến bạn trở nên hấp dẫn hơn đối với bất kỳ số lượng người nào (không chỉ là lập trình viên - giám đốc điều hành!).
Sự khôn ngoan chung là, trong số ba giải pháp NoSQL mà bạn đã đề xuất, thì Cassandra là giải pháp tốt nhất cho khối lượng chèn cao (tất nhiên, nói một cách tương đối, tôi không nghĩ rằng bạn có khối lượng chèn cao - điều này được thiết kế để sử dụng bởi Facebook ); điều này bị phản đối bởi khó làm việc hơn. Vì vậy, trừ khi bạn có một số yêu cầu kỳ lạ mà bạn không đề cập đến, tôi khuyên bạn nên không đề cập đến nó, cho trường hợp sử dụng của bạn.
Nếu bạn đang tích cực triển khai NoSQL, bạn có thể muốn xem xét định lý CAP. Điều này sẽ giúp bạn quyết định giữa MongoDB và CouchDB. Đây là một liên kết tốt:http://blog.nahurst.com/visual-guide-to-nosql-systems. Tất cả đều phụ thuộc vào ý bạn là "độ tin cậy": MongoDB giao dịch tính khả dụng để có tính nhất quán, trong khi CouchDB giao dịch tính nhất quán để có tính khả dụng . (Cassandra cho phép bạn tận dụng sự cân bằng này, trên mỗi truy vấn, bằng cách chỉ định số lượng máy chủ phải được ghi / đọc để ghi / đọc thành công; CẬP NHẬT:Bây giờ, CouchDB cũng vậy, với BigCouch! Rất thú vị ...)
Chúc bạn may mắn trong dự án của mình.
