Klustron（原KunlunBase） 的概要和优势
Klustron（原KunlunBase） 的概要和优势
Klustron 为 DBA 和应用软件开发团队带来的价值
泽拓昆仑Klustron 是一个分布式数据库系统，解决海量数据 存储、管理和分析、利用的系列技术挑战（如下所列），支撑高并发高负载的事务处理，提供高吞吐率和低延时的极致性能。在关系数据模型基础上，Klustron一站式支持GIS, JSON, 文本，向量(vector) 数据管理和查询检索，极大地简化应用系统架构设计和研发复杂度，大幅降低后台系统运维复杂度和硬件资源开销，提供与上层应用系统和其他数据处理组件的标准的互操作性和兼容性，帮助用户实现可插拔的标准化组件式的IT系统架构。
Klustron具备完善的分布式数据库能力，包括数据自动分区，水平弹性扩容，分布式事务处理和分布式并行查询处理，高可用，强一致，自动故障恢复，数据物理和逻辑备份恢复，容灾，数据流式导出（CDC）等核心关键特性，并且具备多数据模型融合处理能力，以及库内计算和机器学习能力，是面向AI的可扩展的数据基础设施。
海量数据存储管理和分析利用的技术挑战包括：
- 单台服务器有限的计算和存储资源与数据管理规模和访问负载持续增长形成巨大矛盾；
- 各种软硬件故障都可能导致计算机服务器节点故障和网络故障，从而导致持续保持数据读写服务的长期可靠性和持续性以及数据持久性和一致性 是巨大的挑战和困难；
- 在弹性波动的数据读写负载下，保持持续稳定的高吞吐率和低延时，具有巨大的技术难度，但对于流畅顺滑的终端用户体验极其重要，因而必须做到;
- 应用生态的兼容性具有巨大价值，兼容现有的使用 MySQL和 PostgreSQL 两大世界级数据库的应用软件有巨大的价值。
- 需要使用多种数据库管理关系数据，JSON，GIS，文本，向量数据，运维负担很重，应用系统开发复杂。
1. 令人“头都大了”的分库分表中间件
为了应对第 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 迁移到其他数据库。
Klustron让程序员们可以聚焦于开发和实现应用逻辑和功能需求，完全不需要在应用系统中承担数据管理功能，大大提升其工作效率和其业务系统和产品的可靠性和用户体验，降低公司IT系统软硬件和人员成本，保障其在线业务系统的上线时间可控可预期。
下面我们具体分析一下使用应用层分库分表或者使用分库分表中间件的问题。 诸如 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 手动完成，需要暂停服务一段时间（比如若干个小时），停服会严重影响业务持续性和用户体验。
2. 石器时代的应用分库分表
业界还有一种更加原始的方法来解决数据存储规模和访问负载过大的问题——应用层数据分区。这种做法之所以更加原始，是因为它除了具有所有上述令人“头都大了”的问题之外，还有以下一系列严重的问题，以至于我们可以说这些公司的产品和服务还处于石器时代。令人吃惊的是，这样的石器时代的公司还不在少数。
应用层分表的独有问题包括：
2.1 分表逻辑硬编码
这样要针对每一个表都做相似的功能实现，开发负担和复杂性很高。特别是如果多个应用软件/web服务需要使用同一套数据表的话（这是常见情况），还需要保持所有这些程序对每一个表的分表规则相同，开发工作量和复杂性将指数上升而不仅仅是线性成倍上升。
即使做的聪明一些像上述头都大了的中间件那样使用配置文件，也仍然有问题——需要实现分表逻辑，仍然大大增加了业务开发工作量。并且到最后你就实现了一个平庸的中间件。之所以说它平庸是因为只有你们公司/团队在用，并且可能只适用于你们的特定业务场景。这又让数据管理与应用逻辑进一步紧密绑定和依赖，是非常拙劣的系统设计。
2.2 水平扩容比“头都大了”更加困难
在分库分表逻辑硬编码的情况下，弹性扩容几乎无法完成，因为你需要修改业务代码实现新的数据分区规则才能扩容，那简直是开发人员和 DBA 的噩梦。
所以，我们决定研发一款真正的分布式数据库产品，把上述“头都大了”的用户和处于“石器时代”的用户彻底解救出来，让他们来到现在这个科技时代，感受到前沿的现代科技的魅力。
从此，他们将不再绞尽脑汁设计和实现分布式数据管理和查询程序，只要简单地发送 SQL 语句即可发起和提交分布式事务，以及执行分布式查询并直接得到查询结果。
这样就真正把数据管理重新与应用软件隔离开来，把数据管理从应用逻辑中抽象出来——这正是50年前数据库理论和技术先驱们的初心，也是他们用无数人/月和美金换来的教训：
用独立的数据库系统做数据管理，把应用软件开发与通用的数据管理逻辑分离开来，达到最大程度地软件复用和应用研发简单化，大大提升开发者的工作效率和其业务逻辑与产品的可靠性，降低用户业务系统的技术门槛并大大提升其可靠性，降低公司开发成本，保障其在线业务系统的上线时间可控可预期。
3. Klustron 的融合能力
Klustron通过支持PostgreSQL社区广泛的插件，获得并且放大了这些插件的能力。在这些插件中，Klustron团队扩展了 PostGIS，PGVector插件，而其他插件可以直接使用社区版本源码和Klustron 头文件编译构建。Klustron通过PostGIS 和PGVector插件获得了GIS和向量数据管理能力，成为分布式的PostGIS，分布式的PGVector。Klustron 可以管理和查询JSON数据，可以提供文本数据存储检索，特别是文本与向量联合检索能力。用户可以在同一个SQL语句中使用关系数据的谓词条件，JSON 内容片段，空间位置关系，向量距离和文本关键字来查询目标数据。详见本章第五篇。
下面就阅读本章主要内容，详细了解 Klustron 的架构、基本概念和技术优势，为使用 Klustron 做一个简单的准备。