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

Question

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

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

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

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

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

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

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

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

Answer 1

RavenDB

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

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

Соландра :

• Объединяет Солр и Кассандру
• Полнотекстовый поиск под управлением Solr
• Репликация и шардинг, управляемый Кассандрой

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

ElasticSearch:

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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