点击上方蓝字关注我们

应用软件开发者使用KunlunBase 开发应用系统与使用MySQL或者PostgreSQL开发应用系统完全相同 --- 他们完全不需要考虑数据在KunlunBase 分布式数据库集群中如何拆分存储和分布，也不需要担心一个事务写入多个存储集群的情况下，如何可靠地提交事务，如何执行获取多个存储集群上的数据来执行一个SQL查询语句 --- 所有这些技术细节都由KunlunBase处理，确保数据库事务的ACID 属性，并且高效地从目标数据所在的若干个存储集群获取目标数据来执行任意复杂度的SQL查询。

这是KunlunBase对应用开发团队来说显著优于应用层分库分表或者使用分库分表中间件的部分优势。这篇文章提到了中间件分表和应用层分表的“数宗罪（http://doc.klustron.com/zh/why_Klustron.html）”，可供参考。

KunlunBase架构图

KunlunBase的计算节点(Kunlun-server) 负责接受应用软件端的连接请求，验证请求合法性后建立连接；以及从已经建立的连接中接受SQL查询请求，执行请求，然后后返回查询结果。

三个或者更多个存储节点组成一个存储集群(storage shard，简称shard)，每个shard存储着一部分用户表或者表分区，不同shard的数据没有交集；每个KunlunBase集群有若干个计算节点和若干个shard组成。一个shard的主节点接受来自计算节点的读写请求，执行请求并返回结果给计算节点；启用了备机读功能时，shard 的备节点可以接收和处理来自计算节点的只读请求，常用于做数据分析和报表。

关于KunlunBase架构的更多信息，点击这里（https://doc.kunlunbase.com/zh/Architecture_introduction.html）查看。

2.1 KunlunBase产品设计的核心价值体系

在KunlunBase设计者看来，KunlunBase最重要的特质和价值应该是性能、可靠性、可扩展性、系统资源利用效率等，然后是对应用开发者的效率提升，最后才是对于DBA的易用性和便利性。这是我们做KunlunBase系统设计和实现的三大目标，并且优先级依此排序。同时我们认为，DBA是不可或缺的，数据库系统无法‘自动驾驶’。这是我们做KunlunBase系统架构和功能设计时所秉承的稳定和一贯的价值体系。

最高目标：性能、可靠性、可扩展性和效率

KunlunBase要服务的是专业的用户，用户的业务连续性和用户体验，以及用户的数据的一致性完整性具有最高的价值。因此数据库系统和应用系统的持续稳定性、可靠性，以及高性能和高可扩展性是最高目标；

KunlunBase要确保各种软硬件和网络故障不会导致数据丢失错乱或者数据库服务停止，为此我们做了大量工作，构筑了坚不可摧的系统可靠性，故障恢复能力和容灾能力。

KunlunBase集群要提供平稳的高吞吐率和低延时，并且用户增加更多服务器给KunlunBase集群后，KunlunBase能够线性扩展集群的性能峰值，也就是提供优秀的系统性能和可扩展性。为了这个目标我们在不断努力，虽然目前性能已经领先很多竞品，但是未来我们还有大量的性能优化方面的工作要做。

第二目标：提升应用开发者和架构师效率

KunlunBase分布式数据库集群是应用软件开发人员的可靠的数据管理平台，KunlunBase的第二大目标就是提升应用软件开发人员的工作效率。数据库系统归根到底是应用软件系统和各类信息系统的数据管理平台，那么提升应用软件开发者的效率对我们来说就非常有价值。对绝大多数软件开发团队来说，应用系统的需求多种多样且经常发生变化，这就导致应用软件的开发和维护工作量很大。因此我们认为，让应用开发者完全聚焦实现业务逻辑，把数据管理所需要的所有工作完全承担起来，是一个合格的数据管理平台的基本要求。分库分表中间件或者应用层分库分表这些老办法是完全不合格的。

对使用KunlunBase的应用开发者来说，使用KunlunBase和使用MySQL或者PostgreSQL做应用开发完全相同，无需考虑数据如何分片存储在多个shard，他要读写的数据分布在几个shard上面，如何获取分布在多个shard上面的数据，如何可靠地提交事务等问题，这些问题全部由KunlunBase完全可靠地系统地通用地解决掉了，应用开发者只要像使用单机数据库完全相同的方法写SQL代码甚至用hibernate等ORM中间件生成SQL代码读写数据即可。与此同时，无论应用系统的数据量或者线上实时访问负载有多大，KunlunBase都能够承载并且提供稳定的高性能，这对于应用开发者和应用系统架构师来说具有极其巨大的价值，极大地提升了他们的工作效率，极大地降低了他们的工作量。

第三目标：提升DBA的工作效率

KunlunBase的设计者认为，在确保了上述两大目标之后，KunlunBase也需要提升DBA的工作效率，并且DBA对数据库系统来说是必须的。任何数据库系统都需要专业的DBA处理生产系统的复杂场景，数据库系统不存在自动驾驶。

在自动驾驶这个概念出现了10年之后，面向个人的汽车目前的实用自动驾驶级别仅仅是L2，那么数据库系统能不能自动驾驶，只要问一问银行或者电商巨头的CTO，CIO就知道了。笔者相信，即使有一天汽车的自动驾驶已经商用L4级别了，数据库仍然需要DBA，毕竟对于众多的关键业务来说，停服一分钟带来的损失都是巨大的，如果停服一个小时，其立即可见的经济损失和暂时看不清的品牌/口碑的损失，就可以覆盖他们的DBA团队一年的开销了，并且让其CTO/CIO下岗了。这一点时不时的都会有事故发生作为例证，如果认为DBA无关紧要的人可以问问那些因为相关事故被裁掉技术领导的看法。

当然，DBA需要持续不断地提升自身技术水平，不仅仅要把数据库系统’玩的很溜’，还要理解数据库系统工作原理，甚至操作系统的工作原理。平时练好内功，才能在关键时刻派上用场。各种数据库管控工具把日常数据库运维管理工作几乎完全自动化了，那么需要DBA动手的时候，常常是出现了重大问题的时候，这时，就是考验内功扎实程度和向老板证明自身价值的时候了。

使用大量普通服务器组成集群，并且在其上部署具备优秀的扩展能力的分布式数据库，才能确保应用系统的吞吐率、性能和数据量可以持续增长的同时，提供流畅顺滑的用户体验。弹性伸缩能力是分布式数据库扩展能力的基础，而数据分片(data partitioning)是弹性伸缩的前提条件。KunlunBase满足所有这些要求和条件，能够为用户提供上不封顶的性能，吞吐率和数据读写负载和事务处理能力。

3.1 云计算与存储资源池

为什么弹性伸缩能力对于数据库系统来说是一个必须的能力呢？在当今云计算技术已经普及的情况下，存储空间不足已经不是数据库系统需要弹性伸缩的原因了，因为在公有云环境或者私有云环境里面，都可以借助分布式文件系统，技术上可以做到存储空间无限量供应，只要有足够的资源预算。分布式存储技术，把位于大量计算机服务器上的存储资源变为资源池，能够虚拟出一个具有无限存储空间的‘磁盘’，这样，磁盘空间无限增长对于数据库系统来说是透明的，这就非常完美的解决了外存空间不足的问题。

但问题是，集群计算资源不仅仅包括外存，还包括CPU和内存，而一台服务器的CPU和内存空间有限。并且，我们简单分析一下就会发现，内存是无法在不显著增大读写延时的前提下，做到像磁盘那样虚拟为资源池的。

3.2 内存无法池化

我们先想一想，一个服务器的CPU全硬件连接读写另一台服务器的内存的延时有多大？答案是大于10us。计算方法如下：一个数据中心(IDC)内两台服务器平均连线长度250米，光纤以接近光速传输（2.5*10^8m/s）、再加上光信号中继延迟、接收方RDMA中断处理延迟、cache淘汰等操作带来的延时，特别是网卡、网络设备（交换机）包转发的软硬件延时等。这个延时是本机内存访问耗时（通常在100ns以内）的100倍以上，实际情况下能达到数百倍甚至上千倍。如此巨大的内存读写延迟，就导致假如读写同一个IDC内的另一个服务器的内存，实际上与内存读写的性能预期偏差巨大，其操作已经不能作为内存读写来看待了。也就是说，内存资源无法做成一个大量服务器组成的资源池，实现无线扩展内存容量的理想状况。那样做导致的性能损耗过于巨大而失去了实用意义。由于内存无法无限扩展，自然也就无法跨节点透明地分配CPU指令流，所以CPU也是无法做成资源池的。

3.3 公有云RDS的扩容能力受限于单台服务器的计算资源

性能可以接受的方法只能是增加计算机服务器，并且实现分布式数据库系统的水平弹性扩容。这些是单机数据库（MySQL，PostgreSQL，Oracle等）无法做到的，在公有云上用户会发现可以对这些单机数据库的RDS做扩容，比如从 2核心4GB升级为8核心32GB。但是这样的扩容的前提是虚拟机所在的物理机有更多的CPU核心和内存空间可以扩容，也就是说单机数据库RDS的扩容能力受限于所在的物理机的最大CPU核数和内存空间，无法对数据库系统实现计算资源的池化和自动弹性扩容。如果依靠操作系统的虚拟内存能力，在工作集如果无法完全装入内存的情况下借助虚拟内存的换页操作(swap)来辗转腾挪，则频繁换页操作会严重损耗性能，导致数据库系统及其所在的操作系统性能极低。

3.4 组建服务器集群才能持续增加计算资源

当数据库系统负载很重需要上千个CPU核心和数十TB内存的时候，用户会发现无论他们有多少预算，都无法买到一台这样的服务器。如果用64台相同配置的服务器集群的资源总量达到相近的水平，例如每台32个CPU物理核心，512GB内存，16TB SSD存储，则这些服务器的总价格可以控制在600万人民币左右，这对于有如此之高的业务负载的公司来说，是完全可以承担的价格。

我们再来看一下应用软件的弹性扩容 --- 当今依靠k8s和容器化等技术，可以对各类应用实现自动化的高可用和弹性伸缩，无需应用系统做任何事情。但是这里有一个很容易被忽略的假设 --- 之所以应用可以借助k8s做到自动弹性扩容，是因为其本身无持久状态。对于大多数应用系统来说，其持久状态都存储在数据库系统中。因此，数据库系统的弹性扩容能力是大多数应用系统整体弹性伸缩能力的基础和根本保障；数据库系统如果不能弹性扩展(scale out)，那么使用数据库系统的应用系统的整体性能和吞吐率就有一个无法逾越的硬性瓶颈和天花板。即使那些应用系统处理能力扩容而增大了，其数据库系统仍然成为其性能瓶颈，导致这样的应用系统整体性能被其数据库系统的瓶颈限制住了。

更有一个难点是，数据库系统的可扩展能力(scalability），即如何把一台性能强劲的，拥有数百个CPU核心的服务器的性能完全利用起来。这需要在软件层面做前瞻性的架构设计和大量细致严谨的工程设计和实现。如果没有优秀的可扩展能力，那么即使有一台性能强劲的服务器，也无法充分发挥其性能。这对于单机数据库尤其困难；当然，分布式数据库系统也要很好地系统设计和工程实现才能做到优秀的可扩展能力。

3.5 使用KunlunBase提供上不封顶的水平扩展能力

我们坚信，分布式数据库系统是未来通过大量商用服务器硬件(commodity servers)提供上无止境的系统性能（我们坚信很多行业都会有这样的需求，本文不展开论述）的关键，而且这种硬件技术方案的成本可控，技术路线清晰而且可落地执行，没有技术风险、成本风险和厂商锁定的风险，是适应所有行业所有类型应用的通用的最优技术路线。

在这个路线中，具有优秀的扩展能力的分布式数据库管理系统(Distributed Database Management System, DDBMS)软件的作用至关重要。

首先，DDBMS需要能够利用大量服务器的硬件资源，把数据大致均匀地存储到这些服务器上面，并且随着数据量持续增加以及数据读写负载持续增加，DBA只需要增加服务器给DDBMS，DDBMS就可以自动把一部分数据搬迁到这些新增的服务器上，同时把计算和存储负载扩展到这些新增的服务器上，从而重新达到均衡并且提升集群整体的负载能力。这就是DDBMS的弹性伸缩能力（http://doc.klustron.com/zh/scale_out.html）。

同样重要的是，DDBMS要有优秀的扩展能力，也就是说，如果10台服务器组成的集群可以提供10万TPS的话，那么20台服务器组成的集群要能够提供20万TPS，这就是完美的“线性扩展”的情况。

了解某些知名的传统数据库系统的资深DBA很清楚，这是很难做到的。或者说，某些使用30年前的技术路线的传统数据库的分布式方案，在机器数量达到一定规模（比如8台）后，再增加机器（都是性能强劲价格高昂的服务器、网络和存储系统）带来的性能提升的边际效应持续递减，无法做到线性扩展。到最后DBA会发现，再增加机器，集群的性能反而降低了。

同时，DDBMS必须有效解决服务器软硬件和网络故障，确保这些故障不会导致数据损坏、丢失或者服务停顿，这就是DDBMS的故障恢复和容灾能力（http://doc.klustron.com/zh/The_problem_of_MySQL_distributed_transaction_processing_and_the_solution_to_Kunlun-storage.html）。

除了最关键的这两点之外，DDBMS还需要有便捷的数据库集群管理控制监控排障工具（http://doc.klustron.com/zh/XPanel_Manual.html）和API（http://doc.klustron.com/zh/cluster_mgr_api.html）等，以便提升DBA的工作效率。

KunlunBase具备所有这些能力，本文主要介绍KunlunBase在数据分布和弹性伸缩方面的能力。

在经典的单机数据库时代，数据库设计主要就是根据应用系统的架构和功能设计，来设计和定义数据表，包括每个数据表有哪些列，每个列的数据类型和约束、表的主键、(唯一)索引、表级约束、每个表的触发器等，以及定义存储过程、视图、访问控制规则等。

使用分布式数据库的情况下，还需要设计数据表的分区规则和分布策略。KunlunBase 数据表分布方法包括分区规则和分布策略两部分。分区规则是指如何拆分一个表，用哪些列做什么样的计算来作为拆分依据；分布策略是指一个单表或者表分区应该放置到哪个shard中。KunlunBase基于分布策略把表分区分配到存储集群。

分区规则和分布策略对应用透明的，用户永远只需要读写根表，不需要知道这个表如何分区以及其分区如何分布在哪些shard上面等细节，计算节点负责计算得知用户的查询语句对应的数据在哪些shard的哪些表分片中，并且发送适当的数据读写语句到对应的shard。

在数据被拆分存储到多个shard后，经常会出现同一个事务中写入多个shard上的数据表分片，KunlunBase的分布式事务处理机制（http://doc.klustron.com/zh/two-phase_commit_mechanism_and_principle.html）会确保这些事务可靠地提交，任何节点故障都不会导致数据丢失损坏或者不一致。

同时用户也无需考虑一条SQL涉及的表如何分片存储到那些shard上，KunlunBase的分布式查询处理机制（http://doc.klustron.com/zh/Query_optimization.html）把所有这些细节封装在内部，自动执行任何合法的SQL。

下面简单介绍分区规则，后文详述分区规则的使用场景和SQL语法，以及KunlunBase的数据表分布策略。

4.1 KunlunBase的分区规则

分区表及其所在的shard 示意图

KunlunBase支持Hash, Range, List三种分区规则，每一种规则用户都需要在创建分区表时根据这个表的预期的数据分布规律和常用查询方式选择适当的分区方式，并且选择一个或者多个列作为分区列；并且在创建该分区表的表分区时为它的每个表分区设定该表的分区方式所需的特定的参数。

然后，kunlun-server就会把分区表按照一系列分布策略安排存储到合适的shard上面，并且把这个信息记录在计算节点的元数据表中，并且通过DDL日志复制机制扩散告知其他计算节点。于是一个KunlunBase集群的每个计算节点都知道每个分区表的每一个分区在哪个shard中。

这样，KunlunBase的计算节点(kunlun-server)就可以通过INSERT 语句的数据行，用该表的分区方式和参数计算出每行应该插入到哪一个表分片中，从而发送给每个shard 适当的一组INSERT语句插入最终数据到相关的数据分片中；或者通过用户的UPDATE/DELETE/SELECT SQL语句设定的查询过滤条件指定的分区列得知目标行所在的分区，从而向那些分区发送特定的针对每个数据分片的SQL语句；如果过滤条件中没有指定分区列，那么计算节点就无法知道目标行所在的分区，这样它就会向该表的所有分区所在的shard发送经过KunlunBase的分布式查询优化之后，存储节点应该执行的查询语句，这些存储节点执行这些语句的实际结果，可能是过滤条件在有些shard中匹配到了一些行，另一些shard中并没有任何一行匹配过滤条件。

5.1 使用KunlunBase的表分区功能

下面简单介绍每种分区方式的适用场景以及语法。在KunlunBase中为一个表指定分区方式的方法就是创建这个表及其所有表分区。KunlunBase支持用多个列做分区列，因此我们称多个分区列的字段值组成了一行数据的分区字段向量(sharding key vector)。

Hash

Hash分区方式适用于如下场景：

A. 表的数据量大致可预测，数据量增长不快不突发。这条不是必须条件。如果一个hash方式分区的表的数据量在后期大幅变化导致分区数量不再合适，那么可以使用KunlunBase的重分区(repartition)功能调整分区数量。

B. 对某个或者某组序数值(cardinality) 很大（即 字段值的重复度很低）的列做等值查询是最频繁的查询方式之一

C. 每个分区字段向量的行数分布较均匀

这个表就适合做hash分区，这(几)个列就适合作为hash分区的分区列。如果高频查询所用的列的重复度较高，比如性别，那么最好再增加一两个列一起作为hash分区，否则会发生严重的数据偏斜(skew)，即一些分区数据量很大，另一些分区数据量很少。

常见的适合做Hash分区的信息包括：名称，ID，邮箱，手机号。Hash分区的优缺点都非常明显。

优点：定义简单，不需要知道字段值的分布

缺点：分区字段值分布很不均匀时可能导致该表的数据分布和系统负载严重不均衡。

Hash方式需要选择列和分区个数，下面是创建hash分区表的语法示例：

CREATE TABLE t1(a serial primary key, b int, c varchar(32)) partition by hash(a);
CREATE TABLE t1_0 partition of t1 for values with (modulus 4, remainder 0);
CREATE TABLE t1_1 partition of t1 for values with (modulus 4, remainder 1);
CREATE TABLE t1_2 partition of t1 for values with (modulus 4, remainder 2);
CREATE TABLE t1_3 partition of t1 for values with (modulus 4, remainder 3);

Range

Range分区方式适用于以下场景：

A. 对某个或者某组序数值(cardinality) 很大（即 字段值的重复度很低）的列做范围查询是最频繁的查询方式之一

B. 或者分区字段值的数据量分布很不均匀

常见的适合做Hash分区的信息包括：数量或者日期、时间、ID。

优点：可以对数据分片规则做精确定义

缺点：随着数据量的变化，分布规则可能不再适合。此时，就需要KunlunBase的重分区(repartition)功能（https://doc.kunlunbase.com/zh/repartition.html）调整分区边界和数量。

Range方式需要选择分区列和分区边界向量，比如：如下语句创建的表t1:

CREATE TABLE t1(a serial primary key, b int, c varchar(32)) partition by range(a);
CREATE TABLE t1_0 partition of t1 for values from (MINVALUE) to (100000);
CREATE TABLE t1_1 partition of t1 for values from (100000) to (1000000)

T1的分区列是a，则分区边界是100000, 1000000这样的标量；随着t1更多数据，可以按需创建更多的分区。用户也可以创建有多个分区列的range分区表：

CREATE TABLE t2(a serial primary key, b int, c varchar(32)) partition by range(c, a)

t2的分区列是(c,a)，则分区边界形如(‘abc’,1000), (‘ufo’,10000)等：

CREATE TABLE t2_0 partition of t1 for values from (MINVALUE, MINVALUE) to (‘abc’, 100000);
CREATE TABLE t2_1 partition of t1 for values from (‘mvp’, 100000) to (‘ufo’, 1000000);

List

List方式适合分区字段的不同值数量较少（比如：几十个），分区列每个分区字段向量对应的数据量差别不能太大，并且对分区列主要做等值查询的场景。

常见的适合做Hash分区的信息包括：：国家名，省市区名称，数量很少（数百个以内）的事物的名称、种类等枚举值。适合搭配KunlunBase的枚举类型（https://doc.kunlunbase.com/zh/Enum_data_type.html）使用。

List分区方式的优缺点是：

优点：表定义简单直观

缺点：需要准确掌握数据表在分区列上的分布，否则数据在各个分区上很容易发生严重偏斜。不过如果偏斜严重的话，可以增加下一级分区来解决问题。

List分区需要设置分区列及其对应的一组分区字段向量，例如：

CREATE TABLE t1(a serial primary key, b int, province varchar(32), city varchar(32)) partition by list(c);
CREATE TABLE t1_0 partition of t1 for values in (‘beijing’,‘beijing’);
CREATE TABLE t1_1 partition of t1 for values in (‘guangdong’,‘shenzhen’);

多级分区和缺省分区

KunlunBase支持多级分区和缺省(default)分区，这主要是为了解决在实际生产环境中，在特定的分区规则下，不同表分区的数据量经常会出现显著的不同，数据偏斜比较严重，并且还必须按照此方式分区。通过多级分区，可以把一个表拆分为一个不等高的树，并且这棵树的所有叶子结点的数据量差别不大，从而解决单级分区数据分布严重不均匀的问题。

例如，很多大公司把业务团队、销售渠道、客户资源等按照省份做了划分，但是不同的省份的人口规模有显著的区别，所以按照省份做了一级分区之后，还需要对人口大省按照城市做二级分区，比如广东省这个一级分区下面要把深圳、广州、东莞等几个巨型城市做二级分区，而省内其他小城市则不做二级分区，而是全部放入’default’ 分区。而西北各个省自治区则完全不需要做二级分区；而深圳和广州还需要做第三级分区，因为其每个区都有几百万人口，比很多城市的总人口都要多。

再比如，某直播电商平台按照网红ID做range 拆分订单表，他们面临的技术难题是超级网红的带货量千百倍于普通工作人员，此时可以对这几个超级网红每个人的ID作为一个分区，然后按照生产厂商ID对超级网红的分区做二级分区，而普通工作人员则按照其ID列，每100个人为一个分区。而对于销量很小的其余所有人，放入default分区即可。

5.2 表分布策略

分布策略就是要回答一个问题--- 把一个单表或者表分片放到哪个shard上？

分布策略的最高目标是最优化查询性能，为此可以对不同访问模式的表使用不同的分布策略。在计算节点元数据表pg_class有一个列relshardid，该列记录的就是每个表所在的shard 的id。然后计算节点可以使用pg_shard和pg_shard_node这两个元数据表的数据，得到每个shard当前的主节点的连接信息，从而获得表分片的数据。KunlunBase目前支持如下几种分布策略。

Least Burden

创建一个表分片时，把它分配到平均负载最低的shard。

Least Space

创建一个表分片时，把它分配到占用了最少存储空间的shard。

Random

创建一个表分片时，把它分配到随机选择的shard

Mirror（复制表，镜像表）

如果一个表不常更新（比如每天几千次）并且数据量不大小表（比如1个GB以内），并且它和一些大表经常坐join查询，那么适合创建为mirror表（http://doc.klustron.com/zh/Example_of_using_the_Mirror_table_feature.html），也就是在每个shard放一份，同一个mirror表在所有shard上的copy的数据完全相同，对它的更新，计算节点会更新所有shard上所有的copy。mirror表与其他表t1 join时，如果t1是单表，则kunlun-server把join下推到t1所在的分区执行本地join；如果t1是分区表：则kunlun-server把join下推到t1的所有叶子分区所在的shard做本地join。

Mirror表的好处是kunlun-server可以做join下推，特别适合OLAP 的雪花模型，也就是一个巨大的事实表（分片存储在集群所有shard上面）与多个维度表（每个都是一个mirror表）做join，此时kunlun-server能够把join下推到所有shard，让事实表在每个shard上面的表分片与本shard的维度表做join即可，然后kunlun-server 收回join结果即可。甚至join之上的aggregate节点也可以顺便下推，这样就可以用很多shard的计算资源执行同一个查询了。

KunlunBase可以确保在增加新shard时，复制所有mirror表到新shard。

并且化解创建mirror表与增加新shard 的冲突，确保正在创建的mirror表在新shard存在。

Table Grouping  

在应用实践中，有些表关联紧密，经常做表连接，或者经常在同一个事务中更新，因此Klustron支持用户把这些表始终放在同一个shard，以便得到更好的查询性能和事务处理性能。

为此，KunlunBase实现了TABLEGROUP功能（http://doc.klustron.com/zh/CREATE_TABLEGROUP.html），让用户把这些紧密相关的表放到一个TABLEGROUP中，以便执行组内表连接时可以将表连接下推到存储分片中，同一个事务中更新这些表可以避免两阶段提交，从而获得更好的性能。

创建一个单表或者表分片时可以设定其属于一个table group，例如：
CREATE TABLE t1(a int) WITH(TABLEGROUP=tg1);
不设定的话它就不属于任何table group。同一个table group的所有表或者表分片总是保持在同一个shard。一个TABLEGROUP中的表不可以单独搬迁到另一个shard，KunlunBase会禁止此操作。如果要搬迁（比如扩容时）必须把tablegroup 的所有表全部整体搬迁到新的shard。在一个database中可以有多个TABLEGROUP，以及一些不在任何TABLEGROUP中的表。

手动分配

KunlunBase也支持让用户显式指定表分区所在的shard, 例如：

create table t1(a int) with (shard=3)

我们并不推荐用户这么做，但是始终给用户尽可能大的自由度去定制KunlunBase的关键行为。

另外，用户还可以在CREATE TABLE语句中设置若干其他选项（http://doc.klustron.com/zh/kunlun_server_new_ddl_syntax.html）。

使用具备优秀的扩展能力的分布式数据库才能确保应用系统的吞吐率和数据量可以持续增长。弹性伸缩能力是分布式数据库扩展能力的基础，而数据分片是弹性伸缩的前提条件。KunlunBase支持的多种的表分区规则和分布策略，让用户可以根据其数据特征和数据访问模式，做出最优性能的数据定义。并且KunlunBase支持Online DDL&Repartition功能，让用户可以随时按需修改表分区规则和分布策略。

同时欢迎大家扫码👇添加小助手（备注：加入Klustron技术交流群）欢迎大家在交流群共同探讨更多问题及主题。