主要内容梳理
写入请求量大会造成性能和可用性的问题，如何应对呢？
采取对数据进行"分片"，这是一种思想，在数据库中就是分库分表，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.文中老师说如果要做分库分表留言一次性做到位，但这样在开始会很浪费空间，所以一般公司还是会采取慢慢扩容的方式，这样就引入了不停机迁移数据的问题，针对这种情况，老师是怎么做的呢？
—以上内容摘自用户每天晒白牙的评论
