Почему пять серверов не справлялись с нагрузкой: как мы перестроили архитектуру баз данных
Как мы устранили перегрузку Galera Cluster: 8 виртуальных машин на Proxmox, репликация MySQL и кеширование SELECT через ProxySQL без покупки новых серверов.
Как мы решили проблему медленного поиска по большому объёму контента: перенос поисковых операций на Elasticsearch и оптимизация архитектуры проекта.
Категория: Database Optimization / Search Performance / Infrastructure
Технологии: Elasticsearch, Database Optimization, Search Infrastructure
Большой объём контента в базе данных стал причиной медленной работы поиска на сайте клиента. Рассказываем, как мы решили проблему, вынеся поисковые операции в Elasticsearch, и восстановили комфортную скорость работы сервиса.
По мере развития проекта клиента объём контента в базе данных значительно увеличился.
Это начало сказываться на производительности встроенного поиска. Пользователям приходилось дольше ждать результатов, поскольку обработка поисковых запросов занимала слишком много времени.
Проблема заключалась в том, что существующий механизм поиска перестал соответствовать объёму данных, с которым работал проект.
Для дальнейшего развития сервиса требовалось решение, способное эффективно обрабатывать поисковые запросы без постоянного увеличения нагрузки на основную базу данных.
После анализа ситуации мы приняли решение использовать Elasticsearch — специализированный поисковый движок, предназначенный для индексации и быстрого поиска по большим объёмам данных.
Вместо выполнения поисковых операций непосредственно в основной базе данных мы перенесли поисковую функциональность на Elasticsearch.
Это позволило разделить две разные задачи:
Такой подход позволил использовать специализированный механизм поиска вместо того, чтобы заставлять основную базу данных выполнять ресурсоёмкие поисковые операции.
После перехода на Elasticsearch скорость работы поиска существенно улучшилась.
Пользователи получили возможность быстрее находить необходимую информацию, а поисковые операции перестали выполняться прежним способом непосредственно в основной базе данных.
При этом решение не требовало сокращать объём контента или ограничивать возможности поиска ради производительности.
Главный результат — поисковая система стала значительно быстрее работать с существующим объёмом данных.
По мере роста проекта архитектура, которая эффективно работала с небольшим количеством данных, может перестать соответствовать новым требованиям.
В подобных ситуациях увеличение мощности сервера не всегда является оптимальным решением.
Иногда гораздо эффективнее выделить ресурсоёмкую функцию в отдельный специализированный компонент.
В этом проекте использование Elasticsearch позволило ускорить поиск и отделить поисковую нагрузку от основной базы данных.
Медленный поиск, высокая нагрузка на базу данных и длительная обработка запросов могут указывать на необходимость пересмотра архитектуры приложения.
Инженеры inSave Hosting помогают оптимизировать серверную инфраструктуру, базы данных и производительность приложений.
Свяжитесь с нами, чтобы обсудить вашу задачу и подобрать подходящее решение.
Как мы устранили перегрузку Galera Cluster: 8 виртуальных машин на Proxmox, репликация MySQL и кеширование SELECT через ProxySQL без покупки новых серверов.