分库分表
分库分表
为什么分库分表
在高并发和海量数据的场景下，通过使用分库分表的手段，能够解决单机或者单库单表的性能瓶颈和压力，突破IO、连接数、硬件资源的瓶颈。当然，投入硬件资源会更多，同时也会带来一些技术问题和挑战：如跨分片的复杂查询，跨分片事务等。
一般来说，Mysql 单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大(当然处理能力和字段数量/访问模式/记录长度有进一步关系)。
分库分表后的问题
分布式事务
1）避免分布式事务
同一订单业务相关的数据落在同一下标的库
需要选择合适的业务ID，作为库下标的路由
2）分布式事务问题
见之前的文章
查询数据结果集合并
跨节点Join
首先良好的设计和切分却可以减少此类情况的发生，解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。
跨节点的count,order by,group by以及聚合函数问
每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
分页查询
分库设计时，一般还有配套大数据平台汇总所有分库的记录，有些分页查询可以考虑走大数据平台，如opensearch
数据扩容
1）一致性hash，
减少了影响数据的范围，但还是避免不了数据迁移，最好的方式还是提前预估数据量。
2）id在 0–100万在第一个库中，100-200万在第二个中，200-300万在第3个中
或者按照时间范围来落库
不需要迁移数据，但是带来一个热点问题：当前的数据量达到某个库表的范围时，所有的插入操作，都集中在这个库/表了。
3）淘宝方案，看不太懂
https://www.cnblogs.com/tommyli/p/3767362.html
来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。
全局唯一性ID的保证
要求
1）全局唯一性
2）数据递增
解决
1）UUID
优点：数据迁移不受影响
缺点：字符存储，无序，查询慢，不可读
2）snowFlake雪花算法（twitter）
高位随机+毫秒数+机器码（数据中心+机器ID）+10的流水号
优点：数据迁移不受影响
缺点：强依赖时钟一致
3）redis生成
年份+天+时+redis自增
优点：没有单点故障，不依赖数据库，可读性好
缺点：需要占用网络资源，差于本地
淡淡的烟草味﹌
你的名字
我会带着你远行
野性酷女
还没有评论，来说两句吧...