既然是“漫谈分库分表”,那么我们需要确定我们要谈什么,不谈什么。
-
首先,我们不讨论具体的分库分表框架的实现和源码,这不是我们讨论的范围。
-
我们讨论的是思路,主要讨论如何分库分表的套路,有什么坑,有什么心得,不针对具体的细节进行展开式讨论。当然我自己的能力有限,只是希望能够抛砖引玉。
-
我们要明确,分库分表,并不是一个银弹,它只是我们针对MySQL单机性能不够的情况下,想要节约成本的一种方式。对于boss来说,既想要想要节约成本,又想要支撑业务,提供稳定持久度性能。
程序员发挥出聪明才智,绞尽脑汁,日复一日的努力与实践,最终产生出主要的两种方式:
-
agent嵌入式模式,用一个jar包,集成到我们的代码里,在代码里通过路由规则,分片键方式进行分库分表,属于嵌入式方式。
-
cs模式(客户端-服务端模式),提供一个三方组件, 如: mycat,sharding-sphere中的proxy方式,类似于mycat;存在中心化,需要保证三方组件的高可用。
如果有更好的技术选型,我们宁愿不用分库分表,因为它本身就是一个复杂的解决方案。只是一种折中,更合适的是NewSQL、商业化数据库(比方说,Oracle,在大部分场景下,性能足够用,但是费用高昂)。
如果真的有一天,出现了一个优秀的、经济的newSQL, 比方说 oceanbase,tidb,那么我们基本上可以告别分库分表。
我们之所以选择使用分库分表策略,根本上还是因为,一方面是因为我们的使用成本不能太高;一方面,单机DB数据库性能不够了;一方面,newSQL当前还不成熟,太贵,不敢用。
分库分表用的厂家挺多的,有丰富的开源框架,有社区,还有成熟的案例,所以我们采用,
直接原因在于,阿里站台了,我们国内的风气是,阿里用啥我用啥,阿里怎么做我这么 跟风严重。我的想法是,我们还是有自己的技术前瞻性一些看法,最好不要唯阿里,唯技术。
说了这么多,我们回归正题,开始看问题。
1. 只做分表可以吗?还是必须要分表又分库,如果是分库的话 库是在多个服务器上吗?这个怎么来考虑
我想说,还是要看业务规模,既看当前的业务规模,也看未来3-5年的业务发展趋势。
涉及到技术选型,我们的宗旨是,永远选择最适合当下业务的、成本最低的,收益最高的,合适的就是最好的。
我们选择的方案最好是技术团队刚刚好能够hold住的选型。如果选型已经不适合当前的业务发展,那么大可以换套更适合的。这个本来就是事物发展的必然规律。
要么,业务还没发展到一个更高层次,就已经GG了,那么刚刚好,不用浪费钱买更好的设施,刚好止损;
要么,就是当前的方案确实不够用了,我们换了一套更牛X的,虽然说这样会花更多的钱,请更多的人,但是,这不正合我们的心意么,我们的目的本身就是通过合适的技术架构,更加优秀的代码,支持业务发展。
一句话总结就是,既然不得不花钱,那该花就花吧。
分场景讨论
一图胜千言,我们分别看看这两种场景。
对于 离线数据分析场景