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

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

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

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

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


person barrymac    schedule 18.10.2010    source источник
comment
wiki.apache.org/lucene-java/SearchNumericalFields   -  person barrymac    schedule 18.10.2010


Ответы (3)


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

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

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

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

person Xodarap    schedule 18.10.2010
comment
Отличный ответ! Это действительно проливает свет. Эта проблема будет иметь некоторые случаи, когда десятки правил могут выполняться последовательно в наборе данных, и это может значительно улучшить ситуацию. Я начинающий эмпирик, поэтому я очень ценю ссылку. Я также думаю, что помимо некоторых приятных функций есть еще и архитектурное преимущество в разделении нагрузки индексации. - person barrymac; 18.10.2010
comment
@barrymac: вас также может заинтересовать philosophyforprogrammers.blogspot.com/2010/09 / и цитируемые в нем документы. Вы можете подставить некоторые значения примеров поиска и посмотреть, каким может быть ожидаемый прирост производительности (конечно, при условии, что вы знаете метрики для вашей текущей реализации). - person Xodarap; 18.10.2010

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

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

person Yuval F    schedule 18.10.2010
comment
Большое спасибо за эти полезные ссылки! - person barrymac; 18.10.2010

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

person Kane    schedule 18.10.2010
comment
Я рассматриваю возможность переноса только текстового поиска на lucene, но сначала мне нужно выяснить, какая доля нагрузки приходится на текстовый поиск, чтобы оправдать инвестиции. Я уверен, что это намного быстрее в этом. Если оставить в стороне сравнение технологий, я рассматриваю возможность добавления люцена в качестве оптимизации всей системы, а не варианта «или-или». - person barrymac; 18.10.2010
comment
Я определенно рекомендую использовать комбинацию Lucene и RDBMS, вы будете действительно удивлены производительностью. - person Kane; 18.10.2010
comment
Ну, однажды я реализовал тривиальную настройку поиска в спящем режиме. Хотя эта конкретная установка на самом деле довольно ограничена, скорости и мощности lucene на больших наборах данных было бы достаточно, чтобы у вас закружилась голова :-) - person barrymac; 18.10.2010