为什么需要分布式数据库

​这些年，由于数据规模和业务访问负载越来越大，越来越多的公司无法依赖单台数据库服务器支撑其业务，越来越多的公司不得不做数据分区存储，也就是所谓的分库分表，但大量的烦恼与困惑也随之而来。

• 令人“头都大了”的分库分表中间件

10多年前阿里因此原因不得不把淘宝后台系统从Oracle RAC切换到数百个 MySQL集群构成的分库分表集群，不过那时的淘宝仅仅使用一个分库分表中间件，名为tddl（又名：头都大了，江湖上现在还有tddl的传说），而不是分布式数据库，这两者之间的区别，也可能正是tddl让淘宝后台业务开发者“头都大了”的原因。

具体来说，诸如tddl，mysql_proxy，mysql_router，mycat等数据行路由中间件的问题在于：

01 它们不支持完备的分布式查询处理

用户程序发给这些中间件的合法的SQL语句，只要涉及一些高级SQL功能，比如多表连接，子查询，CTE，window function，aggregation等，都无法正确执行；这导致大量SQL生态下的工具，比如低代码工具，OR映射中间件，机器学习算法等各种数据分析工具和算法 都无法与这些中间件交互和协作。

应用软件程序员需要在业务代码中，分别到目标数据所在的存储集群查询数据片段，然后在业务代码中组装出最终结果。这些操作就是在应用层针对一个特定的SQL语句做了一次查询处理和执行。

这个工作本来可以直接发送SQL语句给分布式数据库就得到结果的，但是没有分布式数据库就只能针对每一个SQL语句做一次类似的查询处理实现，工作量自然非常巨大。特别是，这样的查询处理代码还可能因为业务逻辑的需求的变化和迭代而需要反复修改，这个开发工作量比直接修改SQL语句要大而且复杂太多了。

02 它们不支持可靠容灾的分布式事务处理

应用程序员大多并没有意识到分布式事务不做两阶段提交到底会有什么业务风险，处于“不知不觉”状态；少数应用程序员想到了这个潜在风险，但是无法解决，于是得过且过。

只有极少数程序员认识到了问题并且能够解决，但也只能case by case地解决，比如为了实现可靠的转账功能，需要设计出一套技术在业务层实现