MongoDB hoặc CouchDB - phù hợp cho sản xuất? [đóng cửa]

Tôi đã tự hỏi liệu có ai có thể cho tôi biết MongoDB hoặc CouchDB đã sẵn sàng cho môi trường sản xuất hay không .

Bây giờ tôi đang xem các giải pháp lưu trữ này (hiện tại tôi đang ủng hộ MongoDB), tuy nhiên các dự án này còn khá trẻ và vì vậy tôi dự đoán rằng tôi sẽ phải làm việc khá chăm chỉ để thuyết phục người quản lý của mình rằng chúng ta nên áp dụng điều này công nghệ mới.

Điều tôi muốn biết là:

1. Ai đang sử dụng MongoDB hoặc CouchDB ngày hôm nay trong môi trường sản xuất?

2. Bạn đang sử dụng MongoDB / CouchDB như thế nào?

3. Bạn đã gặp phải vấn đề gì (nếu có) khi bạn áp dụng cơ chế lưu trữ mới này (và bạn đã khắc phục chúng như thế nào)?

4. Làm thế nào bạn đối phó với bất kỳ vấn đề di chuyển mà bạn phải giải quyết?

5. Bạn có bất kỳ kinh nghiệm tốt / xấu với một trong những giải pháp mà bạn muốn chia sẻ không?

Tôi là CTO của 10gen (nhà phát triển MongoDB) nên tôi hơi thiên vị, nhưng tôi cũng quản lý một vài trang web đang sử dụng MongoDB trong sản xuất.

businessinsider đã sử dụng mongo trong sản xuất hơn một năm nay. Họ đang sử dụng nó cho tất cả mọi thứ từ người dùng và bài đăng trên blog, cho đến mọi hình ảnh trên trang web.

shopwiki đang sử dụng nó cho một số thứ bao gồm phân tích thời gian thực và lớp lưu trữ. Họ đang thực hiện hơn 1000 lần ghi mỗi giây vào một cơ sở dữ liệu khá lớn.

Nếu bạn truy cập trang Triển khai Sản xuất mongodb, bạn sẽ thấy một số người đang sử dụng mongo trong sản xuất.

Nếu bạn có bất kỳ câu hỏi nào về quy mô hoặc phạm vi triển khai sản xuất, hãy đăng lên danh sách người dùng của chúng tôi và chúng tôi sẽ rất vui lòng được giúp đỡ.

các BBC và meebo.com sử dụng CouchDB trong sản xuất và do đó, một trong những khách hàng của tôi. Dưới đây là danh sách những người khác sử dụng Couch: CouchDB ngoài tự nhiên

Thách thức lớn là biết cách tổ chức các tài liệu của bạn và ngừng suy nghĩ về mặt dữ liệu quan hệ.

SourceForge sử dụng MongoDB. Xem bản trình bày này hoặc đọc ở đây .

Chúng tôi đang chạy CouchDB như một công cụ thay thế cho MySQL cho các cửa hàng của chúng tôi (70.0000 mặt hàng / cửa hàng, tổng cộng 4 triệu thuộc tính của tất cả các mặt hàng, kết nối chéo giữa các mặt hàng).

Mục tiêu của chúng tôi là:

1. Dễ dàng sao chép từ một master-db sang một số máy khách với các tài liệu khác nhau.

2. Dữ liệu được tính toán trước nhanh như "tôi có bao nhiêu phần với thuộc tính này và bộ lọc đó, phù hợp với các điều kiện đó"

sự thật:

1. Các cửa hàng của chúng tôi hiện đang chạy nhanh hơn nhiều so với MySQL (và cơ sở dữ liệu mysql cần thêm 1-3 ngày tính toán trước (vì vậy việc cập nhật là hai lần một tháng), giúp dữ liệu sẵn sàng để đếm và lọc sản phẩm, CouchDB cần 5 giờ, vì vậy chúng tôi có thể cập nhật dữ liệu sản phẩm mỗi đêm)
2. Thiết lập phân phối và sao lưu dữ liệu (được lọc) cho các nút của cửa hàng rất nhanh chóng và dễ dàng

nhưng cũng:

1. Hiểu bản đồ / giảm và giới hạn của việc không tham gia là khá khó
2. Không có thao tác trên dữ liệu như "xóa ở đâu" hoặc "cập nhật ở đâu" mà không có các chương trình bên ngoài
3. Nhân rộng hoạt động tốt, trừ khi có vấn đề; sau đó thật khó để tìm ra lý do (đối với người mới bắt đầu)
4. Việc cài đặt CouchDB không có nhị phân (vâng, có một số trong tự nhiên, nhưng không phải cho mọi hệ điều hành / phiên bản) có thể khó khăn, nếu bạn không phải là người đam mê Linux. Nhưng Cộng đồng CouchDB rất hữu ích (#couchdb) và may mắn thay, có những công ty ngoài kia (đám mây, không linh hoạt) cung cấp dịch vụ từ miễn phí đến doanh nghiệp lớn.
5. CouchDB đang tiến lên phía trước, do đó, có rất nhiều thay đổi (cải tiến) đang diễn ra có thể thay đổi cách họ làm việc. Nhưng những điều cơ bản vẫn ổn định.

Kết quả là: MySQL là cơ sở dữ liệu để tạo và duy trì dữ liệu là đáng tin cậy và dễ hiểu và dễ xử lý. Tôi nghĩ rằng chúng tôi sẽ không thay đổi điều này. Nhưng tôi cũng không muốn bỏ lỡ sức mạnh của các khung nhìn CouchDB và dễ dàng thiết lập sao chép.

Việc sản xuất ghế đôi khi gây ra sự cố sau nhiều tháng làm việc do cấu hình sai và logrotate bị lãng quên (chế độ xem quá lâu hoặc bị treo, dừng sao chép), nhưng không bao giờ bị mất dữ liệu và luôn có thể dễ dàng đặt lại.

Tôi đang sử dụng CouchDB trong sản xuất. Hiện tại, nó lưu trữ tất cả các trường 'tùy chọn' không có trong lược đồ DB gốc. Và bây giờ tôi đang nghĩ về việc chuyển tất cả dữ liệu sang CouchDB.

Đó là một bước khá mạo hiểm, tôi thừa nhận. Thứ nhất, vì nó chưa phải là v1.0. Và thứ hai, bởi vì nó đang đói. Theo tính toán của tôi, tệp CouchDB (có chỉ mục) lớn hơn ~ 30 lần so với cơ sở dữ liệu MySQL có cùng hàng. Nhưng tôi khá chắc chắn rằng nó sẽ hoạt động tốt.

CouchDB 0.11 (phát hành vào cuối tháng 3) là phiên bản đóng băng tính năng cho 1.0. Điều này có nghĩa là chúng tôi sẽ duy trì khả năng tương thích với API hiện tại cho 1.0, vì vậy bây giờ là thời điểm tốt để xem xét lại CouchDB nếu bạn không có thời gian.

Bản phát hành mã nguồn CouchDB 0.11 có sẵn ở đây.Có trình cài đặt nhị phân và các tính năng khác được liên kết ở đây.

Tôi không biết gì về MongoDB, nhưng từ Câu hỏi thường gặp về CouchDB :

CouchDB đã sẵn sàng để sản xuất chưa?

Có, xem InTheWild để biết danh sách một phần các dự án sử dụng CouchDB. Một tổng quan tốt khác là Nghiên cứu Điển hình của CouchDB

Ngoài ra, một số liên kết:

• Re: Trạng thái CouchDB hiện tại?
• SimpleDB, CouchDB và các kho dữ liệu "MỚI" khác - Phản hồi

Chúng tôi sử dụng couchdb trong sản xuất và kể từ trước khi dự án đi theo chiếc ô Apache.

Chúng tôi sử dụng nó để lưu trữ mọi thứ mà chúng tôi có thể sử dụng dbms, cộng với tất cả các loại dữ liệu phi cấu trúc. Cá nhân, tôi thực sự thích cách bạn có thể ném tất cả các loại dữ liệu vào đó và sử dụng các chế độ xem để loại bỏ những gì bạn không cần tùy thuộc vào tình huống.

Phần khó nhất là di chuyển ra khỏi suy nghĩ dbms. Chúng tôi đã viết các tiện ích di chuyển của riêng mình khi định dạng lưu trữ thay đổi để an toàn, vì vậy đó không thực sự là vấn đề.

Chúng tôi chưa có bất kỳ trải nghiệm tiêu cực nào, nhưng một lần nữa chúng tôi đã không thiết lập dưới bất kỳ loại tải trọng lớn nào. Tôi nghĩ mọi thứ sẽ hoạt động khá tốt vì chúng tôi có hai máy chủ loại nô lệ sao chép từ một máy chủ chính duy nhất có tất cả các ghi. Tôi khá chắc chắn rằng chúng ta không phải làm theo cách đó để sao chép hoạt động chính xác, nhưng đó là cách chúng ta thiết lập nó ngay từ đầu và nó bị kẹt.

Chúng tôi sử dụng CouchDB để lưu trữ các tin nhắn trong và ngoài nước di động và để báo cáo về lưu lượng truy cập này thông qua một số chế độ xem tùy chỉnh mà tôi đã viết. Mặt trước được viết bằng Python. Chúng tôi không có bất kỳ vấn đề kỹ thuật thực sự nào và nó đã hoạt động từ cuối tháng 12. Rào cản duy nhất tôi gặp phải ban đầu là suy nghĩ về MapReduce, nhưng một khi tôi học được cách làm điều đó, mọi thứ khác đều diễn ra suôn sẻ.

Chúng tôi hiện đang sử dụng MongoDB trong sản xuất làm lớp lưu trữ cũng như công cụ lưu trữ để nhập sản phẩm và thao tác dữ liệu sản phẩm. Chúng tôi là một công ty thương mại điện tử quản lý hơn hai triệu sản phẩm (hơn 100 triệu thuộc tính), trải rộng trên 10 nhà phân phối và không có MongoDB, nhiệm vụ này sẽ gần như không thể.

Chúng tôi hiện đang sử dụng mongodb làm dịch vụ lưu trữ tệp cho sự hợp tác của chúng tôi qua mạng LAN. Ngoài ra, các dự án như trello đang sử dụng mongodb làm kho dữ liệu phụ trợ của họ. Tôi đã sử dụng couchdb trước đó, nhưng không có năng lực sản xuất.

Chúng tôi đang sử dụng MongoDB trong sản xuất trong dịch vụ phụ trợ di động của chúng tôi, cụ thể là Netmera. Chúng tôi đang sử dụng nó để lưu trữ tất cả dữ liệu người dùng và nội dung.

Tôi đã sử dụng CouchDB trong sản xuất gần 2 năm nay. Không có công việc di chuyển nào khi dự án bắt đầu trực tiếp với việc triển khai CouchDB. Nó phục vụ như một cơ sở dữ liệu lưu trữ dữ liệu của một sản phẩm điện tử từ đầu đến khi đóng gói.

Vì chúng tôi đang bán cảm biến với yêu cầu về độ chính xác cao, chúng tôi đã thử nghiệm rất nhiều ở các giai đoạn khác nhau và tất cả những thứ này sẽ được lưu trữ vào một tài liệu trên CouchDB.

Có một số đường cong học tập mà tôi học được từ kinh nghiệm của mình, đó là tận dụng triệt để các khung nhìn (hay còn gọi là các khung nhìn vĩnh viễn). Lượt xem phải là "bộ lọc nhỏ" của một phần Cơ sở dữ liệu sẽ được gọi thường xuyên.

Cơ sở dữ liệu CouchDB của tôi không điên rồ như các công ty khổng lồ khác. Nhưng cho đến nay, tôi vẫn làm tốt. Hiện tại tôi đang có 24000 tài liệu với 700MB.

Tính năng từ CouchDB mà tôi thích là 'sao chép', 'lưu trữ các bản sửa đổi của tài liệu'.

Tôi đã đọc rất nhiều đánh giá tốt trên MongoDB và tôi sẽ muốn dùng thử nếu có cơ hội.

Chúng tôi đang sử dụng mongodb trong sản xuất cho

www.beachfront.io - gần 5k yêu cầu ghi mỗi giây www.beachfrontbuilder.com - 500 yêu cầu đọc / ghi mỗi giây, duy trì 10m dữ liệu người dùng & olap.

Thách thức duy nhất phải đối mặt xung quanh việc lưu trữ dữ liệu, chúng tôi vượt qua bằng cách triển khai thành phần tùy chỉnh của mình.

Câu hỏi này đã được chấp nhận câu trả lời nhưng bây giờ một ngày nữa NoQuery DB đang có xu hướng cho nhiều tính năng tuyệt vời của nó. Nó là Couchbase; chạy như CouchbaseLitetrên nền tảng di động vàCouchbase Server về phía máy chủ của bạn.

Dưới đây là một số tính năng chính của Couchbase Lite.

Couchbase Lite là một công cụ cơ sở dữ liệu có thể đồng bộ hóa, định hướng tài liệu (NoQuery) nhẹ, phù hợp để nhúng vào các ứng dụng di động.

Phương tiện nhẹ:

Công cụ cơ sở dữ liệu nhúng là một thư viện được liên kết vào ứng dụng, không phải là một quy trình máy chủ riêng biệt. Kích thước mã nhỏ rất quan trọng đối với các ứng dụng di động, thường được tải xuống qua các mạng di động. Thời gian khởi động nhanh rất quan trọng vì các thiết bị di động có CPU tương đối chậm. Sử dụng bộ nhớ thấp Các bộ dữ liệu di động điển hình tương đối nhỏ, nhưng một số tài liệu có thể có tệp đính kèm đa phương tiện lớn. Tất nhiên, con số chính xác của con số phụ thuộc vào dữ liệu và ứng dụng của bạn.

Phương tiện định hướng tài liệu:

Lưu trữ các bản ghi ở định dạng JSON linh hoạt thay vì yêu cầu các lược đồ hoặc chuẩn hóa được xác định trước. Tài liệu có thể có tệp đính kèm nhị phân có kích thước tùy ý, chẳng hạn như nội dung đa phương tiện. Định dạng dữ liệu ứng dụng có thể phát triển theo thời gian mà không cần phải di chuyển rõ ràng. Lập chỉ mục MapReduce cung cấp tra cứu nhanh mà không cần sử dụng ngôn ngữ truy vấn đặc biệt.

Có thể đồng bộ hóa có nghĩa là:

Bất kỳ hai bản sao của cơ sở dữ liệu đều có thể được đưa vào đồng bộ thông qua thuật toán sao chép hiệu quả, đáng tin cậy, đã được chứng minh. Đồng bộ hóa có thể theo yêu cầu hoặc liên tục (với độ trễ vài giây). Các thiết bị có thể đồng bộ hóa với một tập hợp con của một cơ sở dữ liệu lớn trên một máy chủ từ xa. Công cụ đồng bộ hỗ trợ các kết nối mạng không liên tục và không đáng tin cậy. Xung đột có thể được phát hiện và giải quyết, với logic ứng dụng có toàn quyền kiểm soát việc hợp nhất. Cây sửa đổi cho phép các cấu trúc liên kết sao chép phức tạp, bao gồm máy chủ-máy chủ (đối với nhiều trung tâm dữ liệu) và ngang hàng, không mất dữ liệu hoặc xung đột sai. Couchbase Lite cung cấp API gốc để phát triển iOS (Objective-C) và Android (Java) liền mạch. Ngoài ra, nó bao gồm Plug-in Couchbase Lite cho PhoneGap,

Bạn có thể khám phá thêm trên Couchbase Lite

và máy chủ Couchbase

Đây là điều lớn lao tiếp theo.

Nói về sản xuất, chuyển đổi dự phòng / khôi phục liền mạch đều yêu cầu người giữ trẻ
1- Couchbase, không có chuyển đổi dự phòng / khôi phục liền mạch, cần phải can thiệp thủ công.
tái cân bằng mất quá nhiều thời gian, quá nhiều rủi ro nếu có nhiều hơn một nút bị mất.

2- Mongo với phân đoạn, phục hồi dữ liệu từ mất máy chủ cấu hình, không phải là một nhiệm vụ dễ dàng

Adobe đang sử dụng MongoDB cho phiên bản sắp tới của Adobe Experience Manager (trước đây là Day CQ ) làm công cụ DB cốt lõi.

Một số khách hàng tại cơ quan tôi làm việc đang sử dụng CouchDB trên các dự án cho các khách hàng lớn.

Cả hai đều là DB tuyệt vời và khả thi, theo ý kiến ​​của tôi. :)

Dưới đây là danh sách các trang web được triển khai với mongoDB

• Thời báo New York : Sử dụng nó trong một ứng dụng xây dựng hình thức để gửi ảnh. Việc thiếu lược đồ của Mongo cung cấp cho các nhà sản xuất khả năng xác định bất kỳ sự kết hợp nào của các trường biểu mẫu tùy chỉnh.
• NguồnForge : được sử dụng để lưu trữ phía sau trên các trang trước của SourceForge, các trang dự án và các trang tải xuống cho tất cả các dự án.
• Bit.ly
• Etsy
• IGN : tăng cường phân tích lưu lượng truy cập thời gian thực và API nội dung RESTful của IGN.
• Justin.tv : tăng sức mạnh cho các công cụ phân tích nội bộ của Justin.tv về tính độc hại, tỷ lệ giữ chân người dùng và số liệu thống kê sử dụng chung mà các giải pháp vượt trội không thể cung cấp.
• Hậu thế
• Trực giác
• Foursquare : Cơ sở dữ liệu Mongo phân đoạn được sử dụng cho hầu hết các dữ liệu tại.
• Business Insider : Sử dụng nó từ đầu năm 2008. Tất cả dữ liệu của trang web, bao gồm các bài đăng, bình luận và thậm chí cả hình ảnh, được lưu trữ trên MongoDB.
• Github : được sử dụng cho một ứng dụng báo cáo nội bộ.
• Examiner : đã di chuyển trang web của họ từ Cold Fusion và SQL Server sang Drupal 7 và MongoDB.
• Grooveshark : hiện đang sử dụng Mongo để quản lý hơn một triệu phiên người dùng duy nhất mỗi ngày.
• Buzzfeed
• Cá dĩa
• Evite : Được sử dụng để phân tích và báo cáo nhanh.
• Không gian hình vuông
• Shutyh : được sử dụng cho các yêu cầu lưu trữ dữ liệu liên tục khác nhau trong Shutyh. MongoDB giúp Shutoston xây dựng một dịch vụ vô song cho phép mối quan hệ cá nhân sâu sắc hơn, sâu sắc hơn giữa khách hàng và những người quan trọng nhất trong cuộc sống của họ.
• Topsy
• Chia sẻ cái này
• Mongohq : cung cấp một nền tảng lưu trữ cho MongoDB và cũng sử dụng MongoDB làm back-end cho dịch vụ của mình. Trang trung tâm lưu trữ của chúng tôi cung cấp thêm thông tin về MongoHQ và các tùy chọn lưu trữ MongoDB khác.

và hơn thế nữa...

Trích xuất từ: http : // lineof Dùt.com/tools/mongodb

Bạn có thể kiểm tra các cơ sở dữ liệu hoặc công cụ khác ở đó.

MongoDB có một số vấn đề với việc cấp phép cho các doanh nghiệp, tôi không chắc về chi tiết nhưng bộ phận pháp lý của chúng tôi đã nói với chúng tôi không có điều khoản nhất định rằng chúng tôi không được phép sử dụng MongoDB trong bất kỳ sản phẩm nào của chúng tôi.