Comments 21
Я сейчас работаю над похожей задачей. Только elasticsearch мне не подошел из-за быстродействия, инфраструктуру сам пишу.
Пока результаты такие: на ноутбуке с Core i5 7300HQ и SSD на массиве в 750 тысяч товаров обрабатывается примерно 5500 сопоставлений в секунду, это с парсингом входящих данных и сохранением результатов в базу, но без ответа на http запросы. Просто модель взаимодействия с клиентами предполагается другая, обработка не по одному запросу, а сразу большого массива данных.
Возможно, из этого получится сервис или что-то вроде того, но пока в публичном доступе ничего нет, к сожалению, продемонстрировать не могу.
Пока результаты такие: на ноутбуке с Core i5 7300HQ и SSD на массиве в 750 тысяч товаров обрабатывается примерно 5500 сопоставлений в секунду, это с парсингом входящих данных и сохранением результатов в базу, но без ответа на http запросы. Просто модель взаимодействия с клиентами предполагается другая, обработка не по одному запросу, а сразу большого массива данных.
Возможно, из этого получится сервис или что-то вроде того, но пока в публичном доступе ничего нет, к сожалению, продемонстрировать не могу.
Если работать с Elasticsearch то там точно ноута маловато будет.
За счет того что он работает на Java то кушает довольно таки много оперативы.
Несколько индексов с объемом от 3 до ~12 млн записей. Ведет себя замечательно…
За счет того что он работает на Java то кушает довольно таки много оперативы.
Несколько индексов с объемом от 3 до ~12 млн записей. Ведет себя замечательно…
Я тоже работаю на сопоставлением лекарств и меня поражает скорость Вашего алгоритма! Можете поподробнее рассказать на каких технологиях разработан алгоритм, какая у алгоритма точность сравнения?
Если вкратце — то алгоритм состоит из последовательных шагов, от быстрых и надежных к более медленным и менее надежным. Скорость достигается за счет использования хэш-таблиц почти везде, где возможно. Сначала просто поиск по полному хэшу, потом поиск с использованием другой хэш-функции, которая нечувствительна к перемене слов местами, потом поиск по третьему хэшу и так далее до момента, когда либо нашли что-то надежное, либо разбиваем исходную строку на части и начинаем сначала. Все это перемешано со множеством костылей (ну или эвристик, как угодно :))
Что касается точности, то мы ведем статистику по 5 категориям. На каталоге с электроникой, бытовой техникой и товарами для дома (тот самый на 750 тысяч товаров) точность такая:
По 80% позиций все решения принимаются автоматически, среди них 0.1% ошибок. Остальное сопоставляется или уже сопоставленное подтверждается человеком, естественно, по каждой позиции — один раз, поэтому со временем процент автоматических решений растет.
Что касается точности, то мы ведем статистику по 5 категориям. На каталоге с электроникой, бытовой техникой и товарами для дома (тот самый на 750 тысяч товаров) точность такая:
- товар есть в каталоге и сопоставился правильно — 84%
- товар есть в каталоге, но не сопоставился, требуется ручное сопоставление — 16%
- товар есть в каталоге и сопоставился неправильно — 0.2%
- товара нет в каталоге, и программа это правильно определила — 98.5%
- товара нет в каталоге, но программа его сопоставила какому-то из товаров — 1.5%
По 80% позиций все решения принимаются автоматически, среди них 0.1% ошибок. Остальное сопоставляется или уже сопоставленное подтверждается человеком, естественно, по каждой позиции — один раз, поэтому со временем процент автоматических решений растет.
Вдогонку к 16%, отправленным на ручное сопоставление. Если электроника, бытовая техника и остальной массовый продукт у разных поставщиков называется хотя бы похоже, то с мебелью — часто мрак. Условно, диван «Диприз трехместный кожа» на сайте — это «Мебель для гостиной 11-21-311» в прайсе.
Если нам поможете в этой задаче — буду признателен, естественно не бесплатно. У нас Эластик.
На самом деле если говорить про FTS индексаторы, то сейчас де факто стандарт это:
Но в принципе под капотом одинаково: токенайзер => стемминг/словарь => инвертированный индекс
- Библиотека Apache lucene и построенные на ней Elastic и Solr. Причем если вам не нужно горизонтальное масштабирование — я бы советовал Solr — там версии lucene посвежей, а elastic получше с кластерностью.
- Sphinx: отечественный, не очень кластерный, но шустрее за счет с++ и кучи оптимизаций.
Но в принципе под капотом одинаково: токенайзер => стемминг/словарь => инвертированный индекс
С 16 года делаю клиентам софт для сравнения цен конкурентов, по заданным алгоритмам. У кого то сравниваются готовые прайсы, у кого то парсинг с сайтов. Все на чистом питоне. GUI для редактирования настроек алгоритма писал на Delphi
Было бы интереснее если бы в статье рассказали про свой способ индексации большого объема данных. Просто сейчас это как пособие для начинающий в котором описаны базовые вещи.
Автор и рассказал — способ индексации — elasticsearch.
Если нтересно «больше внутренностей» — apache lucene — вокруг это библиотки elastic построен
Если нтересно «больше внутренностей» — apache lucene — вокруг это библиотки elastic построен
Нет, это пара товаров…
А вот вопрос как подходить к вопросу с большими данными!? Когда в индексе около 5 млн. записей? Как их индексировать? Как по ним поддерживать актуальность? Не проводить же каждый раз Full Index
А вот вопрос как подходить к вопросу с большими данными!? Когда в индексе около 5 млн. записей? Как их индексировать? Как по ним поддерживать актуальность? Не проводить же каждый раз Full Index
Если использовать symfony и бандл elastica, то можно не заботиться об актуальности данных, бандл следит за изменениями в entitymanager и обновляет индекс elasticsearch
Это все хорошо если источник данных для индекса 1 таблица в полном ее объеме.
А что делать если индекс составляется из нескольких таблиц при этом необходимы не все поля, а только определенные?
При этом надо отслеживать изменения в каждой из таблиц и при изменении в них должен обновится документ в ElasticSearch
А что делать если индекс составляется из нескольких таблиц при этом необходимы не все поля, а только определенные?
При этом надо отслеживать изменения в каждой из таблиц и при изменении в них должен обновится документ в ElasticSearch
5 млн… записей это не большие данные.
На сервере класса HP gen9 elastic переваривает индексацию Bulk потоком 5-10 мегабайт/секунду практически из коробки. Если у вас запись под килобайт то пережует он эти 5 млн записей по килобайту за 7-15 минут.
Но никто не отменял апдейты и партиционирование.
На сервере класса HP gen9 elastic переваривает индексацию Bulk потоком 5-10 мегабайт/секунду практически из коробки. Если у вас запись под килобайт то пережует он эти 5 млн записей по килобайту за 7-15 минут.
Но никто не отменял апдейты и партиционирование.
В далеком 2017 году
Всмысле?
Сложная задача. Мы делаем бизнес на парсинге сайтов xmldatafeed.com и для связок используем Эластик. Результаты очень плачевные, если делаем точность сопоставления (fuzzy) не очень высокую — лезет мусор, клиенты ругаются.
А какие стоят анализаторы!? Настройки индекса!?
Ох. это я призову специалистов. Пока отказались от этой идеи делать связки по эластику. Точнее работают те, когда совпадение 99%.
Наткнулся на одну статью которая может поможет вам выстроить поиск с наибольшей релевантностью результатов:
codedzen.ru/elasticsearch-urok-6-5-poisk-po-neskolkim-poljam/#more-530
codedzen.ru/elasticsearch-urok-6-5-poisk-po-neskolkim-poljam/#more-530
Я для поиска по нескольким полям для большего совпадения использую стандартный query_string, получаем неплохие показатели точности поиска и учетом морфологии.
GET /_search
{
"query": {
"query_string" : {
"fields" : ["description", "name"],
"query" : "Мороженое молочное",
"default_operator": "AND",
"analyzer": "russian"
}
}
}Спасибо!
Sign up to leave a comment.
Сопоставление товаров при помощи Elasticsearch для сервиса мониторинга цен конкурентов