Документно-ориентированные базы данных как первичные базы данных и базы данных СУБД как вторичные базы данных?

Question

У меня проблемы с производительностью базы данных MySQL из-за ее нормализации.

Большинству моих приложений, использующих базу данных, необходимо выполнять несколько сложных вложенных запросов, что в моем случае занимает много времени. Запросы могут занять 2 секунды, с индексами . Без индексов около 45 секунд.

Решение, которое я нашел несколько месяцев назад, состояло в том, чтобы использовать более быструю, более линейную базу документов, в моем случае Solr, в качестве основной базы данных. Как только что-то изменилось в базе данных MySQL, Solr получил уведомление.

Это сработало очень хорошо. Все запросы с использованием базы данных Solr занимали около 3ms .

Числа выглядят хорошо, но у меня есть некоторые проблемы.

• Огромная база данных

База данных MySQL составляет около 200 МБ, база данных Solr содержит около 1,4 ГБ данных. Каждый раз, когда мне нужно изменить таблицу / столбец, базу данных необходимо переиндексировать, что в этом примере заняло более 12 часов.

• Сложно отобразить как объект Solr, так и объект Active Record (MySQL) без получения wet .

Представление опирается на определенный объект. Не имеет значения, является ли сам объект Active Record или объектом Solr, если он может вызывать для него набор атрибутов.

Вот так.

# Controller
@song = Song.first

# View
@song.artist.urls.first.service.name

Проблема в моем случае заключается в том, что данные, возвращаемые из Solr, выглядят как плоские.

{
  id: 123,
  song: "Waterloo",
  artist: "ABBA",
  service_name: "Groveshark",
  urls: ["url1", "url2", "url3"]
}

Это вынуждает меня создать объект активной записи, который можно передать в представление.

Мой вопрос

Есть ли лучший способ решить проблему? Неплохая быстрая первичная база данных только для чтения, которая может быстро обрабатывать сложные запросы.

Answer 1

Обновление отдельных полей Solr

О переиндексации всех при изменении схемы: Solr пока не поддерживает обновление отдельных полей , но существует проблема JIRA , которая до сих пор не решена. Однако сколько раз вы меняете схему?

MongoDB

Если вы можете жить без СУБД (без объединений, схемы, транзакций, ограничений внешнего ключа), БД на основе документов, например MongoDB , или CouchDB идеально подойдет. ( здесь - хорошее сравнение между ними)

Зачем использовать MongoBD:

• данные представлены в собственном формате (вы можете использовать сопоставитель ORM, например Mongoid , непосредственно в представлениях, поэтому вам не нужно адаптировать свои записи, как в Solr)
• динамические запросы
• очень хорошая производительность при неполнотекстовых поисковых запросах
• без схемы (не требуется миграция)
• встроенный, простой в настройке репликация

Зачем использовать SOLR:

• расширенный, очень производительный полнотекстовый поиск

Зачем использовать MySQL

• соединения, ограничения, транзакции

Решения

Итак, решения (комбинации) будут:

1. Использовать MongoDB + Solr

   • но вам все равно нужно переиндексировать все при изменении схемы

2. Использовать только MongoDB

   • но исключить поддержку расширенного полнотекстового поиска

3. Использование MySQL в конфигурации «ведущий-ведомый» и балансирование чтения с ведомого (ых) (с использованием плагина типа octupus ) + Solr

   • сложность настройки

4. Сохранение текущих настроек, денормализация данных в MySQL

   • упорядочена

Solr переиндексация медлительности

База данных MySQL составляет около 200 МБ, база данных Solr содержит около 1,4 ГБ данные. Каждый раз, когда мне нужно изменить таблицу / столбец, база данных должна быть переиндексирован, что в этом примере заняло более 12 часов.

Переиндексирование 200 МБ БД в Solr НЕ ДОЛЖНО занять 12 часов! Скорее всего, у вас есть и другие проблемы, такие как:

MySQL:

• n + 1 выпуск
• индексы

SOLR:

• коммит после каждого запроса - это настройка по умолчанию, если вы используете плагин, такой как sunspot, но это perf killer для производства

С http://outoftime.github.com/pivotal-sunspot-presentation.html:

• По умолчанию Sunspot :: Rails фиксируется в конце каждого запроса это обновляет индекс Solr. Выключи это.
  
  • Использование Solr autoCommit функциональность. Это настроено в solr / conf / solrconfig.xml
  • Be рад за предполагаемое несоответствие. Не используйте поиск там, где нужно будь в курсе.

• другие проблемы с настройкой (http://wiki.apache.org/solr/SolrPerformanceFactors#Indexing_Performance)

Посмотрите логи для более подробной информации

Answer 2

Вместо того, чтобы помещать свои данные в Solr для выравнивания записей, почему бы вам просто не создать отдельную таблицу в базе данных MySQL, которая оптимизирована для доступа только для чтения.

Также вы, кажется, противоречите себе

Представление опирается на определенный объект.Неважно, является ли сам объект объектом Active Record или объектом Solr, если он может вызывать для него набор атрибутов.

Проблема в моем случае заключается в том, что данныевозвращается из Solr плоская ... Это заставляет меня создавать поддельный объект активной записи, который может быть визуализирован представлением.