Поиск похожих товаров в БД. Нужен совет.

Посчитай дома на ноутбуке.
И схожесть наверно надо не всех товаров.
А в разрезе групп, так что матрицы по меньше будут.

а как ты схожесть опеределяешь?

не спрашивайте «зачем?», я сам не знаю

Очевидно чтобы выдать альтернативы.

Результатов должно быть 16000х16000

А представляешь что бывает когда позиций 16000000?

В общем не считают это на PG. Для твоей задачи реально легче посчитать на своей тачке и отбросить результаты меньше какого-то уровня.

«Очевидно чтобы выдать альтернативы.»

Ну не 16000 же алтернатив выдавать?

Ну не 16000 же алтернатив выдавать?

Естественно что topN

А оно нормально товары (модели) сравнивает? И что сравнивается название моделей, наименование, артикул, код изделия?

лучше выяснить по возможности сразу что хотят

Мне скинули скрипт на питоне, который всё это пытался считать в памяти, но он выжирает много гигобайтов памяти и ядро его грохает. Я сделал на постгресе, сравнили результаты, результаты были схожи. Так что вроде нормально считает.

Сравниваются названия, категории и подкатегории, единици измерения, описания и составы.

Скрипт ещё и цену сравнивал.

ну этот вариант в общем случае бестолковый. Т.к. выбирает далеко не все схожие товары. Да и не факт что схожие. Например, товар $brandname1 $modelname1 может быть не похож на $brandname1 $modelname2, а похож на $brandname2 $modelname3

Давненько это было. На одном проекте делал схожий функционал, там у позиций были характеристики с типами (select,boolean,text,numeric), причем производитель, так же дублировался в хар-ки, а на backend-системе, для разделов можно было указывать необходимый минимум характеристик (плюс их конкретных значений), при совпадении которых, позиция/коллекция считалась аналогом другой из соответствующего раздела.

ЕМНИП, просчитывались аналоги при каждом новом запросе, путем пошаговой фильтрации идентификаторов, хранящихся во временных таблицах. Фильтровались стандартным IN. Причем самих позиций было около 25-30к, а связей значений хар-к с позицией типа select в таблицах (в основном для нахождения аналогов контенщики применяли именно этот тип, например - цвет/типа изделия/производитель/etc) что-то около 200-300к. Работало довольно шусто без всяких кэшей, а с memcached дак вообще нагрузок на БД серьезных не было. Пользователей, что-то около 5к в сутки, ЕМНИП, опять же.

Я конечно не знаю, как у вас построены эти самые названия, но в том проекте простое сравнение наименований уж точно бы не прокатило. (продавали стройматериалы, и, например, плитка для пола имела определенную поверхность, и аналоги нужны были по этой самой поверхности, причем без учета цвета, а он как раз присутствовал в названии (плитка some1 красная/плитка some2 синия/etc). Если честно, сам не уверен что этот вариант хорош, но если у вас все позиции имеют детальные значения хар-к, то вполне себе можно попробовать.

У меня база с продуктами питания и наибольший вес сейчас имеет описание и состав, всё остальное по мелочи.

Ты случайно не знаешь, может с тех пор появились какие-то специализированые решения для таких задачь?

Я в общем-то и писал этот пост что бы мне кто-то написал, что для всёго этого есть %progrsm_name%.

К сожалению такого рода ПО мне не встречалось. Я, насколько понял ваша задачу, вижу здесь не столько простой diff между текстами (описание/название/etc), сколько глубокий полнотекстовый поиск и грамотное индексирование всех нужных вам данных. Если бы я решал эту задачу, я бы сначала задался вопросом что я хочу получить в итоге.

Есть база в которой 16000 товаров. Клиент хочет для каждой пары товаров просчитать схожесть(не спрашивайте «зачем?», я сам не знаю).

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

SELECT similarity(pname1, pname2)

Взваливать такое на БД не комильфо, я бы еще понял, если бы это было только наименование в 100-200 байт, но как вы говорите выше, там еще и описание и состав. Я бы реализовал это так. Взял бы какой-нибудь качественный поисковый движок (лично я предпочитаю ElasticSearch из-за его лаконичного RESTful API), проиндексировал бы все нужные мне данные (причем отказался бы от сложных анализаторов, вроде n-gramm, морфологии и прочих, т.к. ошибки - окончания и т.д. в-принципе нас не интересуют, ведь по сути это не пользовательский поиск), ну и после этого уже делал бы нужные запросы по названию/описанию/составу и т.д., причем благодаря тонкой настройки релевантности можно было бы добиться отличных результатов. Если (в чем я лично сомневаюсь) клиенту нужен единоразовый скан на аналоги, то я бы скорее всего ограничился каким-нибудь стандартным алгоритмом diff в процентом соотношении, на любом скрипте (perl/python/etc) По поводу

Мне скинули скрипт на питоне, который всё это пытался считать в памяти, но он выжирает много гигобайтов памяти и ядро его грохает. Я сделал на постгресе, сравнили результаты, результаты были схожи. Так что вроде нормально считает.

очень сложно что-либо сказать, нужно видеть сам скрипт, мне лично сложно представить обработку 16к позиций, даже с описаниями в несколько сот килобайт, от сканирования которых python скипт кушал бы много гигобайтов памяти. Нужно смотреть вообщем. По поводу %program_name% я честно пытался спрашивать гугла, но он глух к моим просьбам. Возможно, что я не так спрашивал, но вангую что все-таки задача не такая уж и общая, чтобы для нее писать какой-то спец. софт.

Там не простой diff, similarity из pg это триграммный поиск, взял из pg потому что данные уже там, а вообще реализовать можно на чём угодно.

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

ElasticSearch. Спасибо за подсказку, попробую предложить.