Why five servers could not handle the load: how we redesigned the database architecture
How we resolved Galera Cluster overload with eight Proxmox VMs, MySQL replication and ProxySQL query caching, without buying more servers.
How we fixed slow search across a large content collection by moving search operations to Elasticsearch and optimizing the project architecture.
Category: Database Optimization / Search Performance / Infrastructure
Technologies: Elasticsearch, Database Optimization, Search Infrastructure
A growing volume of content in the database had made search slow on a client's website. Here is how we moved search operations to Elasticsearch and restored a responsive experience for users.
As the client's project grew, the amount of content in its database increased significantly.
This began to affect the performance of the built-in search. Users had to wait longer for results because search queries took too long to process.
The existing search mechanism could no longer cope with the volume of data the project was handling.
To keep developing the service, the client needed a solution that could process search queries efficiently without continually increasing the load on the primary database.
After analyzing the situation, we decided to use Elasticsearch, a dedicated search engine designed to index and quickly search large volumes of data.
Instead of running search operations directly in the primary database, we moved search functionality to Elasticsearch.
This separated two distinct tasks:
This approach let us use a dedicated search engine rather than asking the primary database to perform resource-intensive search operations.
After the switch to Elasticsearch, search performance improved substantially.
Users could find the information they needed faster, and search operations were no longer executed directly in the primary database using the previous method.
The solution did not require reducing the amount of content or limiting search capabilities for the sake of performance.
The main result was substantially faster search across the existing volume of data.
As a project grows, an architecture that worked well with a small amount of data may no longer meet its needs.
In these situations, increasing server capacity is not always the best solution.
Sometimes, moving a resource-intensive function into a separate, dedicated component is far more effective.
For this project, Elasticsearch helped accelerate search and separate the search workload from the primary database.
Slow search, high database load and lengthy query processing may indicate that the application's architecture needs a review.
The engineers at inSave Hosting help optimize server infrastructure, databases and application performance.
Contact us to discuss your requirements and find a suitable solution.
How we resolved Galera Cluster overload with eight Proxmox VMs, MySQL replication and ProxySQL query caching, without buying more servers.