Nó thực sự phụ thuộc vào tập hợp dữ liệu của bạn. Quy tắc số một cho thiết kế NoSQL là xác định kịch bản truy vấn của bạn trước tiên. Một khi bạn thực sự hiểu cách bạn muốn truy vấn dữ liệu thì bạn có thể xem xét các giải pháp NoSQL khác nhau. Đơn vị phân phối mặc định là khóa. Vì vậy, bạn cần phải nhớ rằng bạn cần có khả năng tách dữ liệu giữa các nút của bạn một cách hiệu quả nếu không bạn sẽ kết thúc với một hệ thống có thể mở rộng theo chiều ngang với tất cả công việc vẫn đang được thực hiện trên một nút (mặc dù các truy vấn tốt hơn tùy thuộc vào từng trường hợp).
Bạn cũng cần suy nghĩ lại về định lý CAP, hầu hết các cơ sở dữ liệu NoSQL đều nhất quán (CP hoặc AP) trong khi DBMS quan hệ truyền thống là CA. Điều này sẽ tác động đến cách bạn xử lý dữ liệu và tạo ra một số thứ nhất định, ví dụ thế hệ khóa có thể trở nên phức tạp.
Cũng nên nhớ hơn một số hệ thống như HBase không có khái niệm lập chỉ mục. Tất cả các chỉ mục của bạn sẽ cần phải được xây dựng bởi logic ứng dụng của bạn và mọi bản cập nhật và các lần xóa sẽ cần được quản lý như vậy. Với Mongo bạn thực sự có thể tạo các chỉ mục trên các trường và truy vấn chúng một cách tương đối nhanh chóng, cũng có khả năng tích hợp Solr với Mongo. Bạn không chỉ cần truy vấn bằng ID trong Mongo như bạn làm trong HBase, đó là một họ cột (còn gọi là cơ sở dữ liệu kiểu Google BigTable), nơi bạn về cơ bản có cặp khóa-giá trị lồng nhau.
Vì vậy, một lần nữa, dữ liệu của bạn, thứ bạn muốn lưu trữ, cách bạn dự định lưu trữ và quan trọng nhất là cách bạn muốn truy cập dữ liệu đó. Dự án Lily trông rất hứa hẹn. Công việc tôi tham gia với chúng tôi lấy một lượng lớn dữ liệu từ web và lưu trữ, phân tích, phân tích, phân tích, phân tích, truyền, cập nhật, v.v. Chúng tôi không chỉ sử dụng một hệ thống mà nhiều phù hợp nhất với công việc trong tầm tay. Đối với quy trình này, chúng tôi sử dụng các hệ thống khác nhau ở các giai đoạn khác nhau vì nó cho phép chúng tôi truy cập nhanh nơi chúng tôi cần, cung cấp khả năng truyền và phân tích dữ liệu theo thời gian thực và quan trọng, theo dõi mọi thứ khi chúng tôi đi (như mất dữ liệu trong sản phẩm hệ thống là một việc lớn). Tôi đang sử dụng Hadoop, HBase, Hive, MongoDB, Solr, MySQL và thậm chí cả các tệp văn bản cũ tốt. Hãy nhớ rằng để sản xuất một hệ thống bằng cách sử dụng các kỹ thuật này là một chút khó khăn hơn so với cài đặt MySQL trên một máy chủ, một số bản phát hành không ổn định và bạn thực sự cần phải làm thử nghiệm của bạn đầu tiên. Vào cuối ngày, nó thực sự phụ thuộc vào mức độ kháng cự kinh doanh và bản chất nhiệm vụ quan trọng của hệ thống của bạn.
Một đường dẫn khác mà không ai đề cập đến là NewSQL - có nghĩa là RDBMS có thể mở rộng theo chiều ngang ... Có một vài ví dụ như cụm MySQL (tôi nghĩ) và VoltDB có thể phù hợp với nguyên nhân của bạn.
Một lần nữa nói đến việc hiểu dữ liệu của bạn và các mẫu truy cập, các hệ thống NoSQL cũng không phải là không quan hệ và có phù hợp hơn với các tập dữ liệu phi quan hệ. Nếu dữ liệu của bạn vốn có quan hệ và bạn cần một số tính năng truy vấn SQL thực sự cần làm những thứ như sản phẩm Cartesian (hay còn gọi là join) thì bạn có thể tốt hơn khi gắn bó với Oracle và đầu tư một thời gian vào việc lập chỉ mục, sharding và hiệu chỉnh.
Lời khuyên của tôi sẽ thực sự phát xung quanh với một vài hệ thống khác nhau.Tuy nhiên đối với trường hợp sử dụng của bạn, tôi nghĩ rằng một cơ sở dữ liệu Column Family có thể là giải pháp tốt nhất, tôi nghĩ có một vài nơi đã thực hiện các giải pháp tương tự cho các vấn đề tương tự (tôi nghĩ NYTimes đang sử dụng HBase để theo dõi số lần nhấp chuột của người dùng). Một ví dụ tuyệt vời khác là Facebook và thích, họ đang sử dụng HBase cho việc này. Có một bài viết thực sự tốt ở đây có thể giúp bạn trên con đường của bạn và giải thích thêm một số điểm ở trên. http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html
Điểm cuối cùng là hệ thống NoSQL không phải là tất cả và kết thúc tất cả. Đưa dữ liệu của bạn vào cơ sở dữ liệu NoSQL không có nghĩa là nó sẽ hoạt động tốt hơn MySQL, Oracle hoặc thậm chí là tệp văn bản ... Ví dụ: xem bài đăng trên blog này: http://mysqldba.blogspot.com/2010/03/cassandra-is-my-nosql-solution-but.html
Tôi có thể xem;
MongoDB - Tài liệu - CP
CouchDB - Tài liệu - AP
Redis - Trong ký ức quan trọng có giá trị (gia đình không cột) - CP
Cassandra - Cột gia đình - Có sẵn & Dung sai phân vùng (AP)
HBase - Cột Family - Phù hợp & phân vùng chịu (CP)
Hadoop/Hive - Cũng có một cái nhìn tại Hadoop trực tuyến ...
Hypertable - Một CF CP DB.
VoltDB - Một sản phẩm thực sự đẹp, cơ sở dữ liệu quan hệ được phân phối và có thể hoạt động cho trường hợp của bạn (có thể là một động thái dễ dàng hơn). Họ cũng dường như cung cấp hỗ trợ doanh nghiệp mà có thể phù hợp hơn cho một env sản (ví dụ: cung cấp cho người dùng doanh nghiệp một cảm giác an toàn).
Bất kỳ cách nào là 2c của tôi. Chơi xung quanh với các hệ thống thực sự là cách duy nhất bạn sẽ tìm hiểu những gì thực sự làm việc cho trường hợp của bạn.
Dữ liệu của bạn trông như thế nào? – NightWolf
1.) Có hàng trăm bản ghi cho mỗi người dùng hay không, mỗi người dùng chỉ có một số rất ít? 2.) Hầu hết các truy vấn có chứa điều kiện user_id không? 3.) Có phải số liệu thống kê trên toàn bộ tập dữ liệu thời gian quan trọng không? (Có lẽ không có gì người dùng được xem) 4.) Bạn có cần tập hợp kết quả được sắp xếp (ví dụ: theo thứ tự bảng chữ cái theo quốc gia) không? Dù bằng cách nào, bạn nên cung cấp cho [ArangoDB v2.6] sắp tới (http://arangodb.org/) một thử! – CoDEmanX