Klustron（原KunlunBase） 核心能力

上章节介绍了 Klustron 的架构，这章节接着介绍 Klustron 的核心能力。

金融级高可靠性

Klustron具备金融级高可靠性，详见此文。

高可用性（ High Availability ）

Klustron 的存储集群 (storage shard) 使用 Klustron-storage 组成 2*N+1 个节点的主备复制集群，这样一个 shard允许同时 N 个节点故障时不失去写入能力也不会损失已提交的用户数据；在主节点故障后，计算节点可以自动切换存储集群主节点( auto failover )，无需人工干预。

详见 Klustron Fullsync技术介绍 和 Klustron Fullsync HA 技术介绍.

分布式事务处理的故障恢复能力

Klustron 的事务处理具备健壮完备的故障恢复能力( crash safety&fault tolerance )，确保集群任何节点故障或者网络故障，不会导致集群停止服务或者用户数据丢失。 计算节点故障不会丢失用户数据或者系统元数据或者导致数据不一致，唯一的影响是应用软件的客户端连接断开，导致正在执行的事务回滚。只要还有一个计算节点在运行，系统就仍然可以正常读写，

Klustron 通过分布式事务两阶段提交技术 确保节点/网络故障时可以保障客户端发起的分布式事务 的ACID属性 --- 已提交的事务的数据更新不会丢失或者损坏或者导致任何错误。

一个 Klustron 集群可以包含任意数量的计算节点，并且随时按需增减计算节点。客户端连接其中任何一个计算节点执行 DDL 语句后，这个 DDL 语句会自动被本集群所有其他计算节点执行，并且本集群所有计算节点执行所有 DDL 的顺序完全相同，确保所有计算节点有完全相同的元数据。执行每一个这样的 DDL 语句事务涉及计算节点，元数据集群，存储集群，Klustron 的容错技术确保 集群内计算节点或者其他组件和节点的故障不会导致 DDL 语句执行和复制重放出现故障。

多机房高可用能力

从Klustron-1.2版本开始，Klustron不仅可以做到集群层面的高可用，在服务器故障时确保集群持续提供服务并且数据不会丢失损坏，还可以做到机房级别的高可用。也就是即使一个机房整体全部同时故障了，Klustron集群仍然可以正常工作并且持续提供服务，不丢失损坏数据。这需要适当的方式来多机房安装和部署Klustron集群，详见 多机房高可用和 集群双活 相关的技术文档。

水平弹性伸缩能力

随着用户数据量、数据的读写访问负载和并发连接数的持续增加，数据库系统的负载会持续增加。对于单机数据库（比如社区版MySQL、PostgreSQL、以及传统商业数据库）来说，此时只能更换处理能力更强的硬件来提升计算和存储能力。但是受限于硬件技术，单台服务器的 CPU 和内存资源总量是有限的，对于 2022 年的服务器来说，具备 128 核心的 x86 CPU 和 1TB 内存 已经是顶级的服务器硬件了，但是现在的大量应用系统的负载会远远超过这样的一台服务器的处理能力，导致数据库系统的性能随着负载不断增加而不断降低，直到无法满足用户业务最低需求。对于这些单机数据库来说，这是无法逾越的障碍，即使公有云场景的数据库服务也都是单节点写入的，其写入能力在达到公有云厂商单台数据库服务器硬件资源和能力的上限后就无法再扩展了。

Klustron 可以平滑地水平弹性伸缩，集群每一个计算节点和存储集群都可以承载读写能力，从而可以持续地增加数据读写能力和事务处理能力。DBA 只要为 Klustron 集群增加更多的计算机服务器，Klustron 就会自动不停服地以用户无感知的方式 弹性扩展到这些新增的服务器，让它们与原有服务器平均承担存储和读写访问负载，以便集群整体可以承担更大的读写访问负载，存储更多数据。

灵活的数据分区和分布方式

弹性伸缩的基础要求是，用户的数据表如果很大的话，需要定义为分区表。我们认为专业的应用系统架构师、程序员和DBA 非常理解和掌握其业务系统的每个数据表的数据分布特征和数据读写访问的特点，可以基于此针对每一张表设计合理的分区方案，因此Klustron 给予用户对 表分区（sharding） 方式完全的定制能力。

Klustron 目前支持的 sharding 方式 : hash/range/list，这3中分区方式在 Klustron 的功能和用法与PostgreSQL 表分区方案完全相同, 此处不再赘述。

从 1.1 版本开始支持 Mirror表。Mirror 表用于提升只读查询性能，当一个表数据量不大（比如小于 1GB）并且不常被更新（比如每天只更新几百次），并且它经常与其他表 join，那么它适合被定义为一个 Mirror 表。一个 Mirror 表在每个存储 shard 都会存储一份，每次更新 Mirror 表，会在一个全局事务中更新每一个 shard 上的这个 Mirror 表的副本。增加存储集群后，所有 Mirror 表会被 Klustron 自动复制到所有新增的存储集群。点击了解更多关于Mirror的信息。

从1.2版本开始，Klustron支持表组(table grouping)功能，此功能让用户把业务逻辑方面紧密关联的表放置到同一个shard，以便提供更好的数据读写性能。

用户表分区方案主要包括：

• 选择表分布策略

  • Mirror表：每个 shard 一个副本
  • Table Group: 若干个表放到同一个shard
  • 随机选择shard
  • 最低负载的shard
  • 最少数据的shard

• 选择表分区方式

  • 单表：不分区
  • hash/range/list方法分区
    • 选择 sharding 列 : 任意若干个列
    • 设定分区的其他参数，每种分区方式各不相同
    • 多级分区：解决数据分布不均匀问题
    • 默认分区

用户根据数据特征和数据读写模式的特点，决定分区方式； 用户可以根据每个数据表的数据量选择分区的数量，不需要预估全局的固定的分区数目，也不把所有表等分为固定数量的分区，各表分区数量可以各异。对于 range 和 list 分区方式，用户可以为每个表按需增加表分区；通过定义合理的分区方式可以最优化系统的数据读写性能和事务处理性能。

计算节点自动为每个单表或者表分片选择合适的存储集群，以便所有存储集群承担均衡的负载；同时，用户在建表时也可以显式指定把表存储到特定的存储集群

多点读写

用户可以根据计算和存储需求，按需增加/减少计算节点和/或存储集群(storage shard)，具体操作方法可以通过 使用XPanel GUI，也可以 调用cluster_mgr API.

每一个计算节点都可以接收用户连接并且处理连接中收到的SQL请求，执行数据读写请求；每一个存储集群存储全量用户数据中的一部分，都可以执行数据读写请求。

Klustron 还支持读写分离，也就是计算节点选择存储集群的备机读取数据，这适用于完成数据只读查询。特别是在 OLAP 场景下，这可以避免因为从主节点读数据而干扰和影响 OLTP 的性能。

OLAP 数据分析能力

Klustron 的 OLAP 分析能力是对目前业界常见的基于列式数据仓库的 BI 和数据挖掘的补充和扩展。 Klustron 受益于 PostgreSQL 完备的数据分析功能，再加上我们在此基础上的深度内核研发的全局多层级并行查询处理技术，Klustron 因此支持用大量数据库服务器资源做 OLAP 数据分析，在后摩尔时代，能够充分利用大量计算资源实现高性能的数据处理和计算。

Klustron 的应用场景与传统的列式数据仓库显著不同，主要是：

1、无需 ETL，直接用最新数据分析

Klustron 不需要 ETL，而是可以使用当前最新的 OLTP 业务系统的数据完成数据分析，因而分析结果是对用户业务的当前最新状况的反应。借助读写分离技术，OLAP 负载并不会影响 OLTP 负载。

2、持续汇聚多源数据

用户可以把其他多个业务系统的数据库系统的数据变更持续地流式汇聚灌入一个 Klustron 集群，在此集群中统一综合分析所有这些业务系统的所有最新的业务数据，发现规律和洞察。在此漫长的持续汇聚流入过程中难免发生发生节点和网络故障，由于 Klustron 支持事务处理，因而节点故障不会导致汇聚起来的数据不一致，并且在一定条件下可以无损续传。

Klustron 的全局多层级并行查询处理技术 让 Klustron 可以在执行一个 SQL 查询语句时，同时实现三个层面的并行，即：

• 计算节点层的并行

• 计算节点与存储节点之间的并行

• 存储节点层的并行

Klustron OLAP 性能在持续提升中，这是 Klustron 1.1 TPC-H 和 TPC-DS 性能报告.

END