Khi nào nên sử dụng CouchDB trên MongoDB và ngược lại

Tôi bị mắc kẹt giữa hai cơ sở dữ liệu NoQuery này.

Trong dự án của tôi, tôi sẽ tạo một cơ sở dữ liệu trong cơ sở dữ liệu. Ví dụ, tôi cần một giải pháp để tạo các bảng động.

Vì vậy, người dùng có thể tạo các bảng với cột và hàng. Tôi nghĩ rằng MongoDB hoặc CouchDB sẽ tốt cho việc này, nhưng tôi không chắc chắn cái nào. Tôi cũng sẽ cần phân trang hiệu quả là tốt.

Trong số C, A & P (Tính nhất quán, Tính khả dụng & Dung sai phân vùng), cái nào quan trọng hơn với bạn? Tham khảo nhanh, Hướng dẫn trực quan về hệ thống NoQuery

• MongodB: Tính nhất quán và dung sai phân vùng
• CouchDB: Tính khả dụng và dung sai phân vùng

Một bài đăng trên blog, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j có các kịch bản ' Được sử dụng tốt nhất ' cho mỗi cơ sở dữ liệu NoQuery được so sánh . Trích dẫn liên kết,

• MongoDB: Nếu bạn cần truy vấn động. Nếu bạn muốn xác định chỉ mục, không phải chức năng ánh xạ / giảm. Nếu bạn cần hiệu suất tốt trên một DB lớn. Nếu bạn muốn CouchDB, nhưng dữ liệu của bạn thay đổi quá nhiều, hãy lấp đầy đĩa.
• CouchDB: Để tích lũy, thỉnh thoảng thay đổi dữ liệu, trên đó các truy vấn được xác định trước sẽ được chạy. Những nơi mà phiên bản là quan trọng.

Một so sánh gần đây (tháng 2 năm 2012) và toàn diện hơn bởi Riyad Kalla,

• MongoDB: CHỈ sao chép Master-Slave
• CouchDB: Bản sao chính chủ

Một bài đăng trên blog (tháng 10 năm 2011) bởi một người đã thử cả hai, A MongoDB Guy Tìm hiểu CouchDB đã nhận xét về việc phân trang của CouchDB không hữu ích.

Một điểm chuẩn ngày (tháng 6 năm 2009) của Kristina Jigorow ( một phần của nhóm đằng sau MongoDB ),

Tôi sẽ đến MongoDB.

Hy vọng nó giúp.

Các câu trả lời trên tất cả làm phức tạp câu chuyện.

1. Nếu bạn dự định có một thành phần di động hoặc cần người dùng máy tính để bàn hoạt động ngoại tuyến và sau đó đồng bộ hóa công việc của họ với máy chủ, bạn cần CouchDB.
2. Nếu mã của bạn sẽ chỉ chạy trên máy chủ thì hãy đi với MongoDB

Đó là nó. Trừ khi bạn cần khả năng sao chép (tuyệt vời) của CouchDB để thiết bị di động và máy tính để bàn, MongoDB có lợi thế về hiệu suất, cộng đồng và công cụ hiện tại.

Câu hỏi rất cũ nhưng nó nằm trên Google và tôi không thích câu trả lời tôi thấy nên đây là câu hỏi của riêng tôi.

Couchdb có nhiều thứ hơn là khả năng phát triển CouchApps. Hầu hết mọi người sử dụng CouchDb trong kiến ​​trúc web 3 tầng cổ điển.

Trong thực tế, yếu tố quyết định đối với hầu hết mọi người sẽ là việc MongoDb cho phép truy vấn đặc biệt với cú pháp giống như SQL trong khi CouchDb thì không (bạn phải tạo bản đồ / giảm chế độ xem khiến một số người tắt ngay cả khi tạo các chế độ xem này là thân thiện với Phát triển ứng dụng nhanh - chúng không liên quan gì đến các thủ tục được lưu trữ).

Để giải quyết các điểm nêu trong câu trả lời được chấp nhận: CouchDb có một hệ thống phiên bản tuyệt vời, nhưng điều đó không có nghĩa là nó chỉ phù hợp (hoặc phù hợp hơn) cho những nơi mà phiên bản là quan trọng. Ngoài ra, couchdb rất thân thiện với chữ viết nhờ vào tính chất bổ sung của nó (hoạt động ghi trở lại nhanh chóng trong khi vẫn đảm bảo rằng sẽ không có dữ liệu nào bị mất).

Một điều rất quan trọng không được ai nhắc đến là CouchDb dựa vào các chỉ số của cây b. Điều này có nghĩa là cho dù bạn có 1 "hàng" hay 20 tỷ, thời gian truy vấn sẽ luôn duy trì dưới 10ms. Đây là một công cụ thay đổi trò chơi làm cho CouchDb trở thành một cơ sở dữ liệu có độ trễ thấp và thân thiện với người đọc và điều này thực sự không nên bỏ qua.

Công bằng và toàn diện, lợi thế MongoDb có trên CouchDb là công cụ và tiếp thị. Họ có các công cụ công dân hạng nhất cho tất cả các ngôn ngữ và nền tảng chính giúp việc lên máy bay trở nên dễ dàng và điều này được thêm vào truy vấn adhoc của họ làm cho việc chuyển đổi từ SQL trở nên dễ dàng hơn.

CouchDb không có mức độ công cụ này - mặc dù ngày nay có rất nhiều thư viện - nhưng CouchDb được hiển thị dưới dạng API HTTP và do đó khá dễ dàng để tạo một trình bao bọc trong ngôn ngữ yêu thích của bạn để nói chuyện với nó. Cá nhân tôi thích cách tiếp cận này vì nó tránh phình to và cho phép bạn chỉ lấy những gì bạn muốn (nguyên tắc phân tách giao diện).

Vì vậy, tôi muốn nói sử dụng cái này hay cái kia phần lớn là vấn đề thoải mái và ưu tiên với mô hình của họ. Đối với một số người, cách tiếp cận CouchDb "chỉ phù hợp", nhưng nếu sau khi tìm hiểu về các tính năng cơ sở dữ liệu (trong hướng dẫn chính thức đầy đủ ), bạn không có khoảnh khắc "hell yeah", có lẽ bạn nên tiếp tục.

Tôi không khuyến khích sử dụng CouchDb nếu bạn chỉ muốn sử dụng "công cụ phù hợp cho công việc phù hợp". bởi vì bạn sẽ phát hiện ra rằng bạn không thể sử dụng nó theo cách đó và cuối cùng bạn sẽ nổi giận và viết các bài đăng trên blog như "Tham gia vào CouchDb ở đâu?" và "Quản lý giao dịch ở đâu?". Thật vậy, Couchdb là - nghịch lý - rất minh bạch nhưng đồng thời đòi hỏi một sự thay đổi mô hình và thay đổi cách bạn tiếp cận vấn đề để thực sự tỏa sáng (và thực sự hoạt động).

Nhưng một khi bạn đã làm điều đó thực sự có kết quả. Cá nhân tôi cần những lý do rất mạnh mẽ hoặc một người phá vỡ thỏa thuận lớn trong một dự án để chọn một cơ sở dữ liệu khác, nhưng cho đến nay tôi vẫn chưa gặp được.

Tự đặt câu hỏi này? Và bạn sẽ quyết định lựa chọn DB của bạn.

1. Bạn có cần chủ-chủ ? Rồi CouchDB. Chủ yếu là CouchDB hỗ trợ sao chép chính chủ, dự đoán các nút bị ngắt kết nối trong thời gian dài. MongoDB sẽ không làm tốt trong môi trường đó.
2. Bạn có cần thông lượng MAXIMUM R / W không? Rồi MongoDB
3. Bạn có cần độ bền của máy chủ đơn vì bạn sẽ chỉ có một máy chủ DB không? Rồi CouchDB.
4. Bạn đang lưu trữ một bộ dữ liệu MASSIVE cần shending trong khi duy trì thông lượng điên rồ? Rồi MongoDB.
5. Bạn có cần sự nhất quán mạnh mẽ của dữ liệu? Rồi MongoDB.
6. Bạn có cần sẵn sàng cao của cơ sở dữ liệu? Rồi CouchDB.
7. Bạn có hy vọng nhiều cơ sở dữ liệu và nhiều bảng / bộ sưu tập? Rồi MongoDB
8. Bạn có một người dùng ứng dụng di động ngoại tuyến và muốn đồng bộ hóa dữ liệu hoạt động của họ với máy chủ? Sau đó, bạn cần CouchDB.
9. Bạn có cần nhiều công cụ truy vấn không? Rồi MongoDB
10. Bạn có cần cộng đồng lớn để sử dụng DB không? Rồi MongoDB

Tôi tóm tắt các câu trả lời được tìm thấy trong bài viết đó:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the- nhược điểm-and-nhược điểm-of -each

MongoDB: Truy vấn tốt hơn, lưu trữ dữ liệu trong BSON (truy cập nhanh hơn), tính nhất quán dữ liệu tốt hơn, nhiều bộ sưu tập

CouchDB: Sao chép tốt hơn, với bản sao chính để làm chủ và giải quyết xung đột, lưu trữ dữ liệu trong JSON (có thể đọc được bằng con người, truy cập tốt hơn thông qua các dịch vụ REST), truy vấn thông qua giảm bản đồ.

Vì vậy, kết luận, MongoDB nhanh hơn, CouchDB an toàn hơn.

Ngoài ra: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

Hãy nhận biết một vấn đề với các chỉ mục duy nhất thưa thớt trong MongoDB. Tôi đã đánh nó và nó cực kỳ cồng kềnh để giải quyết.

Vấn đề là ở đây - bạn có một trường, là trường duy nhất nếu có và bạn muốn tìm tất cả các đối tượng mà trường không có. Cách các chỉ mục duy nhất thưa thớt được triển khai trong Mongo là các đối tượng thiếu trường đó hoàn toàn không có trong chỉ mục - chúng không thể được truy xuất bởi một truy vấn trên trường đó - {$exists: false}chỉ không hoạt động.

Cách giải quyết duy nhất tôi nghĩ ra là có một họ các giá trị null đặc biệt, trong đó một giá trị trống được dịch thành một tiền tố đặc biệt (như null :) được nối với một uuid. Đây là một vấn đề đau đầu thực sự, bởi vì người ta phải quan tâm đến việc chuyển đổi sang / từ các giá trị trống khi viết / quering / đọc. Một phiền toái lớn.

Tôi chưa bao giờ sử dụng thực thi javascript phía máy chủ trong MongoDB (dù sao nó cũng không được khuyên dùng) và bản đồ / giảm của chúng có hiệu suất khủng khiếp khi chỉ có một nút Mongo. Vì tất cả những lý do này mà tôi hiện đang xem xét để kiểm tra CouchDB, có lẽ nó phù hợp hơn với kịch bản cụ thể của tôi.

BTW, nếu bất cứ ai biết liên kết đến vấn đề Mongo tương ứng mô tả vấn đề chỉ số duy nhất thưa thớt - vui lòng chia sẻ.

Tôi chắc chắn rằng bạn có thể với Mongo (quen thuộc hơn với nó), và khá chắc chắn rằng bạn cũng có thể với chiếc ghế dài.

Cả hai đều được định hướng theo tài liệu (dựa trên JSON) vì vậy sẽ không có "cột" mà thay vào đó là các trường trong tài liệu - nhưng chúng có thể hoàn toàn động.

Cả hai đều làm điều đó bạn có thể muốn xem xét các yếu tố khác để sử dụng: các tính năng khác mà bạn quan tâm, mức độ phổ biến, v.v. Những hiểu biết của Google, các bài đăng công việc thực sự.com sẽ là cách để xem xét mức độ phổ biến.

Bạn có thể thử nó tôi nghĩ bạn sẽ có thể chạy mongo trong 5 phút.