NoSQL против других настроек SQL Drupal

Каковы преимущества запуска NoSQL (ex MongoDB) над MySQL, PostGRE SQL или MSSQL в Drupal? Получаются ли преимущества от простого использования хранилища или нужно изменить какую-то конфигурацию Drupal?

7 database

— Kevin
источник

Это вопрос, на который Кароли Негьеси дала бы «авторитетный» ответ. Он, безусловно, знает преимущество использования MongoDB с Drupal.

— kiamlaluno

Читайте мои мысли .. очень интересует другие варианты, если есть существенные преимущества, и, конечно, плюсы приходят с минусами.

— Кевин

Ответы:

MongoDB может использоваться для хранения большинства или всех ваших объектов в быстром, ориентированном на документы хранилище. Этот тип хранилища масштабируется намного лучше, чем стандартное хранилище на основе SQL, которое мы имеем в ядре Drupal (которое основано на схеме «одна таблица на поле»).

В текущем состоянии Drupal 7 у вас будет:

Базовая таблица сущности, хранящаяся в SQL (т. Е. Таблица пользователей, таблица узлов и т. Д.)
Все поля хранятся в SQL
Свойства сущностей из их базовых таблиц, дублированных в MongoDB

Это позволяет быстро запрашивать объекты в MongoDB и добавлять сложные индексы, которые не поддерживаются базой данных Opensource SQL (включая индексы по таблицам). В то же время вы не потеряете совместимость, потому что базовая таблица сущности все еще хранится в SQL и, таким образом, может быть объединена с модулями, которые все еще только для SQL (например, Flag).

Этот тип быстрых запросов доступен благодаря механизму EntityFieldQuery, способу абстрактного построения запросов к сущностям, их свойствам и их полям. Реализация по умолчанию в ядре переводит эти запросы в SQL, но модуль MongoDB имеет полнофункциональную реализацию, которая может удовлетворить эти запросы непосредственно из MongoDB.

Благодаря бэкэнду EntityFieldQuery для Views вы можете легко использовать эту мощь, используя инструменты, к которым вы привыкли. Единственным недостатком является то, что отношения не поддерживаются (но на практике они вам все равно редко нужны - и это можно обойти, добавив дополнительные данные в объект сущности и добавив их в качестве дополнительных свойств сущности).

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

— Дэмиен Турноуд
источник

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

— Пьер

Моя точка зрения точно: наша схема нормализована и, как следствие, имеет очень плохую производительность запросов. Чтобы повысить производительность запросов, вам нужно денормализовать схему. Основным преимуществом использования MongoDB в нашем случае является то, что это своего рода «автоматический механизм денормализации».

— Дэмиен Турноуд

И, конечно, MongoDB великолепен, потому что это база данных, ориентированная на документы. Хранить сложные документы, такие как объекты в хранилище SQL, просто глупо. Это наша реализация по умолчанию, но это не значит, что вы должны ее использовать :)

— Дэмиен Турноуд

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

— Бердир

Ни один модуль не должен ожидать, что поля будут в MySQL. Единственный способ запроса полей в Drupal 7 - это EntityFieldQuery. Откройте ошибку в модуле, если он запрашивает таблицы полей напрямую. Я не знаю ни одного из этих модулей в настоящее время.

— Дэмиен Турноуд

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

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

Когда вы используете mongodb_field_storage , вы можете хранить все поля узла в одном документе и получать с помощью одного запроса.

Вы также можете хранить другие вещи, такие как сторожевой таймер, сессии, кеш, блоки в MongoDB .

Тем не менее, вам все еще нужен MySQL, MongoDB не заменяет его (только для определенных частей).

Еще одним преимуществом является то, что с MongoDB проще масштабировать, вы можете добавить много серверов в кластер, чтобы обмениваться данными между ними.

— Berdir
источник

Привет Бердир! Знаете ли вы, если я уроню MongoDB в существующий проект для проверки производительности, я бы включил и отключил модуль без последствий? Я хочу попробовать монго, но что, если он не работает или что-то? Это безопасно попробовать? (Я знаю, что вы не можете гарантировать это, но мне интересно, что происходит в большинстве случаев)

— Бето Авейга

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

— Бердир

Спасибо Бердир! Я попробовал MongoDB несколько дней назад, но прирост производительности не был заметен, но я также не знал, что вы говорите мне сейчас. Я думал, что "MongoDB должен иметь значение на больших сайтах". Я попробую MongoDB снова.

— Бето Авейга

Плюсы идут с минусами.

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

Многие модули не смогут работать с mongodb, поэтому вы потеряете совместимость.

Если у вас нет острой необходимости (например, часть вашей системы не справляется с количеством запросов / или количеством данных), я бы не стал переключаться. И даже когда вы начинаете приближаться к пределам, перед переключением обратите внимание на аппаратную проблему или настройку.

Я думал, что я ответил на это раньше, на SO есть почти дубликат

— Джереми Френч
источник