• 关于数据库分库分表的讨论
  • 发布于 2个月前
  • 87 热度
    0 评论
  • BruceLe
  • 1 粉丝 34 篇博客
  •   
昨天,小伙伴们在群里就分库分表方案展开了激烈的讨论,这里我对讨论的结果做了一个总结和补充,希望对各位有所帮助。本文的结论与许多网上观点存在分歧,如果你持不同意见,那以你的为准。

1. 为什么要分库分表
很多文章告诉你,当单表数据达到1000万左右就需要考虑分库分表,实际上但凡用单表记录数去评估是否需要进行分库分表,都是错的。衡量是否需要进行分库分表的标准有且仅有:容量。  这里的容量是指存储容量,性能容量。容量不是瓶颈非要去做分库分表设计,那就是脱裤子放屁,多此一举。当达到性能瓶颈并且核心业务系统才需要精心设计的分库分表方案,即通过分布式架构解决传统单一 Oracle 数据库的瓶颈。

这一结论在星球有专门文章进行详细说明,可参考此文:https://articles.zsxq.com/id_nopqqnz7xpb5.html

2.  如何选定分片键
分布式数据库架构设计的原则是:选择一个适合的分片键和分片算法,把数据打散,并且业务的绝大部分查询都是根据分片键进行访问。对于互联网业务,大多数是To C业务,分片键通常是用户的ID。业务的大多数访问都是基于用户ID进行查询,例如:
.查看某个用户下的微博/短视频;
.查看某个用户的商品信息/购买记录;

.查看某个用户自己的余额信息。


对于其他场景,需要根据具体业务情况进行深入分析。在海量高并发的业务场景中,分片键不仅仅是用于将数据打散,更是实现数据单元化的关键。毫不夸张的说分片键的好坏决定了你分库分表架构方案的好坏。

3. 分库分表后如何方便扩缩容
关于扩缩容,这实际上是一个伪命题,因为数据迁移成本是相当大的,不会有所谓的“方便”。有一个前提原则:如果已经确定要实施分库分表,那么一开始就要预估业务10年的数据量,不要幻想着等业务数据量变大再进行数据迁移,这是得不偿失的。

分布式数据库并不一定要求有很多个实例,最基本的要求是将数据进行打散分片。然后,用户可以根据需要进行扩缩容,以实现数据库性能和容量的伸缩性。这才是分布式数据库真正的吸引之处。

4. 分库分表以后如何对于非Sharding key进行查询
技术是为业务服务的,有时业务也需要妥协于技术,这在这种情况下非常适用。在分库分表后,对非Sharding Key的查询会对所有分片进行查询并合并,效率非常慢。在系统开发时务必避免这种情况,开发负责人和DBA必须严格把关,并提前对SQL进行审核预警。(据我所知,阿里是改写了数据库底层逻辑,对于非Sharding Key的查询直接拒绝。

在不直接使用SQL语句的前提下,要做到非Sharding key的查询,常用的有三种方案:
冗余数据法: (按照另外的维度再做一个分片方案,不推荐使用)
索引法表: (插入数据时维护一张单独的索引表)
基因法: (将分片键的信息保存在想要查询的列中)
这三种方案同样在分库分表专栏有详细的说明并配有相应代码,详见 https://articles.zsxq.com/id_q8z8wdjwsmb8.html

5. 分库分表真的会退出历史舞台吗?
最近有不少文章传播一种观点,声称分库分表将被淘汰,而OceanBase才是未来的主流。实际上,这种说法只是为了引起关注,是OceanBase的一种宣传手段。真正了解情况的人应该不会轻信这种言论。上个月参加了阿里的技术交流,目前OceanBase也只在蚂蚁有大规模使用,淘宝系依然还是使用精心设计的分库分表方案。

事实上,OceanBase也是基于分区实现的,数据查询时也需要根据SQL解析结果路由到对应的分区,如果没有命中分区也会退化成全表扫描。对于关键的业务数据场景,仍然需要实施精细化的分库分表方案,至少在5年内不会退出历史舞台,各位还是需要深入理解并掌握 !

以上,这就是我们最终的讨论结果,你们有何看法呢?欢迎留言交流~ 
用户评论