NoQuery so với các thiết lập Drupal SQL khác

Những lợi thế của việc chạy NoQuery (ex MongoDB) so với MySQL, PostGRE SQL hoặc MSSQL trong Drupal là gì? Là những lợi thế có được từ việc sử dụng lưu trữ đơn giản hay một số cấu hình Drupal cần phải thay đổi?

MongoDB có thể được sử dụng để lưu trữ hầu hết hoặc tất cả các thực thể của bạn vào bộ lưu trữ hướng tài liệu nhanh. Loại lưu trữ này chia tỷ lệ tốt hơn so với lưu trữ dựa trên SQL tiêu chuẩn mà chúng ta có trong lõi Drupal (dựa trên lược đồ "một bảng trên mỗi trường").

Trong trạng thái hiện tại của Drupal 7, bạn sẽ có:

• Bảng cơ sở của thực thể được lưu trữ trên SQL (ví dụ: bảng người dùng, bảng nút, v.v.)
• Tất cả các trường được lưu trữ trong SQL
• Các thuộc tính của các thực thể từ các bảng cơ sở của chúng được nhân đôi trong MongoDB

Điều này cho phép truy vấn nhanh trên các thực thể trên MongoDB và khả năng thêm các chỉ mục phức tạp không hỗ trợ cơ sở dữ liệu SQL Opensource (bao gồm các chỉ mục trên các bảng). Đồng thời, bạn không mất khả năng tương tác vì bảng cơ sở của thực thể vẫn được lưu trữ trong SQL và do đó có thể được nối bởi các mô-đun vẫn chỉ có SQL (như Flag).

Kiểu truy vấn nhanh này có sẵn nhờ cơ chế EntityFieldQuery, một cách để xây dựng truy vấn trên các thực thể, thuộc tính và trường của chúng theo cách trừu tượng. Việc triển khai mặc định trong lõi dịch các truy vấn đó sang SQL, nhưng mô-đun MongoDB có triển khai đầy đủ tính năng có thể đáp ứng trực tiếp các truy vấn đó từ MongoDB.

Nhờ vào phụ trợ EntityFieldQuery cho Chế độ xem , bạn có thể dễ dàng tận dụng sức mạnh này, bằng cách sử dụng các công cụ bạn đã quen. Nhược điểm duy nhất là các mối quan hệ không được hỗ trợ (nhưng trong thực tế, bạn hiếm khi cần chúng - và điều này có thể được khắc phục bằng cách đẩy dữ liệu bổ sung vào đối tượng thực thể và thêm hiển thị chúng dưới dạng các thuộc tính bổ sung của thực thể).

Tóm lại, ngay khi hiệu suất truy vấn là một vấn đề trong dự án của bạn, điều này xảy ra ngay khi bạn có một bộ dữ liệu quan trọng (giả sử bắt đầu từ một phần mười của hàng ngàn thực thể trên một loại thực thể nhất định), MongoDB là một lợi ích ròng cho rất rất ít nhược điểm. Rất khuyến khích.

MongoDB và tương tự được thiết kế để lưu trữ dữ liệu có cấu trúc (phân cấp) theo cách tương đối linh hoạt.

Ví dụ Drupal 7, khi sử dụng field_sql_storage, mọi trường đều có các bảng rất riêng. Khi bạn đính kèm 10 trường vào một loại nội dung, bạn sẽ có 10 bảng trong cơ sở dữ liệu của mình. Khi bạn tải nút đó, field_sql_storagesẽ thực hiện truy vấn trên mỗi trường và trên mỗi nút (hoặc nhiều nút, khi sử dụng node_load_multiple).

Khi bạn sử dụng mongodb_field_st Storage , bạn có thể lưu trữ tất cả các trường của một nút trong một tài liệu duy nhất và nhận được với một truy vấn duy nhất.

Bạn cũng có thể lưu trữ những thứ khác như watchdog, session, cache, blocks trong MongoDB .

Tuy nhiên, bạn vẫn cần MySQL, MongoDB không thay thế nó (chỉ dành cho các phần cụ thể).

Một ưu điểm khác là nó dễ dàng hơn với MongoDB quy mô , bạn có thể thêm nhiều máy chủ vào một cụm chia sẻ dữ liệu giữa chúng.

Các ưu đi kèm với khuyết điểm.

Toàn bộ Drupal không thể được chuyển sang MongoDb, vì vậy bạn sẽ phải hỗ trợ hai cơ sở dữ liệu và đảm bảo chúng hoạt động tốt với nhau.

Nhiều mô-đun sẽ không thể làm việc với mongodb, do đó bạn sẽ mất khả năng tương tác.

Trừ khi bạn có nhu cầu cấp bách (như một phần trong hệ thống của bạn không đối phó với số lượng yêu cầu / hoặc lượng dữ liệu) tôi sẽ không chuyển đổi. Và ngay cả khi bạn bắt đầu tiếp cận giới hạn, hãy nhìn vào việc ném phần cứng vào vấn đề hoặc điều chỉnh trước khi chuyển đổi.

Tôi nghĩ rằng tôi đã trả lời điều này trước đây, có một sự trùng lặp gần như trên SO