Có trang web thương mại điện tử nào sử dụng cơ sở dữ liệu NoSQL

Question

Tôi đã đọc rất nhiều về cơ sở dữ liệu 'NoSQL' như CouchDB, MongoDB vv. Hầu hết các trang web mà tôi đã thấy bằng cách sử dụng này chủ yếu dựa trên các trang web văn bản như The New Thời báo York và nguồn giả mạo.

tôi đã tự hỏi nếu bạn có thể áp dụng điều này để các trang web mà thanh toán là một vấn đề rất lớn. Tôi đang nghĩ đến các vấn đề sau:

• tốt như thế nào bạn có thể bảo mật dữ liệu
• Do các hệ thống cung cấp một bản sao lưu dễ dàng/khôi phục Cơ chế
• như thế nào giao dịch xử lý cam/rollback

Tôi đã đọc các bài viết sau đây bao gồm một số khía cạnh:

• Can I do transactions and locks in CouchDB?
• Pros/Cons of document based database vs relational database

Trong các bài đăng này, khía cạnh giao dịch nếu được bảo hiểm. Tuy nhiên, các câu hỏi về bảo mật và sao lưu không được đề cập đến. Ai đó có thể làm sáng tỏ chủ đề này?

Và nếu có thể, không ai biết của một số trang web thương mại điện tử đã thực hiện thành công các cơ sở dữ liệu dựa trên tài liệu.

Answer 1

EDIT: Tháng Ba, 2013

Ban đầu tôi đã gửi một liên kết đến một bài báo tôi đã viết trên MongoDB và thương mại điện tử, nhưng tôi không còn đồng ý với tất cả các điểm mà tôi đã có. Tôi vẫn tin rằng mô hình dữ liệu tài liệu của MongoDB có thể hoạt động rất tốt cho phía quản lý danh mục của một trang thương mại điện tử và có lẽ cho các giỏ hàng mua sắm. Nhưng rõ ràng là các trường hợp giao dịch rất quan trọng và MongoDB không cung cấp cho bạn những điều này.Câu trả lời cho câu hỏi này với số phiếu bầu cao nhất tiếp theo tạo ra nhiều điểm đáng xem xét.

Dưới đây là bài viết gốc cho những người quan tâm:

http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/ (archive.org link)

Answer 2

Tôi không nghĩ rằng an ninh sẽ được bất kỳ khác nhau trên một cơ sở dữ liệu NoSQL hơn trên một cơ sở dữ liệu quan hệ. Cuối cùng, bảo mật là câu hỏi trực giao về cách dữ liệu được lưu trữ thực sự. Bên cạnh đó, nó không giống như bạn cho phép truy cập vào cơ sở dữ liệu từ bất cứ thứ gì trừ các máy chủ tầng nghiệp vụ của bạn từ quan điểm mạng.

Như để sao lưu, cơ sở dữ liệu NoSQL nhất mà tôi biết cho phép sao lưu nóng, giống như một cơ sở dữ liệu thường xuyên thực hiện.

Câu hỏi thực sự, IMO, là liệu bạn có thể sống với những hạn chế mà một cơ sở dữ liệu NoSQL đặt vào bạn - đặc biệt là sự thiếu chung của các truy vấn ad-hoc. Ví dụ, nếu bạn đã bao giờ muốn biết tất cả những người đã từng mua sản phẩm "X", sau đó bạn sẽ phải xây dựng vào lớp truy cập dữ liệu của bạn một bộ đếm cho rằng từ ngày đầu tiên (hoặc chạy một rất tốn kém tra cứu serial của mọi giao dịch trong quá khứ). Trong một cơ sở dữ liệu SQL thông thường, bạn chỉ có thể thêm một chỉ mục và thực hiện một truy vấn và bạn đã hoàn thành (hoặc thậm chí, không thêm một chỉ mục nếu nó là một lần duy nhất). Hoặc có thể bạn muốn tìm hiểu tất cả những người đã mua sản phẩm "Y" trước khi phiên bản mới nhất xuất hiện (để bạn có thể gửi lời nhắc cho họ nâng cấp hoặc bất kỳ thứ gì): một lần nữa, bạn phải lên kế hoạch trước với cơ sở dữ liệu NoSQL, nhưng nó tầm thường với một cơ sở dữ liệu quan hệ.

Tôi nghĩ rằng bạn có thể lập kế hoạch cho lược đồ và mẫu sử dụng của mình trước thời hạn và thỉnh thoảng có thể chấp nhận quét lại các bản ghi để thêm một số trường hoặc chỉ số mới. Nhưng đối với một trang web thương mại điện tử, tôi nghĩ rằng các truy vấn đặc biệt chỉ là một tính năng quá giá trị để mất. Tất nhiên, đó chỉ là ý kiến ​​của tôi, và chắc chắn không có lý do tại sao bạn không thể trộn-n-phù hợp với các phần của ứng dụng giữa hai cơ sở dữ liệu. Tôi muốn cá nhân chọn một cơ sở dữ liệu quan hệ với memcached ở giữa cho hiệu suất bổ sung, mặc dù ...

Answer 3

Xử lý thông tin tài chính là một trong những lĩnh vực mà SQL thực sự là công cụ thích hợp cho công việc. Hầu hết các hệ thống NOSQL được thiết kế để cải thiện khả năng mở rộng bằng cách chấp nhận rủi ro mất dữ liệu hoặc mâu thuẫn cao hơn.Họ cũng có xu hướng có khả năng hạn chế chạy báo cáo trên tất cả các bản ghi, vì trên một trang web lớn điển hình, bạn chỉ cần đủ dữ liệu trong chỉ mục để tìm và hiển thị một bản ghi - phần còn lại có thể hoàn toàn không thể truy cập được cho đến khi bạn biết bản ghi bạn đang tìm kiếm cho.

Khi xử lý tiền, bất kỳ sự không thống nhất dữ liệu nào là một vấn đề lớn, và nếu bạn cần khả năng mở rộng cao hơn một máy chủ sql đơn lẻ có thể cung cấp cho bạn, bạn có đủ tiền để có thể trả chi phí cao hơn. Ngoài ra, báo cáo đặc biệt có sẵn từ sql là thứ bạn muốn bỏ lỡ nếu bạn không sử dụng sql - nhiều thông tin bạn muốn về lịch sử bán hàng là tầm thường để lấy từ sql, nhưng có khả năng yêu cầu mã tùy chỉnh phức tạp từ một đối tượng cửa hàng.

Answer 4

Chi phí làm cho RDBMS quá chậm, đảm bảo tính nguyên tử, nhất quán, cách ly, độ bền, còn được gọi là ACID. Một số thuộc tính này khá quan trọng đối với các ứng dụng xử lý tiền. Bạn không muốn mất một thứ tự khi đèn tắt.

Cơ sở dữ liệu NoSQL thường hy sinh một số hoặc tất cả các thuộc tính ACID để đổi lấy chi phí bị giảm nghiêm trọng. Đối với nhiều ứng dụng, điều này là tốt - nếu một vài "diggs" bị mất tích khi đèn tắt, nó không phải là vấn đề lớn.

Đối với trang web thương mại điện tử, bạn cần phải tự hỏi mình những gì bạn thực sự cần.

1. Bạn có thực sự cần một mức hiệu suất mà RDBMS không thể phân phối không?
2. Bạn có cần độ tin cậy mà RDBMS cung cấp không?

Thành thật mà nói, câu trả lời cho # 2 có lẽ là "có", trong đó loại trừ hầu hết các giải pháp NoSQL. Và trừ khi bạn đang đối phó với các mức lưu lượng có thể so sánh với amazon.com, RDBM, thậm chí trên phần cứng khiêm tốn có thể sẽ đáp ứng nhu cầu hiệu suất của bạn, đặc biệt nếu bạn giới hạn mình thành các truy vấn đơn giản và lập chỉ mục đúng cách. Mà làm cho câu trả lời cho # 1 "không".

Bạn có thể tuy nhiên, hãy cân nhắc sử dụng RDBMS cho dữ liệu giao dịch và cơ sở dữ liệu NoSQL cho dữ liệu không quan trọng, như trang sản phẩm, đánh giá của người dùng, v.v. và bất kỳ mối quan hệ nào giữa dữ liệu trong hai kho dữ liệu sẽ phải được quản lý bằng mã - sẽ không có sự tham gia vào cơ sở dữ liệu NoSQL của bạn đối với RDBMS của bạn. Điều này có thể dẫn đến mức độ phức tạp không cần thiết.

Cuối cùng, nếu một RDBMS cung cấp các tính năng bạn phải có cho độ tin cậy, và nó thực hiện chấp nhận cho các loại tải bạn sẽ gặp phải, một RDBMS có lẽ là đặt cược tốt nhất.

Answer 5

Các bạn nên kiểm tra này ra:

Replication Acknowledgement via getlasterror

MongoDB đang trên bờ vực cung cấp ghi bền. Tôi nghĩ rằng đó là vấn đề chính với mọi người thảo luận về chủ đề này w.r.t. tiền bạc. Phần giao dịch ít quan trọng hơn do các tính năng tài liệu lồng nhau.

Answer 6

Gilt.com sử dụng Voldemort để xử lý giỏ/hàng tồn kho theo tải trọng lớn. Xem bản trình bày này từ London QCon 2010 về chi tiết - http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-Groupe

Tôi cũng nhắc lại rằng "NoSQL" không có nghĩa là "Không có SQL", "Không chỉ SQL" và thay vì xem bất kỳ công nghệ nào cho một rip hoàn toàn/thay thế của bất kỳ khác, bạn nên nhìn vào công cụ tốt nhất cho công việc. Các kho dữ liệu NoSQL không tạo kho dữ liệu rất tốt và có thể không thích hợp để lưu trữ các giao dịch người dùng, nhưng chúng rất tốt trong các lĩnh vực thích hợp nhất định - xem ví dụ Gilt Groupe ở trên.

Một ví dụ nổi bật khác là trang chủ BBC - không giao dịch nhưng thú vị. Họ sử dụng CouchDB để lưu trữ các sở thích của người dùng. Thật không may, họ dường như đã bị rơi dưới tải.

[UPDATE: Tôi cũng có thể xác nhận rằng ASOS Marketplace sử dụng một số thành phần NoSQL - http://bagcheck.com/bag/9206-asos-marketplace-technology]

Answer 7

Dưới đây là một loạt các ứng dụng web thương mại có sử dụng MongoDB, đó là một trong những cơ sở dữ liệu phổ biến hơn NoSQL.

http://www.mongodb.org/display/DOCS/Production+Deployments

Đó không phải là chính xác các trang web thương mại điện tử cho mỗi gia nhập, nhưng nhiều những khía cạnh NoSQL-powered rằng các doanh nghiệp phụ thuộc vào. Tôi có thể xác nhận rằng ChatPast hoàn toàn được thực hiện trên MongoDB. Chúng tôi làm thương mại điện tử nhưng điều đó được tải xuống Chargify do các mối lo ngại về bảo mật/xử lý thay vì sợ làm thương mại trên MongoDB.

Answer 8

Có, http://myestoreapp.com sử dụng MongoDB cho mọi thứ. Kiểm tra nó ra; cảm thấy tự do để bắn qua bất kỳ câu hỏi nào.