Khi nào nên sử dụng MongoDB hoặc các hệ thống cơ sở dữ liệu định hướng tài liệu khác? [đóng cửa]

Chúng tôi cung cấp một nền tảng cho video và âm thanh clip, hình ảnh và vector-grafics. Chúng tôi đã bắt đầu với MySQL là phụ trợ cơ sở dữ liệu và gần đây bao gồm MongoDB để lưu trữ tất cả thông tin meta của các tệp, vì MongoDB phù hợp hơn với các yêu cầu. Ví dụ: ảnh có thể có thông tin Exif , video cũng có thể có các đoạn âm thanh mà chúng tôi cũng muốn lưu trữ thông tin meta. Video và đồ họa véc tơ không chia sẻ bất kỳ thông tin meta phổ biến nào, v.v. vì vậy tôi biết rằng MongoDB là hoàn hảo để lưu trữ dữ liệu phi cấu trúc này và giữ cho nó có thể tìm kiếm được.

Tuy nhiên, chúng tôi tiếp tục phát triển nền tảng của chúng tôi và thêm các tính năng. Bây giờ một trong những bước tiếp theo sẽ là cung cấp một diễn đàn cho người dùng của chúng tôi. Câu hỏi đặt ra bây giờ là: sử dụng cơ sở dữ liệu MySQL, đây sẽ là một lựa chọn tốt để lưu trữ diễn đàn và bài đăng trên diễn đàn, v.v. hay sử dụng MongoDB cho việc này?

Vì vậy, câu hỏi là: khi nào nên sử dụng MongoDB và khi nào nên sử dụng RDBMS. Bạn sẽ lấy gì, mongoDB hoặc MySQL, nếu bạn có sự lựa chọn và tại sao bạn lại chọn nó?

Trong NoQuery: If Only It Was Easy , tác giả viết về MongoDB:

MongoDB không phải là kho lưu trữ khóa / giá trị, nó còn hơn thế một chút. Nó chắc chắn không phải là một RDBMS. Tôi chưa sử dụng MongoDB trong sản xuất, nhưng tôi đã sử dụng nó một chút để xây dựng một ứng dụng thử nghiệm và nó là một bộ công cụ rất tuyệt vời. Nó dường như rất hiệu quả và có, hoặc sẽ sớm có khả năng chịu lỗi và tự động bảo vệ (hay còn gọi là nó sẽ mở rộng). Tôi nghĩ Mongo có thể là thứ gần nhất với sự thay thế RDBMS mà tôi đã thấy cho đến nay. Nó sẽ không hoạt động cho tất cả các tập dữ liệu và mẫu truy cập, nhưng nó được xây dựng cho công cụ CRUD điển hình của bạn. Lưu trữ những gì thực chất là một hàm băm lớn và có thể chọn bất kỳ khóa nào trong số đó, là những gì hầu hết mọi người sử dụng cơ sở dữ liệu quan hệ.Nếu DB của bạn là 3NF và bạn không tham gia (bạn chỉ cần chọn một loạt các bảng và đặt tất cả các đối tượng lại với nhau, AKA là những gì hầu hết mọi người làm trong một ứng dụng web), MongoDB có thể sẽ đá vào mông bạn.

Sau đó, trong kết luận:

Điều thực sự cần chỉ ra là nếu bạn bị kìm hãm việc tạo ra thứ gì đó siêu tuyệt vời vì bạn không thể chọn cơ sở dữ liệu, bạn đã làm sai. Nếu bạn biết mysql, chỉ cần sử dụng nó. Tối ưu hóa khi bạn thực sự cần. Sử dụng nó như cửa hàng ak / v, sử dụng nó như một rdbms, nhưng vì chúa, hãy xây dựng ứng dụng sát thủ của bạn! Không ai trong số này sẽ quan trọng với hầu hết các ứng dụng. Facebook vẫn sử dụng MySQL, rất nhiều. Wikipedia sử dụng MySQL, rất nhiều. FriendFeed sử dụng MySQL, rất nhiều. NoQuery là một công cụ tuyệt vời, nhưng chắc chắn nó sẽ không phải là lợi thế cạnh tranh của bạn, nó sẽ không làm cho ứng dụng của bạn nóng lên và hầu hết, người dùng của bạn sẽ không quan tâm đến bất kỳ điều gì trong số này.

Tôi sẽ xây dựng ứng dụng tiếp theo của mình trên cái gì? Có lẽ là Postgres. Tôi sẽ sử dụng NoQuery chứ? Có lẽ. Tôi cũng có thể sử dụng Hadoop và Hive. Tôi có thể giữ mọi thứ trong các tập tin phẳng. Có lẽ tôi sẽ bắt đầu hack trên Maglev. Tôi sẽ sử dụng bất cứ điều gì tốt nhất cho công việc. Nếu tôi cần báo cáo, tôi sẽ không sử dụng bất kỳ NoQuery nào. Nếu tôi cần bộ nhớ đệm, có lẽ tôi sẽ sử dụng Tokyo Tyrant. Nếu tôi cần ACIDity, tôi sẽ không sử dụng NoQuery. Nếu tôi cần một tấn quầy, tôi sẽ sử dụng Redis. Nếu tôi cần giao dịch, tôi sẽ sử dụng Postgres. Nếu tôi có một tấn tài liệu duy nhất, có lẽ tôi sẽ sử dụng Mongo. Nếu tôi cần viết 1 tỷ đối tượng mỗi ngày, có lẽ tôi sẽ sử dụng Voldemort. Nếu tôi cần tìm kiếm toàn văn, có lẽ tôi sẽ sử dụng Solr. Nếu tôi cần tìm kiếm toàn văn bản dữ liệu dễ bay hơi, có lẽ tôi sẽ sử dụng Sphinx.

Tôi thích bài viết này, tôi thấy nó rất nhiều thông tin, nó cung cấp một cái nhìn tổng quan tốt về phong cảnh và sự cường điệu của NoQuery. Nhưng, và đó là phần quan trọng nhất, nó thực sự giúp bạn tự hỏi mình những câu hỏi phù hợp khi lựa chọn giữa RDBMS và NoQuery. Đáng đọc IMHO.

Liên kết thay thế cho bài viết

Sau hai năm sử dụng MongoDb cho một ứng dụng xã hội, tôi đã chứng kiến ​​ý nghĩa thực sự của việc sống mà không cần RDBMS SQL.

1. Bạn kết thúc công việc viết để làm những việc như tham gia dữ liệu từ các bảng / bộ sưu tập khác nhau, một việc mà RDBMS sẽ tự động làm cho bạn.
2. Khả năng truy vấn của bạn với NoQuery bị tê liệt nghiêm trọng. MongoDb có thể là thứ gần gũi nhất với SQL nhưng nó vẫn còn rất xa. Tin tôi đi Các truy vấn SQL là siêu trực quan, linh hoạt và mạnh mẽ. Truy vấn MongoDb thì không.
3. Các truy vấn MongoDb có thể truy xuất dữ liệu từ chỉ một bộ sưu tập và chỉ tận dụng một chỉ mục. Và MongoDb có lẽ là một trong những cơ sở dữ liệu NoQuery linh hoạt nhất. Trong nhiều tình huống, điều này có nghĩa là nhiều chuyến đi khứ hồi đến máy chủ để tìm các bản ghi liên quan. Và sau đó bạn bắt đầu khử chuẩn hóa dữ liệu - có nghĩa là các công việc nền.
4. Thực tế rằng nó không phải là một cơ sở dữ liệu quan hệ có nghĩa là bạn sẽ không có (ràng buộc bởi một số người thực hiện kém) các ràng buộc khóa ngoại để đảm bảo dữ liệu của bạn nhất quán. Tôi đảm bảo với bạn rằng điều này cuối cùng sẽ tạo ra sự không nhất quán dữ liệu trong cơ sở dữ liệu của bạn. Được chuẩn bị. Nhiều khả năng bạn sẽ bắt đầu viết các quy trình hoặc kiểm tra để giữ cho cơ sở dữ liệu của bạn nhất quán, điều này có thể sẽ không hoạt động tốt hơn là để RDBMS làm điều đó cho bạn.
5. Hãy quên đi các khung trưởng thành như ngủ đông.

Tôi tin rằng 98% tất cả các dự án có thể tốt hơn với RDBMS SQL điển hình so với NoQuery.

để lưu trữ dữ liệu phi cấu trúc này

Như bạn đã nói, MongoDB phù hợp nhất để lưu trữ dữ liệu phi cấu trúc. Và điều này có thể tổ chức dữ liệu của bạn thành định dạng tài liệu. Những altenatives RDBMS gọi NoSQL lưu trữ dữ liệu ( MongoDB , CouchDB , Voldemort ) rất hữu ích cho các ứng dụng quy mô ồ ạt và đòi hỏi nhanh hơn truy cập dữ liệu từ những lưu trữ dữ liệu lớn.

Và việc triển khai các cơ sở dữ liệu này đơn giản hơn RDBMS thông thường. Vì đây là các đối tượng nhị phân kiểu khóa có giá trị khóa hoặc tài liệu đơn giản được nối tiếp trực tiếp vào đĩa. Các cửa hàng dữ liệu này không thực thi các thuộc tính ACID và bất kỳ lược đồ nào . Điều này không cung cấp bất kỳ khả năng giao dịch . Vì vậy, điều này có thể mở rộng quy mô lớn và chúng ta có thể đạt được quyền truy cập nhanh hơn (cả đọc và viết).

Nhưng ngược lại, RDBM thi hành ACID và lược đồ trên dữ liệu. Nếu bạn muốn làm việc với dữ liệu có cấu trúc, bạn có thể tiếp tục với RDBM.

Tôi sẽ chọn MySQL để tạo diễn đàn cho loại công cụ này. Bởi vì điều này sẽ không có quy mô lớn. Và đây là một ứng dụng rất đơn giản (phổ biến) có cấu trúc quan hệ giữa các dữ liệu.

Lưu ý rằng về cơ bản Mongo lưu trữ JSON. Nếu ứng dụng của bạn đang xử lý nhiều Đối tượng JS (có lồng nhau) và bạn muốn duy trì các đối tượng này thì có một đối số rất mạnh khi sử dụng Mongo. Nó làm cho các lớp DAL và MVC của bạn trở nên cực kỳ mỏng, bởi vì chúng không bỏ gói tất cả các thuộc tính đối tượng JS và cố gắng khớp chúng vào một cấu trúc (lược đồ) mà chúng không phù hợp một cách tự nhiên.

Chúng tôi có một hệ thống có một số Đối tượng JS phức tạp và chúng tôi yêu Mongo vì chúng tôi có thể duy trì mọi thứ thực sự, thực sự dễ dàng. Các đối tượng của chúng tôi cũng khá vô định hình và không có cấu trúc, và Mongo tiếp nhận sự phức tạp đó mà không chớp mắt. Chúng tôi có một lớp báo cáo tùy chỉnh giải mã dữ liệu vô định hình cho tiêu dùng của con người và điều đó không khó để phát triển.

Tôi sẽ nói sử dụng RDBMS nếu bạn cần các giao dịch phức tạp. Nếu không, tôi sẽ sử dụng MongoDB - linh hoạt hơn để làm việc và bạn biết nó có thể mở rộng khi bạn cần. (Mặc dù tôi thiên vị - Tôi làm việc trong dự án MongoDB)

Ai cần phân phối, phân chia diễn đàn? Có thể là Facebook, nhưng trừ khi bạn đang tạo đối thủ cạnh tranh với Facebook, chỉ cần sử dụng Mysql, Postgres hoặc bất cứ điều gì bạn cảm thấy thoải mái nhất. Nếu bạn muốn dùng thử MongoDB, ok, nhưng đừng hy vọng nó sẽ làm nên điều kỳ diệu cho bạn. Nó sẽ có những điều kỳ quặc và khó chịu chung, giống như mọi thứ khác, vì tôi chắc chắn rằng bạn đã phát hiện ra nếu bạn thực sự đã làm việc với nó.

Chắc chắn, MongoDB có thể được thổi phồng và có vẻ dễ dàng trên bề mặt, nhưng bạn sẽ gặp phải những vấn đề mà các sản phẩm trưởng thành hơn đã khắc phục. Đừng bị dụ dỗ dễ dàng như vậy, mà hãy đợi cho đến khi "nosql" đáo hạn hoặc chết.

Cá nhân, tôi nghĩ rằng "nosql" sẽ khô héo và chết vì phân mảnh, vì không có tiêu chuẩn nào được đặt ra (gần như theo định nghĩa). Vì vậy, cá nhân tôi sẽ không đặt cược vào nó cho bất kỳ dự án dài hạn nào.

Điều duy nhất có thể lưu "nosql" trong cuốn sách của tôi là nếu nó có thể tích hợp vào Ruby hoặc các ngôn ngữ tương tự một cách liền mạch và làm cho ngôn ngữ trở nên "bền bỉ", gần như không có bất kỳ chi phí nào trong mã hóa và thiết kế. Điều đó có thể đi qua, nhưng tôi sẽ đợi cho đến lúc đó, không phải bây giờ, VÀ dĩ nhiên nó cần phải trưởng thành hơn.

Btw, tại sao bạn tạo một diễn đàn từ đầu? Có rất nhiều diễn đàn nguồn mở có thể được điều chỉnh để phù hợp với hầu hết các yêu cầu, trừ khi bạn thực sự đang tạo Thế hệ tiếp theo của Diễn đàn (mà tôi nghi ngờ).

Tôi đã thấy rất nhiều công ty đang sử dụng MongoDB để phân tích thời gian thực từ nhật ký ứng dụng. Lược đồ của nó thực sự phù hợp với nhật ký ứng dụng, trong đó lược đồ ghi có xu hướng thay đổi theo thời gian. Ngoài ra, tính năng Capped Collection của nó rất hữu ích vì nó tự động xóa dữ liệu cũ để giữ dữ liệu vừa với bộ nhớ.

Đó là một lĩnh vực tôi thực sự nghĩ MongoDB phù hợp, nhưng nói chung MySQL / PostgreSQL được khuyến nghị nhiều hơn. Có rất nhiều tài liệu và tài nguyên dành cho nhà phát triển trên web, cũng như chức năng và sự mạnh mẽ của chúng.

Hai lý do chính khiến bạn muốn Mongo là

• Tính linh hoạt trong thiết kế lược đồ (kho lưu trữ tài liệu kiểu JSON).
• Khả năng mở rộng - Chỉ cần thêm các nút và nó có thể mở rộng theo chiều ngang khá tốt.

Nó phù hợp cho các ứng dụng dữ liệu lớn. RDBMS không tốt cho dữ liệu lớn.

Bạn biết đấy, tất cả những thứ này về các liên kết và 'giao dịch phức tạp' - nhưng chính Monty, người, nhiều năm trước, đã giải thích "nhu cầu" cho CAMIT / ROLLBACK, nói rằng 'tất cả những gì được thực hiện trong các lớp logic (và không phải cơ sở dữ liệu) dù sao đi nữa '- vì vậy nó lại giống nhau một lần nữa. Những gì cần thiết là một công cụ lưu trữ / truy xuất dữ liệu cực kỳ gọn gàng và cực kỳ gọn gàng, cho 99% những gì ứng dụng web làm.

Giống như đã nói trước đây, bạn có thể chọn giữa rất nhiều lựa chọn, hãy xem tất cả các lựa chọn đó: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Những gì tôi đề xuất là tìm sự kết hợp tốt nhất của bạn: MySQL + Memcache thực sự tuyệt vời nếu bạn cần ACID và bạn muốn tham gia một số bảng MongoDB + Redis hoàn hảo cho kho lưu trữ tài liệu Neo4J hoàn hảo cho cơ sở dữ liệu đồ thị

Những gì tôi làm: Tôi bắt đầu với MySQl + Memcache vì tôi đang sử dụng, sau đó tôi bắt đầu sử dụng khung cơ sở dữ liệu khác. Trong một dự án duy nhất, bạn có thể kết hợp MySQL và MongoDB chẳng hạn!