1 Introduction
I believe you often separate read and write, split vertically, horizontally split, sub-library sub-table these terms was very ignorant force. I sometimes very ignorant force, then to put a few common terms database to find out today, but also record it.
2. The separate read and write
The relatively good understanding of some, is divided into the main database from the database, a master database ( Master ) for writing data, from a plurality of libraries ( Slaver polling data read process), between the master and slave through a library kind of communication mechanism for data synchronization, it is a common database schema. The picture below shows the structure on the "one main two from" in:
2.1 Why separate read and write
Most Internet data read write operations are often small, with the growth of data, "read" the database will first become a bottleneck. If we want to enhance the linear read performance and write performance of the database, you need to read and write as much as possible without affecting each other, their own way. Before using separate read and write, we should consider the use of caching can not solve the problem . Then consider the database grouped according to "read" and "write." Separate read and write means will be a unitary structure is dispersed in the large amount of data, high concurrency scenario to consider the following issues
- How to ensure the Master high availability, failover, current limiting fuse.
- The rules distinguish between read and write operations, the code level, how to handle read and write commands, try to perceive no business without intrusion.
Tolerance data consistency. Although the data is synchronized, but due to the uncertainty of this network remains a problem can not be ignored.
Sub-libraries
Database vertical split, horizontal split database collectively sub-libraries . Refers to a specific article and dimensions, the same data will be split into a plurality of databases in the database (host) in order to achieve the above dispersion in one database (host) load. We disguised reduces the size of the data set, space for time to improve performance.
3.1 Database vertical split
数据库垂直拆分 指的是按照业务对数据库中的表进行分组，同组的放到一个新的数据库（逻辑上，并非实例）中。需要从实际业务出发将大业务分割成小业务。比如商城的整个业务中的 用户相关表，订单相关表，物流相关表 各自独立分类形成 用户系统数据库，订单系统数据库，物流系统数据库 如下图：
这样带来了一些好处： （a）业务清晰，职责单一 （b）易维护，易扩展 （c）数据服务化 。 同时也有一些负面的作用：（a）提高了整个应用的复杂度，而且会形成跨库事务 （b）引发 “木桶效应”，任何一个短板有可能影响整个系统 （c）部分表关系不能 join 只能通过服务相互调用来维系。甚至由于网络问题引发数据不一致。
在需要进行分库的情况下，通常可优先考虑垂直拆分。
3.2 数据库水平拆分
在数据库垂直拆分后遇到单机数据库性能瓶颈之后，就可以考虑数据库水平拆分了。 之所以先垂直拆分才水平拆分，是因为垂直拆分后数据业务清晰而且单一，更加方便指定水平的标准。比如我们对商城业务垂直拆分后的 用户系统 进行水平拆分就比对整个商城业务进行水平拆分好找维度，我们可以根据用户注册时间的区间、用户的区域或者用户 ID 的范围、 hash 等条件，然后关联相关表的记录将数据进行拆分，如果放在整个商城业务上你是以用户为准还是以订单为准都不太好考虑。
我们按照每 100 万为区间对用户系统水平拆分如下：
这种拆分的好处在于： （a）单个库的容量可控 （b）单挑记录保证了数据完整性 （c）数据关系可以通过 join 维持 （d） 避免了跨库事务 ；缺点同样存在：（a）拆分规则对编码有一定的影响 （b）不同业务的分区交互需要统筹设计
4. 分表
分表也分为 数据表垂直拆分 和 数据表水平拆分 。
4.1 数据表垂直拆分
数据表垂直拆分就是纵向地把表中的列分成多个表，把表从 “宽” 变“窄”。一般遵循以下几个点进行拆分：
- 冷热分离，把常用的列放在一个表，不常用的放在一个表。
- 大字段列独立存放
- 关联关系的列紧密的放在一起
我们把用户表中常用的和不常用的而且大字段分离成两张表：
4.2 数据表的水平拆分
表的水平拆分感觉跟库的水平拆分思想上都是一样的，只不过粒度不同。表结构维持不变。也就是说拆分后数据集的并集等于拆分前的数据集。理解了 3.2 章节 之后这个就没有什么可说的了。
5. 总结
这里简单阐述了几个数据库优化概念，在实际操作中往往会组合使用。我们在实际操作之前要做好数据量的预估，这样能够根据预测未来数据的增量来进行选型。业务数据增长较小，常用于表的拆分。增长特别大达到上万级别则可以选择分库，比如一些资金积分流水，历史记录之类的。有些时候并不是拆分完就万事大吉了，比如我们按照地区拆分后，A 地区业务增长很快业绩很好，而 B 地区推广不力竞争激烈业绩萧条，造成了数据倾斜。也会影响分库分表的期望效果。这需要建立长效的监控预测机制来应对，甚至根据实际情况及时调整策略。数据拆分还面临分布式的很多问题，分布式事务，高可用，数据一致性，全局唯一性都是应该考虑的问题。如果你有什么问题可以通过公众号：Java知己 与我交流。
关注公众号：Java知己 获取更多资讯
[个人博客：https://blog.kotom.cn/)