ayazer

Т.е. сделать свой препарсер, который будет отдавать потом запрос в нормальный парсер, который обрежет словоформы.

на моем опыте - любое использование полнотекстового поиска (будь это еластик, солр или встроенный в постгрес) именно этим и заканчивалось. Рано или поздно все-равно возникает необходимость сделать что-то большее чем "взять запрос от пользователя и передать дальше". Начиная от банального "выделить ключевые слова чтоб они в результатах поиска имели больший вес", "этот пользователь не может видеть некоторых результатов" или "затереть все что похоже на пароль" и заканчивая "тут на самом деле поиск по частично структуированым данным, потому для части запросов мы можем вообще другой скл генерировать"

Дальше это нужно ранжировать. У нас OR, и я не очень понимаю, как будут распределяться веса

если тут нужно МНОГО специфических настроек - лучше сразу смотреть в сторону того-же солра. В постгресе все-же поддержка полнотекстового поиска постолько-поскольку. Для многих задач ее хватает, но я в свое время страдал т.к. постоянно натыкался на стену "а так сделать нельзя". Но в целом хоть как-то постгрес ранжирует +есть возможность ручками подправить веса для ключевых частей. Т.е. для примера

select json_flat_content , ts_rank_cd(json_flat_tsv, 'jzvmw | julva | qxqvh | name | value') r
from my_fulltext_index i
where
	i.json_flat_tsv @@ to_tsquery('simple', 'jzvmw | julva | qxqvh | name | value')
order by r desc

вернет

[{"name": "qtmlx", "value": "jzvmw  vajwq julva  ipsmwtbhki  lhgzr"}, {"name": "fslto", "value": "viykw"}]	0.6
[{"name": "lhnhq", "value": "sxgxh!!daxrh guxux!!kfgtirmgig!!ivqwz"}, {"name": "qxqvh", "value": "qbeli"}]	0.5
[{"name": "cepja", "value": "mrfma"}, {"name": "gwjqa", "value": "csxaf"}]	0.4
[{"name": "val", "value": "TNhmT<KxERm"}]	0.2

ну и да, для запроса "мультфильм | Норштейн | Ежик <-> тумане" может понадобится ручками указать меньший вес для "мультфильм" и больший для "Норштейн". И заодно подумать что делать если в поиске из-за очепятки будет "орНштейн"

+ стоит обратить внимание что постгрес (по крайней мере версии 9.5 и 10.? с которыми я работал) плохо работал с нграмами. а точнее - для этого нужно было ставить доп. плагины и потом все это собирать в кучу. т.е. по"сло:*" найти "слово" можно, но по "ово" найти "слово" - уже нет.

+ возможно нужна будет работа с очепятками

+ я не помню умеет ли постгрес работать с синонимами. Это может быть тоже важно

в целом как для быстрого и сердитого прототипирования - полнотекстовый поиск в постгресе удобно использовать. Но если нужен серьезный полнотекстовый поиск - лучше смотреть на инструменты которые на это заточены

const pool = new Pool({
  user:'postgres',
  password:'password',
  host:'localhost',
  port:5432,
  database:'delviery'
});

pasword => password

итак, вопрос на самом деле можно привести к "как построить процесс внесения изменений в базу, чтоб все случайно не угробить и не было больно".

1. можно использовать тулзы для генерации дифоф а-ля https://github.com/djrobstep/migra

дифы добавляются вместе с пр, если схема была изменена пока работаешь - накатываешь диффы у себя локально, генерируешь новый дифф и добавляешь его в пр.

2. чтоб автоматизировать накатывание дифов на базу - можно использовать flyway (или любой другой аналог). суть проста - оно ведет историю выполненых миграций, при запуске приложение - применяет все новые в правильном порядке

3. в момент когда данных становится много - оно теряет актуальность т.к. на практике все миграции все-равно выполняется ручками (т.е. не запустил-и-забыл). (дальше мой опыт касается больше майскля, т.к. в постгресе у нас нет многотерабайтных таблиц) основная проблема тут - изменения таблицы = лок = аутейдж, чего допускать нельзя. потому для того, чтоб внести изменения - надо создать новую таблицу с новой схемой, перелить в нее все старые данные, синхронизировать все новые данные, поменять таблицы местами и дропнуть старую. тут помогает тулкит перконы и гитхаба (pt-online-schema-change и gh-ost), которые это все автоматизируют. Но обе они заточены под майскл, для постгреса надо искать и тестировать (ну или может кто-то уточнит)