Tôi nên chọn gì: MongoDB/Cassandra/Redis/CouchDB?

Question

Chúng tôi đang phát triển một dự án thực sự lớn và tôi đã tự hỏi nếu có ai có thể cho tôi một số lời khuyên về những gì DB phụ trợ chúng ta nên chọn.

Hệ thống của chúng tôi là hợp chất bởi 1100 thiết bị điện tử gửi tín hiệu đến máy chủ trung tâm và sau đó máy chủ lưu trữ thông tin tín hiệu (tín hiệu dài khoảng 35 byte). Làm thế nào bao giờ các thiết bị này sẽ được gửi khoảng 3 tín hiệu mỗi phút, vì vậy nếu chúng ta làm de số, đó sẽ là 4.752.000 hồ sơ mới/ngày trên cơ sở dữ liệu, và tổng cộng 142.560.000 hồ sơ mới/tháng.

Chúng tôi cần một DB Backend có ánh sáng nhanh và đáng tin cậy. Tất nhiên chúng ta cần làm một số khai phá dữ liệu phức tạp trên DB đó. Chúng tôi đang thực hiện một số nghiên cứu về MongoDB/Cassandra/Redis/CouchDB, tuy nhiên các trang web tài liệu vẫn đang ở giai đoạn đầu.

Bất kỳ trợ giúp nào? Ý tưởng?

Cảm ơn rất nhiều!

Answer 1

Tôi đã sử dụng MongoDB từ Incanter và đã thích nó. Mặc dù tôi không thể nói với tốc độ với các bộ dữ liệu lớn như vậy, Clojure (dựa trên Incanter) rất đáng tin cậy về mặt quản lý giao dịch. Incanter cũng cung cấp một số công cụ phân tích tuyệt vời, vì vậy nếu bạn đang lập kế hoạch phân tích tất cả dữ liệu đó, MongoDB + Incanter có thể là một sự kết hợp mạnh mẽ.

Answer 2

Vì vậy, bạn đang lưu trữ dữ liệu trong một db trung tâm cho datamining? Không xử lý giao dịch trực tuyến?

Tôi không nghĩ rằng MongoDB thực hiện tốt công việc khi nói đến độ bền. Xem http://nosql.mypopescu.com/post/392868405/mongodb-durability-a-tradeoff-to-be-aware-of.

Có thể bạn có thể sử dụng phân tích db Infobright, nó có phiên bản cộng đồng: http://www.infobright.org/?

Answer 3

Nếu bạn thích giao diện của Cassandra cho khả năng thiết kế-bắt đầu của nó để mở rộng theo chiều ngang, điều chỉnh tính nhất quán với tính khả dụng và như vậy, bạn cũng có thể xem Riak. nhưng một cách tiếp cận khác.

Answer 4

~ 3000 tín hiệu/phút = 50 lần viết/s mà bất kỳ hệ thống nào trong số này sẽ có thể xử lý dễ dàng.

Cassandra có thể sẽ hoạt động tốt nhất vì tập dữ liệu của bạn lớn hơn bộ nhớ, và tích hợp Hadoop sẽ giúp khai thác dữ liệu của bạn.

Answer 5

Bạn đang tìm kho dữ liệu có thể cho phép ghi "nhanh" (dữ liệu được lưu trên đĩa) và khai phá dữ liệu sẽ xảy ra ở giai đoạn sau (đây là chu kỳ READ). Ngoài ra, xem xét các con số bạn nêu, nó chỉ ra bạn sẽ thu thập tất cả 159MB thông tin mỗi ngày, hoặc khoảng 5GB mỗi tháng.

Trong trường hợp này, tại sao không xem xét Redis.

Bạn luôn có thể lưu trữ các tập tin dữ liệu Redis hàng ngày, và tham khảo nó sau này (nếu bạn có mối quan tâm của tải 5GB hoặc số tiền lớn của không gian RAM, sau đó bạn lưu trữ này có thể là một workaround)

Redis là khá nhanh chóng, dựa trên các số được xuất bản trên trang web đó. Hy vọng điều này sẽ hữu ích. Kiran

Answer 6

CouchDB rất đáng tin cậy, mang lại độ bền tuyệt vời và bạn sẽ phải chịu tải CPU rất thấp. Nó cũng là tuyệt vời tại sao chép giữa nhiều nút, hoặc theo yêu cầu hoặc liên tục.

Nhờ khả năng nhân rộng và RESTful API (nó sử dụng HTTP cho API của nó), bạn có thể mở rộng theo chiều ngang khá dễ dàng bằng các công cụ trưởng thành. (Nginx hoặc Apache để đảo ngược proxy, cân bằng tải HTTP, v.v.)

Bạn viết chức năng bản đồ/giảm trong JavaScript để truy vấn trước. Các kết quả được xây dựng tăng dần trên đĩa có nghĩa là chúng chỉ được neeed để được tính một lần cho mỗi tín hiệu. Nói cách khác, các truy vấn có thể rất nhanh bởi vì nó chỉ phải thực hiện các phép tính trên dữ liệu tín hiệu được ghi lại kể từ lần cuối cùng bạn chạy truy vấn.

CouchDB giao dịch không gian đĩa để thực hiện, vì vậy bạn có thể mong đợi sử dụng nhiều dung lượng đĩa. Truy vấn của bạn có thể cực nhanh và tiết kiệm dung lượng đĩa nếu bạn triển khai chúng đúng cách.

Give CouchDB a try.

Check-out Why Large Hadron Collider Scientists are Using CouchDB và CouchDB at the BBC as a fault tolerant, scalable, multi-data center key-value store

Answer 7

Đừng để quy mô không gian (1000 thiết bị) đánh lừa bạn như với quy mô tính toán và/hoặc lưu trữ. Một vài chục bít 35 byte mỗi giây là một khối lượng công việc tầm thường đối với bất kỳ DBMS chính thống nào, thậm chí 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ỉ dựa trên thứ tự 1 ~ 10 gigabyte dung lượng lưu trữ mỗi tháng mà không có bất kỳ nén nào, kể cả chỉ mục.

Trong bình luận câu hỏi của bạn, bạn nói:

"Đó là tất cả về độ tin cậy, khả năng mở rộng và tốc độ Nó rất quan trọng là các giải pháp quy mô một cách dễ dàng (MongoDB autosharding?) Chỉ ném vào nút hơn, và tốc độ. cũng rất quan trọng

Độ tin cậy là gì? Ngay cả với một máy đơn, 10 ~ 100 lần khối lượng công việc này không phải là một prob lem. Khả năng mở rộng? Với tốc độ hiện tại, dữ liệu cả năm, không nén, thậm chí được lập chỉ mục đầy đủ, sẽ dễ dàng phù hợp với 100 gigabyte không gian đĩa (tương tự như vậy, chúng tôi đã thiết lập tỷ lệ chèn không phải là vấn đề).

Như vậy, tôi không thấy rõ nhu cầu về giải pháp kỳ lạ như NoSQL, hoặc thậm chí một 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 đang lo lắng về chuyển đổi dự phòng, chỉ cần thiết lập một máy chủ sao lưu trong một cấu hình master-slave. Nếu chúng ta đang nói 100 hoặc 1000 lần tỷ lệ hiện tại, chỉ 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à {partition index} = {device id} modulo {number of partitions}) .

Gấu nhớ rằng bỏ sự hạn chế 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ả biểu hiện mô hình của nó và bộ công cụ phong phú của nó. Điều này sẽ làm cho "datamining phức tạp" của bạ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, bạn cũng cần phải lấy nó ra.

Tất cả những điều đó đượ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 hấp dẫn hơn với bất kỳ số 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 thông thường là, trong ba giải pháp NoSQL bạn đề xuất, Cassandra là tốt nhất cho khối lượng chèn cao (tất nhiên, tương đối nó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ế được sử dụng bởi Facebook); điều này được chống lại bằng cách làm việc khó khăn hơn. Vì vậy, trừ khi bạn có một số yêu cầu lạ bạn đã không đề cập đến, tôi sẽ khuyên bạn nên chống lại nó, cho trường hợp sử dụng của bạn.

Nếu bạn đang tích cực đặt vào 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 đi xuống với ý nghĩa của bạn về "độ tin cậy": MongoDB giao dịch sẵn có cho tính nhất quán, trong khi CouchDB giao dịch nhất quán cho tính khả dụng. (Cassandra cho phép bạn finesse này tradeoff, mỗi truy vấn, bằng cách xác định bao nhiêu máy chủ phải được viết/đọc cho một viết/đọc để thành công; UPDATE: Bây giờ, vì vậy có thể CouchDB, với BigCouch! Rất thú vị ...)

Tốt nhất của may mắn trong dự án của bạn.

Answer 8

Phần lớn câu trả lời phụ thuộc vào những gì bạn muốn làm với nó sau khi nó được thu thập. Lưu trữ rất nhiều dữ liệu rất dễ dàng: chỉ cần dumt nó vào các tập tin đăng nhập, không cần một cơ sở dữ liệu. Mặt khác, nếu bạn muốn thực hiện phân tích phức tạp và khai thác dữ liệu trên đó, thì cơ sở dữ liệu sẽ hữu ích.

Câu hỏi tiếp theo là loại phân tích bạn sẽ làm. Nó sẽ được thực hiện trên một tập con của dữ liệu có một thuộc tính cụ thể, chỉ giờ cuối cùng/ngày/tuần/tháng, liệu dữ liệu có được tổng hợp hay bằng cách nào đó được tính toán trước không? Nói cách khác: bạn có cần truy cập vào toàn bộ tập dữ liệu trong biểu mẫu được thu thập không? Bạn có thể lưu trữ dữ liệu khi nó quá cũ để trở nên thú vị không? Bạn có thể tổng hợp dữ liệu và thực hiện phân tích về tổng hợp không?

Theo kinh nghiệm của tôi khi làm việc với phân tích quảng cáo (thu thập hàng tỷ điểm dữ liệu về tổng hợp quảng cáo) là chìa khóa. Bạn thu thập dữ liệu thô, vệ sinh nó và sau đó đặt nó vào một cơ sở dữ liệu như MongoDB, Cassandra hoặc thậm chí MySQL cho phép bạn cập nhật và truy vấn. Sau đó, bạn định kỳ tổng hợp dữ liệu và loại bỏ nó khỏi cơ sở dữ liệu (nhưng lưu trữ dữ liệu thô, bạn có thể cần nó sau này).

Tổng hợp về cơ bản yêu cầu tất cả các câu hỏi mà bạn muốn hỏi về dữ liệu và lưu nó dưới dạng giúp dễ dàng truy xuất câu trả lời cho một câu hỏi cụ thể. Nói rằng bạn muốn biết ngày nào trong tuần có nhiều X. Việc thực hiện ngây thơ này sẽ là giữ cho tất cả các tín hiệu được ghi lại trong một bảng lớn và thực hiện một truy vấn tổng hợp tất cả các hàng có X. Là số lượng được thu thập tín hiệu phát triển truy vấn này sẽ mất nhiều thời gian hơn và lâu hơn. Không có số lượng lập chỉ mục, sharding hoặc tối ưu hóa sẽ giúp với điều này. Thay vào đó mỗi ngày/giờ/phút (tùy thuộc vào trường hợp sử dụng chính xác và cập nhật báo cáo của bạn), bạn nhìn vào các tín hiệu mới bạn đã ghi lại và cho mỗi X bạn tăng bộ đếm theo dõi số lượng X đã có vào thứ hai, nếu đó là một thứ hai, thứ ba nếu đó là một thứ ba và như vậy. Bằng cách đó bạn có thể sau này lấy số đếm cho mỗi ngày trong tuần và so sánh chúng. Bạn làm điều này cho tất cả các câu hỏi mà bạn muốn để có thể trả lời, và sau đó bạn loại bỏ các tín hiệu từ cơ sở dữ liệu (nhưng một lần nữa, giữ nguyên dữ liệu).

Loại cơ sở dữ liệu bạn ghi lại tập hợp có thể giống với loại bạn lưu trữ tín hiệu đến, nhưng không cần phải rất ưa thích. Nó sẽ lưu trữ các khóa đại diện cho một câu trả lời cụ thể và các giá trị thường chỉ là số.

Trong kho dữ liệu trường học cũ nói cơ sở dữ liệu bạn lưu trữ tín hiệu đến được gọi là OLTP (để xử lý giao dịch trực tuyến) và cơ sở dữ liệu bạn lưu trữ tập hợp trong được gọi là OLAP (cho xử lý phân tích trực tuyến).OLTP được tối ưu hóa để chèn và OLAP được tối ưu hóa cho truy vấn. Các điều khoản là cũ và khi mọi người nghe họ họ có xu hướng ngay lập tức nghĩ rằng SQL và starchemas và tất cả những điều đó. Có lẽ tôi không nên sử dụng chúng, nhưng chúng là những thuật ngữ thuận tiện.

Dù sao, đối với OLTP bạn muốn có thứ gì đó nhanh chóng chèn dữ liệu, nhưng cũng có thứ gì đó hỗ trợ lập chỉ mục dữ liệu và tìm kiếm mọi thứ. Việc tập hợp được giúp đỡ rất nhiều bởi một cơ sở dữ liệu mà làm một nửa công việc của tổng hợp và tìm tối đa và tối thiểu. Tôi thực sự thích MongoDB bởi vì nó rất dễ dàng để thiết lập và làm việc với. Dữ liệu tôi làm việc với xu hướng lộn xộn và không phải tất cả các mục đều có cùng một tập hợp các thuộc tính, do đó, sự tha thứ tha thứ của Mongo là một lợi ích. Mặt khác, dữ liệu của bạn có vẻ đồng nhất hơn nhiều, vì vậy Mongo có lẽ sẽ không mang lại cho bạn nhiều lợi ích. Tuy nhiên, đừng bỏ qua cơ sở dữ liệu quan hệ cũ tốt. Nếu bạn định thực hiện rất nhiều tính năng tổng hợp, v.v. thì SQL rất tuyệt, đó là những gì nó được xây dựng.

Đối với OLAP một cái gì đó đơn giản hơn nhiều công trình, một cửa hàng giá trị quan trọng là tất cả những gì bạn cần. Tôi sử dụng Redis vì nó cũng rất dễ làm việc và thiết lập. Nó cũng cho phép bạn lưu trữ nhiều hơn các giá trị vô hướng, thuận tiện. Đôi khi giá trị của bạn thực sự là một danh sách, hoặc một băm, trong hầu hết các cửa hàng giá trị khóa, bạn phải mã hóa các giá trị như vậy, nhưng Redis xử lý nó một cách tự nhiên. Nhược điểm của Redis là bạn không thể thực hiện các truy vấn ("như cung cấp cho tôi tất cả các hàng có giá trị này cho Y"), bạn phải tự mình lưu giữ các chỉ mục vào dữ liệu của mình. Mặt khác, bạn sẽ không cần chỉ số rất nhiều vì câu trả lời cho tất cả các câu hỏi của bạn đã được precomputed, tất cả những gì bạn cần làm là tìm kiếm câu trả lời bằng một khóa được xác định bởi câu hỏi. Đối với câu hỏi ở trên, ngày nào trong tuần có nhiều nhất X, bạn tra cứu số lượng công việc X vào thứ hai, thứ ba, v.v. có lẽ bạn đã lưu trữ chúng như X: thứ hai, X: thứ ba, v.v.

Trong kết luận: MongoDB và Redis hoạt động rất tốt cho tôi. Tôi không nghĩ MongoDB rất tốt cho trường hợp sử dụng của bạn, thay vào đó tôi nghĩ bạn thực sự có thể hưởng lợi nhiều hơn từ cơ sở dữ liệu SQL truyền thống (nhưng nó phụ thuộc, nếu dữ liệu của bạn thực sự đơn giản, bạn có thể sử dụng Redis). Điều quan trọng nhất là không mắc sai lầm khi nghĩ rằng bạn cần có dữ liệu trong một cơ sở dữ liệu và giữ nó mãi mãi. Tổng hợp và vứt bỏ dữ liệu cũ là chìa khóa.