数据库分表、分库及读写分离的基本概念

最近因为项目原因一直在研究分表、分库和读写分离。本来打算直接使用一款开源产品，但只开源了一部分，无奈只好自己动手丰衣足食了。

作者实现的简单分布式数据源:https://git.oschina.net/babybearhome/distributed-datasource.git

为什么要分表、分库和读写分离？
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用或者金融领域项目，日益增长的业务数据，无疑对数据库造成了相当大的负载，同时对于系统的稳定性和扩展性提出很高的要求。随着时间和业务的发展，库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作的开销也会越来越大；另外，无论怎样升级硬件资源，单台服务器的资源（CPU、磁盘、内存、网络IO、事务数、连接数）总是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。分表、分库和读写分离可以有效地减小单台数据库的压力。


分表、分库常用策略：
1.平均进行分配 hash(object)%N(适用于简单架构)。
2.按照权重进行分配且均匀轮询。
3.按照业务进行分配。
4.按照一致性hash算法进行分配(适用于集群架构，在集群中节点的添加和删除不会造成数据丢失，方便数据迁移)。
分表又分为单库分表（表名不同）和多库分表（表名相同），不管使用哪种策略都还需要自己去实现路由。


读写分离的基本原理：
让主数据库处理事务性增、删、改操作（INSERT、DELETE、UPDATE），而从数据库处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。
读写分离的基本结构：
一台主、多台从。主提供写操作，从提供读操作。
读写分离的实现：
我们只需要实现读写分离，主从复制数据一般由数据库级来实现同步，当然也可以自己去实现同步，只是需要考虑的点比较多。


什么时候用分库、分表？什么时候用读写分离？
在实际项目中可以从以下几个维度来考虑：
1.数据实时性是否比较高？
2.查询复杂度是否比较高？
3.读和写的比例即侧重点是哪一个？


作者给出的几点建议：
1.当主键和分表字段为同一个字段时适合选用分库、分表，因为通过主键进行散列分库、分表时，主键就是唯一的获取该条信息的主要途径。
2.当读大于写且数据量增加不明显时适合选用读写分离（读写分离+缓存）