KunlunBase FAQ
KunlunBase FAQ
1、KunlunBase 是否是默认开启分布式事务?是否有开关可以关闭?例如有的分布式数据库支持开关,可根据业务需求进行配置?
KunlunBase的分布式事务处理是自动运行的,没有开关切换。只有当一个事务确实写入了多个shard之后,才会做两阶段提交,否则就是一阶段提交,也就是说无需手动开关。
2、针对常规的统计信息,如TPS(含回滚率等)、QPS、RT等指标,在KunlunBase中如何查看?可以在系统视图中,还是在XPanel可查?
- 1.3 版本中可以在XPanel中查看。
3、KunlunBase 中锁的机制如何?文档中只看到 MySQL 中锁的处理机制。同理,死锁检测机制如何,相关参数有哪些?
- 计算节点中对表上锁,如果是DML语句,则获取行级意向锁;如果是DDL语句,则排他表级锁。存储节点中,与MySQL完全相同:DML语句的INSERT/DELETE/UPDATE语句在server层获取表级意向写锁,在innodb中则获取行锁;对于SELECT则获取全局和本地快照,不获取事务锁。DDL在server层和引擎层都获取表级排他锁。
- KunlunBase全局死锁检测技术 | Klustron
4、KunlunBase 常规的隔离级 RR、RC 都支持?
- 支持多种事务隔离级别:读已提交,可重复读,串行化。
5、关于序列问题,我看在是在元数据库中记录在一个表中。这里是否会存在性能瓶颈?此外,如果创建时指定Cache选型,在不同计算节点使用时,是Cache到本地,因此会存在跳号等问题吧
- 创建序列时可以指定cache多个值,以避免性能瓶颈。假如cache设置为1,则获取每一个值都需要修改元数据shard中的序列记录,那么性能就会损耗较大。
- 如果多个计算节点CN1,CN2同时在使用同一个序列,每个序列cache 20值,那么CN1使用的序列值100-119时,CN2在使用的序列值是120-139。
6、针对table group,我理解是人为设定表的存储位置;这与常规分布式数据库的ER表还有所不同。KunlunBase是否支持ER表?
- Table group用于确保多个表始终在同一个shard上面,仿佛是一个框子把这些表绑在一起。ER表确实可以被分组为同一个table group中,这样就可以确保这些表在同一个shard,即使扩容也会同时把一个table group中全部的表扩容到另一个shard。
7、PG支持的多种索引(如非BTree索引),是否在KunlunBase中可创建?
- 不可以。KunlunBase存储节点kunlun-storage基于MySQL开发,以避免PostgreSQL 存储引擎的性能问题,同时也就不再使用PostgreSQL的索引。不过,MySQL不仅支持b+tree索引,也支持空间索引,全文索引,因此并不存在无法索引的数据类型。
8、全局二级索引,是否有计划未来支持?
- 全局二级索引会严重降低数据增删改的性能,如果仅用于查询则很鸡肋。KunlunBase的计算节点知道每个表的分片所在的shard,因此即使查询条件没有指定shard key,也只需要到存储着这个表的分片的那几个shard去读写数据,并不会读写全部shard。
尽管如此,未来我们会根据用户需求来决定何时实现该功能。
9、视图是否支持跨分片的语句?如果支持,查询视图时会拆解视图后下推吗?
- 视图支持跨分片语句。在查询处理的转换阶段,各级视图的查询语句会合并到使用视图的顶层查询语句的语法树中,统一执行。因此在查询执行层面,并不知道那个查询语句是否使用了视图,因此也就不存在‘下推视图’这样的动作。
10、之前谈到的复合分片(分片+分片),分片分区方式是否支持?
- KunlunBase支持多级分区,每一级分区的方式和参数彼此独立没有影响。唯一一个要求是,每一级分区的shard key 列集合一定包含上面各级分区的shard key列集合。详见此文
11、游标是否支持?自定义函数是否支持?
- KunlunBase支持游标和自定义函数。不仅支持用PL/SQL定义存储过程,还可以用c/python,java,javascript, lua等多种编程语言定义存储过程。
12、字符集方面,MySQL 常见的UTF8MB4、GB18030 是否支持?
- 支持客户端使用GBK/GB18030/GB2312。
- KunlunBase 内部支持的字符集包括UTF8在内的unicode各种编码存储数据,但是不包括GBK/GB18030等,不过KunlunBase支持把客户端以中文GB系列编码输入的文本自动转换为内部支持的字符编码。
13、如果源库与目标库的字符集不同,但兼容情况下,通过KunlunBase提供的工具是否可实现迁移和同步能力?
- KunlunBase支持客户端使用常见字符集。只要源库字符编码是KunlunBase支持的客户端字符集(就是PostgreSQL支持的客户端字符集),那么数据以SQL语句送入KunlunBase后就被自动转换为KunlunBase内部字符集(UTF8等,CREATE DATABASE时可以指定)。
- 数据迁移工具cdc从mysql实例的binlog导入数据到KunlunBase时,只要这个字符编码是KunlunBase客户端支持的编码,那么就可以导入成功。
14、备份方面,我看目前支持物理备份到HDFS,是否支持备份到本地(或NFS上)?是否支持时点还原?是否支持对象闪回?
- 支持恢复到任意时间点。用户可以通过恢复到指定时间点来找回各种数据库对象。
15、常规的 MySQL 和 PG 的导入导出命令是否支持?是否可实现不通过计算节点,针对数据节点的快速导入?
- KunlunBase支持数据 支持PostgreSQL的数据导入命令,不支持MySQL的LOAD DATA导入命令。必须经过计算节点才能导入数据。
16、当前是否支持版本升级?滚动升级?降级?
- 正在做不停服的热升级即滚动升级,1.3版本中发布。升级和降级是一样的,都支持。
17、在扩展方面,针对计算节点的扩容是可以在线进行?是否有对应的LB方案提供?存储节点扩容方面,数据需手工做重分布?
- 可以在集群运行期间通过XPanel GUI界面或者调用cluster-mgr API随时增加计算节点,不影响已有连接中任何业务。计算节点加入集群完成初始化之后就可以对外提供服务。
- LB方案需要用户自己配置,在计算节点完成初始化之后,把它加入到LB的候选节点集合中即可。
18、读写分离方面,是否支持延迟感知(即将延迟大的从库剥离出来,不承担读)?针对跨片情况,是否支持读的一致性?
- 计算节点自动选择延时最小的备机来读取;如果从备机读取数据,则全局MVCC机制由于主备延迟不可预测因此无法正常工作。全局MVCC只能处理主节点读取数据的情况。
19、cluster_mgr、node_mgr,应支持高可用?如node_mgr异常,如何恢复?
- Cluster_mgr支持高可用,可以在clustermgr集群主节点退出后自动选出新主;nodemgr运行在每个server 中,由crontable或者linux system服务自动拉起。Cluster_mgr和nodemgr没有本地持久状态,所以无需数据恢复。
20、当出现脑裂时,cluster_mgr与计算和存储节点脑裂等,行为如何?是否做过混沌测试?
- Cluster_mgr和存储集群高可用机制确保了不会发生脑裂。
- 一个KunlunBase集群的多个计算节点之间没有直接复制关系,这些计算节点把DDL日志写入到元数据集群的ddl log,并且总是从中复制其他计算节点执行过的ddl log,来达到一个KunlunBase集群的所有计算节点具有相同的元数据。
- 做过节点故障的混沌测试,有大量自动测试,每天在Jenkins自动运行。
21、计算节点是否支持连接池处理?
- 支持外部连接池。
22、新增存储节点时,复制表(Mirror Table)如何处理?自动复制数据?
- 是的,见此文档
23、Xpanel 是否有慢查询能力
- 1.3版本会图形化显示慢查询及其相关信息,目前收集到了ES中,通过kinaba可以查找到。
24、存储节点是否支持国密算法?
- 1.3 版本实现国密算法加密插件
25、安全方面,如SQL审计、防火墙功能、白名单是否支持?
- 支持,这些功能都是直接使用PostgreSQL 自带功能。
26、KunlunBase是否完全遵循SQL92\SQL99标准?
- 几乎完全遵循,仅有少量例外,在现代软件开发中几乎不可能用到,在PostgreSQL的文档中有详细列出;另外,KunlunBase对于PostgreSQL的语法,针对分布式数据库的场景和特点,做了少量取舍,但是不会影响业务系统开发,详见 KunlunBase不支持的PostgreSQL语法和功能汇总。
27、KunlunBase是否支持CTE语法?
- 支持CTE, window function,以及cube,rollup, grouping set 等所有OLAP语法。
28、兼容Postgres,那是否在Postgres上注册的所有函数,可以不用调整直接注册在KunlunBase上?
- PostgreSQL的系统函数,在昆仑数据库中全都存在,可以直接在SQL语句中调用,且支持pg的plsql存储过程。并且可以使用CREATE EXTENSION语句,把pg 生态中的各种插件加上去来在KunlunBase中使用这些插件。
- pg生态绝大多数extension无需任何修改就可以挂到KunlunBase正常工作。只有postgis, pgvector等少量重量级的有自己的数据类型或者数据存储方法的extension,是需要我们进一步的研发工作特殊处理的。我们扩展了postgis,以便它可以挂到KunlunBase的计算节点上,并且与KunlunBase的存储节点读写GIS数据。对于pgvector我们也需要在KunlunBase的存储节点中实现向量数据管理,以便pgvector可以挂到KunlunBase的计算节点实现向量数据管理和查询功能
29、KunlunBase支持API连接还是JDBC连接操作,JDBC是否有特殊性?
- 通用的jdbc库就可以连,我们没有修改jdbc实现。而且各种编程语言的客户端连接库(connector)都可以连接,详见KunlunBase对当前主流编程语言的 MySQL connector 汇总
- KunlunBase支持MySQL和PostgreSQL两种连接协议和SQL语法,原本使用MySQL和PostgreSQL的应用软件系统,无需修改或者重新编译,就可以直接连接到KunlunBase正常工作