Как искать огромные нетекстовые наборы данных?

В проекте, в котором я работаю, клиент имеет старую и массивную (терабайтную) RDBMS. Запросы всех видов медленны, и нет времени для исправления/реорганизации схемы. Я определил набор общих запросов, которые нужно оптимизировать. Этот набор разделен на два: запросы с полным текстом и метаданными.

Мой план состоит в извлечении данных из их базы данных и разбиении их на две разные системы хранения, каждая из которых оптимизирована для определенного набора запросов.

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

Для запросов метаданных я не уверен, какой маршрут взять. В настоящее время я думаю об использовании РСУБД с чрезвычайно де-нормированной схемой, которая представляет собой конкретное подмножество данных из "Авторитетных" РСУБД. Однако мой клиент обеспокоен отсутствием осколков и репликации такой подсистемы и трудностями/сложностями при настройке таких функций по сравнению с Solr, который уже включает их. Метаданные в этом случае принимают форму целых чисел, дат, bools, бит и строк (с максимальным размером 10chars).

Существует ли система хранения базы данных, которая имеет встроенные функции очертания и репликации, которые могут быть особенно полезны для запроса указанных метаданных? Может быть, нет-sql-решение, которое обеспечивает хороший механизм запросов?

Осветите пожалуйста.

Дополнения/Ответы:

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

Ответ 1

Используйте MongoDB для вашего хранилища метаданных:

Встроенный sharding
Встроенная репликация
Отказоустойчивость и высокая доступность
Простой механизм запросов, который должен работать для большинства распространенных случаев

Однако, недостатком является то, что вы не можете выполнять объединения. Будьте осторожны в денормализации ваших данных, чтобы избежать этого.

Ответ 2

RavenDB:

Он имеет Lucene встроенный для полнотекстового поиска.
Это может быть реплицировано.
Он поддерживает sharding.
Он имеет HTTP API, поэтому вы можете в принципе использовать его с любой платформы.

Минусы: лицензия AGPL. В зависимости от вашей среды dev/server вы можете считать, что она работает на .NET con. Также я не знаю статус клиентов для других форматов, чем .NET.

Solandra:

Интегрирует Solr и Cassandra
Полнотекстовый поиск, управляемый Solr
Репликация и очертание, управляемые Cassandra

Минусы: еще не выпущены.

ElasticSearch:

Он имеет Lucene встроенный для полнотекстового поиска.
Это может быть реплицировано.
Он поддерживает sharding.
Он имеет HTTP API, поэтому вы можете в принципе использовать его с любой платформы.

ElasticSearch похож на RavenDB, но, как представляется, подчеркивает полнотекстовый поиск, где RavenDB подчеркивает, что он является общей базой данных NoSQL.

Ответ 3

Я уверен, что вам известно, что вы не будете получать быстрые запросы в любой системе с частыми обновлениями. Чтобы реализовать очертание себя на РСУБД, вам нужно найти какой-то ключ для разделения записей и заполнения нескольких баз данных. Затем вы можете запросить их все одновременно, чтобы получать и обрабатывать данные на карте, уменьшая моду. Это позволит увеличить число машин по мере роста ваших данных и, возможно, увеличить скорость работы. Из быстрого поиска Google оба MongoDB и Hadoop предоставляют эту карту/уменьшают функциональность, я не знаком с обоими.

Нередко генерируются сложные долговременные отчеты на лету. Однако это обычно сопровождается уведомлением по электронной почте, когда отчет завершен. Он обеспечивает хороший формат уведомлений о Push для взаимодействия с людьми. Кроме того, если эти отчеты ожидаются циклически (например, еженедельно, ежемесячно и т.д.), Вы все равно можете использовать уведомление по электронной почте, когда эти отчеты готовы, единственная разница - это время запуска для генерации, автоматизированное.

Ответ 4

Если вы используете elasticsearch, вы можете просто добавить метаданные в качестве дополнительных ключей документа json:

{
    "message": ... your full text,
    "date": "2009-11-15T14:12:12",
    ...
}

Затем вы можете выполнять поиск одновременно. В противном случае, если вы все еще хотите сделать два системных подхода, monogoDB - это хранилище документов с автоматическим отрисовкой, в котором есть некоторые довольно продвинутые механизмы запросов (поля, map-reduce, индексы для быстрых запросов).