Налаштування NoSQL проти інших SQL Drupal


14

Які переваги роботи NoSQL (колишній MongoDB) над MySQL, PostGRE SQL або MSSQL в Drupal? Чи є переваги, отримані від простого використання пам’яті чи потрібно змінити конфігурацію Drupal?


Це питання, на яке Каролі Негєсі дав би "авторитетну" відповідь. Він точно знає перевагу використання MongoDB з Drupal.
kiamlaluno

Прочитайте міркування ... дуже зацікавлені в інших варіантах, якщо є істотні переваги, і звичайно плюси мають мінуси.
Кевін

Відповіді:


13

MongoDB можна використовувати для зберігання більшості або всіх ваших організацій у швидкому, орієнтованому на документ сховищі. Цей тип шкал зберігання набагато кращий, ніж стандартне сховище на основі SQL, яке ми маємо в ядрі Drupal (яке базується на схемі "одна таблиця на поле").

У поточному стані Drupal 7 у вас буде:

  • Базова таблиця сутності, що зберігається в SQL (тобто таблиця користувачів, таблиця вузлів тощо)
  • Усі поля, що зберігаються в SQL
  • Властивості сутностей їх базових таблиць дублюються в MongoDB

Це дозволяє швидко запитувати сутностей у MongoDB та можливість додавати складні індекси, які не підтримують базу даних SQL Opensource (включаючи індекси в таблицях). У той же час ви не втрачаєте інтероперабельність, оскільки базова таблиця об'єкта все ще зберігається в SQL і, таким чином, може бути приєднана до модулів, які все ще є лише SQL (наприклад, Прапор).

Цей тип швидкого запиту доступний завдяки механізму EntityFieldQuery, способу абстрактного побудови запитів про сутності, їх властивості та поля. Реалізація за замовчуванням в ядрі переводить ці запити в SQL, але модуль MongoDB має повнофункціональну реалізацію, яка може задовольнити ці запити з MongoDB безпосередньо.

Завдяки програмі EntityFieldQuery для Views , ви можете легко використовувати цю потужність за допомогою інструментів, до яких ви звикли. Єдиним недоліком є ​​те, що відносини не підтримуються (але на практиці їх рідко все-таки потрібні - і це можна вирішити шляхом введення додаткових даних в об'єкт сутності та додавання викриття їх як додаткових властивостей сутності).

Коротше кажучи, щойно ефективність запитів є проблемою у вашому проекті, яка відбувається, як тільки у вас є значний набір даних (скажімо, починаючи з кількох десятих тисяч об'єктів для даного типу сутності), MongoDB - це чистий прибуток за дуже мало недоліків. Настійно рекомендується.


Деміен Турноуд: Якщо у вас виникли проблеми з продуктивністю лише декількох десятих тисяч записів, то, ймовірно, існує основна проблема (конфігурація СУБД, погано написані запити, це може бути все, що завгодно). Якщо лежить в основі схеми SQL досить добре, вам не доведеться хвилюватися перед мільйоном записів в одній таблиці (але поля можуть швидко зростати, якщо ви, мабуть, вважаєте редакції та багатозначні поля).
П’єр

Моя річ точно: наша схема нормалізована, і як наслідок, дуже низька продуктивність запитів. Щоб покращити продуктивність запитів, вам потрібно денормалізувати схему. Основна перевага використання MongoDB в нашому випадку полягає в тому, що це якийсь "двигун автоматичної денормалізації".
Дамієн Турноуд

І звичайно, MongoDB тут чудовий, тому що це база даних, орієнтована на документи. Зберігання складних документів, таких як сутності у сховищі SQL, просто нерозумно. Це наша реалізація за замовчуванням, але це не означає, що ви повинні використовувати її :)
Damien Tournoud

@Pierre: Демієн говорив про кілька десятих тисяч сутностей , що може бути зовсім іншою річчю, ніж рядки таблиць. Наприклад, у вас може бути 10 або більше полів для цієї сутності, тоді у вас є 10 додаткових таблиць, які потрібно запитувати окремим запитом при кожному завантаженні такої сутності. І MongoDB може замінити ці додаткові таблиці, а не базову таблицю сутності.
Бердір

2
Жоден модуль не повинен очікувати, що поля будуть у MySQL. Єдиний спосіб запиту полів на Drupal 7 - це EntityFieldQuery. Відкрийте помилку в модулі, якщо він безпосередньо запитує таблиці полів. Наразі я не знаю жодного з цих модулів.
Дамієн Турноуд

7

MongoDB та подібні розроблені для зберігання структурованих (ієрархічних) даних порівняно гнучко.

Наприклад, у Drupal 7випадку використання field_sql_storageкожного поля отримує дуже власні таблиці. Коли ви додаєте 10 полів до типу вмісту, ви отримуєте 10 таблиць у вашій базі даних. Завантажуючи цей вузол, field_sql_storageвін виконує запит на поле та на вузол (або кілька вузлів при використанні node_load_multiple).

Коли ви використовуєте mongodb_field_storage , ви можете зберігати всі поля вузла в одному документі і отримувати з одним запитом.

Ви також можете зберігати інші речі, такі як сторожовий дог, сеанси, кеш, блоки в MongoDB .

Ви все ще потребуєте MySQL, проте MongoDB не замінює його (лише для конкретних частин).

Ще одна перевага полягає в тому, що з MongoDB простіше масштабувати, ви можете додати багато серверів, щоб кластер обмінювався даними між ними.


Привіт Бердіре! Чи знаєте ви, якби я запустив MongoDB в існуючий проект для перевірки працездатності, чи дозволить я відключити модуль без наслідків? Я хочу спробувати монго, але що робити, якщо це не працює, чи щось? Чи безпечно спробувати? (Я знаю, ви не можете цього гарантувати, але мені цікаво, що відбувається в більшості випадків)
Beto Aveiga

1
Ну, для початку ви не можете просто випустити його. Кожне поле налаштовує, який резервний сервер пам’яті він використовує, вам доведеться змінити / знову створити свої поля, заново створити свої представлення (так як вони повинні використовувати бекенд efq_views ), можливо, ваші власні запити, якщо ви писали прямі запити проти польових таблиць даних. Можливо, буде легше відновити таку ж структуру в новій установці для початкового порівняння.
Бердір

Дякую Бердіре! Я спробував MongoDB кілька днів тому, але не було помітного підвищення продуктивності, але також я не знав про речі / зміни, про які ви мені зараз говорите. Я подумав, що "MongoDB повинен змінити великі сайти". Я спробую MongoDB ще раз.
Beto Aveiga

5

Плюси приходять із мінусами.

Drupal в цілому не може бути переключений на MongoDb, тому вам доведеться підтримати дві бази даних і переконатися, що вони добре працюють разом.

Багато модулів не зможуть працювати з mongodb, тому ви втратите сумісність.

Якщо у вас є нагальна потреба (наприклад, частина вашої системи не справляється з кількістю запиту / або кількістю даних) я б не перемикався. І навіть коли ви починаєте наближатись до обмежень, погляньте на те, щоб кинути апаратне забезпечення на проблему чи налаштування перед перемиканням.

Я думав, що відповів на це раніше, є майже дублікат на ПУ

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.