为什么要选择分布式数据库？

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

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

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

如果你还处于“头都大了”的状态，欢迎联系我们，我们将尽可能帮助你。

点击阅读原文

推荐阅读

KunlunBase架构介绍
KunlunBase技术优势介绍
KunlunBase技术特点介绍
KunlunBase集群基本概念介绍

END

昆仑数据库是一个HTAP NewSQL分布式数据库管理系统，可以满足用户对海量关系数据的存储管理和利用的全方位需求。
应用开发者和DBA的使用昆仑数据库的体验与单机MySQL和单机PostgreSQL几乎完全相同，因为首先昆仑数据库支持PostgreSQL和MySQL双协议，支持标准SQL:2011的 DML 语法和功能以及PostgreSQL和MySQL对标准 SQL的扩展。同时，昆仑数据库集群支持水平弹性扩容，数据自动拆分，分布式事务处理和分布式查询处理，健壮的容错容灾能力，完善直观的监测分析告警能力，集群数据备份和恢复等 常用的DBA 数据管理和操作。所有这些功能无需任何应用系统侧的编码工作，也无需DBA人工介入，不停服不影响业务正常运行。
昆仑数据库具备全面的OLAP 数据分析能力，通过了TPC-H和TPC-DS标准测试集，可以实时分析新的业务数据，帮助用户发掘出数据的价值。昆仑数据库支持公有云和私有云环境的部署，可以与docker，k8s等云基础设施无缝协作，可以轻松搭建云数据库服务。
请访问 http://www.kunlunbase.com/ 获取更多信息并且下载昆仑数据库软件、文档和资料。
KunlunBase项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb

相关文章