Database Flashcards
(1 cards)
Database scaling strategies
Before implementing dB scaling solutions, an important principle should be kept in mind - avoid premature optimization or scaling your database before it’s necessary.
Scaling introduces complexity like slower feature development, increased security complexity, harder testing and more challenging bug resolution.
Accept these trade offs only if your sop is at capacity. Keep your system simple & scale only when genuinely needed.
1) cache database queries
Cache database queries is one of the simplest improvements you can make to handle database load. Reduce load by caching frequently requested query results. Tools like Redis or Memcached store these results in memory, allowing your app to fetch data faster without hitting the database repeatedly.
2) Database indexes
Another straightforward strategy that delivers outsized performance benefits. Indexing accelerates data retrieval by enabling quick data location without scanning every row. Typically implemented with B-trees, indexes reduce data access time complexity from O(n) to O(logn). Significantly faster queries.
3) Database read replication
In read-heavy environments, replication may be the next best stone to turn. With read replication, you have a single database that you write to.
It’s cloned into several (as many as you need) replica databases that you read from. With each replica database sitting on another machine.
4) Database sharding
While the previous strategies focus on handling read load, sharding focuses on read and writes.
Sharding involved splitting your database into smaller, independent pieces (shards), with each handling a subset of data. This enables horizonal scaling by distributing the load across multiple servers. While powerful sharing adds significant complexity to data management and query logic.
Typically a strategy you only want to consider after exhausting other simpler solutions.
