Чому п’ять серверів не справлялися з навантаженням: як ми перебудували архітектуру баз даних
Як ми усунули перевантаження 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 без придбання нових серверів.