Klustron（原KunlunBase） 的概要和优势
Klustron（原KunlunBase） 的概要和优势
Klustron 为 DBA 和应用软件开发团队带来的价值
Klustron 是一个分布式 HTAP 数据库系统，聚焦于解决各行业的应用软件、Web 系统和 SaaS云服务在存储、管理和利用海量关系型数据，以及支撑高并发高负载的事务处理和数据读写服务方面面临如下的一系列巨大挑战，从而为应用软件开发商、服务商和最终用户创造价值。
- 单台服务器有限的计算和存储资源与数据管理规模和访问负载持续增长形成巨大矛盾；
- 各种软硬件故障都可能导致计算机服务器节点故障和网络故障，从而导致持续保持数据读写服务的长期可靠性和持续性以及数据持久性和一致性 是巨大的挑战和困难；
- 在弹性波动的数据读写负载下，保持持续稳定的高吞吐率和低延时，具有巨大的技术难度，但对于流畅顺滑的终端用户体验极其重要，因而必须做到;
- 应用生态的兼容性具有巨大价值，兼容现有的使用 MySQL和 PostgreSQL 两大世界级数据库的应用软件有巨大的价值。
为了应对第 1 类挑战，前些年很多 MySQL 用户使用分库分表中间件或者在应用系统中实现分表逻辑，这些“土方法”有下述的一系列严重缺陷，并且无法应对第 2,3,4 类挑战。使用这些‘土方法’ ，本质上用户需要在业务系统中 case by case 实现数据管理功能，甚至是事务处理和容错功能，这对于绝大多数应用软件开发团队来说是不可能完成的任务，其应用软件系统的可靠性、稳定性、可维护性都会面临严重的问题，并且开发难度大大增加，开发周期不可控，项目延期风险大大增加，项目所需人力成本大大增加。同时也无法完成自动弹性伸缩，因为数据拆分逻辑与应用软件深度绑定。
使用 Klustron 可以完全地、彻底地、可靠地应对所有上述挑战！Klustron 把数据库系统的功能完全封装起来，让应用软件开发者只需要聚焦实现业务逻辑。无论需要存储和管理的数据量和在线访问负载有多大，用户（DBA，应用软件开发者和架构师）都可以把数据管理任务完全交给 Klustron，只需要 DBA 按需增减数据库服务器硬件，Klustron 即可自动完成弹性伸缩来承载这些弹性变化的负载。 这就极大地提升应用软件程序员的工作效率，极大降低其应用系统开发工作量和技术难度，确保应用软件系统的质量，稳定性和可靠性，并且大大降低项目开发周期和成本。
对于应用开发者来说，使用 Klustron 与使用 MySQL 和 PostgreSQL 数据库完全一样，因为 Klustron 支持 JDBC，ODBC，Hibernate，MyBatis 以及所有常见编程语言的客户端连接库，所有这些语言编写的软件都可以连接到 Klustron 并正确执行所有符合标准的 SQL 语句，以及 MySQL 和 PostgreSQL 私有的 DML SQL语句，因此原本使用 MySQL 和 PostgreSQL 的应用软件可以不做任何修改就使用 Klustron。同时，Klustron 支持从所有常见的关系数据库导入全量和增量数据，方便用户随时迁移到 Klustron 或者从 Klustron 迁移到其他数据库。
下面我们具体分析一下使用应用层分库分表或者使用分库分表中间件的问题。
01 令人“头都大了”的分库分表中间件
诸如 mysql_proxy，mysql_router，mycat 等数据行路由中间件的问题在于：
1.1 它们不支持完备的分布式查询处理
用户程序发给这些中间件的合法的 SQL 语句，只要涉及一些高级 SQL 功能，比如多表连接，子查询，CTE，window function，aggregation 等，这类中间件通常无法处理；这导致大量 SQL 生态下的工具，比如低代码工具，OR 映射中间件（例如 hibernate），机器学习算法等各种数据分析工具和算法 都无法与这些中间件交互和协作。
如果使用应用层分库分表，则应用软件程序员需要在业务代码中，分别到目标数据所在的存储集群查询数据片段，然后在业务代码中组装出最终结果。这些操作就是在应用层针对一个特定的 SQL 语句做了一次查询处理和执行。一旦需要修改“查询语句”，则需要修改大量应用代码，所以应用软件维护代价非常大。
这个工作本来可以直接发送SQL语句给分布式数据库就得到结果的，但是没有分布式数据库就只能针对每一个SQL语句针对具体查询实现一次查询处理功能，工作量自然非常巨大。特别是，这样的查询处理代码还可能因为业务逻辑的需求的变化和迭代而需要反复修改，这个开发工作量比直接修改SQL语句要大而且复杂太多了。
1.2 它们不支持可靠容灾的分布式事务处理
很多应用程序员并没有意识到分布式事务不做两阶段提交到底会有什么业务风险，处于“不知不觉”状态；少数应用程序员想到了这个潜在风险，但是无法解决，于是得过且过。
少数程序员认识到了问题并且能够解决，但也只能 case by case 地解决，比如为了实现可靠的转账功能，需要设计出一套技术在业务层实现转账场景的容灾能力。遇到其它场景又需要重新设计和实现一套算法。
这导致应用开发的技术门槛和工作量陡增，产品可靠性和稳定性有巨大风险和不确定性；项目延期风险大，开发成本高。尽管有些中间件使用了 MySQL 的 XA 功能做两阶段提交，但是无法可靠地保障在节点宕机/断网/超时等异常情况发生时确保用户数据的一致性（ACID）等属性。
上述一个共同的问题是，应用软件开发者需要知道他的每一个表到底存储在哪个存储集群中，才能做出正确的数据管理和查询功能，这让数据管理与业务逻辑产生了进一步的绑定，违背了数据库系统的初衷 --- 把数据管理完全封装起来，让应用软件开发者完全不考虑数据存储管理的任何细节。
1.3 它们无法做到自动水平弹性扩容
扩容需要 DBA 手动完成，需要暂停服务一段时间（比如若干个小时），停服会严重影响业务持续性和用户体验。
02 石器时代的应用分库分表
业界还有一种更加原始的方法来解决数据存储规模和访问负载过大的问题——应用层数据分区。这种做法之所以更加原始，是因为它除了具有所有上述令人“头都大了”的问题之外，还有以下一系列严重的问题，以至于我们可以说这些公司的产品和服务还处于石器时代。令人吃惊的是，这样的石器时代的公司还不在少数。
应用层分表的独有问题包括：
2.1 分表逻辑硬编码
这样要针对每一个表都做相似的功能实现，开发负担和复杂性很高。特别是如果多个应用软件/web服务需要使用同一套数据表的话（这是常见情况），还需要保持所有这些程序对每一个表的分表规则相同，开发工作量和复杂性将指数上升而不仅仅是线性成倍上升。
即使做的聪明一些像上述头都大了的中间件那样使用配置文件，也仍然有问题——需要实现分表逻辑，仍然大大增加了业务开发工作量。并且到最后你就实现了一个平庸的中间件。之所以说它平庸是因为只有你们公司/团队在用，并且可能只适用于你们的特定业务场景。这又让数据管理与应用逻辑进一步紧密绑定和依赖，是非常拙劣的系统设计。
2.2 水平扩容比“头都大了”更加困难
在分库分表逻辑硬编码的情况下，弹性扩容几乎无法完成，因为你需要修改业务代码实现新的数据分区规则才能扩容，那简直是开发人员和 DBA 的噩梦。
所以，我们决定研发一款真正的分布式数据库产品，把上述“头都大了”的用户和处于“石器时代”的用户彻底解救出来，让他们来到现在这个科技时代，感受到前沿的现代科技的魅力。
从此，他们将不再绞尽脑汁设计和实现分布式数据管理和查询程序，只要简单地发送 SQL 语句即可发起和提交分布式事务，以及执行分布式查询并直接得到查询结果。
这样就真正把数据管理重新与应用软件隔离开来，把数据管理从应用逻辑中抽象出来——这正是50年前数据库理论和技术先驱们的初心，也是他们用无数人/月和美金换来的教训：
用独立的数据库系统做数据管理，把应用软件开发与通用的数据管理逻辑分离开来，达到最大程度地软件复用和应用研发简单化，大大提升开发者的工作效率和其业务逻辑与产品的可靠性，降低用户业务系统的技术门槛并大大提升其可靠性，降低公司开发成本，保障其在线业务系统的上线时间可控可预期。
03 Klustron 的技术特点
Klustron 是一款高性能 NewSQL OLTP 分布式数据库，这是 Klustron 的核心能力。我们的核心目标是解决用户的海量数据存储管理和利用面临的问题。
面向新技术时代海量数据管理和利用的全方位新需求，通过水平弹性扩容，数据自动分区，分布式事务处理和分布式查询处理，容灾，高可用，强一致等核心关键特性，让各行业应用软件开发者聚焦应用逻辑开发，完全不需要承担数据管理功能实现，大大提升开发者的工作效率和其业务逻辑与产品的可靠性，降低用户业务系统的技术门槛并大大提升其可靠性，降低公司开发成本，保障其在线业务系统的上线时间可控可预期。
相信您现在知道为什么应该选择使用 Klustron，从根本上解决这些问题，把数据管理完全交给 Klustron，在用户的业务系统中完全无需知道关于数据存储和管理的任何细节，大大降低业务系统开发难度和成本，提升业务系统可靠性、稳定性。
下面就阅读本章主要内容，详细了解 Klustron 的架构、基本概念和技术优势，为使用 Klustron 做一个简单的准备。