5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
А иногда нужно чтобы просто поиск работал и что-то релевантное находил. Без претензий на вселенский охват, типа по произвольной строке искал и в адресе и в фио и в должности и в подразделении.
И для этого постгресовский ФТС представляет довольно много возможностей.
понял, это я не то чтобы оспаривал, мне фтс по сути не доводилось делать, просто реально интересно как по-хорошему такой поиск делать
Читать полностью…
Я там сейчас натужно пытаюсь найти в документации слова "relevancy" (даже встречается пару раз), "precision", "recall", "idf", "bm25", пока что застрял на
This function computes the cover density ranking for the given document vector and query, as described in Clarke, Cormack, and Tudhope's "Relevance Ranking for One to Three Term Queries" in the journal "Information Processing and Management", 1999. Cover density is similar to ts_rank ranking except that the proximity of matching lexemes to each other is taken into consideration.
Потому что обсуждать поведение сферической бд в вакууме неинтересно ;-)
Читать полностью…
Последовательность полей при создании индекса важна для б три
Читать полностью…
уверены? Вот по пг как раз видео видел от одного из комитеров/разраба пг, в целом работает ДБА, так он наоборот говорил что все равно сколько полей, он будет искать что бы был набор полей необходимых, и порядок не важен. Ну ил мне так криво запомнилося и для b-tree там особый случай
Читать полностью…
Ну до какого-то объема БД вообще за индекс цепляться не будет. Проще будет тупо все перебрать. Ваше чуть больше скорее всего погрешность. Планы то одинаковые?
Читать полностью…
И тут мы задумываемся чем поиск отличается от выборки (и бд от поискового движка)
Читать полностью…
Мы так сейчас дойдем до того, что не надо все это искать в БД, а нужен отдельный индекс внешний
Читать полностью…
Поиск отличается от выборки как минимум двумя вещами:
- Динамичностью, с которой невозможно подстроиться отдельно под каждый возможный вариант
- Наличием релевантности, которая очень сильно зависит от приложения к приложению
С текстом всё очень сложно. Нужны нечёткие совпадения, нужны совпадения по фразе, нужны совпадения по термам, находящимся на определённом расстоянии, нужны произвольные decay functions, нужны cross-field queries, когда есть правила, по которым можно искать совпадения термов в нескольких полях, "шиномонтаж акварелька" должен сработать только когда либо оба терма есть в имени / описании, либо когда один в имени, другой в описании, нужны n-грамы, в которых n-gram это не обязательно символ (а, например, полноценное слово или слог), нужен юникодный матчинг всяких умляутов.
Без бейзлайна в виде idf / okapi bm25 я даже не знаю, что обсуждать
Читать полностью…
Хм, в доках пишут что тоже можно. Но я насколько понимаю это приведет к сканированию индекса по левым колонкам
Читать полностью…
Почему обязательно триграмы. Есть обычный FTS
Стоп-слова и прочий snowball
https://www.postgresql.org/docs/current/textsearch.html
Это значит, что если есть оба или первое, тогда будет использовать индекс
Читать полностью…
Дак это будет происходить, потому что на этом объеме такое делать дёшево, мы обсуждаем вариант с потенциальными тормозами
Читать полностью…
рано, сначала нужно сложить всё в json и познать боль gin индекса
Читать полностью…
а теперь вопрос знатокам, сколько нужно таких композтных индексов, если фильтрация возможна не по двум, а по пяти атрибутам?
Читать полностью…
В pgsql все так. Второе поле по индексу будет искать только если первое поле так же есть в условии. Это если мы говорим про дефолтный b-tree.
Читать полностью…