04关于大型网站技术演进的思考四存储瓶颈

1、而言那就是有不尽的项目可以做，虽然会感觉很忙，但是人过的充实，心里也踏实数而言那就是有不尽的项目可以做，虽然会感觉很忙，但是人过的充实，心里也踏实数据库水平拆分简单说来就是先将原数据库里的一在做垂直拆分出来放置在单独的数据库和单独的表里后更进一步的把本来是一个整体的表进一步拆分成多，每一都用独立的数据库进行。表被水平后，原数据表成为了一个逻辑的概念，而这个逻辑表的业务含义需要多张物理表协同完成，因此数据库的表被水平拆分后，那么对这的操作已经超出了数据库本身提供给现有段，换句话说对表的操数据库的水平拆分是数据库垂直拆分的升级版，它和垂直拆分更像继承机制里的父子关系，因此水平垂直拆分所遇到的 UT

2、 查询 以及分布式事务 任然存在，由于表被物理拆解增加了逻辑表的维度，这也给垂直拆分里碰到的两个难题增加了 的维度，因此水平拆分里 UT 查询 和分布式事务会变得更加复难题一：数据库的表被水平拆分后，该表的主键设计会变得十分难题二：原来单表的查询逻辑会在备本篇文章时候，我看到一些资料里提到了一些难题，这些难题难题三：平分表后，外键的设也会变得十分；难题四：这个难题是针对数据的新增操作的，大致的意思是，难题，我在上篇已经给出了解答，这里我进行一定的补充，其实外键问题在垂直拆分就已经存在， 过在讲垂直拆分时候 没有讲到这个问题，这主要是我设定了一个前提，就是数据表在最原始的数据建模阶段就要抛弃所有

3、外键的设计，并将外键的逻辑抛给服务层去完成， 要尽全力减轻数据库承担的运算压力，其实除了减轻数据库运算压力外， 还要将作为 直接的办法就是去掉表与表之间关联的象征：外键，这样 就可以从根基上为将来数据库做垂直拆分和水平拆分至于难题四，其实问题的本质是分库分表后具体的数据在哪里 ，而数据 在表里的关键 其实就是主键，试想一下， 设计 ，所有字段 都准 以为空，但是表里有个字段是绝对不能为空的，那就是主键，主键是数据在数据库里 的象征，因此 在主键设计上是可以体现出该数据的 规则，那么首先是水平拆分里的主键设计问题，抛开所有主键所能代表的业务含义，数据库里标的主键本质是表达表里的某一条的唯一性，在

4、设计数据库的时候可以由一个绝对不可重复的字段表示主键，也可以使用多个字段合起来表达这种唯一性，使用一个字表示主键，这已经是很原子的操作，没法做进一步的修改，但是果用多个字段表示一个主键对于水平拆而言就会碰到问题了，这个题主要是体现在数据到底于哪个据库，关于主键对数据的影响我会在把相关知识讲解完毕后再着重阐述，这里要提的是碰到联合主键时候我们可以设定一个没有任业务含义的字段来替代，不过这个要看场景了，我倾向于将联合主各个字段里的值由上所述，这里我给出水平拆分主键设计的第一个原则：被水平拆分的表的主键设计最好使用一个字段表示。唯一性的话，那么水平拆分时候相对要简单的多，例如在 XI 数据库里有一个

5、 KTI 机制，这其实就是一个自增数的算法，自增机制几乎所有关系数据库都有，也平时最喜使用的主键字段设计方案，如要拆分的表，使用了自增字段，同时这个自增字段只是用来表唯一性那么水平拆分时候处理起来就简单多了，我这里给出两个经典方案，方案如下关于大技术演进的思考（四） -的瓶颈方案一：自增列都有设定步长的特性，假打算把只拆分为两个物理表，那可以在其中里把主键的自增列的步长设计为 2，起始值为 1，那么它的自增方案一：自增列都有设定步长的特性，假打算把只拆分为两个物理表，那可以在其中里把主键的自增列的步长设计为 2，起始值为 1，那么它的自增规律就是 1,3,5,7 依次类推，另外一张物理也可以设

6、置为 2，如果起始值为 2，那么自增规律就是 2,4,6,8 以此类推，这样的步的主键就绝对会重复了，而也不用另外做两张物理表相应的逻辑关联了。这种方案还有个潜在的好处，那就是步长的把步长设计为 9，那么理小和水平数据拆分的粒度关联，也拆分的物理表可以扩容到 9 个为水平拆分的扩方案二其实事先通过一定业务技术规则大致估算出来最多让2 亿条，那可以这么设定自增列的规律，第一张物理表自增列从 假估算开始，步长就设为 1，第二种物理表的自增列则从 2 亿开始，步长也设为 1，自增列都做最大值的限制那么如果表的主键不是使用自增列，而是业务设计的唯一字段，那些的主键问题，那么碰到这个情又该如何解决了仔细

7、回味下数据库的水平拆分，它其实和分布式缓存其的类似，数据库的主键就相当于分布式缓存里的键值，那可以按照分布式缓存的方案来设计主键的型，方案如下方案一：使用整数哈希求余的算法，字符串如果进行哈希运算会得出一个值，这个值是该字符串的唯一标志如稍微改变下字符串的内容，计算的哈希值肯定是不同，两个不同的哈希值对应两个不同字符串，一个哈希值有且只对应唯一一个字符串，加密算法里的 MD5 ，SHA 都是使用哈希算法的原理计算出一个唯一标示的哈希值，通过哈希值的匹配可以判断数据是否被篡改过。不过大多数哈希算法最后得出的值都是一个字符加数字就要统计 通过得到的余数来选择服务器，该算法的原理图如下所示计算的整数

8、哈希值除以服务器的数量即取模计方案二：就是方案一的升级版一致性哈希，一致性哈希最大的作用是候以及物理表集群中某台服务器失效时候才会体现，这个问题我后续文章会详，此这里先不展了由上所述发现在数据库进行水平拆分时候一性设计的特点，最终于哪个物理数据库也是由主键的设计原则所决定的，回到上文里我提到的如果原的方案二：就是方案一的升级版一致性哈希，一致性哈希最大的作用是候以及物理表集群中某台服务器失效时候才会体现，这个问题我后续文章会详，此这里先不展了由上所述发现在数据库进行水平拆分时候一性设计的特点，最终于哪个物理数据库也是由主键的设计原则所决定的，回到上文里我提到的如果原的数据表使用联合字段设计主键

9、，那就必须首先合并联合主键字段，然后通过上面的算法来确定数据规则，虽然不合并一个字段看起来也不是太麻烦，但是在我多年开发里，把唯一性的字段分割成多个字段就等于给主键增加了维度，字段不得不时刻留心这些维度，果就很容易出错，我为了让数据库解决数据库表的水平拆分后的主键唯一性问题有一个更加直接的方案，这也是很多人碰到此类问题很自然想到的方法，那就是把主键生成规则做成一个主键生成系统，放置在单独一台服务器生成，每次新增数据键都从这个服务器里获取，主键生成的算法其实很简单，很多语言都有计算 ;/* 的功能，;/* 缺点一：把主键生成放到外部服务器进行，这就不得不通过网络通信完成主键值的传递，而网络是算机

10、体系里效率最低效的方式，因此它会影响数据新增的效率，特别是数据量很大时候，新增操作很频繁时候缺点二：如使用 ; 算法做主键生成的算法，因为 ; 是依赖单台服务器进行，那么整个水平拆的物理数据库集群，主就变成系的短板，而且是关键短板，主键生成服务器如果失效，整个统都会无法使用，而需要被水平拆分，而且拆分的表是业务表的时候在整个系统里的很高，它如果做了水平拆分后出现单点故障，这对于整个系统都是致命的。当然有人肯定说，既然有单点故障，那就做个集群系统，问题不是解决了吗？这个想法的确可以解决我上面阐，但是我前文讲到过，现实的件系统开发要坚守一个原则那就是有简单方案尽量选择简单的方案解决问题，引入集引入了分布式系统，这样就为系统开发增加了开发难度和运维风险，如上文的方案就能解，缺点三：使用外部系统生成主键使的水平拆分数据库的方案增加了状态性，而我状态的，有状态的系统会相互影响，例如使用外部系统生成主键，那么当数据操作增大时候，必然会造成在主键统上资源竞争的事情发生，如对主键系统上的竞争状态处理不好，很有可能造成主键系统被死锁，也就会产生我前文里说到的 错误，而无状态的系统是不存在资源竞争和死锁这里我列出单独主键生成系统的缺点不是想说明我觉得这种解决方案完全不可取，这个要看具体的业务了系