1.介绍
相信你经常被读写分离垂直拆分、水平拆分、子库子表这些术语搞混。有时候很迷茫，所以今天我就把这些数据库里的常用术语找出来，记录下来。
2.读写分离
这个比较好理解，就是把数据库分为主从数据库，一个主数据库(Master)用来写数据，几个从数据库(slave)用来轮询和读取数据。主从数据库通过某种通信机制来同步数据，这是一种常见的数据库架构。下图是“一主两从”的结构:
2.1为什么要把阅读和写作分开？
大部分互联网数据操作倾向于多读少写。随着数据的增长，数据库的“读取”首先会成为瓶颈。如果要线性提升数据库的读写性能，就需要让读写尽可能的独立。在使用读写分离之前，要考虑使用缓存是否能解决问题。然后考虑根据“读”和“写”对数据库进行分组。读写分离意味着整合的结构被分散。在大数据量、高并发的场景下，需要考虑以下问题。
如何保证
Master
的高可用，故障转移，熔断限流等。读写操作的区分规则，代码层面如何处理好读命令和写命令，尽量无感知无业务入侵。数据一致性的容忍度。虽然是数据同步，但是由于网络的不确定性这仍然是一个不可忽视的问题。
3.分割图书馆
数据库垂直拆分和数据库水平拆分统称为子数据库。是指将同一数据库中的数据按照特定的条件和维度拆分到多个数据库(主机)中，以达到分散单个数据库(主机)负载的效果。这样我们就变相的减少了数据集的大小，改变了空之间的时间来提高性能。
3.1垂直数据库拆分
垂直数据库拆分是指将数据库中的表按照业务进行分组，将同一个组放入一个新的数据库中(逻辑上，不是实例)。要根据实际业务把大业务分成小业务。比如将商城整个业务中的用户相关表、订单相关表、物流相关表独立分类，形成用户系统数据库、订单系统数据库、物流系统数据库，如下图:
这带来了一些好处:(a)业务清晰，责任单一；(b)易于维护和扩展；以及(c)数据服务。
同时也有一些负面影响:(a)增加了整个应用的复杂度，会形成跨数据库的事务；(b)会造成“木桶效应”，任何短板都可能影响整个系统；(c)一些表关系不能被连接，而只能通过服务相互调用来维护。甚至数据不一致都是网络问题造成的。
在库分离的情况下，垂直分割通常是首选。
3.2数据库水平分割
垂直数据库拆分后遇到单机数据库的性能瓶颈后，可以考虑水平数据库拆分。之所以先垂直拆分后水平拆分，是因为垂直拆分后的数据服务清晰单一，更容易指定水平标准。比如我们把商城业务纵向拆分后的用户系统横向拆分时，比整个商城业务横向拆分更容易找到维度。我们可以根据用户的注册时间间隔、用户所在的区域或者用户ID、hash等条件对数据进行拆分，然后关联相关表的记录。如果放在整个商城业务中，你会以用户为标准。
我们按照100万的间隔水平拆分用户系统如下:
这种拆分的优点是:(a)单个库的容量可控。(b)一对一记录确保了数据的完整性。(c)数据关系可以通过join来维护。(d)避免跨数据库交易。
缺点也存在:(a)拆分规则对编码有一定影响。(b)不同业务的分区交互需要整体设计。
将桌子分开
表拆分还可以分为数据表的垂直拆分和数据表的水平拆分。
4.1数据表的垂直拆分
垂直数据表拆分是指将一个表中的列垂直分成多个表，并将表由“宽”改为“窄”。一般按照以下几点进行拆分:
冷热分离，把常用的列放在一个表，不常用的放在一个表。大字段列独立存放关联关系的列紧密的放在一起
将用户表中常见和不常见的大型字段分成两个表:
4.2数据表的水平拆分
表横向拆分的感觉和库是一样的，只是粒度不同。表格结构保持不变。也就是说，拆分后的数据集的并集等于拆分前的数据集。在理解了第3.2章之后，这就没什么可说的了。
5.摘要
本文简要阐述了几个数据库优化概念，在实际操作中经常结合使用。我们要在实际操作之前预估数据量，这样才能根据未来数据的预测增量来选择类型。业务增长小，经常用来分表。如果增长达到几万级别，可以选择分银行，比如一些资金点，历史记录等等。有时候，分手后并不是一切都好。比如我们按区域拆分后，A区业务增长很快，业绩很好，而B区推广乏力，竞争激烈，业绩低迷，造成数据倾斜。也会影响子数据库和子表的预期效果。这就需要建立长期的监测和预测机制来应对，甚至根据实际情况及时调整策略。数据拆分还面临很多分布式问题，如分布式事务、高可用性、数据一致性和全局唯一性等。希望我的解释能帮到你，也希望你多加注意！
本文来自热恋少女投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/477845.html
微信扫一扫 
