Увеличение скорости обновления информации в 100 раз за счет миграции данных из самописного хранилища на базе СУБД PostgreSQL

Ранее мы уже описывали архитектуру мультиязычного сайта с большим количеством магазинов в разных странах. 

Перед нашим клиентом, компанией Levenhuk, встала задача обновления и модернизации текущего самописного хранилища на СУБД Postgre. 

Добавлять новый функционал или оптимизировать текущий – долго, дорого, больно. А развитие и дальнейшее масштабирование проекта необходимо, и зависит от работы базы. Задача номер 2, которую бизнес хочет решить в рамках этого изменения – это скорость обновления информации о товарах на сайте. 

Нашли довольно быстрое и нестандартное решение – самописное хранилище данных на СУБД Postgre мигрировать в БУС (Битрикс: Управление Сайтом), заменив сущности на инфоблоки и HL-блоки.

Бизнес-задача

Исходя из текущей архитектуры проекта

Архитектура веб-проекта

Задачи перед нами стояли следующие:

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

  • Оптимизировать способ обновления товаров (в старой архитектуре на обновление товаров могло уйти до 20 часов).

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

Почему решили что-то менять?

В самописном хранилище на СУБД Postgre содержатся данные, для “обогащения” сайта информацией о свойствах товаров. И один из критических моментов с масштабированием проекта — это увеличение памяти  под каждый сайт. Требуется гораздо больше памяти — как оперативной, так и постоянной (эта проблема, в целом, решаема, и не такая страшная).
Но основная причина экономическая:

  • старая админка;

  • слабая поддержка;

  • бизнесу нужно больше изменений, гибче настройки.

Архитектура Enrich

Enrich — агент на сайте, который следит за товарами. Он их “обогащает” переводами (много языковых версий), свойствами из HL-блоков и “включает”. Чтобы не вдаваться в детали, приведем схему первой версии работы Enrich в связке с PostgreSQL.

Архитектура работы Enrich

Мы убрали скрипт импорта товаров, и стали их записывать в HighLoad блоки (ХЛБ) из которых Enrich брал информацию и распределял между SKU и товарами.

Рефакторинг Enrich

Ключевая задача — это добавление mapper’ов ( один из подвидов воркеров). Их роль – распараллелить процессы обновления информации. Одни воркеры занимаются обновление SKU, другие занимаются привязкой данных товаров и т.п.

В нашем представлении Enrich должен быть оптимизирован по следующей схеме:

Оптимизация работы Enrich

Что это даст? Как минимум оптимизирует хранение всех данных в БД, а также ускорит процесс обновления информации на стороне сайта (многократно).

Если разбивать по шагам, то получается следующий порядок процесса рефакторинга:

  1. При импорте из 1С GUID раздела сохранять в SKU.

  2. Настроить ActiveMQ для enrich.

  3. Добавить mapper'ы, которые объединяют SKU в рамках товаров.

  4. Разместить модуль enrich в отдельный репозиторий (B2B, B2C).

Что будем переносить из PostgreSQL?

Переносим все поля свойств из PostgreSQL на highload-блок Битрикса, так называемый LOC. Простой, но в тоже время самый трудоемкий процесс, т.к. текущие таблицы очень большие и необходимо правильно и в той же последовательности связать их в highload-блок Битрикса, чтобы не нарушить целостность системы.

По сути перенеся все данные, мы можем отрубать PostgreSQL и пользоваться её аналогом в среде Битрикс и дальнейшей докруткой визуальной части системы.

Как выглядит обмен данными теперь

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

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

Оптимизация бизнес-процессов

LOC — это и есть наш аналог PostgreSQL на Битриксе. В нем содержатся данные для сайта, такие как: Файлы, изображения, свойства товаров, адреса складов/салонов. В Enrich у нас уходят только свойства и адреса. Если прям совсем подробнее то вот к такой схеме работы связки LOC-Enrich мы пришли:

Схема работы связки LOC-Enrich

Выводы

На текущий момент экосистема работает. Результаты:

  • Если товар изменили на стороне LOC, то практически моментально идет обновление на всех сайтах (если очередь забита, самая длинное обновление составляло ~10 мин, ранее это могло занимать до 20 часов).   

  • Уменьшили нагрузку на сервер и избежали пиковых нагрузок. Если раньше нагрузка росла пропорционально кол-ву языковых сайтов (запускается новая языковая версия сайта, включаем еще один экземпляр скрипта для нового сайта), то теперь количество запущенных скриптов (воркеров) постоянно. Так же все обрабатывается параллельно. В цифрах нагрузка с 52% уменьшилась до 23-25%.

  • Аналог PostgreSQL на Битриксе оптимизирует хранение данных (если раньше все свойства занимали место на сервере ~800Гб, то теперь ~300Гб).

Оцените статью
23.06.2022
Понравилась статья?
Поделитесь ссылкой с друзьями и коллегами!

Статьи по теме

Как b2b-платформа передает в 1С данные по новым контрагентам В этой статье мы расскажем, что происходит после того, как клиент зарегистрировал в б2б-кабинете новое юридическое лицо и сделал заказ, а также покажем, как...
Автоматизация и оптимизация бизнес-процессов — лонгрид, чтобы не запутаться Статья будет полезна всем, кто хочет улучшить эффективность своего бизнеса или узнать больше о возможностях автоматизации бизнес-процессов для повышения ко...
10 обязательных задач поддержки сайта на БитриксСтатья посвящена организации поддержки сайтов на Битрикс. Здесь не только про решение технических проблем и устранение багов. Здесь про развитие живых проектов...
B2B-SaaS или B2B-система (платформа+CRM) на вашем сервере: плюс и минусы, что выбрать? Введение Эта статья для коммерческих директоров, руководителей отделов продаж производственных и оптово-торговых компаний, которые ищут инструменты для ро...
Обзор международных исследований о тенденциях развития B2B-сегмента Важность темы — рост B2B-продаж в онлайне В современном бизнесе наблюдается стремительный переход в online оптовых продаж. Это стало одной из ключевых тен...
Несколько способов сделать оптовый заказ на портале — Обновление B2B-платформы (v2.0) Коллеги, спешим поделиться важной новостью! Мы обновили один из наших флагманских продуктов — готовую платформу оптовых продаж. B2B-платформа v2.0 сочетает...
Мы работаем по одному из двух форматов:
  • аренда команды (от 2 человек, не менее 3 месяцев);
  • итерации с фиксированной ценой (1-3 месяца длительностью).
ИНТЕРВОЛГА предоставляет:
  • регулярные онлайн-планерки с заказчиком;
  • квалифицированных специалистов;
  • организованную команду (находятся в одном помещении, что упрощает решение рабочих вопросов);
  • полную прозрачность и регулярность отчетов о результатах.
Ключевые услуги:
  • нагруженный интернет-магазин;
  • личный кабинет;
  • оптовые продажи — B2B-платформа;
  • маркетплейс;
  • технический аудит сайта;
  • Битрикс24 — корпоративные HR-порталы;
  • Битрикс24 — построение CRM-системы;
  • Битрикс24 — личные кабинеты сотрудников;
  • Битрикс24 — аудит портала;
  • 1С — интеграция с другими системами;
  • 1С — доработка системы;
  • маркетинг — комплексное интернет-продвижение;
  • маркетинг — продвижение для B2B.
Хотите получать лучшие статьи от INTERVOLGA раз в месяц?
Подпишитесь на рассылку — спамить не будем