Как оптимизировать структуру баз данных для ювелирного интернет-магазина

О проекте

Франчайзинговая федеральная ювелирная сеть предлагает покупателям готовые украшения из серебра и золота с драгоценными и полудрагоценными камнями, а также большой выбор оптики, часов и других аксессуаров. Бизнес сотрудничает с 18 мировыми торговыми марками, является почетным членом Гильдии Ювелиров России и объединяет 1000 магазинов в 230 городах.

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

Описание задачи

До подключения команды RedLab ювелирная компания сталкивалась с ошибками при обращении к базе данных — неэффективные запросы приводили к избыточной нагрузке на сервер, возникали неоптимальные и зачастую излишнее индексы, а неправильное планирование конфигураций замедляло работу СУБД. Также некорректная структура БД усложняла процесс создания бэкапов, увеличивая время их выполнения и повышая риск потери данных. Было необходимо:

• Спроектировать легко поддерживаемую конструкцию.
• Обеспечить согласованность данных, устранив избыточные сведения.
• Увеличить надежность резервного копирования.

Реализация

Технологический стек:

• Postgresql
• Patroni
• Python
• Ansible
• IaaC
• Grafana
• Prometheus

С целью обеспечения надежной и функциональной системы команда RedLab провела следующие работы:

• Проанализировали текущую ИТ-инфраструктуру, а именно: существующие процессы и инструменты разработки, сборки, тестирования, доставки кода и управления окружениями.
• Передали данные с OpenTelemetry по проблемным приложениям командам разработки и Ops.
• Обновили и расширили кластер Kubernetes (K8s) с 15.х до 22.х. Новая группа вычислительных узлов позволила повысить гибкость разработки, уменьшить время развертывания программы и автоматизировать процесс управления контейнерами.
• Добавили OpenTelemetry к стандартному стеку мониторинга. Удалось улучшить видимость работы приложений и организовать единый источник данных о работоспособности инфраструктуры.
• Присвоили каждому запросу специальный идентификатор, благодаря которому можно найти конкретные ошибки в работе ПО и не искать примерно подходящие сбои по времени или по IP.
• Составили план поэтапного обновления кластеров с помощью Kubespray. Получилось легко и быстро развернуть компоненты системы.