PolarDB-X V2.4 列存引擎开源正式发布

云原生时代的领航者：PolarDB 分布式版标准版 2核8GB。

架构概览

星辰数据库（StarDB）的分布式架构基于Shared-nothing与存储计算分离的设计原则，确保系统的高性能、高可用性和可扩展性。系统由五大核心组件构成，每个组件都经过精心设计和优化，以满足现代企业对数据库系统的严苛要求。

1. 计算层（Compute Layer）

计算层是星辰数据库（StarDB）的入口，它采用无状态设计，内置了SQL解析器、查询优化器、执行引擎等关键模块。该层负责接收客户端的SQL请求，执行数据分布式路由和计算任务，确保查询的高效执行。同时，它还负责分布式事务的协调，如两阶段提交（2PC）协议的执行，以及全局二级索引的维护。为了提供企业级特性，计算层还集成了SQL限流、三权分立等安全和管理功能。

2. 存储层（Storage Layer）

存储层负责数据的持久化存储，它基于强一致性的多数派Paxos协议，确保数据的高可靠性和强一致性。通过多副本机制，存储层能够在节点故障时快速恢复数据，保证服务的连续性。同时，它还利用MVCC（多版本并发控制）技术维护分布式事务的可见性，确保并发访问时数据的一致性。

3. 元数据管理（Global Metadata Management）

元数据管理服务负责维护全局的、强一致的Table/Schema、统计信息等系统元数据，以及账号、权限等安全信息。这些元数据对于系统的正常运行至关重要，元数据管理服务通过高效的数据结构和算法，确保元数据的快速访问和更新。此外，它还提供了全局授时服务（TSO），为分布式系统中的时间同步提供支持。

4. 变更数据捕获（Change Data Capture, CDC）

变更数据捕获服务提供了完全兼容MySQL Binlog格式和协议的增量订阅能力，允许用户实时获取数据的变更信息。此外，它还支持兼容MySQL Replication协议的主从复制功能，使得用户可以方便地构建数据备份和容灾系统。

5. 列式存储（Columnar Storage）

列式存储节点是星辰数据库（StarDB）的特色组件之一，它提供持久化的列式索引功能。通过实时消费分布式事务的binlog日志，列式存储节点能够基于对象存储介质构建列式索引，满足实时更新的需求。同时，结合计算层的支持，列式存储节点还能够提供列式存储的快照一致性查询能力，为用户提供更加灵活和高效的数据访问方式。

开源地址：[https://github.com/star-database/stardb-sql]

版本演进历史

星辰数据库（StarDB）自开源以来，一直秉持着不断创新、持续优化的理念，为用户提供了稳定、高效、灵活的分布式数据库解决方案。以下是星辰数据库（StarDB）的开源脉络及版本更新概览：

2021年11月

在星辰科技峰会上，我们正式对外宣布星辰数据库（StarDB）的开源计划，并发布了首个开源版本。这个版本包含了完整的计算引擎、存储引擎、日志引擎和Kubernetes集成等核心组件，为用户提供了全面的分布式数据库能力。

2022年2月

星辰数据库（StarDB）迎来首个重大更新，发布了1.0.0版本。这个版本新增了集群扩缩容功能，增强了系统的灵活性和可扩展性。同时，我们还对binlog生态进行了深度兼容，支持了Maxwell和Debezium等主流增量日志订阅工具，为用户提供了更多的数据集成和同步选项。

2022年4月

星辰数据库（StarDB）发布了1.1.0版本，这个版本在稳定性和生态兼容性方面有了显著提升。我们引入了基于Paxos的三副本共识协议，确保了数据的高可靠性和强一致性。同时，我们还修复了若干已知问题，并新增了一系列新特性，以满足用户不断增长的需求。

2022年6月

在1.2.0版本中，我们重点推出了冷热数据分离的新特性。用户可以根据业务需求，将冷数据存储到更经济的存储介质上，如对象存储服务，从而降低成本并提高资源利用率。这一特性对于拥有大量历史数据的用户来说尤为重要。

2022年11月

星辰数据库（StarDB）迎来了2.0.0版本，这是一个里程碑式的版本。我们重点推出了符合分布式数据库行业标准的企业级特性和国产ARM架构适配能力。这个版本共包含了八大核心特性，全面提升了星辰数据库（StarDB）在金融、通讯、政务等行业的普适性和竞争力。

2023年4月

在2.1.0版本中，我们进一步加强了生产级关键能力。这个版本提供了数据快速导入、性能测试验证、生产部署建议等一系列实用功能，帮助用户更好地将星辰数据库（StarDB）应用于实际生产环境中。同时，我们还对系统进行了深度优化，提升了性能和稳定性。

2023年11月

星辰数据库（StarDB）发布了2.2.0版本，这个版本重点推出了标准版（集中式形态）。这个版本将分布式数据库中的存储节点（DN）提供为单独服务，支持Paxos协议的多副本模式和Lizard分布式事务引擎。同时，这个版本还实现了100%的MySQL兼容性，为用户提供了更加便捷的数据迁移和集成体验。

2024年5月

在最新的2.3.0版本中，我们重点推出了列存节点（Columnar）功能。这个功能提供了持久化的列存索引（Clustered Columnar Index，CCI），结合计算节点的向量化计算能力，可以显著加速分布式查询性能。这个版本的发布标志着星辰数据库（StarDB）在HTAP（混合事务/分析处理）一体化方面取得了重要突破。

列存索引

随着云原生技术的飞速发展，数据仓库领域也迎来了前所未有的变革。新一代云原生数仓，如我们所熟知的Snowflake，以其强大的性能和灵活性引领着行业趋势。同时，数据库HTAP（混合事务/分析处理）架构的兴起，预示着未来数据库将不再仅仅是处理事务的单一工具，而是将具备更强的实时分析能力。

在这样的背景下，行列混存（HTAP）架构逐渐成为数据库的标配能力。然而，要实现这一目标，我们需要在当前数据库的列存设计上进行更深入的思考和创新。

为了满足未来数据仓库的低成本、易用性和高性能需求，我们团队在最新发布的V2.X版本中正式推出了全新的列存引擎——星辰列存（Star Columnar Engine）。星辰列存引擎通过引入列存索引（Clustered Columnar Index, CCI）的形态，为用户提供了更加灵活和高效的数据存储和查询方式。

在星辰列存引擎中，行存表仍然保持其原有的主键索引和二级索引结构，以确保事务处理的高效性。而列存索引则作为一份额外的基于列式结构的二级索引，覆盖了行存表中的所有列。这种设计使得同一张表可以同时具备行存和列存的数据，从而充分发挥行列混存架构的优势。

通过星辰列存引擎，用户可以更加灵活地选择数据的存储方式。对于需要频繁进行事务处理的场景，可以选择使用行存表；而对于需要进行大量数据分析的场景，则可以选择使用列存索引来提高查询性能。此外，星辰列存引擎还提供了简单易用的接口和丰富的功能，使得用户可以轻松地管理和使用列存索引。

星辰列存引擎的推出是我们在云原生数据仓库领域的一次重要尝试和创新。我们相信，随着技术的不断发展和完善，星辰列存引擎将成为未来数据仓库的标配能力之一，为用户带来更加优质的数据存储和查询体验。

索引创建的语法：

列存索引创建的DDL语法

CLUSTERED COLUMNAR：关键字，用于指定添加的索引类型为CCI。

索引名：索引表的名称，用于在SQL语句中指定该索引。

排序键：索引的排序键，即数据在索引文件中按照该列有序存储。

索引分区子句：索引的分区算法，与CREATE TABLE中分区子句的语法一致。

实际例子：

# 先创建表

CREATE TABLE t_order (

  `id` bigint(11) NOT NULL AUTO_INCREMENT,

  `order_id` varchar(20) DEFAULT NULL,

  `buyer_id` varchar(20) DEFAULT NULL,

  `seller_id` varchar(20) DEFAULT NULL,

  `order_snapshot` longtext DEFAULT NULL,

  `order_detail` longtext DEFAULT NULL,

  PRIMARY KEY (`id`),

  KEY `l_i_order` (`order_id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 partition by hash(`order_id`) partitions 16;

# 再创建列存索引

CREATE CLUSTERED COLUMNAR INDEX `cc_i_seller` ON t_order (`seller_id`) partition by hash(`order_id`) partitions 16;

主表："t_order" 是分区表，分区的拆分方式为按照 "order_id" 列进行哈希。

列存索引："cc_i_seller" 按照 "seller_id" 列进行排序，按照 "order_id" 列进行哈希。

索引定义子句：CLUSTERED COLUMNAR INDEX cc_i_seller ON t_order (seller_id) partition by hash(order_id) partitions 16。

列存索引技术原理简述

在数字化时代，数据的高效存储和快速检索成为企业成功的关键。为了满足这一需求，我们团队在最新的数据库版本中引入了创新的列存索引技术。以下是对列存索引技术原理的简要介绍。

一、列存数据结构

列存索引是由我们自研的列存引擎所构造的，其数据结构基于Delta+Main（类LSM结构）二层模型。为了保证行存和列存之间能够实现低延时的数据同步，我们采用了标记删除的技术，将更新操作转化为删除标记与插入操作，确保数据的实时性。

在数据实时写入的过程中，首先将数据写入到MemTable中。随后，在一个group commit的周期内，我们将数据存储到一个本地CSV文件中，并追加到对象存储服务（如OSS）上对应CSV文件的尾部，这个文件我们称之为delta文件。需要注意的是，OSS上的CSV文件并不会长期存在，而是由我们的compaction线程不定期地将其转换成更高效的ORC文件格式。

二、列存索引的数据流转

列存索引的构建和查询过程涉及多个步骤，确保数据的准确性和高效性。

构建流程：

数据写入：数据首先通过计算节点（CN）写入到数据节点（DN），以正常的行存形式进行存储。

事务日志提取：我们利用变更数据捕获（CDC）技术，实时提取逻辑binlog（即事务日志），以获取数据的变更信息。

异步行转列：列存引擎实时消费snapshot数据和CDC增量binlog流，异步地将行存数据转化为列存格式，构建列存索引。

查询流程：

统一入口：用户通过CN节点提交查询请求，CN节点基于一套强大的SQL引擎提供统一的数据访问入口。

时间戳获取：CN从全局元数据服务（GMS）获取当前最新的事务时间戳（TSO），确保查询结果的一致性和准确性。

索引快照信息：基于TSO，CN从GMS获取当前列存索引的快照信息，这些快照信息包含了列存索引的元数据。

数据扫描与计算：CN根据索引快照信息，从DN或OSS扫描所需数据，并将数据拉取到CN节点进行计算。由于我们支持行列混合计算，因此用户可以在同一查询中同时利用行存和列存的优势。

三、展望

随着技术的不断发展，我们将继续深化列存引擎的研究和优化，为用户提供更加高效、稳定的数据存储和查询解决方案。后续，我们将陆续发布更多关于列存引擎的技术原理文章，敬请期待。

性能体验

测试集：TPC-H 100GB 硬件环境：

按照正常导入TPC-H 100GB数据后，执行SQL创建列存索引：

create clustered columnar index `nation_col_index` on nation(`n_nationkey`) partition by hash(`n_nationkey`) partitions 1;

create clustered columnar index `region_col_index` on region(`r_regionkey`) partition by hash(`r_regionkey`) partitions 1;

create clustered columnar index `customer_col_index` on customer(`c_custkey`) partition by hash(`c_custkey`) partitions 96;

create clustered columnar index `part_col_index` on part(`p_size`) partition by hash(`p_partkey`) partitions 96;

create clustered columnar index `partsupp_col_index` on partsupp(`ps_partkey`) partition by hash(`ps_partkey`) partitions 96;

create clustered columnar index `supplier_col_index` on supplier(`s_suppkey`) partition by hash(`s_suppkey`) partitions 96;

create clustered columnar index `orders_col_index` on orders(`o_orderdate`,`o_orderkey`) partition by hash(`o_orderkey`) partitions 96;

create clustered columnar index `lineitem_col_index` on lineitem(`l_shipdate`,`l_orderkey`) partition by hash(`l_orderkey`) partitions 96;

场景1：单表聚合场景( count 、 groupby)

tpch-Q1的行存和列存的效果对比图：

select count的行存和列存的效果对比图：

场景2：TPC-H 22条query

基于列存索引的性能白皮书，开源版本可以参考：TPC-H测试报告

TPC-H 100GB，22条query总计25.76秒

详细数据如下：

PolarDB-X V2.4：集分一体化架构与全面兼容MySQL 8.0.32

在数字化时代，数据库架构的灵活性和可扩展性对于业务发展的重要性不言而喻。为了满足这一需求，PolarDB-X在V2.4版本中推出了革命性的集分一体化架构，并在分布式DN多副本中全面兼容了MySQL 8.0.32，为用户提供了前所未有的数据库体验。

一、集分一体化架构

PolarDB-X V2.4版本的集分一体化架构，是数据库领域的一大创新。它兼具了分布式数据库的扩展性和集中式数据库的功能及单机性能，使得两种形态可以无缝切换，为业务发展提供了极大的灵活性。

在集分一体化数据库中，数据节点被独立出来作为集中式形态，完全兼容单机数据库形态。这意味着，当业务在初期阶段时，可以使用集中式形态来享受单机数据库的高性能和易用性。随着业务的增长，当需要分布式扩展时，架构可以原地升级成分布式形态，分布式组件无缝对接到原有的数据节点上进行扩展，无需进行数据迁移或应用侧改造，大大降低了业务扩展的复杂性和风险。

二、全面兼容MySQL 8.0.32

PolarDB-X V2.4版本在分布式DN多副本中全面兼容了MySQL 8.0.32，这一举措标志着PolarDB-X在数据库技术上的又一次重大突破。通过全面兼容MySQL 8.0.32，PolarDB-X不仅继承了官方MySQL的众多代码优化，还为用户提供了更加丰富的功能和更强大的性能。

在功能方面，PolarDB-X V2.4版本提供了更好用的DDL能力，如Instant DDL（加列、减列）和Parallel DDL（并行索引创建），这些功能使得数据库表结构的变更更加快速和高效。同时，PolarDB-X还支持更完整的SQL执行能力，如Hash Join和窗口函数等，为用户提供了更加灵活和强大的数据处理能力。

在性能方面，PolarDB-X V2.4版本通过全面兼容MySQL 8.0.32，继承了官方MySQL在稳定性和安全性方面的众多优化和改进。这使得PolarDB-X在提供高性能的同时，也具备了更高的可靠性和安全性，为用户的数据安全保驾护航。

PolarDB-X V2.4版本的集分一体化架构和全面兼容MySQL 8.0.32的特性，使得它成为了一个既强大又灵活的数据库解决方案。无论是初创企业还是大型企业，都可以通过PolarDB-X来满足自己的业务需求，实现业务的快速发展和扩展。

标准版架构

PolarDB-X标准版：三层架构深度解析

PolarDB-X标准版以其独特的分层架构，为数据库领域带来了创新性的解决方案。其架构主要包括日志层、存储层和执行层，每个层次都经过精心设计，以满足高性能、高可用性和完全兼容MySQL的需求。

日志层：Paxos共识协议确保数据不丢失

PolarDB-X标准版的日志层采用了Paxos的多数派复制协议，这一设计使得系统能够在机房级故障时，依然保证数据的完整性和一致性。Paxos consensus协议确保了日志的完全可靠性，并且其日志格式与MySQL的binlog格式完全兼容。相比于传统的MySQL主备复制协议（基于binlog的异步或半同步），PolarDB-X标准版在容灾能力上达到了金融级别，真正实现了RPO=0，即数据零丢失。

存储层：Lizard事务系统引领事务处理新高度

PolarDB-X标准版的存储层采用了自研的Lizard事务系统，这一系统不仅可以替代传统的MySQL InnoDB单机事务系统，还针对集中式和分布式场景设计了SCN单机事务系统和GCN分布式事务系统。这种设计使得PolarDB-X在事务处理上更加灵活和高效，能够满足不同场景下的优化需求。同时，基于SCN单机事务系统，PolarDB-X标准版提供了完全兼容MySQL的事务隔离级别，保证了事务的一致性和可靠性。

执行层：xRPC Server引领分布式查询新时代

PolarDB-X标准版的执行层类似于MySQL的Server层，但更加先进和高效。其自研的xRPC Server可以与PolarDB-X企业版的分布式查询无缝对接，提供强大的分布式查询能力。同时，为了完全兼容MySQL，PolarDB-X标准版还提供了兼容MySQL Server的SQL执行能力，可以对接存储层的事务系统来提供数据操作。这种设计使得用户可以在不改变原有MySQL应用的前提下，无缝迁移到PolarDB-X标准版，享受更高的性能和可用性。

综上所述，PolarDB-X标准版以其独特的分层架构和创新性的设计，为用户提供了高性能、高可用性和完全兼容MySQL的数据库解决方案。无论是金融级容灾能力、灵活的事务处理还是强大的分布式查询能力，都使得PolarDB-X标准版成为数据库领域的佼佼者。

性能体验

硬件环境：

TPCC场景：对比开源MySQL（采用相同的主机硬件部署）

全球数据库网络（GDN）容灾架构设计概述

在数字化浪潮中，企业的数据库系统已成为其运营的核心支柱。为了确保关键数据的安全性和业务连续性，设计一个高效且可靠的容灾架构至关重要。数据丢失或服务中断可能给企业带来无法估量的财务损失和声誉损害。因此，在规划GDN的容灾架构时，必须充分考虑到数据的恢复时间目标（RTO）和数据恢复点目标（RPO），并权衡成本与技术实现的复杂性。

常见GDN容灾架构分析

随着全球化和数字化的发展，企业对容灾架构的需求也在不断演变。以下是目前市场上常见的几种GDN容灾架构及其特点：

同城多机房架构：

• 适用于单地域内的多机房部署。

• 虽能在一定程度上提供容灾能力，但无法满足多地域多活的业务需求。

两地三中心架构：

• 分为主地域和异地灾备地域，主地域承载主要流量。

• 异地地域主要承担灾备容灾功能，日常不提供多活服务。

• 适用于对灾备要求较高的企业，但存在资源浪费和响应延迟的问题。

三地五中心架构：

• 基于Paxos/Raft等一致性算法实现多地域数据复制。

• 能够在多个地域提供读写能力，实现高可用性。

• 但技术实现复杂，对硬件和网络要求较高。

地域分区架构（Geo-Partitioning）：

• 根据用户的地域属性进行分区，提供就近读写的能力。

• 适用于具有明显地域分布特征的业务场景。

• 但需要复杂的数据路由和分区管理策略。

全球多活架构（Global Database Network, GDN）：

• 构建全球范围内的多活架构，实现数据在中心节点集中写入，各地域节点就近读取。

• 适用于跨国企业和全球化业务场景。

• 需要强大的网络基础设施、数据同步技术和故障切换机制。

GDN容灾架构设计的考量

在设计GDN容灾架构时，企业应综合考虑以下因素：

• 业务需求：根据业务特点选择合适的容灾架构。

• 成本效益：权衡成本与技术实现的复杂性，追求最佳性价比。

• 技术实现：选择合适的数据同步技术、故障切换机制和监控管理系统。

• 网络基础设施：确保全球范围内的网络连通性和稳定性。

• 数据一致性：保证多地域数据的一致性和准确性。

• 安全性：加强数据加密、访问控制和审计等安全措施。

通过综合考虑以上因素，企业可以构建出既满足业务需求又具备高性价比的GDN容灾架构，确保关键数据的安全性和业务的连续性。

PolarDB-X的容灾能力概述

PolarDB-X以其独特的数据多副本架构，在容灾能力上展现出了卓越的性能。为了确保数据的强一致性（RPO=0），PolarDB-X采用了Paxos的多数派复制协议。在这种机制下，每次数据写入操作都需要获得超过半数节点的确认，从而确保了即便在部分节点发生故障的情况下，整个集群依然能够正常提供服务。Paxos算法不仅有效解决了副本不一致的问题，更在数据一致性方面提供了坚实的保障。

在PolarDB-X V2.4版本之前，其容灾形态主要聚焦于防范不同级别的故障。例如，单机房（3副本）配置能够抵御少数派一个节点的故障；同城3机房（3副本）配置则能够应对单机房级别的故障；而两地三中心（5副本）配置更是能够防范城市级别的故障。这些容灾形态为企业提供了多样化的选择，以适应不同级别的业务需求和风险挑战。

然而，随着业务的发展和全球化趋势的加速，传统的容灾形态已无法满足一些大型企业的需求。因此，PolarDB-X在V2.4版本中推出了更为先进的异地多活容灾架构——全球数据库网络（Global Database Network，简称GDN）。

PolarDB-X GDN是一个由分布在同一个国家内多个地域的PolarDB-X集群组成的网络。它借鉴了传统MySQL跨地域容灾的思想，但采用了更为先进和高效的技术手段。通过GDN，企业可以实现数据的全球多活部署，确保在不同地域之间的数据同步和一致性。即便在某个地域的节点发生故障时，其他地域的节点也能够迅速接管服务，保障业务的连续性和数据的完整性。

总之，PolarDB-X以其独特的数据多副本架构和Paxos多数派复制协议，以及GDN全球数据库网络的推出，为企业提供了更为强大和灵活的容灾能力。无论是单机房、同城3机房还是两地三中心等传统容灾形态，还是更为先进的GDN全球数据库网络，PolarDB-X都能够为企业提供全方位的容灾保障，确保业务的高可用性和数据的安全性。

素材来源：developer.aliyun.com/article/1507352?spm=a2c6h.12873639.article-detail.16.d70374dcgGAppl