Полнотекстовое хранилище журналов с возможностью поиска с использованием Cassandra и Lucene

Решение

Постоянное и доступное для поиска хранилище данных должно быть базой данных. Хотя некоторые традиционные РСУБД (MySql, о которых я знаю) поддерживают полнотекстовый поиск, но хранение огромного количества данных с высокой скоростью записи может быстро стать узким местом. Таким образом, мы выходим из решения RDBMS.

Хранилища данных на основе Lucene, такие как SolR / Elastic Search, могут быть хорошим предложением, предпочтительно ElasticSearch, если мы примем простоту использования. Однако эти инструменты индексируют документ мудро; то есть полная запись со всеми ее полями индексируется, проще говоря. Эти решения хорошо подходят для сложных (структурно) поисковых возможностей записи, но могут быть излишними для ограниченного поискового объекта (только для поиска по фразе или термину) и без необходимости, например, поиска по релевантности.

Это приводит нас к опциям nosql. Ближайшими кандидатами, которые приходят на ум, исключительно на основе популярности (ну, по крайней мере, в результатах поиска в Интернете!), Являются Кассандра и Монгодб. На самом деле Mongo имеет встроенную поддержку полнотекстового поиска. Однако, учитывая природу временных рядов данных, кажется, что хранилище значений ключей (Cassandra) должно лучше подходить, чем ориентированное на документы (Mongo). Кроме того, учитывая высокую природу операции записи, мне показалось, что Кассандра — лучший кандидат. Последний вывод просто основан на предыдущем проекте, над которым я работал, где мы создавали прототип большой платформы для приема данных на Cassandra. Итак .. Кассандра!

Подход

При использовании Cassandra необходимо помнить следующее:

• Основная проблема в том, что Cassandra (v2.2.3) не имеет встроенной поддержки полнотекстового поиска.
• Пагинация набора данных, которая не является тривиальной при использовании Cassandra и имеет некоторые ограничения на предыдущие / следующие выборки.
• Модель данных Cassandra должна быть разработана сверху вниз, то есть мы проектируем, как мы храним данные, основываясь на том, что мы хотим видеть, а не иначе
• Ключ раздела должен основываться на чем-то, что всегда будет предоставляться при запросе. Это также должно быть достаточно для равномерного распределения данных по кластеру.
• Столбец метки времени должен быть первым ключом кластеризации с типом данных timeuuid. Использование timeuuid будет служить двойной цели естественного упорядочения данных временных рядов, а также обеспечит уникальный ‘rowid’, который может быть полезен для запросов на нумерацию страниц.
• Любое другое поле поиска, скажем, уровень ведения журнала, может быть сохранено в качестве последующего ключа кластеризации.

Полнотекстовый поиск

Для полнотекстового поиска мы будем использовать пользовательский дополнительный индексный плагин для Cassandra. Пользовательский вторичный индекс в Кассандре является внешним расширением Java , который использует Кассандра в качестве библиотеки динамической. Некоторые обсуждения здесь .

Stratio разработала реализацию пользовательского вторичного индекса на основе lucene в качестве части своей основной платформы больших данных, и она имеет открытый исходный код . Из их Github вики:

Это плагин для Apache Cassandra, который расширяет функциональность своего индекса для обеспечения поиска в режиме реального времени, такого как ElasticSearch или Solr, включая возможности полнотекстового поиска и бесплатный многопараметрический, геопространственный и битемпоральный поиск.

 Учитывая вышеперечисленные моменты, простая модель данных может быть следующей:

CREATE TABLE data_points (

    app_id text,

    event_ts timeuuid,

    level text,

    log_text text,

    lucene text,

    PRIMARY KEY (app_id, event_ts)

) WITH CLUSTERING ORDER BY (event_ts DESC)

SELECT * FROM data_points WHERE app_id=<app_log_id> AND lucene='{filter:{type:"boolean", must:[{type:"phrase",field:"log_text",value:"<search_phrase_or_term>"},{type:"match",field:"level",value:"INFO"}],should:[],not:[]},sort:{fields:[{field:"event_ts",reverse:false}]}}' AND event_ts>=minTimeuuid(<lower_bound_timeuuid>) AND event_ts<=maxTimeuuid(<upper_bound_timeuuid>) LIMIT <page_size>;