关于数据库:小数据量用户场景使用KunlunDB的价值

前言

在一个公司或者部门的新业务倒退的起步阶段，其用户的数据量通常并不大，比方只有数十 GB 以内，一个 MySQL 主备复制集群就能够轻松搞定。那么这种状况下，应用 KunlunDB 有什么价值呢？其实依然有微小的价值，本文就全面地答复这个问题。

高可用性

Kunlun-storage Fullsync 的高性能强同步性能，确保了每个 kunlun-storage shard 的高可用能力。

同时，KunlunDB 的 cluster_mgr 模块会主动实现主节点探活，主动 & 手动选主，主动切换到新主节点等工作，使得昆仑数据库的具备欠缺的主动高可用能力，无需用户干涉。

相比于 MySQL Group Replication 或者 semisync replication，KunlunDB 具备更高的性能和更短的延时，并且对计算资源耗费更低。

起因如下：

• MGR 须要在 Flush 事务的 binlog 之前持锁期待备机确认（ACK）收到事务的 binlog，这样就会长工夫阻塞所有与这些正在期待 ack 的事务有事务锁抵触的所有沉闷事务，从而升高了零碎并发解决能力，并且缩短了那些被阻塞的事务的运行工夫，影响了业务零碎的响应速度。而 Kunlun-storage Fullsync 做 after-commit 期待，期待备机收到 binlog 的确认之前，曾经开释了它持有的事务锁，所以不会因为期待备机应答而阻塞那些与之抵触的事务。

• 同时，fullsync 在期待备机 ACK 期间不须要占用工作线程，而 semisync 和 MGR 都须要占用工作线程，这就导致 MySQL 须要启动更多的工作线程应答业务负载。每一个工作线程都会耗费 CPU 工夫片，内存以及须要 OS 治理它们的状态，这些都是对计算资源的耗费。

• 因为这些技术劣势，kunlun-storage fullsync 在 sysbench 等性能测试中比 MGR 有最多达到 5 倍的性能劣势。

高性能

不仅 kunlun-storage 比 MySQL 有更好的 replication 性能，而且 KunlunDB 在数据分析，查询处理等方面具备一系列高性能和可扩大能力，具体如下。

• 读写拆散

计算节点执行只读查问语句（即 select 语句）时，能够主动向存储集群的备机节点发送 select 查问获取数据，来执行 select 查问语句。

这个行为不须要用户干涉，这样用户程序就不须要批改即可应用该性能。当然，用户也能够在一个连贯中或者全局层面敞开此性能。通过在备机执行只读查问能够升高主节点的负载。

不过须要留神的是，有些只读查问并不能发送到备机，比方更新了一个表之后在同一个事务中查问这个表的数据，此时为了确保查问到最新的数据，防止产生不统一的查问后果，这个 select 语句默认就不能发送到备机去执行，除非用户升高了一致性级别强制读取备机的可能旧的数据。

也就是说读写拆散技术并不总是能分摊主节点的负载，这对于任何分布式数据库或者分库分表中间价都是这样。

• 并行 select 查问

KunlunDB 反对并行 select 查问，包含计算节点内的并行查询处理，计算节点与存储节点之间的并行查问和存储节点外部的并行查问。

这三个层面的并行处理能力大大晋升了 KunlunDB 的查问性能，特地是对数据分析类的简单查问性能晋升微小。

计算节点内的并行是指多个线程执行查问打算的特定节点。在 kunlun-server 的一部分查询处理性能具备并行查问能力，包含 NestedLoopJoin，HashJoin，MergeJoin，Append，Aggregate 等节点；这部分并行能力是继承自 PostgreSQL。

计算节点与存储节点之间的并行：是指计算节点能够异步发送 SQL 语句读写存储节点的指标数据，这样含有指标数据的所有存储节点就会并行执行收到的 SQL 语句；这是 KunlunDB 从最后公开公布的 0.6 版本就具备的能力，也是咱们自研的技术。

存储节点内的并行：当计算节点有多条只读 select 语句发送到同一个存储集群时，计算节点会开启多个连贯到这个指标存储节点，在每个连贯中执行一个 select 语句，这些 select 语句在这个存储节点中是并行执行的。

这样，计算节点就能够利用到存储节点的更多的计算资源同时服务同一个查问申请。这个性能在昆仑数据库 1.0 版本中会公布，也是咱们自研的技术。

• 数据分析性能

无论一个 KunlunDB 集群有几个 storageshard，用户都能够部署若干个计算节点专门用于数据分析类查问的解决，这些计算节点应用读写拆散技术从这些 storage shard 的备机节点获取数据来执行剖析语句，因此不会影响 OLTP 负载的性能。

KunlunDB 的计算节点反对齐备的数据分析性能，通过了所有 TPC-H, TPC-DS 的性能测试，这是 MySQL 不具备的能力。

具体来说，kunlun-server 反对所有的 window function，grouping sets, cube，rollup 等性能，而 MySQL 只反对 rollup 和一部分 window function 性能。

KunlunDB 的全集群多级并行查询处理能力，带来数据分析类查问的性能飞跃。

• 充分利用硬件资源

应用最简略的一个 MySQL 一主两备的集群，须要 3 台机器，然而这 3 台机器中只有主节点能够承当写入负载，其 CPU 和 IO 负载通常比备机较高。

而应用 KunlunDB 后，在 3 台机器应用对等部署模式部署一个 KunlunDB 集群，这个集群有 3 个存储 shard，每个机器都有其中一个 shard 的主节点和另外两个 shard 的一个备节点（如下图），这样就把计算和写入负载以及利用发动的连贯总数均匀摊派到 3 台机器中，充分利用每一台机器的计算资源，实现集群整体更高的吞吐能力和性能。

全面而灵便的集群治理性能

• 可编程的根底集群治理 API

KunlunDB 反对齐备的集群治理性能，包含主动的集群备份和全局一致性的复原，程度弹性扩容，增删启停计算节点，增删存储集群和存储节点，重做备机，主动或者手动的主备切换，业务无感知的 Online DDL 等等。

并且所有这些性能都有对应的 API 接口，因而内部软件系统能够可编程的形式操作和应用 KunlunDB 的集群治理性能，例如能够十分不便地集成到用户的数据库集群治理界面中。

• 预留程度扩容能力

随着用户业务规模的增长，一个 KunlunDB 集群即便以后应用一个存储 shard，当前也能够主动的利用无感知的形式程度弹性扩容到多个存储 shard，只有用户给集群调配了更多的服务器节点即可，不须要 DBA 的其余干涉。这样用户就不须要放心如何应答数据规模在将来一直的增长。

主动的程度弹性扩容期间，昆仑数据库集群并不会锁表，不影响利用程序运行。

• 图形化的运行监控和故障诊断及告警

KunlunDB 各模块的运行日志，慢查问日志和其余日志文件中蕴含集群各模块丰盛的运行时信息，这些日志被昆仑数据库用于图形化的半自动的故障诊断，帮忙 DBA 迅速精确地定位问题。

同时，借助 prometheus+grafana 的风行的监控零碎组合，实现了集群节点监控。还能够以短信、电话等多种形式做告警，告诉 DBA 及时处理问题。

数据库迁徙工作量

从其余数据库系统迁徙到 KunlunDB，灌入数据这部分应用第三方工具即可实现。

通常难度和工作量比拟大的是对利用零碎的革新，在这方面咱们做了大量工作帮忙用户轻松地从 MySQL 和 Oracle Server 迁徙到 KunlunDB。

• MySQL 兼容性

KunlunDB 反对 PostgreSQL 和 MySQL 两种连贯协定，在每一种协定中都能够发送 KunlunDB 反对的任何 SQL 语句。

这样，就能够利用到比 MySQL 更加宽泛的数据存储管理和利用能力，例如 KunlunDB 的 OLAP 剖析能力，性能远远优于 MySQL。

同时，KunlunDB 反对 MySQL 的公有 DML 语法，详见这篇文章（KunlunDB 对 MySQL 公有 DML 语法的反对）。

对于 MySQL 特有的（也就是没有定义在 SQL 规范中的）SQL 函数，咱们会按需减少反对，这包含除了 GIS 函数和 JSON 函数之外的所有 MySQL 特有函数。减少一个这样的函数难度很小，咱们后续也可能会抽调资源对立把所有此类函数在昆仑数据库计算节点中实现进去。

这样，本来应用 MySQL 的应用软件不须要任何代码批改或者从新编译，能够间接连贯到 KunlunDB。

• Oracle 兼容性

KunlunDB 继承了 PostgreSQL 对 Oracle 数据库的兼容性，包含反对 PL/SQL 和 SQL-2003 的绝大多数性能。

其余 Oracle 特有性能，用户须要实现利用侧代码批改（通常须要批改大量存储过程和 SQL 查问语句），并且能够借助一些第三方工具简化和提速这些工作。

如果应用程序本来应用 ODBC 或者 JDBC 连贯 Oracle 数据库，那么不须要任何代码批改就能够连贯到 KunlunDB；否则还须要批改利用侧代码，应用相应的编程语言针对 PostgreSQL 的客户端库来连贯到 KunlunDB。

-END-

昆仑数据库是一个 HTAP NewSQL 分布式数据库管理系统，能够满足用户对海量关系数据的存储管理和利用的全方位需要。
利用开发者和 DBA 的应用昆仑数据库的体验与单机 MySQL 和单机 PostgreSQL 简直完全相同，因为首先昆仑数据库反对 PostgreSQL 和 MySQL 双协定，反对规范 SQL:2011 的 DML 语法和性能以及 PostgreSQL 和 MySQL 对规范 SQL 的扩大。同时，昆仑数据库集群反对程度弹性扩容，数据主动拆分，分布式事务处理和分布式查询处理，强壮的容错容灾能力，欠缺直观的监测剖析告警能力，集群数据备份和复原等 罕用的 DBA 数据管理和操作。所有这些性能无需任何利用零碎侧的编码工作，也无需 DBA 人工染指，不停服不影响业务失常运行。
昆仑数据库具备全面的 OLAP 数据分析能力，通过了 TPC- H 和 TPC-DS 规范测试集，能够实时剖析最新的业务数据，帮忙用户发掘出数据的价值。昆仑数据库反对私有云和公有云环境的部署，能够与 docker，k8s 等云基础设施无缝合作，能够轻松搭建云数据库服务。
请拜访 http://www.zettadb.com/ 获取更多信息并且下载昆仑数据库软件、文档和材料。
KunlunDB 我的项目已开源
【GitHub：】
https://github.com/zettadb
【Gitee：】
https://gitee.com/zettadb