Как в 100 раз повысить производительность поиска в 1С и одновременно улучшить качество результатов

Мы в Zionec специализируемся на сложных проектах для крупных компаний, и вот пример одного из таких проектов.

Крупная розничная сеть — топ-3 в России в своей нише — столкнулась с неприемлемо низкой производительностью системы поиска в 1С. Компания обратилась к нам с задачей радикально улучшить производительность и качество результатов поиска товаров.

Ассортимент товаров компании очень большой и продолжал расти, а время обработки поисковых запросов в базу данных о товарах было неприемлемо долгим: поиск занимал в среднем около 7 секунд на каждый запрос (однако при высокой нагрузке оказывался намного большим, до 12 секунд). Это очень сильно усложняло работу сотрудников колл-центра, и разумеется, было очень плохо для компании. Представьте, что вам нужно ждать 10 секунд каждый раз, когда вы кликаете мышью на какой-нибудь кнопке в интерфейсе вашего компьютера — и вы поймете, насколько такая задержка может быть мучительна и как сильно она затрудняет работу.

Например, нужно было найти кроссовки определенного цвета — однако люди часто ошибаются в написании, и поэтому результат поиска может оказаться не таким, как ожидает клиент. Может быть, не будет найдено вообще ничего. В результате, клиенты делают уточняющие запросы, а с учетом того, что время выполнения каждого запроса большое, такие последовательные повторные уточняющие запросы занимают очень много времени и всё это было совершенно неприемлемо.

В 1С в общей сложности было порядка 700 складов с постоянно меняющимися остатками и 90 тысяч активных позиций товаров. Планируемая система должна была переваривать 200 пользовательских запросов по остаткам в секунду.

Соответственно, первой и главной задачей было ускорение поисковых запросов на два порядка, чтобы производительность поиска стала сравнима со скоростью обычного отклика интерфейса: не более 0.2 сек вместо 5-12 секунд на каждый запрос.

Однако, это не всё, что от нас требовалось. Помимо ускорения поиска, требовалось также улучшить результаты самого поиска, а именно, обеспечить учёт опечаток, разных форм слов, синонимов и просто ошибок в запросах, чтобы результаты были подобны тому, что выдают поисковики наподобие Гугла и Яндекса: они «догадываются», что скорее всего имел в виду клиент, и выдают список наиболее подходящих запросов. Именно такие результаты поиска по базе данных товаров в 1С нам предстояло обеспечить.

Но и это было ещё не всё. Гугл и Яндекс не выводят в результатах поиска никакой информации о складских остатках по каждой ссылке в результатах поиска — но мы-то делали поиск для торговой сети, где количество конкретного товара в конкретном магазине является очень важной информацией. Ведь именно для этого люди ищут товары в базе — для того, чтобы узнать, где этот товар есть в наличии и заказать его там, а не просто кликнуть по ссылке. Соответственно, каждую строчку результата поиска нам нужно было снабдить информацией о наличии и количестве данного товара на складе. Разумеется, получение этой информации одновременно с выполнением основного поискового запроса требует дополнительного времени, — и по этой причине, в системе, с которой к нам обратился Заказчик, это не было реализовано (и без того поиск был очень долгим). Однако, нам предстояло это реализовать.

Резюмируя, перед нами стояла задача сделать следующее:

Как видите, мы не просто так говорим, что беремся за задачи, от которых другие отказываются. Повысить на порядки скорость работы высоконагруженной системы, при этом обеспечить этот рост производительности, несмотря на гораздо более сложные запросы — нетривиальная задача.

Описание того, как мы тестировали различные платформы и продукты, в этой статье я опущу. Разумеется, этот этап был непростой: мы разворачивали тестовые платформы на тех или иных решениях, генерировали потоки запросов с разными характеристиками, измеряли производительность.

И наконец, мы нашли решение — высокопроизводительное, масштабируемое, отказоустойчивое (развернуто на кластере из нескольких серверов), и при этом относительно недорогое с точки зрения железа и стоимости эксплуатации. Мы использовали связку Tarantool и ElasticSearch — и с помощью разработанных нами компонентов, обеспечивающих их интеграцию, они вместе предоставляют ту самую гибкость поиска с учетом морфологии слов и ошибок набора, которая была важна Заказчику, с одновременным подбором данных в разрезе конкретных магазинов — и при этом обеспечивают очень высокий уровень производительности, на уровне отклика интерфейса, который также был обязательным требованием Заказчика.

Дополнительно к этому, наше решение развернуто на кластере недорогих серверов — то есть для этой производительности не нужно дорогое железо, а архитектура является отказоустойчивой, масштабируемой и недорогой в эксплуатации.

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

База данных Tarantool распределена на несколько серверов — они автоматически синхронизируются между собой, а специальный балансировщик распределяет между ними пользовательские запросы. Помимо очень высокой производительности, такая система также обеспечивает устойчивость в случае падения одного из серверов, а также эта архитектура позволяет очень легко нарастить емкость и производительность системы: достаточно подключить к кластеру еще один или несколько серверов, и система Tarantool сделает всё необходимое, чтобы включить их в работу.

Поскольку Tarantool является очень быстрым и эффективным сервером приложений, то там же, внутри Tarantool, мы написали наше приложение, обеспечивающее интеграцию Tarantool со вторым важным компонентом нашего решения: системой релевантного поиска ElasticSearch.

Для учета морфологии и ошибок в написании товаров, и для релевантного поиска по размерам/цветам и другим свойствам, мы выбрали ElasticSearch. Туда мы загружаем номенклатуру товаров (вместе с их характеристиками, то есть не только наименования, но и цвета, размеры, и так далее), задаем «веса» этих характеристик (насколько те или иные характеристики важны) — и система обеспечивает релевантный поиск по всем товарам.

Например, написанный с ошибкой запрос «красовка крсная» вернёт в поиске именно то, что ожидает пользователь: различные «кроссовки красные». Система «поймёт», что имеет в виду пользователь и заменит ошибочное написание на правильное, с учетом наименований и характеристик товаров, которые есть в ассортименте.

Теперь, когда у нас есть система для релевантного поиска с учетом морфологии, ассортимента и характеристик товаров, и быстрая база данных для поиска складских остатков — осталось их интегрировать вместе.

Разработанная нами система (приложение Tarantool), получает правильные идентификаторы товаров из системы ElasticSearch (которая обрабатывает поисковый запрос, введенный пользователем) и затем формирует запрос по складским остаткам в Tarantool, с учетом фильтров по конкретным магазинам, если он был задан в запросе. Если фильтра не было — то поиск ведется по всем магазинам. Поскольку поиск теперь очень быстрый, запрос даже по всем магазинам исполняется без какой-либо ощутимой задержки: пользователи получают результаты мгновенно, со скоростью отклика интерфейса.

Поскольку релевантных товаров, учитывая большое количество разных характеристик и магазинов, может быть весьма большим — необходима система, которая «склеивает» все эти результаты вместе для вывода пользователю. Эту работу тоже делает наше приложение, прямо внутри Tarantool.

При этом, результаты поиска отсортированы по релевантности: первыми отображаются те, которые наиболее вероятно соответствуют запросу пользователя. Ниже расположены результаты, менее точно соответствующие запросу. И каждый результат сопровождается информацией о складских остатках по каждому магазину.

Хотя требования заказчика к новой системе поиска в 1С были очень высокими — мы одновременно должны были обеспечить очень высокую производительность на очень сложных запросах — созданная нами система поиска их полностью выполняет.

Поиск стал мгновенным, очень точным, и наша система «угадывает», что имел в виду пользователь и предлагает товары из ассортимента, наиболее релевантные запросу. Сразу же в результатах, по каждому товару, добавляется информация о наличии и количестве товара в магазинах.

Эти результаты возвращаются пользователю за 0.25 секунды или быстрее, и такая производительность обеспечивается на 200 запросах в секунду — обеспечивая большой запас производительности на будущее.

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

Задавайте ваши вопросы ниже в комментариях — обязательно ответим!

То, о чём мы рассказали в этой статье — далеко не всё, что мы умеем делать. Обращайтесь к нам, в Зионек, с любыми вашими задачами по интеграции, автоматизации и цифровизации бизнеса. Мы специализируемся на создании сложных систем и берёмся за задачи, от которых другие отказываются.

И в то же время, мы умеем работать и с небольшими компаниями, и помогаем им расти. В отличие от некоторых других интеграторов, мы внедряем только то, что действительно полезно для бизнеса и принесёт предприятию немедленную выгоду. Вот наш сайт: https://zionec.ru/. Пишите, звоните — мы вас поймём, проконсультируем, поможем!