Честно говоря не до конца понял Ваш пример. Можете описать его более подробно?
Если я правлиьно понял, то таким образом если пользователь ввел например while, то мы бы могли быстро найти необходимый кусок текста, но если бы он ввел whi, то ведь уже нет? И если бы в наших признаках не было бы например for, а пользователь ввел в поиск for и в коде это есть, то мы бы тоже ничего не нашли?
Он похож, на то, что нужно на первый взгляд, но мы хотели получить не подсказку, что идет следом, а целую строку, в которой находится вхождение.
Если я ничего не путаю, Completion это скорее аналог edge ngram, а не просто ngram.
Разница в том, что он ищит только то, что начинается с поисковой строки, которую передали, поэтому в середине текста с его помощью ничего найти не получится. Для этого нужно было бы разбивать строку на этапе предобработке тем самым руками делая те же ngram'ы.
У нас обновляется весь документ, но отдельно по строкам, одна строка отдельный паралелльный запрос на индексацию, все верно.
Консистетность нестеда была причиной очень долгой индексации, что вызывало проблемы. И да, в нашем случаи не страшно лишиться этой консистентности, потому что следом быстро придет другой запрос на индексацию, который исправит проблемы, если они возникли.
Случаев с расхождением еще не было и если это станет или стало бы частым явлением, то вариантом исправления было бы линеаризация или объединенине в батчи, но пока данных подход показываем тебя хорошо.
Честно говоря не до конца понял Ваш пример. Можете описать его более подробно?
Если я правлиьно понял, то таким образом если пользователь ввел например while, то мы бы могли быстро найти необходимый кусок текста, но если бы он ввел whi, то ведь уже нет?
И если бы в наших признаках не было бы например for, а пользователь ввел в поиск for и в коде это есть, то мы бы тоже ничего не нашли?
Он похож, на то, что нужно на первый взгляд, но мы хотели получить не подсказку, что идет следом, а целую строку, в которой находится вхождение.
Если я ничего не путаю, Completion это скорее аналог edge ngram, а не просто ngram.
Разница в том, что он ищит только то, что начинается с поисковой строки, которую передали, поэтому в середине текста с его помощью ничего найти не получится. Для этого нужно было бы разбивать строку на этапе предобработке тем самым руками делая те же ngram'ы.
У нас обновляется весь документ, но отдельно по строкам, одна строка отдельный паралелльный запрос на индексацию, все верно.
Консистетность нестеда была причиной очень долгой индексации, что вызывало проблемы. И да, в нашем случаи не страшно лишиться этой консистентности, потому что следом быстро придет другой запрос на индексацию, который исправит проблемы, если они возникли.
Случаев с расхождением еще не было и если это станет или стало бы частым явлением, то вариантом исправления было бы линеаризация или объединенине в батчи, но пока данных подход показываем тебя хорошо.
в этом и была шутка)