2019-10-07主要内容梳理
写入请求量大会造成性能和可用性的问题，如何应对呢？
采取对数据进行"分片"，这是一种思想，在数据库中就是分库分表，Kafka中是分区，ES中是分片
分库分表的思想是根据某种分配策略把数据尽量均匀的分到多个数据库节点或多个表中，这样每个数据库节点和表都只存储部分数据，这样对数据的存储、读和写都有意义
存储:因为分库分表后每个节点和表只存储部分数据，这样就能解决数据存储的瓶颈
读:因为每个节点和表存储部分数据，数据量变小，可以提升查询性能
写:数据写入被分摊到多个节点和表，写入性能提高
分库分表有两种方式:垂直拆分和水平拆分
垂直拆分的关注点在业务相关性，原则是按照业务拆分，核心思想是专库专用，将业务耦合度高的拆分到单独库中
水平拆分是把单一数据库按照某种规则拆分到多个数据库和多个数据表中，关注点在数据的特点
水平拆分的两种方法
1.根据某个字段的hash值拆分
比如想把用户表拆成16库64表，方案如下
先对id进行hash操作hash(id)，这样有助于打散数据
然后对16取余 hash(id)%16，这样就得到了分库后的索引
最后对64取余 hash(id)%16%64，这样就得到了分表后的索引值
2.根据某个字段的区间或范围拆分
可以根据时间拆分
引入分库分表确实有很多优点，但也会引入新的问题
1.引入了分区分表键，也叫分区键
因为我们需要对分区键进行hash进行索引，这样就导致我们查询都要带上该分区键，比较好的解决办法是用id做分区键，但是如果有根据用户昵称查询的需求怎么办呢？
解决办法就是建立一个昵称和id的映射表
2.一些数据库的特性的实现变得困难
(1)夸库join不可用
解决办法是在业务代码中做处理
(2)求count
采取第三方组件例如redis实现
课后思考题
大数据的存储组件一般都涉及数据分片技术
例如Kafka的分区，ES的分片等等
拿Kafka的分区来举例
Kafka会对消息的key进行hash然后对分区数量取模，这样就得到了topic对应的分区索引
疑问点
1.老师我想请教下就是多库join的问题，如果采用在业务代码中进行处理不太妥吧，数据量太大了，如果有分页或排序的需求，这是要把各个库的数据都查出来，在内存中进行操作，这样会想当耗费内存，且性能低，老师有啥好办法吗？
2.如果一个订单库采用了买家id做为分区键，这样查询买家的订单非常容易，那要查询卖家的订单是不是和文中根据昵称查询一样，建立一个卖家和买家的映射表解决？
3.文中老师说如果要做分库分表留言一次性做到位，但这样在开始会很浪费空间，所以一般公司还是会采取慢慢扩容的方式，这样就引入了不停机迁移数据的问题，针对这种情况，老师是怎么做的呢？
谢谢老师展开作者回复: 1.多表join一般不会是全量数据，是分页数据，所以只有一少部分
2.建议是订单ID分库分表，然后建立买家ID和卖家ID和订单ID的映射
3. 一般是先双写两个库，然后校验数据，然后灰度切读，最后全量切读 3 39
2019-10-09老师说的道理 我都明白 只是如果现在有一张上亿的表 并且存在特定属性更新 那么如何不停机 进行分库分表 有木有具体的实践作者回复: 可以搭建新的库之后，先在业务上双写，然后校验两边的数据，再灰度切读，再全量切读
9
2019-10-07老师，请问下昵称和 ID 的映射表怎么建立，是按照昵称进行分库分表吗，即先查询这个昵称在哪个库哪个表，然后找到 ID，根据 ID 所在的库和表进行查询吗？作者回复: 是的，没错
2 5
2019-10-07公司小业务少时，不可能一开始就规划很多库和表(如16*64)，就像很多项目开始都只有一个库，但是我们做架构时可以预先考虑到后面可能会分库分表。请问老师，能不能讲一下最开始设计数据库时需要为今后分库分表考虑哪些因素，和一旦扩容后数据迁移的方案和注意点。谢谢。作者回复: 主要考虑数据的增长情况，数据迁移一般是先双写旧库和新库，然后校验数据，然后灰度切读，最后全量切读，注意点就是数据校验过程，会比较繁琐
1 4
2019-10-10老师能详细介绍一下分区和分片技术吗？ 3
2019-10-09分库分表之后,对于app端查询的问题还比较好解决。但是后端运营系统查询就麻烦，比如订单分库分表后，运营系统查询订单的时候可能根据多维度查询，这种方案您在工作中是怎么去解决的？我现在的做法就是同步到es里面。用ES去查。作者回复: 可以的，也可以同步到一个大库中，不过性能有点儿差
1 3
2019-10-08感谢老师分享，对于分表有点疑问：
1.如果是用户信息表需要分表，数据量大的前提下，需要准备一个映射表来存储昵称+uid的对应关系，文中提到了映射表也可以做分库分表，基本的思路是什么？用户在做登录相关操作的时候，都不知道昵称+uid的映射关系在哪张表中，难道是通过昵称算出hash值来确定分区键？
2.如果hash分表的策略又达到了瓶颈，需要更多的容量呢？基于对业务影响最小的方案是采用数据冗余+新的分区表还是重建分表规则做数据迁移？这一部分没有讲到哦，后面能否专门讲解下，一般应该是前者吧，因为后者在数据量大的情况下做一次数据迁移成本太高了？
3.对于文中提到的，16个库每个库中64张表，1024个张表，这个分表策略的理由是什么？个人感觉这个分表规则显得有些太浮夸了，因为有些业务压根用不到这么多表，甚至有时候分表操作是分表策略（局部分表）+当前模式（局部不分表）公用的方式来协调的，一步一步迭代过来的？不是很理解文中提到的这个策略的容量是如何计算出来的？如果数据量压根用不到这么多表，数据过于分散，对于管理和维护成本来讲有点小题大做了吧？
另外有一点，文中提到的总计数的问题，用redis存储的前提是当前的业务逻辑不是敏感的，用redis可以提升性能，如果是敏感业务的话，在更新数据库后还没有写入redis中的这个时间差，请求并发没办法估量和控制，所以最后的数据总量仅仅是最终的数据是一致的，但是逻辑是不一致的，核心原因是redis和mysql是属于不同的存储系统，无法做到两个系统公共支持一个分布式事物，无法拿到精确一致的视图，当然如果是非敏感业务，在保证性能的前提下，逻辑不一致可以容忍的话是可以考虑这种方案的。展开作者回复: 1. 是对昵称做hash，登陆的时候不需要知道昵称呀，可以针对手机号做hash，昵称是用来判断昵称是否存在
2. 不太清楚数据冗余 + 新的分区表的意思，是增加新的分区表吗？那么就要改分库分表的规则，那这样原先的数据就读不到了？是要做数据迁移？
3. 是需要一步步迭代，这里是说这些库表是足够了，如果业务没有那么大数据量，可以按照业务来
4. 计数是最终一致就好了 3
2019-10-24扬哥，后续可以开一期讲一下线上数据迁移的专题吗？作者回复: 马上就有啦：）
2
2019-10-15老师查询conut怎么做冗余，那种有where条件的作者回复: 可以考虑用es
2
2019-10-11打卡。老师，我一直以为“垂直”分表，是把一张大宽表，选出其中一些“列”，来化为新表😢 另外，在Oracle中的分区Partition索引，它支持多级 Sub Partition，那个它复杂度和存储是不是很恐怖呢😱 2
2019-10-10这个东西能不用就不用。毕竟很多老系统还有超多join操作，你一开始分库分表，所有代码都要重写。我倒觉得换es，mongodb是个好思路作者回复: 如果有运维能力也可
2
2019-10-07请教老师，为什么id要先做hash再做取余计算分库位置呢？直接用id取余不可以吗？作者回复: 直接取余也好，只是怕ID会不均匀
2
2019-10-22老师，如果水平分表是按照用户Id分的，如何进行分页查询呢？作者回复: 如果需要按照别的字段分页查询就需要冗余存储一份了
1 1- 2019-10-18老师，今天回来提个问题：在垂直拆分各个业务到不同的库和中心后，以前的那种rel关系表，到底应该归为哪个中心呢？望解答，困惑了我很久，谢谢！
作者回复: 我归在了用户中心
1 - 2019-10-08如果分库分表后 又增加了一个库来存储。那么原来的数据岂不是都不能用了？所有的数据再需要重新的分一遍吗？
据说一致性hash能解决这问题？老师可以具体说说吗作者回复: 一致性hash解决不了这个问题，如果要增加库的话，只能重新分配，所以会比较麻烦
1 1 
2019-10-07我挺推荐AWS Dynamo DB的，不用我自己部署，原生支持分区（有partition key），还支持分区内排序（有sort key），而且可以用API调用。
这个不是广告，纯属个人使用感受。 1 1
2020-01-27垂直分的含义是：一个库里的多个表分散到多个库里？
垂直分不是指：把某些特定的列划分到特定的分区，减少表的宽度，每个分区都保存了其中列所在的行。作者回复: 嗯 两种都是垂直拆分的方式
2020-01-21老师好，我这辈子做过的最大系统，不仅仅用上分库分表和读写分离了。很简单就是在100个MySQL，每个MySQL有100个表，这样根据id后四位就可以定位到它应该放在哪个MySQL和哪个表。但是因为每天可能有20亿的事务量，长此以往的数据积累，单表超过2000万时增改查性能都急剧下降，而且还有大数据团队要从这里导数据出去，低峰时还要删数据。那么我们就在时间纬度上也做了“分库分表”的思想：这一套分库分表乘以31，每天一套表来做日切，于是避免了单表过大，线上导数据风险大的问题，但业务上只能实时查询的31天内的数据，就是成本好大运维压力挺大。作者回复: 👍能解决问题就好
2019-12-29分库分表中还有一个难点分布式事务，这个老师可以介绍一下么？
2019-12-25用redis记录总数，逻辑上可能会出现不一致作者回复: 会有几率，可以手动修复