Khi nào chúng ta nên sử dụng MongoDB?

MongoDB là một cơ sở dữ liệu NoQuery mà tôi thấy khá dễ sử dụng. Gần đây tôi đã phải phát triển một ứng dụng đơn giản cần thu thập một số dữ liệu bằng các yêu cầu HTTP và lưu trữ một số kết quả sau khi xử lý dữ liệu và tôi đã thử sử dụng MongoDB.

Từ kinh nghiệm này, tôi thấy nó dễ sử dụng hơn nhiều so với cơ sở dữ liệu quan hệ truyền thống và vì tôi là nhà phát triển chứ không phải DBA, công việc của tôi đã được đơn giản hóa rất nhiều.

Tuy nhiên, đôi khi tôi cảm thấy không chắc chắn khi nào nên sử dụng MongoDB thay vì cơ sở dữ liệu quan hệ truyền thống, như SQL Server hoặc MySQL.

Trong trường hợp đó, khi chúng ta có thể sử dụng MongoDB thay vì cơ sở dữ liệu quan hệ? Có một số cảnh báo lớn về MongoDB khiến nó không phù hợp với một số tình huống?

Về cơ bản:

• Nếu bạn có thể biểu thị dữ liệu của mình dưới dạng một loạt các tài liệu, MongoDB có thể là một lựa chọn tốt.

• Nếu bạn muốn tưởng tượng dữ liệu của mình là một loạt các bảng được kết nối với nhau, MongoDB có thể không phải là một lựa chọn tốt.

Đây là hai ví dụ mà tôi thấy minh họa:

• Vài năm trước, tôi đã tạo ra một công cụ blog. Mục đích của nó là lưu trữ các bài viết trên blog và cho mỗi bài viết, lưu trữ các phiên bản khác nhau, một số siêu dữ liệu, số liệu thống kê truy cập, v.v.

  Điều này có thể được lưu trữ dưới dạng một loạt các bảng, nhưng khi cố gắng xây dựng một mô hình, nó phát triển rất nhanh đến hàng tá bảng, nếu không muốn nói là nhiều hơn. Một số truy vấn SQL có thể trở nên xấu với rất nhiềujoin s, và ... tốt, bạn sẽ có được hình ảnh.

  Vấn đề ở đây là có một điều trung tâm, một bài viết trên blog của Google và có tất cả những thứ này xung quanh bài viết, điều này làm cho nó phù hợp với cơ sở dữ liệu dựa trên tài liệu. Với MongoDB, việc lập mô hình cơ sở dữ liệu cực kỳ dễ dàng: một bộ sưu tập chứa các bài viết trên blog và một bộ sưu tập nhỏ thứ hai chứa danh sách người dùng được phép viết bài. Mỗi tài liệu trong bộ sưu tập đầu tiên sẽ chứa tất cả thông tin tôi cần khi hiển thị một bài viết, nó sẽ là tên của tác giả hoặc các thẻ.

• Bây giờ hãy tưởng tượng một dự án rất khác nhau. Có một số người dùng có thể viết nội dung và chia sẻ nội dung được viết bởi người dùng khác. Trên trang của một người dùng, bạn sẽ tìm thấy cả những điều người dùng này đã viết và những điều cô ấy đã chia sẻ. Có một hạn chế: khi ai đó chỉnh sửa những gì anh ta đã viết trong quá khứ, sự thay đổi xuất hiện ở mọi nơi mà văn bản gốc được chia sẻ.

  Với cách tiếp cận dựa trên tài liệu, thật khó để tìm ra đâu là tài liệu. Một người dùng có thể? Vâng, đó là một khởi đầu tốt. Một tài liệu người dùng sẽ chứa tất cả những điều người dùng này đã viết. Nhưng những gì cô ấy chia sẻ?

  Một cách có thể là đặt những thứ đó trong cùng một tài liệu. Vấn đề với cách tiếp cận này là nếu ai đó chỉnh sửa mục nhập, ứng dụng sẽ duyệt qua mọi tài liệu người dùng trong cơ sở dữ liệu để chỉnh sửa mọi lần xuất hiện của mục nhập cũ. Không tính trùng lặp dữ liệu.

  Một cách khác là giữ trong tài liệu người dùng chỉ danh sách các mục mà người dùng này đã chia sẻ (với ID của người dùng được giới thiệu và mục nhập). Nhưng bây giờ, một vấn đề khác sẽ xảy ra: nếu một người dùng chia sẻ hàng ngàn mục nhập từ hàng ngàn người dùng, thì sẽ cần phải mở hàng ngàn tài liệu để có được những mục đó.

  Hoặc chúng ta có thể mô hình bộ sưu tập của mình xung quanh các mục, mỗi mục đề cập đến tác giả của nó và có một danh sách người dùng đã chia sẻ nó. Một lần nữa, các vấn đề về hiệu suất có thể trở nên đáng chú ý khi bạn cần xem qua tất cả các tài liệu để hiển thị những tài liệu được xuất bản bởi một người dùng nhất định.

  Bây giờ, bạn cần bao nhiêu bảng nếu bạn đang sử dụng cơ sở dữ liệu quan hệ? Phải, ba. Nó sẽ đơn giản để mô hình hóa, và cũng dễ sử dụng.

Mỗi công nghệ có ưu điểm của nó.

Ưu điểm của cơ sở dữ liệu quan hệ là RDBMS thực hiện một số điều cho bạn, như:

• Thực thi tính toàn vẹn tham chiếu (không cho phép chèn chi tiết hóa đơn nếu hóa đơn không thuộc về hóa đơn)
• Tránh dư thừa: mọi thứ chỉ được lưu trữ một lần.
• Các truy vấn phức tạp có thể được thực hiện với một ngôn ngữ khai báo (SQL) trưởng thành, được chứng minh theo thời gian và được phổ biến rộng rãi.

Tất cả điều đó có nghĩa là bạn phải viết ít mã hơn vì RDBMS thực thi mọi thứ cho bạn.

Ngoài ra, tính độc lập dữ liệu: thường là khi bạn sử dụng các cấu trúc SQL tiêu chuẩn và không có cấu trúc cụ thể của nhà cung cấp, bạn có thể di chuyển dữ liệu của mình từ RDBMS này sang RDBMS khác với rắc rối tối thiểu, trong khi cơ sở dữ liệu NOSQL hoàn toàn không được chuẩn hóa.

Mặt khác, một trong những lợi thế của cơ sở dữ liệu NOSQL là chúng có quy mô duy trì hiệu suất tốt hơn cho hàng triệu hàng. Chúng phù hợp hơn cho việc lưu trữ dựa trên tài liệu, tức là dữ liệu không có cấu trúc. Nhưng hầu hết các ứng dụng không cần các tính năng này.

Đối với trường hợp cụ thể của bạn, MongoDB nghe có vẻ là một lựa chọn tốt, nhưng có rất nhiều tình huống (có lẽ là hầu hết trong số đó) trong đó nó sẽ không phải là lựa chọn tốt nhất.

MongoDB phù hợp hơn trong các tình huống yêu cầu đọc / ghi nhiều dữ liệu, không chú trọng đến an toàn giao dịch (nếu một số dữ liệu thỉnh thoảng bị mất trong sự cố máy chủ, đó không phải là vấn đề lớn), mong muốn mở rộng quy mô và không ' t thực sự có một lược đồ ổn định.

MongoDB không phù hợp với các kịch bản yêu cầu:

1. Đảm bảo ACID mạnh: MongoDB cho phép lưu trữ dữ liệu trùng lặp, đọc không nhất quán và thậm chí mất dữ liệu. Những điều này là tốt trong một số ứng dụng, nhưng không phải trong hầu hết.
2. Giao dịch đa đối tượng: MongoDB không hỗ trợ các giao dịch ACID, nhưng chỉ cho một đối tượng / tài liệu. Điều này sẽ không cắt giảm cho các hoạt động phức tạp hơn như chuyển khoản ngân hàng, đặt phòng, v.v.
3. BI truyền thống: có rất nhiều công cụ BI ngoài kia chỉ chơi tốt với SQL truyền thống.
4. SQL: MongoDB có một ngôn ngữ truy vấn rất cụ thể, trong khi SQL được rất nhiều người biết đến (có thể là một khía cạnh quan trọng cần xem xét), có thể làm rất nhiều việc phức tạp (trong khi với MongoDB bạn gặp khó khăn khi thực hiện một cách đơn giản tham gia) và có thể chuyển nhượng qua rất nhiều triển khai.

MongoDB nhanh hơn và sẽ cho phép bạn tăng hiệu suất ra khỏi hệ thống bằng cách loại bỏ rất nhiều thứ mà RDBMS thực thi theo mặc định, như kiểm tra tính toàn vẹn (dù sao bạn cũng có thể điều chỉnh RDBMS cho các mục đích như vậy), nhưng sự thật là, trong hầu hết các kịch bản, nó chỉ không cần thiết. Thêm vào đó, sự đánh đổi là độ tin cậy và tính linh hoạt (bạn sẽ gặp rắc rối nếu sau này, bạn quyết định bạn cần thực hiện các thao tác phức tạp hơn với dữ liệu hiện có).

Tất cả phụ thuộc vào nhu cầu của ứng dụng bạn đang xây dựng. Là tốc độ và tính sẵn sàng, hoặc an toàn, độ tin cậy và linh hoạt. Bạn phải biết nơi dữ liệu của bạn (và trong các kết nối dữ liệu của bạn) nằm ở đâu nhiều giá trị hơn. Nếu bạn chưa biết, có lẽ tốt nhất nếu bạn chọn thứ gì đó sẽ không vẽ bạn vào một góc trong tương lai và sẽ cho phép bạn thêm các tính năng và thực hiện các thao tác mà ứng dụng của bạn cần.

MongoDB thật tuyệt vời khi bạn có thể biểu thị dữ liệu của mình dưới dạng "gói" thông tin độc lập. Bạn có google maps mã ZIP, được nhúng trong mã ZIP là các công ty và bên trong các công ty là nhân viên. Tất cả các mã zip là độc lập với nhau và bạn có thể nhận được toàn bộ thông tin một cách đơn giản, đẹp và nhanh chóng. Đó là một kịch bản tốt cho một giải pháp nonQuery.

Có lần nói rằng, tôi hoàn toàn không đồng ý với xu hướng hiện tại mà tôi đang tìm kiếm ngụ ý rằng MongoDB là một loại bài đăng và giải pháp ưu việt cho RDBMS và noQuery phải là giải pháp của bạn theo mặc định. Tất cả những điều đó là vô lý. MongoDB là một cơ sở dữ liệu thích hợp và 90% các dự án là quan hệ và cần tùy chọn RDBMS vì bạn muốn một giải pháp truy vấn mạnh mẽ như SQL để tạo các báo cáo của bạn và tìm kiếm dữ liệu phân tán: "tham gia" là một pro, không phải là một con. Bên cạnh đó, RDBMS hiện đại hỗ trợ các bộ sưu tập BSON và tích hợp không gian địa lý, do đó, có thể thị trường ngách cho noQuery thậm chí còn hẹp hơn.

MongoDB rất hữu ích để lưu trữ toàn bộ dữ liệu có cấu trúc cần thiết để xây dựng một thể hiện nhất định của một trang web. Bạn có thể truy xuất dữ liệu cho một trang nhất định, chuyển nó đến ứng dụng khách của bạn, sau đó có thể hiển thị dữ liệu đó.

Trong bối cảnh như vậy, MongoDB rất nhanh và đáng tin cậy. Nhưng đừng bao giờ quên bạn không có thông tin quan hệ trong cơ sở dữ liệu của bạn. Điều đó có nghĩa là nếu bạn thay đổi một cái gì đó trong cấu trúc trang web của mình, bạn có thể không thể lấp đầy các lỗ hổng trong các trang đã lưu trữ của mình vì bạn không có dữ liệu cần thiết để làm như vậy. Thêm về điều này ở đây: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/