写点什么

小数据量用户场景使用 KunlunBase 的价值

作者:KunlunBase
  • 2022 年 7 月 12 日
  • 本文字数:3610 字

    阅读完需:约 12 分钟

前言

在一个公司或者部门的新业务发展的起步阶段,其用户的数据量通常并不大,比如只有数十 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

发布于: 刚刚阅读数: 3
用户头像

KunlunBase

关注

还未添加个人签名 2022.03.09 加入

还未添加个人简介

评论

发布
暂无评论
小数据量用户场景使用KunlunBase的价值_KunlunBase_InfoQ写作社区