Tôi đã từng xây dựng ứng dụng Ruby on Rails với MySQL.MongoDB vs MySQL
MongoDB hiện nay ngày càng trở nên nổi tiếng và hiện tôi đang bắt đầu thử.
Vấn đề là, tôi không biết lý thuyết cơ bản về cách MongoDB đang làm việc (đang sử dụng đá quý mongoid nếu nó quan trọng)
Vì vậy, tôi muốn có một sự so sánh về hiệu suất giữa việc sử dụng MySQL + ActiveRecord và mô hình được tạo ra bởi mongoid đá quý, bất cứ ai có thể giúp tôi tìm ra nó?
Bài viết có tựa đề: What the heck are you actually using NoSQL for? thực hiện công việc rất tốt khi trình bày ưu và nhược điểm của việc sử dụng NoSQL.
Edit: Ngoài ra đọc http://blog.fatalmind.com/2011/05/13/choosing-nosql-for-the-right-reason/ bài viết trên blog quá
Re-edit: Tôi tìm thấy một số tài liệu gần đây (xuất bản năm 2014) về chủ đề này mà tôi cho là có liên quan: What’s left of NoSQL?
Nó không nhận được các chi tiết hoặc chi tiết cụ thể về thời điểm sử dụng một triển khai NoSQL so với cách khác, như tiêu đề sẽ đề xuất, tuy nhiên trường hợp được thực hiện khá tốt. Không sử dụng một cái gì đó chỉ vì bạn có thể hoặc đó là xu hướng mới nhất hoặc từ/thuật ngữ/công nghệ buzz. Có thể công cụ bạn đã hoạt động hoàn hảo, nhưng bạn không sử dụng nó đúng cách. Khi nói đi: Một công nhân xấu đổ lỗi cho công cụ của mình. Dù bằng cách nào, đạo đức của câu chuyện cũng được phát hiện. –
Như @MattSetter cho biết, không sử dụng một cái gì đó chỉ vì bạn có thể hoặc vì nó hợp thời trang. Tôi sẽ bổ sung điều này: hầu hết các dữ liệu không có quan hệ chặt chẽ hoặc dựa trên tài liệu và MongoDB rất dễ mở rộng. – wprl
Tôi không biết nhiều về lý thuyết cơ bản. Nhưng đây là lời khuyên tôi nhận được: chỉ sử dụng MongoDB nếu bạn chạy nó trên nhiều máy chủ; đó là khi nó sẽ tỏa sáng. Theo như tôi hiểu, phong trào NoSQL xuất hiện một phần không nhỏ do nỗi đau của cơ sở dữ liệu quan hệ cân bằng tải trên nhiều máy chủ. Vì vậy, nếu bạn đang lưu trữ ứng dụng của mình trên không nhiều máy chủ, MySQL sẽ là lựa chọn ưu tiên.
Những người tốt qua tại Doctrine project gần đây đã viết một số khá hữu ích blog post về chủ đề này.
Có bất kỳ tính năng nào trong MongoDB làm cho nó phù hợp hơn cho nhiều máy chủ không ? – PeterWong
Giống như nhiều giải pháp tìm kiếm, MongoDB sử dụng "sharding". Đó là cách tách các dải dữ liệu trên nhiều máy chủ. Ngoài ra, kể từ khi MongoDB thiếu nhiều tính năng toàn vẹn dữ liệu của cơ sở dữ liệu quan hệ, nó sẽ được chạy trên không ít hơn hai máy chủ (một bậc thầy và một nô lệ). http: //en.wikipedia.org/wiki/MongoDB – Henrik
Cơ sở dữ liệu quan hệ hỗ trợ sharding. Các giải pháp NoSQL không hỗ trợ các giao dịch và thường thất bại trong các bản ghi xả vào đĩa. Chúc may mắn trong việc sử dụng chúng, nơi nhất quán dữ liệu là phải. –
Từ những gì tôi đã đọc cho đến nay ... đây là của tôi về nó.
Giao dịch SQL tiêu chuẩn có hiệu suất thấp hơn cho tính năng phong phú ... tức là nó cho phép bạn thực hiện Ghép và Giao dịch trên các tập dữ liệu (bảng/bộ sưu tập nếu bạn muốn) trong số những thứ khác.
Điều này cho phép nhà phát triển ứng dụng đẩy một số ứng dụng phức tạp vào lớp cơ sở dữ liệu. Điều này có lợi thế là không phải lo lắng về tính toàn vẹn dữ liệu và phần còn lại của các thuộc tính ACID của ứng dụng bằng cách phụ thuộc vào công nghệ đã được chứng minh. Việc thiếu khả năng mở rộng cực kỳ hiệu quả cho tất cả các dự án miễn là có thể quản lý ứng dụng trong thời gian dự kiến, đôi khi dẫn đến việc phải mua các hệ thống cơ sở dữ liệu quan hệ/hiệu năng cao.
Mặt khác, Mongo DB, cố ý loại trừ phần lớn sự phức tạp vốn có liên quan đến cơ sở dữ liệu quan hệ, bằng cách cho phép hiệu suất có thể mở rộng tốt hơn. Cách tiếp cận này buộc nhà phát triển ứng dụng phải kiến trúc lại ứng dụng để làm việc xung quanh việc thiếu các tính năng quan hệ ... mà chính bản thân nó là một điều tốt, nhưng nỗ lực liên quan thường chỉ đáng giá nếu bạn có khả năng mở rộng yêu cầu. Xin lưu ý rằng với MongoDB tùy thuộc vào yêu cầu dữ liệu w.r.t thuộc tính ACID, ứng dụng sẽ phải đẩy mạnh và xử lý khi cần thiết.
Bạn nói chung, nhưng tôi muốn chỉ ra rằng Mongo là "chủ yếu" ACID tuân thủ ở cấp tài liệu. Tham gia là ma quỷ. Cả hai cạm bẫy tiềm ẩn này đều ít gây ra vấn đề hơn bằng cách lập kế hoạch thiết kế cơ sở dữ liệu để tránh sự cần thiết phải tham gia hoặc ghi vào nhiều tài liệu. Định nghĩa lược đồ được thực hiện trong ứng dụng, nhưng có thể được thực hiện bằng cách sử dụng thư viện, do đó, nó không quá khác với việc xác định sơ đồ của bạn, ví dụ: một tệp hibernate.xml (exept, như bạn nói, các định nghĩa lược đồ được thực thi trong ứng dụng, không phải trong cơ sở dữ liệu). – wprl
Bạn có thể thấy điều này thú vị và thú vị khi nghe http://www.xtranormal.com/watch/6995033/mongo-db-is-web-scale – dkroy