Scaling a relational or structured database is a means to continually provide High-Availability (minimal downtime, always available) and prevent unnecessary constraint on an organization’s resources.
There are a few ways to do this.
Starting with a “Read Replica”
You can think of a read replica as a clone of your original database.
It can only be read from. There can be multiple Read Replicas in synchronization. Writing will still occur on the primary database.
Therefore these are useful when there is more read activity.
In cases of disaster replicas can be promoted to the primary/master.
So, data will be written to the master database.
Then cloned to the Read Replicas.
At any time Replicas can be promoted to be the primary, master database.
Caching:
Caching stores frequent requests for the data.
(Redis or Memcached placed in front of the database) The first time a request is asked, the data will be retrieved from the database. Every subsequent request for the *same* data will then be retrieved from the cache.
This alleviates constant, repetitive requests to the database, improving performance.
Useful when there are many requests for the same thing.
Queueing:
Queuing messages (requests) helps decouple the architecture by providing a buffer zone between the application and the database.
This allows the application to send requests to the queue forming a line, instead of directly writing to the database.
Messages can be directed to proceed in a First in—First out method, or default which should offer better performance due to sending messages to the database in the most efficient way possible. (If the customers below had cash in hand or whether they needed to fumble around in their pocket could determine how quickly they are let inside.)
This will help prevent a surge to the database and improve overall performance as well.
In conjunction these mechanisms will allow for a more reliable and available database.
So what does this look like architecturally?
Follow the arrows, starting from the top
Breaking down what we just talked about, we see the initial request coming in drawn from the top and it goes straight to the database.
Thereafter, if the same data is requested it can instead be routed to the cache. We can also see the queue, and if multiple requests (the people in line in the photo above) are received, they will have to wait to access the database.
Hope this gives you a better idea of how to go about scaling a relational database! See you next time.