这些年，因为数据规模和业务拜访负载越来越大，越来越多的公司无奈依赖单台数据库服务器撑持其业务，越来越多的公司不得不做数据分区存储，也就是所谓的分库分表，但大量的懊恼与困惑也随之而来。
- 令人“头都大了”的分库分表中间件
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 地解决，比方为了实现牢靠的转账性能，须要设计出一套技术在业务层实现转账场景的容灾能力。遇到其它场景又须要从新设计和实现一套算法。
因而开发技术门槛和工作量陡增。只管有些中间件应用了 mysql 的 XA 性能做两阶段提交，然而无奈牢靠地保障在节点宕机 / 断网 / 超时等异常情况产生时确保用户数据的一致性（ACID）等属性。
上述一个独特的问题是，应用软件开发者须要晓得他的每一个表到底存储在哪个存储集群中，能力做出正确的数据管理和查问性能，这让数据管理与业务逻辑产生了进一步的绑定，是一个微小的问题。
03 它们无奈做到主动程度弹性扩容
扩容须要 DBA 手动实现，须要暂停服务一段时间（比方若干个小时），停服会重大影响业务持续性和用户体验。
- 石器时代的利用分库分表
业界还有一种更加原始的办法来解决数据存储规模和拜访负载过大的问题——应用层数据分区。这种做法之所以更加原始，是因为它除了具备所有上述令人“头都大了”的问题之外，还有以下一系列重大的问题，以至于咱们能够说这些公司的产品和服务还处于石器时代。令人吃惊的是，这样的石器时代的公司还不在少数。
应用层分表的独有问题包含：
01 分表逻辑硬编码
这样要针对每一个表都做类似的性能实现，开发累赘和复杂性很高。特地是如果多个应用软件 /web 服务须要应用同一套数据表的话（这是常见状况），还须要放弃所有这些程序对每一个表的分表规定雷同，开发工作量和复杂性将指数回升而不仅仅是线性成倍回升。
即便做的聪慧一些像上述头都大了的中间件那样应用配置文件，也依然有问题——须要实现分表逻辑，依然大大增加了业务开发工作量。并且到最初你就实现了一个平庸的中间件。之所以说它平庸是因为只有你们公司 / 团队在用，并且可能只实用于你们的特定业务场景。这又让数据管理与应用逻辑进一步严密绑定和依赖，是十分高明的零碎设计。
02 程度扩容比“头都大了”更加艰难
在分库分表逻辑硬编码的状况下，弹性扩容简直无奈实现，因为你须要批改业务代码实现新的数据分区规定能力扩容，那几乎是开发人员和 DBA 的噩梦。
所以，咱们决定研发一款真正的分布式数据库产品，把上述“头都大了”的用户和处于“石器时代”的用户彻底解救出来，让他们来到当初这个科技时代，感触到前沿的现代科技的魅力。
从此，他们将不再搜索枯肠设计和实现分布式数据管理和查问程序，只有简略地发送 SQL 语句即可发动和提交分布式事务，以及执行分布式查问并间接失去查问后果。
这样就真正把数据管理从新与应用软件隔离开来，把数据管理从应用逻辑中形象进去——这正是 50 年前数据库实践和技术先驱们的初心，也是他们用有数人 / 月和美金换来的教训：
用独立的数据库系统做数据管理，把应用软件开发与通用的数据管理逻辑拆散开来，达到最大水平地软件复用和利用研发简单化，大大晋升开发者的工作效率和其业务逻辑与产品的可靠性，升高用户业务零碎的技术门槛并大大晋升其可靠性，升高公司开发成本，保障其在线业务零碎的上线工夫可控可预期。
- 昆仑分布式数据库的技术特点
昆仑分布式数据库是一款高性能 NewSQL OLTP 分布式数据库。咱们的外围指标是解决用户的海量数据存储管理和利用面临的问题。
面向新技术时代海量数据管理和利用的全方位新需要，通过程度弹性扩容，数据主动分区，分布式事务处理和分布式查询处理，容灾，高可用，强统一等外围要害个性，让各行业应用软件开发者聚焦应用逻辑开发，齐全不须要承当数据管理性能实现，大大晋升开发者的工作效率和其业务逻辑与产品的可靠性，升高用户业务零碎的技术门槛并大大晋升其可靠性，升高公司开发成本，保障其在线业务零碎的上线工夫可控可预期。
我的项目已全副开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb
如果你还处于“头都大了”的状态，欢送分割咱们，咱们将尽可能帮忙你。
须要技术支持能够微信搜寻微信号（KunLunDB-Linda），增加客服，在线沟通即可。