Có ý nghĩa gì khi sử dụng cả hai mongodb và mysql trong cùng một ứng dụng đường ray?

Question

Tôi có một lý do chính đáng để sử dụng MongoDB cho một phần ứng dụng của mình. Nhưng mọi người thường mô tả nó không phù hợp cho các ứng dụng "giao dịch" như ngân hàng nơi giao dịch phải chính xác/nhất quán, v.v.

Có ý nghĩa khi chia nhỏ mô hình trong Rails và sử dụng một số mô hình trong Rails MySql và những người khác mongo? Hay điều này thường sẽ gây ra nhiều vấn đề hơn nó đáng giá?

Tôi không xây dựng ứng dụng ngân hàng hay bất kỳ thứ gì nhưng nghĩ rằng nó có thể có ý nghĩa đối với bảng hoặc bảng giao dịch của người dùng của tôi (ghi doanh thu) để thực hiện điều đó trong MySql.

Answer 1

Đó là những gì chúng tôi làm với CouchDB và PostgreSQL.

Tất cả các loại người dùng và nhóm của chúng tôi đều có trong cơ sở dữ liệu postgresql.
Bất cứ điều gì khác (trong trường hợp của chúng tôi, một số hồ sơ có số liệu thống kê) nằm trong cơ sở dữ liệu couchdb.

Trong trường hợp của chúng tôi, nó cho phép chúng tôi có một cơ sở dữ liệu couchdb cho mỗi khách hàng (ứng dụng tự kết nối với một hoặc một tùy thuộc vào máy chủ của người dùng).
Và chỉ có một cơ sở dữ liệu postgresql có tất cả người dùng trong đó.

Vì vậy, có, tôi nghĩ rằng nên có một cơ sở dữ liệu SQL và NOSQL trong cùng một ứng dụng.

Answer 2

Tôi sẽ cảnh giác với cách tiếp cận chia nhỏ mặc dù tôi sẽ không loại trừ nó. Nếu bạn cần MySQL + InnoDB và nó giống như bạn làm, tôi chỉ giới thiệu MongoDB cho các phần riêng biệt hơn có thứ gì đó quan trọng để đạt được từ những lợi ích mà MongoDB mang lại, và có mối quan hệ tối thiểu với các bảng MySQL cốt lõi .

Tôi hiện đang vật lộn với cùng một vấn đề, một ứng dụng Rails với 20 bảng trên MySQL. Sử dụng MongoDB sẽ giải quyết một số tai ương thiết kế cơ sở dữ liệu (lồng sub-đối tượng và cột mảng lập chỉ mục đặc biệt), nhưng thật khó để biện minh cho việc overhead thêm:

• 2 phương pháp truy vấn khác nhau
• Awkward mã tùy chỉnh dọc theo vỉa của Các đối tượng MySQL/Mongo liên quan đến nhau.
• Nền tảng cơ sở dữ liệu thứ hai hỗ trợ trong sản xuất.

Tôi đang trong quá trình triển khai MongoDB cho bảng đăng nhập của mình và tôi sẽ lấy nó từ đó.

Answer 3

Tôi muốn nói bạn đã trả lời câu hỏi của riêng bạn tại đây.

Tôi có lý do chính đáng để sử dụng mongodb cho một phần của ứng dụng của tôi.

Giả sử bạn cũng có lý do chính đáng để giữ các phần khác trong MySQL, tôi cho rằng câu trả lời là có. Câu hỏi của bạn ngụ ý (ít nhất là với tôi) rằng bạn có hiểu biết tốt về các tùy chọn khác nhau và điểm mạnh và điểm yếu của chúng và do đó đạt được một kết luận hợp lý trong việc chia nhỏ mô hình của bạn là có thể thực hiện được.

Giả sử hai nửa không liên kết theo cách nào đó (mối quan hệ giữa hai âm thanh như công thức để giảm đau sau này), tôi khuyên bạn nên sử dụng nó và sử dụng từng công cụ cho những gì tốt nhất.

Có thể giải quyết một số mối quan tâm mà Michael nêu ra với phương pháp này. vì bạn đang tập trung vào việc sử dụng Rails, bạn có thể sử dụng ActiveRecord cho các mô hình dựa trên MySQL của mình và sử dụng MongoMapper cho các mô hình dựa trên MongoDb của bạn. Bằng cách này, bạn sẽ không phải đối phó với hai phương thức truy vấn hoàn toàn khác nhau vì MongoMapper cung cấp một cách tiếp cận rất ActiveRecordish. Tất nhiên, bạn có thể dễ dàng thả xuống vào truy vấn Mongo cụ thể và khi bạn cần.

Mối quan tâm liên quan đến mối quan hệ chéo-DB là hợp lệ theo ý kiến ​​của tôi và nếu đây là điều bạn muốn có, tôi chắc chắn sẽ khuyên bạn nên kiểm tra tình huống để đảm bảo đây là điều bạn hạnh phúc khi sống với. Tôi tưởng tượng bạn có thể tiết kiệm rất nhiều đau cho sau này trong trường hợp cụ thể đó.

Nhìn chung, tôi khuyên bạn nên miễn là hai nửa của bạn tương đối bị ngắt kết nối với nhau, lớp kiên trì chia tách sẽ hoạt động tốt cho bạn.

Answer 4

Nghĩ về độ bền: http://blog.mongodb.org/post/381927266/what-about-durability, ví dụ khi bạn mất điện (điện).

Answer 5

Không có lý do gì khiến bạn không thể giữ bảng người dùng của mình trong MongoDB. Cho dù bạn quyết định giữ một bảng giao dịch trong MongoDB là một câu hỏi khác. Nếu bạn cần các giao dịch đa đối tượng, thì bạn phải sử dụng một cơ sở dữ liệu quan hệ có hỗ trợ các giao dịch. Nếu bạn không cần kiểu giao dịch này, thì việc sử dụng MongoDB cho điều này vẫn có thể là một ý tưởng hay.

Hãy nhớ rằng nếu bạn sử dụng MongoDB, chúng tôi khuyên bạn nên chạy với bản sao cho chuyển đổi dự phòng. Điều cần lưu ý là nếu bạn đang sử dụng một cơ sở dữ liệu quan hệ vì sự đảm bảo nhất quán, bạn vẫn cần đảm bảo rằng phần cứng của bạn được cấu hình để tận dụng các tính năng đó. Xem các lưu ý cảnh báo ở đây:

http://dev.mysql.com/doc/refman/4.1/en/innodb-configuration.html

Nếu bạn không dùng các biện pháp phòng ngừa, sau đó không phải là một sự khác biệt lớn giữa độ bền MongoDB và của một cơ sở dữ liệu quan hệ.