В проекте, в котором я работаю, клиент имеет старую и массивную (терабайтную) RDBMS. Запросы всех видов медленны, и нет времени для исправления/реорганизации схемы. Я определил набор общих запросов, которые нужно оптимизировать. Этот набор разделен на два: запросы с полным текстом и метаданными.
Мой план состоит в извлечении данных из их базы данных и разбиении их на две разные системы хранения, каждая из которых оптимизирована для определенного набора запросов.
Для полнотекстового поиска Solr - это двигатель, который имеет наибольший смысл. Возможности масштабирования и репликации делают его очень подходящим для половины проблемы.
Для запросов метаданных я не уверен, какой маршрут взять. В настоящее время я думаю об использовании РСУБД с чрезвычайно де-нормированной схемой, которая представляет собой конкретное подмножество данных из "Авторитетных" РСУБД. Однако мой клиент обеспокоен отсутствием осколков и репликации такой подсистемы и трудностями/сложностями при настройке таких функций по сравнению с Solr, который уже включает их. Метаданные в этом случае принимают форму целых чисел, дат, bools, бит и строк (с максимальным размером 10chars).
Существует ли система хранения базы данных, которая имеет встроенные функции очертания и репликации, которые могут быть особенно полезны для запроса указанных метаданных? Может быть, нет-sql-решение, которое обеспечивает хороший механизм запросов?
Осветите пожалуйста.
Дополнения/Ответы:
Solr может использоваться для метаданных, однако метаданные нестабильны. Поэтому мне пришлось бы часто указывать индексы. Это приведет к быстрому ухудшению поиска.
Используйте MongoDB для вашего хранилища метаданных:
Однако, недостатком является то, что вы не можете выполнять объединения. Будьте осторожны в денормализации ваших данных, чтобы избежать этого.
Минусы: лицензия AGPL. В зависимости от вашей среды dev/server вы можете считать, что она работает на .NET con. Также я не знаю статус клиентов для других форматов, чем .NET.
Минусы: еще не выпущены.
ElasticSearch похож на RavenDB, но, как представляется, подчеркивает полнотекстовый поиск, где RavenDB подчеркивает, что он является общей базой данных NoSQL.
Я уверен, что вам известно, что вы не будете получать быстрые запросы в любой системе с частыми обновлениями. Чтобы реализовать очертание себя на РСУБД, вам нужно найти какой-то ключ для разделения записей и заполнения нескольких баз данных. Затем вы можете запросить их все одновременно, чтобы получать и обрабатывать данные на карте, уменьшая моду. Это позволит увеличить число машин по мере роста ваших данных и, возможно, увеличить скорость работы. Из быстрого поиска Google оба MongoDB и Hadoop предоставляют эту карту/уменьшают функциональность, я не знаком с обоими.
Нередко генерируются сложные долговременные отчеты на лету. Однако это обычно сопровождается уведомлением по электронной почте, когда отчет завершен. Он обеспечивает хороший формат уведомлений о Push для взаимодействия с людьми. Кроме того, если эти отчеты ожидаются циклически (например, еженедельно, ежемесячно и т.д.), Вы все равно можете использовать уведомление по электронной почте, когда эти отчеты готовы, единственная разница - это время запуска для генерации, автоматизированное.
Если вы используете elasticsearch, вы можете просто добавить метаданные в качестве дополнительных ключей документа json:
{
"message": ... your full text,
"date": "2009-11-15T14:12:12",
...
}
Затем вы можете выполнять поиск одновременно. В противном случае, если вы все еще хотите сделать два системных подхода, monogoDB - это хранилище документов с автоматическим отрисовкой, в котором есть некоторые довольно продвинутые механизмы запросов (поля, map-reduce, индексы для быстрых запросов).