即便是不懂编程的玩家，在比照 NAS 的时候，也会两眼放光，考虑良多因素，好比 RAID 级别、速度、易用水平等。做为每时每刻与代码打交道的我们，更需要存眷数据的存取问题。
一起头，开箱即用的 MySQL，必然是企业的首选。不单单因为用的人多，更重要的是生态成熟。要东西有东西，要人有人。关于老板来说，员工看着不爽，能够随时解雇，是一个十分抱负的形态。
但是，没有襟怀的老板，干的必然不会长久，因为若是商务会吹、老板会忽悠，营业会飞速开展（固然如今那种时机比力少了）。关于 MySQL 来说，很快就会碰到问题。
那个时候，就需要一些比只会用 MySQL 级别高一些的人才，来共同老板圆梦。
是时候了，由单机 MySQL 向散布式开展了。
单机 MySQL 面对良多问题。
单表太大，好比超越 500w，查询就十分费劲单库太大，各类资本告急读恳求太高，严峻影响写恳求对此，一堆概念也是腾空而出，好比分库分表、读写别离等。
很长时间以来，国内互联网的做法遍及是接纳参加一个中间件的体例来处理，但跟着散布式数据库的手艺越来越成熟，那些魔法逐步下沉到它本应该处理的层面--数据库实现层。
留给分库分表手艺的时间，已经不多了，它的存量市场越来越少了。分库分表手艺，退出汗青舞台，也是迟早的工作了。
处理上面三个单机 MySQL 问题，有良多种切入层面。好比，你简单的在 MyBatis 或者 JPA 之上利用 AOP 或者拦截器封拆一层，也能够实现，那也是最傻的体例。
再进一步，就能够接纳在 JDBC 之上的驱动层来实现，把分库分表的路由维护在内存里，通过重写的 DataSource、Connection、Statment、ResultSet等，对营业停止无侵入的改良。但可惜的是，我们还必需要维护与逻辑表相对应的物理表，并且功用也是阉割的，不确定性仍然不小。更要命的是，JDBC 只撑持 Java，关于某些公司来说，就十分的不适用。
再就是中间件的传统形式，PRoxy。把本身假装成一个MySQL Server，承受 Client 的恳求。至于它后面怎么去操做实在的数据库，你都不需要晓得。但 Proxy 自己也是一套办事，你有运维成本在里面，同时功用仍然是阉割的。
框架层，驱动层，代办署理层，在过去很长一段时间里，有无数的互联网公司前仆后继的试水，从 TDDL、Cobar，到 MyCat、ShardingSphere，各类层面的中间件也是屡见不鲜。但比来几年，那种争相斗艳的排场逐步不再，到最初剩下来的，也就ShardingSphere那桂林一枝了。
是问题不存在了么？不，正好相反，问题越来越严峻。并非问题消逝了，而是它被转化成其他处理体例了。
抛开关系型数据库不说，很久之前，类似于 ElasticSearch、Cassandra如许的 NoSQL 存储，分片和副本的概念，就已经十分成熟了，并且它们是内置的，其实不需要 DBA 去人工维护它们的物理位置。
关于关系型数据库来说，走向散布式也末将成为一定。跟着 Raft 等协议应用越来越普遍，散布式数据库的可靠性也逐步得到了包管。若是你以前因为事务问题而回绝接纳某些 NoSQL 产物，那么现在完全兼容 MySQL 的散布式数据库，你没有理由再说 No。
云厂商，间接供给了像Aurora、PolarDB之类的MySQL加强，更有类似 TiDB、OceanBase 如许地道的散布式数据库，越来越多的营业走向了那个末途。当你的团队加班加点验证着分库分表中间件的时候，却发现其实换个兼容的存储就能玩得转，你会怎么选，几乎不消再多说。
当然，一旦你选用了散布式数据库，以前的 DBA 经历可能就不管用了，好比说索引及其二级索引。你的团队不能不进修新的常识，来应对散布式情况。
但那些都是阵痛，久远看来，散布式数据库是趋向，而分库分表中间件只能吃存量。
当你的营业有了终年累积的复杂数据，你可能会接纳复杂的分库分表组件，但若是你的营业比力新，可预见的将来会有大量数据，那一个散布式数据库可能是最适宜的。
分库分表中间件并非消逝了。它摇身一变，酿成了散布式数据库的一部门。
你可能会听到良多切到散布式数据库，又从散布式数据库切回到 MySQL 的案例，那属于想吃螃蟹但并没有吃到。目前来看，散布式数据库越来越不变，生态建立也越来越好。而分库分表，则属于存量营业，末将会退出汗青的舞台。
Original reprint：https://mp.weixin.电话.com/s/tLnZ_5mCcsLPQkEw8uTUXA
发表评论