Comments 14
кода-то занимался схожим вопросом.
с одной стороны 160к это как-то не серьезно.
а с другой стороны чем lucene не угодила?
с одной стороны 160к это как-то не серьезно.
а с другой стороны чем lucene не угодила?
sql интерфейс, полная интеграция с субд
UFO just landed and posted this here
Пост был не столько об особенностях ранжирования или фильтрации, а, скорее, о реализации нечеткого поиска средствами самой СУБД.
Что люцена, что сфинкс суть надстройки над базой данных. Требуется предпринимать усилия для интеграции, периодическую переиндексацию…
А так, сделал и забыл.
Что люцена, что сфинкс суть надстройки над базой данных. Требуется предпринимать усилия для интеграции, периодическую переиндексацию…
А так, сделал и забыл.
UFO just landed and posted this here
а как насчет транзакционности?
UFO just landed and posted this here
40 млн? не, не ляжет. Скорость просядет, но не фатально. Для 400 млн, придется что-то придумывать.
UFO just landed and posted this here
В памяти только словарь. Со всем остальным работа идет средствами sql процесссора.
А почему 250 * 80? Это же индекс. Такое может произойти только если все слова встречаются во всех документах. Что неверно в силу размера документа. Да и для таких случаев нечеткий поиск не очень то и нужен.
А почему 250 * 80? Это же индекс. Такое может произойти только если все слова встречаются во всех документах. Что неверно в силу размера документа. Да и для таких случаев нечеткий поиск не очень то и нужен.
UFO just landed and posted this here
Давайте считать :)
Пусть 40 млн документов.
Поиск по 4 словам.
Каждое поисковое слово встречается в 10% документов.
Всего надо прочитать 16 млн инвертированных записей. Записи эти для одного слова идут подряд и помежается их ну...500 на одну страницу субд.
Всего 32 000 страниц. Страницы все на диске и идут частично подряд и пусть на чтение уйдет в среднем 1 мс на страницу.
Итого, 32 секунды. Да, 2 минуты вполне достижимы :) но для очень тяжелого и маловероятного случая.
Пусть 40 млн документов.
Поиск по 4 словам.
Каждое поисковое слово встречается в 10% документов.
Всего надо прочитать 16 млн инвертированных записей. Записи эти для одного слова идут подряд и помежается их ну...500 на одну страницу субд.
Всего 32 000 страниц. Страницы все на диске и идут частично подряд и пусть на чтение уйдет в среднем 1 мс на страницу.
Итого, 32 секунды. Да, 2 минуты вполне достижимы :) но для очень тяжелого и маловероятного случая.
Однако, если индекс не помещается в памяти, эти данные всё равно придется где-то хранить и лазить за ними на диск. Это справедливо для любой системы, не только СУБД. Речь может идти только о минимизации дисковых операций и Вы, видимо, считаете, что для индекса, написанного руками этого добиться проще. Я согласен, однако осмелюсь утверждать, что конкретная СУБД в целом для этих целей тоже подходит. Но дает еще приятный бонус в виде инфраструктуры.
Sign up to leave a comment.
Нечеткий динамический текстовый поиск? Не так уж и страшно