Каковы преимущества запуска NoSQL (ex MongoDB) над MySQL, PostGRE SQL или MSSQL в Drupal? Получаются ли преимущества от простого использования хранилища или нужно изменить какую-то конфигурацию Drupal?
Это вопрос, на который Кароли Негьеси дала бы «авторитетный» ответ. Он, безусловно, знает преимущество использования MongoDB с Drupal.
kiamlaluno
Читайте мои мысли .. очень интересует другие варианты, если есть существенные преимущества, и, конечно, плюсы приходят с минусами.
Кевин
Ответы:
13
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 может заменить эти дополнительные таблицы, а не таблицу базы данных.
Бердир
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 в существующий проект для проверки производительности, я бы включил и отключил модуль без последствий? Я хочу попробовать монго, но что, если он не работает или что-то? Это безопасно попробовать? (Я знаю, что вы не можете гарантировать это, но мне интересно, что происходит в большинстве случаев)
Бето Авейга
1
Ну, для начала, вы не можете просто вставить его. Каждое поле настроило, какой бэкэнд хранилища он использует, вам придется изменить / заново создать ваши поля, заново создать ваши представления (так как им нужно использовать бэкэнд efq_views). ), возможно, ваши собственные запросы, если вы написали прямые запросы к полевым таблицам данных. Может быть проще воссоздать ту же структуру в новой установке для первоначального сравнения.
Бердир
Спасибо Бердир! Я попробовал MongoDB несколько дней назад, но прирост производительности не был заметен, но я также не знал, что вы говорите мне сейчас. Я думал, что "MongoDB должен иметь значение на больших сайтах". Я попробую MongoDB снова.
Бето Авейга
5
Плюсы идут с минусами.
В целом Drupal нельзя переключить на MongoDb, поэтому вам придется поддерживать две базы данных и убедиться, что они хорошо работают вместе.
Многие модули не смогут работать с mongodb, поэтому вы потеряете совместимость.
Если у вас нет острой необходимости (например, часть вашей системы не справляется с количеством запросов / или количеством данных), я бы не стал переключаться. И даже когда вы начинаете приближаться к пределам, перед переключением обратите внимание на аппаратную проблему или настройку.
Я думал, что я ответил на это раньше, на SO есть почти дубликат
Ответы:
MongoDB может использоваться для хранения большинства или всех ваших объектов в быстром, ориентированном на документы хранилище. Этот тип хранилища масштабируется намного лучше, чем стандартное хранилище на основе SQL, которое мы имеем в ядре Drupal (которое основано на схеме «одна таблица на поле»).
В текущем состоянии Drupal 7 у вас будет:
Это позволяет быстро запрашивать объекты в MongoDB и добавлять сложные индексы, которые не поддерживаются базой данных Opensource SQL (включая индексы по таблицам). В то же время вы не потеряете совместимость, потому что базовая таблица сущности все еще хранится в SQL и, таким образом, может быть объединена с модулями, которые все еще только для SQL (например, Flag).
Этот тип быстрых запросов доступен благодаря механизму EntityFieldQuery, способу абстрактного построения запросов к сущностям, их свойствам и их полям. Реализация по умолчанию в ядре переводит эти запросы в SQL, но модуль MongoDB имеет полнофункциональную реализацию, которая может удовлетворить эти запросы непосредственно из MongoDB.
Благодаря бэкэнду EntityFieldQuery для Views вы можете легко использовать эту мощь, используя инструменты, к которым вы привыкли. Единственным недостатком является то, что отношения не поддерживаются (но на практике они вам все равно редко нужны - и это можно обойти, добавив дополнительные данные в объект сущности и добавив их в качестве дополнительных свойств сущности).
Короче говоря, как только производительность запроса становится проблемой для вашего проекта, что происходит, как только у вас есть значительный набор данных (скажем, начиная с нескольких десятых тысяч сущностей для данного типа сущности), MongoDB является чистым выигрышем за очень мало недостатков. Настоятельно рекомендуется.
источник
MongoDB и аналогичные предназначены для хранения структурированных (иерархических) данных относительно гибким способом.
Например
Drupal 7, при использованииfield_sql_storageкаждое поле получает свои собственные таблицы. Когда вы присоединяете 10 полей к типу контента, в вашей базе данных получается 10 таблиц. При загрузке этого узлаfield_sql_storageбудет выполняться запрос для каждого поля и для каждого узла (или нескольких узлов при использованииnode_load_multiple).Когда вы используете mongodb_field_storage , вы можете хранить все поля узла в одном документе и получать с помощью одного запроса.
Вы также можете хранить другие вещи, такие как сторожевой таймер, сессии, кеш, блоки в MongoDB .
Тем не менее, вам все еще нужен MySQL, MongoDB не заменяет его (только для определенных частей).
Еще одним преимуществом является то, что с MongoDB проще масштабировать, вы можете добавить много серверов в кластер, чтобы обмениваться данными между ними.
источник
Плюсы идут с минусами.
В целом Drupal нельзя переключить на MongoDb, поэтому вам придется поддерживать две базы данных и убедиться, что они хорошо работают вместе.
Многие модули не смогут работать с mongodb, поэтому вы потеряете совместимость.
Если у вас нет острой необходимости (например, часть вашей системы не справляется с количеством запросов / или количеством данных), я бы не стал переключаться. И даже когда вы начинаете приближаться к пределам, перед переключением обратите внимание на аппаратную проблему или настройку.
Я думал, что я ответил на это раньше, на SO есть почти дубликат
источник