Комментарии 2
Нормальные результаты, надо посмотреть поближе скрипты, на компьютере а не на телефоне. Спасибо за статью (перевод). Все в пределах ожидания, у питона вычисления активнее и не такое активное кеширование (в котором люсин "большой специалист" - память жрет будь здоров). Завтра на свежую голову еще раз посмотрю статью и код.
Индексирование по скорости нормальное, 600 к/hr у эластика, это укладывается в норму, у меня типичное для простых документов на всех видах движков на люсин было примерно 1-2 млн в час. Это зависит от настроек и клиента, возможно железо медленное или коммиты частые.
Недавно заглянул в код базы H2 и что я вижу - полнотекстовый поиск на люсин!
Почему бы тогда не прикрутить индексы на b-tree или sstable в люсин поисковике для ускорения JoinUtil? Вполне себе вариант, вот на днях выделю пару выходных и прикручу, посмотрим как join запрос в люсин будет себя вести.
А может в эластике уже индексы прикрутили? У них join поля регистрируются в схеме, в отличие от солр, и проект пухлый, напихали много чего.
Код ещё не смотрел, только вот это
списки id документов ,,, источником входных данных BM25
- наверное нет, и даже повредит (это я об id).
Я сделал поисковик хуже Elasticsearch