parent
8d4641f7d8
commit
14dcc2b2a6
6 changed files with 65 additions and 6 deletions
@ -1 +1,11 @@ |
||||
# Replication |
||||
# Replication |
||||
|
||||
## Master-slave replication: |
||||
The master serves reads and writes, replicating writes to one or more slaves, which serve only reads. Slaves can also replicate to additional slaves in a tree-like fashion. If the master goes offline, the system can continue to operate in read-only mode until a slave is promoted to a master or a new master is provisioned. |
||||
|
||||
## Master-master replication: |
||||
Both masters serve reads and writes and coordinate with each other on writes. If either master goes down, the system can continue to operate with both reads and writes. |
||||
|
||||
To learn more, visit the following links: |
||||
|
||||
- [Getting started with Replication](https://github.com/donnemartin/system-design-primer#replication) |
@ -1 +1,10 @@ |
||||
# Sharding |
||||
# Sharding |
||||
|
||||
Sharding distributes data across different databases such that each database can only manage a subset of the data. Taking a users database as an example, as the number of users increases, more shards are added to the cluster. |
||||
|
||||
Similar to the advantages of federation, sharding results in less read and write traffic, less replication, and more cache hits. Index size is also reduced, which generally improves performance with faster queries. If one shard goes down, the other shards are still operational, although you'll want to add some form of replication to avoid data loss. Like federation, there is no single central master serializing writes, allowing you to write in parallel with increased throughput. |
||||
|
||||
Learn more from the following links: |
||||
|
||||
- [The coming of the Shard](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html) |
||||
- [Shard (database architecture)](https://en.wikipedia.org/wiki/Shard_(database_architecture)) |
@ -1 +1,7 @@ |
||||
# Federation |
||||
# Federation |
||||
|
||||
Federation (or functional partitioning) splits up databases by function. For example, instead of a single, monolithic database, you could have three databases: forums, users, and products, resulting in less read and write traffic to each database and therefore less replication lag. Smaller databases result in more data that can fit in memory, which in turn results in more cache hits due to improved cache locality. With no single central master serializing writes you can write in parallel, increasing throughput. |
||||
|
||||
Learn more from the following links: |
||||
|
||||
- [Intro to Federation](https://github.com/donnemartin/system-design-primer#federation) |
@ -1 +1,10 @@ |
||||
# Denormalization |
||||
# Denormalization |
||||
|
||||
Denormalization attempts to improve read performance at the expense of some write performance. Redundant copies of the data are written in multiple tables to avoid expensive joins. Some RDBMS such as PostgreSQL and Oracle support materialized views which handle the work of storing redundant information and keeping redundant copies consistent. |
||||
|
||||
Once data becomes distributed with techniques such as federation and sharding, managing joins across data centers further increases complexity. Denormalization might circumvent the need for such complex joins. |
||||
|
||||
To learn more, visit the following links: |
||||
|
||||
- [Guide to Denormalization](https://github.com/donnemartin/system-design-primer#denormalization) |
||||
- [Denormalization](https://en.wikipedia.org/wiki/Denormalization) |
@ -1 +1,13 @@ |
||||
# Sql tuning |
||||
# SQL Tuning |
||||
|
||||
SQL tuning is a broad topic and many books have been written as reference. It's important to benchmark and profile to simulate and uncover bottlenecks. |
||||
|
||||
- Benchmark - Simulate high-load situations with tools such as ab. |
||||
- Profile - Enable tools such as the slow query log to help track performance issues. |
||||
|
||||
Benchmarking and profiling might point you to the following optimizations. |
||||
|
||||
To learn more, visit the following links: |
||||
|
||||
- [What is SQL Tuning?](https://github.com/donnemartin/system-design-primer#sql-tuning) |
||||
- [Optimizing MySQL Queries](https://aiddroid.com/10-tips-optimizing-mysql-queries-dont-suck/) |
@ -1 +1,14 @@ |
||||
# Rdbms |
||||
# RDBMS |
||||
|
||||
A relational database like SQL is a collection of data items organized in tables. ACID is a set of properties of relational database transactions. |
||||
|
||||
- **Atomicity** - Each transaction is all or nothing |
||||
- **Consistency** - Any transaction will bring the database from one valid state to another |
||||
- **Isolation** - Executing transactions concurrently has the same results as if the transactions were executed serially |
||||
- **Durability** - Once a transaction has been committed, it will remain so |
||||
|
||||
There are many techniques to scale a relational database: master-slave replication, master-master replication, federation, sharding, denormalization, and SQL tuning. |
||||
|
||||
To learn more, visit the following links: |
||||
|
||||
- [Guide to RDBMS?](https://github.com/donnemartin/system-design-primer#relational-database-management-system-rdbms) |
Loading…
Reference in new issue