Гуру поиска звонков: Производительность поиска по числовому диапазону с Lucene?

Question

Я работаю в системе, которая выполняет сопоставление больших наборов записей на основе строк, числовых диапазонов и диапазонов дат. Насколько я могу судить, совпадения строк - это, в основном, точные совпадения, в отличие от менее точных результатов полнотекстового поиска, для которых, как я понимаю, обычно предназначен lucene. Числовая точность важна, поскольку данные касаются цен.

Я заметил, что в Lucene недавно добавлена ​​поддержка поиска по числовому диапазону, но он изначально не предназначен для этого.

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

У меня такой вопрос: вероятно ли, что Lucene будет выполнять во много раз быстрее и масштабировать до больших наборов данных дешевле, чем RDBMS для этого типа индексации и поиска?

Answer 1

1. Lucene хранит свои числовые данные как три; реализация SQL, вероятно, будет хранить его как b-дерево или r-дерево. То, как Lucene хранит свои данные и SQL использует R-дерево, довольно схоже, и я был бы удивлен, если бы вы увидели огромную разницу (если вы не использовали некоторые из масштабируемости, которые дает Solr).
2. Что касается общего вопроса о производительности полнотекста Lucene и SQL, то я обнаружил хорошее исследование: Цзин, Й., К. Чжан и Х. Ван. «Эмпирическое исследование по сравнению производительности Lucene и реляционной базы данных». В «Коммуникационное программное обеспечение и сети», 2009 г. ICCSN'09. Международная конференция, 336-340. IEEE, 2009.

Во-первых, при выполнении точный запрос, производительность Lucene намного лучше, чем что из неиндексированного RDB, в то время как почти так же, как индексированных RDB. Во-вторых, когда подстановочный запрос является префиксом запрос, то индексированный-RDB и Lucene оба выполняют очень ну все же, используя индекс ... В-третьих, для комбинационного запроса, Lucene выполняет гладко и обычно стоит немного времени, а время запроса RDB связан с условиями комбинационного поиска и количество проиндексированных полей. Если некоторые поля в комбинационное условие не было проиндексировано, поиск будет стоит намного больше времени. В-четвертых, время запроса Lucene и unindexed-RDB имеет отношения со сложностью записи, но индексированный RDB почти не зависит от него.

Короче говоря, если вы выполняете поиск, например, "select *, где x = y", не имеет значения, какой вы используете. Чем больше предложений вы добавите в (x = y OR (x = z AND y = x) ...), тем лучше будет Lucene.

Они на самом деле не упоминают об этом, но огромным преимуществом Lucene является вся встроенная функциональность: выделение, разбор запросов и т. Д.

Answer 2

Предлагаю вам прочитать Марк Крелленштайн "Полнотекстовые поисковые системы против СУБД".

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

Answer 3

По своей сути и в самой простой форме Lucene - это поисковая система с плотностью слов.Lucene может масштабироваться для обработки очень больших наборов данных, а при правильной индексации возвращает результаты с невероятной скоростью.Для текстового поиска возможно и очень вероятно, что результаты поиска будут возвращаться в Lucene быстрее, чем SQL Server / Oracle / My SQL.При этом было бы несправедливо сравнивать Lucene с традиционными RDBMS, поскольку они оба имеют совершенно разное использование.