SQL (MySQL) so với NoQuery (CouchDB) [đã đóng]

Tôi đang trong giai đoạn thiết kế một ứng dụng có khả năng mở rộng cao, phải lưu trữ nhiều dữ liệu. Ví dụ, nó sẽ lưu trữ rất nhiều về người dùng và sau đó là rất nhiều tin nhắn, bình luận của họ, v.v. Tôi đã luôn sử dụng MySQL trước đây nhưng bây giờ tôi có ý định thử một cái gì đó mới như couchdb hoặc tương tự không phải là SQL.

Có ai có bất kỳ suy nghĩ hoặc hướng dẫn về điều này?

Đây là một trích dẫn từ một bài đăng trên blog gần đây từ Dare Obasanjo .

Cơ sở dữ liệu SQL giống như truyền tự động và cơ sở dữ liệu NoQuery giống như truyền thủ công. Khi bạn chuyển sang NoQuery, bạn phải chịu trách nhiệm cho rất nhiều công việc mà hệ thống sẽ tự động xử lý trong một hệ thống cơ sở dữ liệu quan hệ. Tương tự như những gì xảy ra khi bạn chọn thủ công qua hộp số tự động. Thứ hai, NoQuery cho phép bạn tăng thêm hiệu năng ra khỏi hệ thống bằng cách loại bỏ rất nhiều kiểm tra tính toàn vẹn được thực hiện bởi cơ sở dữ liệu quan hệ khỏi tầng cơ sở dữ liệu. Một lần nữa, điều này tương tự như cách bạn có thể đạt được hiệu suất cao hơn từ chiếc xe của mình bằng cách lái hộp số tay so với xe số tự động.

Tuy nhiên, điểm tương đồng đáng chú ý nhất là giống như hầu hết chúng ta không thể tận dụng lợi ích của xe số tay vì phần lớn lái xe của chúng ta đang ngồi trên đường trên đường và đi làm, có một thực tế khắc nghiệt tương tự trong đó hầu hết các trang web không ở quy mô của Google hoặc Facebook và do đó không cần Bigtable hoặc Cassandra.

Tôi chỉ có thể thêm việc chuyển đổi từ MySQL, nơi bạn có ít nhất một số kinh nghiệm, sang CouchDB, nơi bạn không có kinh nghiệm, nghĩa là bạn sẽ phải giải quyết một loạt vấn đề mới và tìm hiểu các khái niệm khác nhau và thực tiễn tốt nhất. Mặc dù điều này thật tuyệt vời (tôi đang chơi ở nhà với MongoDB và thích nó rất nhiều), đó sẽ là một chi phí mà bạn cần tính toán khi ước tính công việc cho dự án đó và mang lại rủi ro chưa biết trong khi hứa hẹn những lợi ích chưa biết. Sẽ rất khó để đánh giá nếu bạn có thể thực hiện dự án đúng thời hạn và với chất lượng bạn muốn / cần thành công, nếu nó dựa trên công nghệ mà bạn không biết.

Bây giờ, nếu bạn có trong nhóm một chuyên gia trong lĩnh vực NoQuery, thì bằng mọi cách hãy xem xét kỹ về nó. Nhưng không có bất kỳ chuyên môn nào trong nhóm, đừng nhảy vào NoQuery cho một dự án thương mại mới.

Cập nhật : Chỉ cần ném một ít xăng vào lửa mở bạn đã bắt đầu, đây là hai bài viết thú vị từ những người trong trại SQL. :-)

Tôi không thể chờ đợi NoQuery chết (bài viết gốc đã biến mất, đây là bản sao )
Chiến đấu với tư duy NoQuery, mặc dù đây không phải là một bản
cập nhật chống NoQuery : Vâng đây là một bài viết thú vị về NoQuery
Tạo cảm giác về NoQuery

Có vẻ như chỉ có các giải pháp thực sự ngày nay xoay quanh việc nhân rộng hoặc bỏ đi. Tất cả các cơ sở dữ liệu hiện đại (NoQuery cũng như NewQuery) đều hỗ trợ mở rộng theo chiều ngang ra khỏi hộp, ở lớp cơ sở dữ liệu, mà không cần ứng dụng phải có mã shending hoặc thứ gì đó.

Thật không may, đối với MySQL cũ tốt đáng tin cậy, shending không được cung cấp "ngoài luồng". ScaleBase (từ chối trách nhiệm: Tôi làm việc ở đó) là nhà sản xuất một giải pháp mở rộng quy mô hoàn chỉnh, một "máy bảo vệ tự động" nếu bạn muốn. ScaleBae phân tích dữ liệu và luồng SQL của bạn, phân chia dữ liệu qua các nút DB và tổng hợp trong thời gian chạy - vì vậy bạn sẽ không phải! Và nó miễn phí tải về.

Đừng hiểu sai ý tôi, NoQuery rất tuyệt, chúng mới, mới là lựa chọn nhiều hơn và lựa chọn luôn tốt !! Nhưng việc chọn NoQuery đi kèm với một mức giá, đảm bảo bạn có thể trả nó ...

Bạn có thể xem thêm ở đây một số dữ liệu về MySQL, NoQuery ...: http://www.scalebase.com/extternal-scalability-with-mongodb-and-mysql-part-1-auto-shending

Hy vọng rằng đã giúp.

Một trong những lựa chọn tốt nhất là sử dụng MongoDB (NOSql dB) hỗ trợ khả năng mở rộng. Tạo ra lượng lớn dữ liệu không có gì ngoài bigdata ở dạng tài liệu không giống như các hàng và bảng trong sql. để đảm bảo dữ liệu đảm bảo duy trì nhiều máy chủ có máy chủ db chính làm cơ sở. Ngôn ngữ độc lập. Linh hoạt để sử dụng