Ưu điểm của việc sử dụng cơ sở dữ liệu không có lược đồ như MongoDB so với cơ sở dữ liệu quan hệ là gì?

Tôi đã quen với việc sử dụng cơ sở dữ liệu quan hệ như MySQL hoặc PostgreSQL và kết hợp với các khung công tác MVC như Symfony, RoR hoặc Django và tôi nghĩ nó hoạt động rất tốt.

Nhưng gần đây tôi đã nghe nói nhiều về MongoDB, một cơ sở dữ liệu phi quan hệ, hoặc để trích dẫn định nghĩa chính thức ,

một cơ sở dữ liệu hướng tài liệu, hiệu suất cao, có thể mở rộng, hiệu suất cao, không có lược đồ.

Tôi thực sự quan tâm đến việc đi trước và muốn biết tất cả các lựa chọn tôi sẽ có cho một dự án tiếp theo và chọn những công nghệ tốt nhất hiện có.

Trong trường hợp nào sử dụng MongoDB (hoặc các cơ sở dữ liệu tương tự) tốt hơn so với việc sử dụng cơ sở dữ liệu quan hệ "cổ điển"? Và lợi thế của MongoDB vs MySQL nói chung là gì? Hoặc ít nhất, tại sao nó lại khác biệt như vậy?

Nếu bạn có con trỏ đến tài liệu và / hoặc ví dụ, nó cũng sẽ giúp ích rất nhiều.

Dưới đây là một số lợi thế của MongoDB để xây dựng các ứng dụng web:

1. Một mô hình dữ liệu dựa trên tài liệu. Đơn vị lưu trữ cơ bản tương tự như JSON, từ điển Python, hàm băm Ruby, v.v. Đây là một cấu trúc dữ liệu phong phú có khả năng chứa các mảng và các tài liệu khác. Điều này có nghĩa là bạn thường có thể biểu diễn trong một thực thể duy nhất một cấu trúc sẽ yêu cầu một số bảng để biểu diễn chính xác trong một db quan hệ. Điều này đặc biệt hữu ích nếu dữ liệu của bạn là bất biến.
2. Khả năng truy vấn sâu. MongoDB hỗ trợ các truy vấn động trên tài liệu bằng ngôn ngữ truy vấn dựa trên tài liệu gần như mạnh mẽ như SQL.
3. Không có di chuyển giản đồ nào. Vì MongoDB là không có giản đồ, mã của bạn xác định lược đồ của bạn.
4. Một con đường rõ ràng cho khả năng mở rộng theo chiều ngang.

Bạn sẽ cần đọc thêm về nó và chơi với nó để hiểu rõ hơn. Đây là bản demo trực tuyến:

http://try.mongodb.org/

Có rất nhiều lợi thế.

Ví dụ: lược đồ cơ sở dữ liệu của bạn sẽ có khả năng mở rộng cao hơn, bạn sẽ không phải lo lắng về việc di chuyển, mã sẽ dễ viết hơn ... Ví dụ đây là một trong những mã của mô hình của tôi:

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Thêm khóa chỉ là thêm một dòng mã!

Ngoài ra còn có những lợi thế khác sẽ xuất hiện trong thời gian dài, như khả năng quay và tốc độ tốt hơn.

... Nhưng hãy nhớ rằng cơ sở dữ liệu không quan hệ không tốt hơn cơ sở dữ liệu quan hệ . Nếu cơ sở dữ liệu của bạn có nhiều mối quan hệ và chuẩn hóa, thì việc sử dụng một cái gì đó như MongoDB có thể không có ý nghĩa gì. Đó là tất cả về việc tìm kiếm công cụ phù hợp cho công việc.

Để biết thêm những điều cần đọc, tôi khuyên bạn nên xem " Tại sao tôi nghĩ Mongo là đối với Cơ sở dữ liệu mà Rails là đối với Khung công tác " hoặc bài đăng này trên trang web mongodb. Để trở nên hào hứng và nếu bạn nói được tiếng Pháp, hãy xem bài viết này giải thích cách thiết lập MongoDB từ đầu.

Chỉnh sửa: Tôi gần như quên nói với bạn về railscast này của Ryan . Nó rất thú vị và khiến bạn muốn bắt đầu ngay lập tức!

Ưu điểm của schema-free là bạn có thể kết xuất bất cứ thứ gì tải của bạn trong đó và không ai có cơ sở để phàn nàn về nó hoặc nói rằng nó đã sai.

Nó cũng có nghĩa là bất cứ thứ gì bạn đổ vào đó, sẽ hoàn toàn vô nghĩa sau khi bạn đã làm như vậy.

Một số cho rằng đó là một bất lợi hoàn toàn, một số khác thì không.

Thực tế là cơ sở dữ liệu quan hệ có một lược đồ được thiết lập tốt, là kết quả của việc nó có một tập hợp các vị từ mở rộng được thiết lập tốt, cho phép chúng ta gắn ý nghĩa với những gì được ghi trong cơ sở dữ liệu và cũng là điều kiện tiên quyết cần thiết để chúng tôi làm được điều đó.

Nếu không có một lược đồ được thiết lập tốt, không có các vị từ mở rộng và không có các phân khu mở rộng, thì không có cách nào để người dùng hiểu được bất kỳ ý nghĩa nào từ những gì được nhồi vào đó.

MongoDB đã được giới thiệu trên FLOSS Weekly tuần này - http://twit.tv/floss105 Một cơ sở dữ liệu sử dụng khái niệm tương tự là CouchDB đã được giới thiệu trên FLOSS Weekly khác: http://twit.tv/floss36

Tôi nghĩ rằng thật đáng để nghe những điều đó ngoài các liên kết được cung cấp bởi @marcgg

Kinh nghiệm của tôi với Postgres và Mongo sau khi làm việc với cả hai cơ sở dữ liệu trong các dự án của tôi.

Postgres (RDBMS)

Postgres được khuyến nghị nếu các ứng dụng trong tương lai của bạn có một lược đồ phức tạp cần nhiều phép nối hoặc tất cả dữ liệu có mối quan hệ hoặc nếu chúng ta có nhiều văn bản. Postgres là mã nguồn mở, nhanh hơn, tuân thủ ACID và sử dụng ít bộ nhớ hơn trên đĩa, đồng thời hoạt động tốt cho việc lưu trữ JSON và bao gồm khả năng tuần tự hóa đầy đủ của các giao dịch với 3 cấp độ cách ly giao dịch.

Lợi thế lớn nhất của việc ở lại với Postgres là chúng tôi có cả hai thế giới tốt nhất. Chúng ta có thể lưu trữ dữ liệu vào JSONB với các ràng buộc, tính nhất quán và tốc độ. Mặt khác, chúng ta có thể sử dụng tất cả các tính năng của SQL cho các loại dữ liệu khác. Công cụ cơ bản rất ổn định và đối phó tốt với nhiều khối lượng dữ liệu. Nó cũng chạy trên sự lựa chọn của bạn về phần cứng và hệ điều hành. Postgres cung cấp khả năng NoSQL cùng với hỗ trợ giao dịch đầy đủ, lưu trữ các tài liệu JSON với các ràng buộc về dữ liệu trường.

Ràng buộc chung cho Postgres

Chia tỷ lệ Postgres Theo chiều ngang khó hơn đáng kể, nhưng có thể làm được.

Các thao tác đọc nhanh không thể đạt được đầy đủ với Postgres.

KHÔNG có cơ sở dữ liệu SQL

Mongo DB (Hổ có dây)

MongoDB có thể đánh bại Postgres theo kích thước “tỷ lệ ngang”. Lưu trữ JSON là những gì Mongo được tối ưu hóa để làm. Mongo lưu trữ dữ liệu của nó ở định dạng nhị phân gọi là BSONb, (đại khái) chỉ là một biểu diễn nhị phân của một tập siêu JSON. MongoDB lưu trữ các đối tượng chính xác như khi chúng được thiết kế. Theo MongoDB, đối với các ứng dụng đòi hỏi nhiều khả năng ghi, Mongo cho biết công cụ mới (Wired Tiger) giúp người dùng tăng hiệu suất ghi lên đến 10 lần (tôi nên thử điều này), với việc giảm 80% việc sử dụng bộ nhớ, giúp giảm chi phí lưu trữ. , đạt được hiệu quả sử dụng phần cứng cao hơn.

Những hạn chế chung của MongoDb

Việc sử dụng một công cụ lưu trữ ít lược đồ dẫn đến vấn đề về các lược đồ ngầm. Các lược đồ này không được công cụ lưu trữ của chúng tôi xác định nhưng thay vào đó được xác định dựa trên hành vi và kỳ vọng của ứng dụng.

Các công nghệ NoSQL độc lập không đáp ứng các tiêu chuẩn ACID vì chúng hy sinh các biện pháp bảo vệ dữ liệu quan trọng để có hiệu suất thông lượng cao cho các ứng dụng phi cấu trúc. Không khó để áp dụng ACID trên cơ sở dữ liệu NoSQL nhưng nó sẽ làm cho cơ sở dữ liệu chậm và không linh hoạt ở một mức độ nào đó. “Hầu hết các hạn chế của NoSQL đã được tối ưu hóa trong các phiên bản và bản phát hành mới hơn, chúng đã khắc phục được những hạn chế trước đây của nó ở mức độ lớn”.

Đó là tất cả về sự đánh đổi. MongoDB nhanh nhưng không phải ACID, nó không có giao dịch. Nó tốt hơn MySQL trong một số trường hợp sử dụng và tệ hơn ở những trường hợp khác.

Những dòng dưới đây được viết bằng MongoDB: Hướng dẫn cuối cùng.

Có một số lý do chính đáng:

1. Giữ các loại tài liệu khác nhau trong cùng một bộ sưu tập có thể là một cơn ác mộng đối với các nhà phát triển và quản trị viên. Các nhà phát triển cần đảm bảo rằng mỗi truy vấn chỉ trả về các tài liệu thuộc một loại nhất định hoặc mã ứng dụng thực hiện truy vấn có thể xử lý các tài liệu có hình dạng khác nhau. Nếu chúng tôi đang truy vấn các bài đăng trên blog, thì thật rắc rối khi loại bỏ các tài liệu chứa dữ liệu tác giả.
2. Việc lấy danh sách các bộ sưu tập nhanh hơn nhiều so với trích xuất danh sách các loại trong một bộ sưu tập. Ví dụ: nếu chúng tôi có một khóa loại trong bộ sưu tập cho biết mỗi tài liệu là tài liệu “đọc lướt”, “toàn bộ” hay “chú khỉ con”, thì việc tìm ba giá trị đó trong một bộ sưu tập sẽ chậm hơn nhiều so với có ba bộ sưu tập riêng biệt và truy vấn tên của chúng
3. Nhóm các tài liệu cùng loại với nhau trong cùng một tập hợp cho phép định vị dữ liệu. Nhận một số bài đăng trên blog từ một bộ sưu tập chỉ chứa các bài đăng có thể sẽ yêu cầu ít lần tìm đĩa hơn so với việc lấy các bài đăng tương tự từ một bộ sưu tập bao gồm các bài đăng và dữ liệu tác giả.
4. Chúng tôi bắt đầu áp đặt một số cấu trúc vào tài liệu của mình khi chúng tôi tạo chỉ mục. (Điều này đặc biệt đúng trong trường hợp chỉ mục duy nhất.) Các chỉ mục này được xác định cho mỗi tập hợp. Bằng cách chỉ đặt các tài liệu của một loại duy nhất vào cùng một bộ sưu tập, chúng tôi có thể lập chỉ mục các bộ sưu tập của mình hiệu quả hơn

Sau khi đặt câu hỏi về cơ sở dữ liệu có lưu trữ dạng văn bản), tôi liếc qua MongoDB và các hệ thống tương tự.
Nếu tôi hiểu đúng, chúng được cho là dễ sử dụng và thiết lập hơn, và nhanh hơn nhiều. Có lẽ cũng an toàn hơn vì việc thiếu SQL ngăn chặn việc tiêm SQL ...
Rõ ràng, MongoDB được sử dụng chủ yếu cho các ứng dụng Web.
Về cơ bản, và họ tuyên bố rằng bản thân, các cơ sở dữ liệu này không phù hợp với các truy vấn phức tạp, khai thác dữ liệu, v.v. Nhưng chúng tỏa sáng trong việc truy xuất nhanh chóng nhiều dữ liệu phẳng.

1. MongoDB hỗ trợ tìm kiếm theo trường, tìm kiếm biểu thức chính quy, bao gồm các hàm tập lệnh java do người dùng định nghĩa.
2. MongoDB có thể được sử dụng như một hệ thống tệp, tận dụng các tính năng cân bằng tải và sao chép dữ liệu trên nhiều máy để lưu trữ tệp.