Tôi có kinh nghiệm với Redis và MongoDB, nhưng tôi không khuyên bạn nên sử dụng chúng cho trường hợp sử dụng của bạn. Redis tuyệt vời ở mọi khía cạnh, nhưng vì nó chỉ có RAM và không có tính năng phân cụm (chúng đang được phát triển) nên nó không mở rộng quy mô tốt lắm. MongoDB Tôi sẽ không bao giờ sử dụng lại cho bất cứ thứ gì cần bất cứ thứ gì ngoại trừ một bộ bản sao nhỏ.
Về cơ bản, MongoDB chưa trưởng thành và hoàn toàn không phù hợp với bất kỳ loại yêu cầu hiệu suất cao, âm lượng lớn nào. Nó có một khóa ghi toàn cầu được giữ trong quá trình xả đĩa, có nghĩa là hiệu suất có thể khác nhau tùy thuộc vào những gì bạn làm. Trên thực tế, việc cập nhật tài liệu không thể thực hiện được và bạn cũng cần phải hết sức cẩn thận với việc xóa. Nói về xóa, chúng phân mảnh cơ sở dữ liệu một cách nghiêm trọng, vì vậy nếu bạn xóa nhiều lần, hiệu suất của bạn sẽ bị ảnh hưởng.
Sharding trong 1.8.0 đến 1.8.1 là một thảm họa. Có những lỗi hoàn chỉnh về nút chặn chương trình mà lẽ ra không bao giờ có thể đưa nó vào một bản phát hành ổn định. Cấu hình không được xóa đúng cách và rất dễ khiến cơ sở dữ liệu của bạn ở trạng thái xấu để các phần không bao giờ di chuyển khỏi phân đoạn chính. 1.8.2 giải quyết hầu hết chúng và có vẻ ổn định hơn, nhưng tôi không tin tưởng một chút vào việc triển khai sharding. Thêm vào đó, việc làm sắc nét rất khó ngay cả khi mọi thứ hoạt động, không phải lúc nào cũng dễ dàng chọn một phím phân đoạn tự nhiên và nếu bạn không làm sắc nét sẽ khiến bạn rất buồn.
MongoDB thực sự dễ làm việc và bộ tính năng thực sự tuyệt vời. Tài liệu, trình điều khiển và cộng đồng đều tuyệt vời. MongoDB hoạt động hiệu quả như một sự thay thế cho MySQL, nhưng không sử dụng nó cho bất kỳ thứ gì cần mở rộng quy mô.
Chúng tôi hiện đang xem xét việc chuyển đến Cassandra. Tôi thấy mô hình Dyo (ví dụ:không có nút chính; viết và đọc ở bất kỳ đâu; chỉ cần thêm các nút để phát triển cụm) hấp dẫn và các tính năng ít nhiều phù hợp với chúng tôi. Mô hình dữ liệu là lược đồ ít giống như MongoDB, mặc dù hạn chế hơn một chút (về cơ bản, bạn có thể chọn giữa một hoặc hai mức băm). Tôi chắc rằng cộng đồng sẽ tốt khi bạn tham gia vào nó, nhưng cho đến nay tôi thấy khó tìm được thông tin tốt về cách giải quyết các vấn đề chung và tài liệu còn thiếu. Hầu hết thông tin bạn tìm thấy trên blog đều đã có từ một năm trước và rất nhiều thứ đã xảy ra kể từ đó (0,7 và 0,8 dường như là những cập nhật thực sự quan trọng cả hai, nhưng hầu hết những thứ bạn tìm thấy là khoảng 0,6). Các trình điều khiển cũng không thuần thục hoặc được ghi chép đầy đủ, từ những gì tôi đã thấy cho đến nay và mọi người dường như đang tranh cãi về việc liệu Thrift, Avro hay CQL là thứ nên được sử dụng (và điều đó đã thay đổi từ 0,6 thành 0,7 thành 0,8) .
Riak rất thú vị, vì những lý do tương tự như Cassandra, nhưng đối với chúng tôi, một kho khóa-giá trị thuần túy là không đủ, chúng tôi cần có thể cập nhật mà không cần đọc trước. Với Riak, điều này là không thể vì các giá trị chỉ là các đốm màu. Điều này có vẻ như nó không phải là một vấn đề đối với bạn.
HBase là một đối thủ khác. Có vẻ như khó thiết lập và chạy vì nhiều phần khác nhau, ZooKeeper, HDFS, v.v. Nhưng mô hình dữ liệu tương tự như Cassandra (cột, tức là băm một cấp), hoạt động tốt cho chúng tôi, nhưng có thể không quan trọng đối với bạn. Nó có vẻ đã được thử và đúng, nhưng như với MongoDB, bạn phải đề phòng các vấn đề về sharding, bạn phải suy nghĩ kỹ về các phím của mình nếu không bạn sẽ gặp rắc rối.
Ngoài ra còn có CouchDB, Project Voldemort và vô số sự lựa chọn khả thi khác. Tôi nghĩ rằng nếu bạn thực sự nghiêm túc về "khối lượng dữ liệu cực lớn" thì đó là giữa Cassandra, Riak và HBase. Đánh Riak nếu không đủ bộ nhớ khóa-giá trị thuần túy. Tùy thuộc vào ý của bạn khi nói "sao chép hoàn toàn nhất quán" thì Cassandra và Riak sẽ ra ngoài, bởi vì có khả năng (không nhất thiết phải lớn và có thể điều chỉnh được) đọc một giá trị cũ.
Cuối cùng, bạn rõ ràng phải thử nó trong trường hợp sử dụng cụ thể của mình, vì vậy tất cả những gì bạn thực sự nên rút ra từ câu trả lời này là:đừng bận tâm với MongoDB.
