Сопоставление товаров при помощи Elasticsearch для сервиса мониторинга цен конкурентов

[@Razoomnick]

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

Пока результаты такие: на ноутбуке с Core i5 7300HQ и SSD на массиве в 750 тысяч товаров обрабатывается примерно 5500 сопоставлений в секунду, это с парсингом входящих данных и сохранением результатов в базу, но без ответа на http запросы. Просто модель взаимодействия с клиентами предполагается другая, обработка не по одному запросу, а сразу большого массива данных.

Возможно, из этого получится сервис или что-то вроде того, но пока в публичном доступе ничего нет, к сожалению, продемонстрировать не могу.

[@GHostly_FOX]

Если работать с Elasticsearch то там точно ноута маловато будет.
За счет того что он работает на Java то кушает довольно таки много оперативы.

Несколько индексов с объемом от 3 до ~12 млн записей. Ведет себя замечательно…

[@mentalMedley]

Я тоже работаю на сопоставлением лекарств и меня поражает скорость Вашего алгоритма! Можете поподробнее рассказать на каких технологиях разработан алгоритм, какая у алгоритма точность сравнения?

[@Razoomnick]

Если вкратце — то алгоритм состоит из последовательных шагов, от быстрых и надежных к более медленным и менее надежным. Скорость достигается за счет использования хэш-таблиц почти везде, где возможно. Сначала просто поиск по полному хэшу, потом поиск с использованием другой хэш-функции, которая нечувствительна к перемене слов местами, потом поиск по третьему хэшу и так далее до момента, когда либо нашли что-то надежное, либо разбиваем исходную строку на части и начинаем сначала. Все это перемешано со множеством костылей (ну или эвристик, как угодно :))

Что касается точности, то мы ведем статистику по 5 категориям. На каталоге с электроникой, бытовой техникой и товарами для дома (тот самый на 750 тысяч товаров) точность такая:

• товар есть в каталоге и сопоставился правильно — 84%
• товар есть в каталоге, но не сопоставился, требуется ручное сопоставление — 16%
• товар есть в каталоге и сопоставился неправильно — 0.2%
• товара нет в каталоге, и программа это правильно определила — 98.5%
• товара нет в каталоге, но программа его сопоставила какому-то из товаров — 1.5%

По 80% позиций все решения принимаются автоматически, среди них 0.1% ошибок. Остальное сопоставляется или уже сопоставленное подтверждается человеком, естественно, по каждой позиции — один раз, поэтому со временем процент автоматических решений растет.

[@Razoomnick]

Вдогонку к 16%, отправленным на ручное сопоставление. Если электроника, бытовая техника и остальной массовый продукт у разных поставщиков называется хотя бы похоже, то с мебелью — часто мрак. Условно, диван «Диприз трехместный кожа» на сайте — это «Мебель для гостиной 11-21-311» в прайсе.

[@makasin4ik]

Если нам поможете в этой задаче — буду признателен, естественно не бесплатно. У нас Эластик.

[@FYR]

На самом деле если говорить про FTS индексаторы, то сейчас де факто стандарт это:

• Библиотека Apache lucene и построенные на ней Elastic и Solr. Причем если вам не нужно горизонтальное масштабирование — я бы советовал Solr — там версии lucene посвежей, а elastic получше с кластерностью.
• Sphinx: отечественный, не очень кластерный, но шустрее за счет с++ и кучи оптимизаций.

Но в принципе под капотом одинаково: токенайзер => стемминг/словарь => инвертированный индекс

[@Mantikor_WRX_STi]

С 16 года делаю клиентам софт для сравнения цен конкурентов, по заданным алгоритмам. У кого то сравниваются готовые прайсы, у кого то парсинг с сайтов. Все на чистом питоне. GUI для редактирования настроек алгоритма писал на Delphi

[@GHostly_FOX]

Было бы интереснее если бы в статье рассказали про свой способ индексации большого объема данных. Просто сейчас это как пособие для начинающий в котором описаны базовые вещи.

[@bormotov]

Автор и рассказал — способ индексации — elasticsearch.
Если нтересно «больше внутренностей» — apache lucene — вокруг это библиотки elastic построен

[@GHostly_FOX]

Нет, это пара товаров…
А вот вопрос как подходить к вопросу с большими данными!? Когда в индексе около 5 млн. записей? Как их индексировать? Как по ним поддерживать актуальность? Не проводить же каждый раз Full Index

[@AlexSidor]

Если использовать symfony и бандл elastica, то можно не заботиться об актуальности данных, бандл следит за изменениями в entitymanager и обновляет индекс elasticsearch

[@GHostly_FOX]

Это все хорошо если источник данных для индекса 1 таблица в полном ее объеме.
А что делать если индекс составляется из нескольких таблиц при этом необходимы не все поля, а только определенные?
При этом надо отслеживать изменения в каждой из таблиц и при изменении в них должен обновится документ в ElasticSearch

[@FYR]

5 млн… записей это не большие данные.
На сервере класса HP gen9 elastic переваривает индексацию Bulk потоком 5-10 мегабайт/секунду практически из коробки. Если у вас запись под килобайт то пережует он эти 5 млн записей по килобайту за 7-15 минут.
Но никто не отменял апдейты и партиционирование.

[@makasin4ik]

Сложная задача. Мы делаем бизнес на парсинге сайтов xmldatafeed.com и для связок используем Эластик. Результаты очень плачевные, если делаем точность сопоставления (fuzzy) не очень высокую — лезет мусор, клиенты ругаются.

[@GHostly_FOX]

А какие стоят анализаторы!? Настройки индекса!?

[@makasin4ik]

Ох. это я призову специалистов. Пока отказались от этой идеи делать связки по эластику. Точнее работают те, когда совпадение 99%.

[@GHostly_FOX]

Наткнулся на одну статью которая может поможет вам выстроить поиск с наибольшей релевантностью результатов:

codedzen.ru/elasticsearch-urok-6-5-poisk-po-neskolkim-poljam/#more-530

[@GHostly_FOX]

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

GET /_search
{
    "query": {
        "query_string" : {
            "fields" : ["description", "name"],
            "query" : "Мороженое молочное",
            "default_operator": "AND",
            "analyzer": "russian"
        }
    }
}

[@makasin4ik]

Спасибо!