简介：基于Binlog的传统MySQL的主要体系结构具有其局限性，包括限制存储空间，缓慢的备份恢复和主要复制的延迟。对于弹性望远镜需求，Polardb启动了历史库（基于X -Ngine Engine）产品，支持物理复制并提供单阅读能力。现在已在阿里巴巴云的官方网站上出售。本文主要解释了如何使用基于LSM-Tree结构的存储引擎读取和阅读数据库。
作者|Yanxian来源|阿里技术公共帐户
Polardb是由阿里巴巴开发的新一代基于云的关系数据库。在存储和计算分离结构下，软件和硬件的优点用于为用户提供最终的弹性，庞大的存储，高性能和低成本数据库服务。x -Ngine是阿里巴巴的新一代存储引擎。作为Alisql的核心引擎之一，它已被广泛用于阿里巴巴集团的核心业务，包括交易历史库，指甲历史库，图片空间等。x -Ngine基于LSM -Tree Architecture。它的核心功能是，除了写作，高压和低成本外，数据还编写。它适用于业务场景，具有更多的阅读较少和低成本吸引力。传统的MySQL基于Binlog复制的主要体系结构的限制，包括有限的存储空间，缓慢的备份恢复和主要复制的延迟。启动了历史库（基于X引擎引擎）产品，该产品支持物理复制并提供单阅读能力。它已在阿里巴巴云的官方网站上出售。本文主要解释了如何使用基于LSM-Tree结构的存储引擎读取和阅读数据库。
LSM-Tree的全名是日志结构合并树。它是针对磁盘的分层，有序且设计的数据结构。它的核心想法是在批处理中使用磁盘。将倾斜化成其他写作方法，以通过吞吐量来改善写作。LSM-Tree类的存储引擎也首先源自Bigtable的Bigtable Storage Engine，这是Google Trunk之一，作为开源LevelDB，LSM-TREE存储引擎具有多种特征。首先，增量数据像日志一样书写，并且订单是按顺序编写的；其次，数据是根据键以有序的方式组织的，因此内存和磁盘将在内存和磁盘中一一形成。最后，可以返回每个“有序树”，并将内存中的增量数据迁移到磁盘。磁盘上的多个“有序树”可以返回并优化树的形状。整个LSM树是有序的索引组织结构。
在Yun的本地数据库时代，多阅读技术已在生产环境中广泛使用。主要的云生产商具有其基准产品。典型的代表包括亚马逊的Aurora，Alibaba的Polardb和Microsoft Cloud的Socrate。计算没有状态的节点。多个计算节点共享数据。数据库可以以低成本快速扩展性能。aurora是该领域的发起人，该领域实现了行业中的第一个数据库，可以计算节点比例，存储节点比例扩展并将日志模块推到存储层。在节点之间进行计算，计算和存储nodesthe重做日志是传输的，并且计算节点基于Quorum协议以编写多个副本以确保可靠性。该存储层提供了Page Services的多个版本。PolardB类似于Aurora。它还采用存储计算分离体系结构。与Aurora相比，Polardb具有自己的特征。存储基础是一个常规分布式文件系统。副本的一致性由ParalleLraft协议保证。POLARDB计算节点和存储节点传输数据页面和重做日志，仅通过计算节点和之间的站点信息传递。计算节点。就像Aurora的“日志是数据库”概念，仅在Socrates的节点之间传输重做日志，这也实现了多个版本的页面服务。它的特征是将数据库存储层的耐用性和可用性分开。每个数据库分为3层，一层计算服务，一层页面服务器服务和日志服务。该设计的优点是可以优化分层并提供更灵活，更细化的控制。
尽管Aurora，Polardb和Socrates具有自己的特征，但它们都练习存储计算分离的想法，并且数据库级别提供了更多阅读和阅读的能力。只要储存引擎加深，这些产品都基于B+树存储引擎。如果完成了LSM-Tree存储引擎？LSM-Tree具有自己的特征，添加订单，数据存储和磁盘上的数据块仅更有益于压缩。X-引擎引擎云产品RDS（X--发动机）已经完全发挥了LSM-Tree高压和低成本特征的特征。相同数量的数据，存储空间仅占RDS（InnoDB），RDS（RDS（RDS（rds）（X -Ngine的传统主要体系结构）仍然面临大规模复制延迟和缓慢备份等问题，RDS（rds（rds）（rds）（rds）（rds）（rds）（rds）（rds）（rds）（rds）（rds）（rds（rds）），则存储空间相同数量相同。在LSM-TREE引擎上恢复。以实现另一种读数，不仅计算资源和存储资源解耦，而且共享数据的多个节点可以进一步压缩存储成本。
基于LSM-TREE引擎，另外一读正面临与B+树引擎不同的技术挑战。首先，存储引擎日志不同。LSM-TREE引擎是双重逻辑流。第二个是数据组织方法不同。LSM-TREE引擎使用分层存储，并添加新数据来添加新数据。有必要求解多个计算节点一致性物理快照和组成问题。在本文中，作为数据库引擎，您还需要在多阅读模式下解决DDL的物理复制问题。，B+树发动机和LSM -Tree引擎的各自优势也面临着新的挑战，也就是说，如何在同一时间表的数据库产品中实现两个存储引擎之一（Innodb，X -Engine）之一。读。
1 Polardb整体体系结构
在Polardb支持X引擎引擎之后，X引擎引擎和InnoDB引擎仍然独立存在。这两个引擎各自接收写作请求，数据和日志存储在基础分布式存储上。其中，IDB文件表示InnoDB的数据文件，而SST文件表示X -Ngine的数据文件。这里的要点是InnoDB与Xengine共享了重做日志。当写X -Ngine时，Wal log被嵌入InnoDB的重做中。在将重做日志和备用节点分发到InnoDB发动机和Xengine发动机之后，分别分发了。
polardb（x -ngine）体系结构
X- ngine Engine架构
X引擎发动机使用LSM-Tree结构。除了添加它之外，数据还将数据写入内存中，并定期将其定期为磁盘。存储器中的数据以可记忆的形式存在，包括活跃的记忆和多个静态不变的。X- ngine最小空间分配单元是一定程度，默认值为2m，每个范围包含几个块，默认值为16k。DATA记录将密切存储在块中。由于其他写作的特征，仅读取磁盘上的数据块。因此，X -Ngine引擎默认情况下可以压缩块。此外，与InnoDB发动机相比，X -Ngine的存储空间仅为1/3，并且某些场景（例如图片空间）甚至可以压缩至1/7。其他写作带来了写作的优势。对于历史版本数据，有必要通过压实任务恢复。对于X -Ngine的核心技术，您可以参考Sigmod19中发布的论文，“ X -Engine：用于大型电子商务的优化存储引擎事务处理”
X- ngine整体体系结构
2个物理复制体系结构
物理复制的核心是通过引擎本身的日志完成副本，以避免由其他日志引起的成本和性能损失。写入交易需要同时编写引擎日志和Binlog日志。这是一个问题，一方面需要在键写入路径上写两个日志。缩短Binlog的串行写作。另一方面，Binlog复制是逻辑复制。复制延迟的问题还使复制体系结构的可用性很大，并且仅阅读库的阅读服务能力大大降低了，尤其是在执行DDL操作时。ISIT的延迟将进一步扩大。
有两个日志：InnoDB中的重做和撤消。撤消日志可以理解为特殊的“数据”，因此实际上，InnoDB的所有操作都可以通过重做日志确保耐用性。因此，在复制时，您只需要在主节点上复制重做日志。x -ngine。发动机包含两个日志，一个是WAL日志（Writeaheadlog），用于记录前台的操作；另一个是SLOG（Storagelog）的操作，用于记录LSM-Tree的形状的变化，主要是指/flush等。WALlog保证了前平台的原子和持久性，以及口号确保X引擎中LSM-Tree的形状变化的原子性和持久性。两个日志都是必不可少的，需要复制同步。
共享存储下的物理复制
主要复制物理复制体系结构
LSM-TREE引擎阅读和阅读更多的能力是增强PolardB。它反映在架构级别中，该级别是充分利用现有的复制链接，包括主要 - > replica传输日志信息链接和replica-> primary Transmornation Collaborative Control InformationLink.innodb由多个MTR（Mini-Transactions）组成。写入重做日志中的最小单元是mtr。我们在Innodb的重做日志中添加一个日志以指示X -Ngine日志，并将X -Ngine的内容写入重做日志中。Soshare副本的副本。由于主和副本共享了日志和数据，dump_thread只需要传递网站信息，而复制品则根据网站信息读取重做日志。replica解析日志，将日志分配给不同的播放引擎，到日志类型。该体系结构使所有复制框架都与先前的复制一致。引擎与InnoDB引擎完全脱在一起。
由于LSM-TREE的附加写作的特征，记忆内存中的数据数据是定期齐平的磁盘。为了确保主和复制读取一致性物理视图，主和副本需要同步交换机，这需要一个新的SwitchMemtable控制日志才能坐标。重做日志持久后，主动将站点信息推动到通过复制来通过副本。log，以便副本将及时播放最新的日志以减少同步延迟。对于slog日志，您可以使用重做的日志积极地“推”来同步站点。它也可以与副本活动“ public” method.slog是背景日志同步。与前台事务的真实时间要求相比，不必将重做站点和SLOG站点放在复制链接中以提高复杂性。因此
灾难恢复集群之间的物理复制
主要的物理复制体系结构
与共享集群的副本不同，灾难恢复群集具有独立的存储。主 - >待机需要传递完整的重做日志。Stanby和副本之间的区别在于日志的来源是不同的。副本从共享存储中获取日志。STACTY从复制链接中获取日志。其他分析和返回路径是相同的，这是将slog日志作为重做日志的一部分传递到待机的问题。SLOG日志是由冲洗/压实操作生成的，该操作记录了LSM-Tree形状的物理变化。如果它也通过重做日志链接与备用链接同步，它将带来一些复杂性。一方面，需要更改X引擎内的日志的方法，并且需要与新文件操作相关的物理日志，以确保主要的物理结构与物理结构，失败的逻辑一致恢复也需要改编；另一方面，作为背景任务的操作日志，slog表示链接副本上的所有字符都必须相同。如果放弃了相同的结构，那么恒定的节点可能会触发齐平/compactionTask编写日志，这是通过允许primary在物理复制中编写日志而违反的。口号是背景日志。此操作不会及时返回以不影响数据视图的正确性。因此，复制链接仅包括X组织wallog和InnodB重做日志），备用控制冲洗/压实以生成slog日志，因此备用不必与主节点在物理上是同质的。整个体系结构与现有系统匹配，并且也更加灵活。
3平行物理复制加速度
X -Ngine的事务包括两个阶段。第一阶段是阅读和写作阶段。在此阶段，事务操作数据将在交易的背景下放慢速度。第二阶段是提交阶段。在读取操作中的记忆中写入。对于待机/复制节点，播放过程与主节点相似。它分析了从重做到交易日志，然后将交易放回记忆中。要解决的是可见性问题。当播放交易序列时，序列版本编号正在不断增加，交易可见性没有问题。在与场景并行的同时，我们仍然需要保留订单。通过引入“滑动窗口”机制，只有连续序列序列才能促进全局序列版本编号。该全局序列用于读取操作以获取快照。
并行复制框架
在多阅读体系结构下，为了确保同一数据库实例的主，复制和备用的内存镜完全一致，添加了新的SwitchMemtableLogGog。在RW的Switch_Memtable期间生成的日志。因此，请主动触发switch_memtable操作，而是将SwitchMemtableLog从RW.SwitchMemtable操作中同步switch_memtableG，这是一个全局障碍点，可以防止插入过程中当前写入的记忆，并导致数据混淆。需要对数据本身的日志进行调整。2PC事务还包括四种类型的日志：beginprepare，endprepare，commit，collback。在写作过程中，请确保将beginprepare和endprepare写入写入批次并顺序结束。它们将被解析到replaytask。如果提交和回滚日志在准备日志中播放，则在整体恢复的_transaction_map上插入一个键，该密钥对应于XID的空交易，相应的交易状态为提交或回滚；然后，当释放准备日志时，如果您发现相应的事务已经存在于Recovered_transaction_map中，则可以决定根据交易状态直接提交交易或丢弃事务。
对于B+树的物理复制，LSM-Tree的物理复制不是真正的“物理”复制。因为B+Tree通过重做的内容的内容是数据页的修改，并且通过重做内容传递了。LSM-Tree是关键值。结果是，B+树物理复制可以基于数据页的粒度并行，并且LSM-Tree的物理复制基于基于事务的并发。树有其自身的复杂性。例如，有必要解决系统页面的问题和常规数据页面。它还需要解决由同一MTR.LSM-Tree中多个数据页面引起的不一致的物理视图的问题，以解决在同一位置和2PC交易等问题之类的问题。
4 MVCC（多次共同控制）
物理复制技术解决了数据同步的问题，为存储计算的分离奠定了基础。为了实现仅读取节点的能力的弹性，动态提升，添加和删除，只有读取节点的能力才能具有能力阅读一致性。此外，RW节点和RO节点共享数据。历史版本回收也是必须考虑的问题。
一致性阅读
X- ngine提供了读取快照的能力，并通过多种版本的机制来实现读取和写作的非排斥效果。从上面的X-Engine架构图可以看到，X-Engine的数据实际上包括两个部分：内存和磁盘。与InnoDB引擎内存中的页面不同，磁盘上的磁盘的缓存。X- ngine中的内存数据和磁盘数据 - ngine Arecomplete异质性，“快照”需要对应于内存+磁盘data.x -ngine使用其他写作。新数据将产生新的记忆。背景任务还会产生齐平/压实任务也将生成新的Extens。首先，每个跨snapshot对应于一组记忆和L0，L1，L2 Extenss，因此数据范围是物理确定的，然后可以通过Snapshot.Sex，Snapshot，此处的快照来处理线路级版本。实际上是提交序列编号序列的事务。从InnoDB交易号的开始顺序不同，您需要通过主动交易视图来判断记录的可见性；X -Ngine事务是按顺序提交的。Sequecom.sequence.inMulti Read模式，副本节点和主节点共享磁盘数据，并且磁盘数据定期与内存中的数据一起转储。数据视图的符合性。
一个更可读的压实
在多阅读方案中，复制品可以通过类似于主的快照机制实现明确的阅读。需要解决的问题是历史版本回收问题。回收的历史版本取决于压实任务。这里的恢复包括两个部分，以及某些MetasNapshot的回收。它主要确认可以将哪些可记忆和扩展可以进行物理回收。可以回收历史版本。对于元数据的回收，主要版本将收集所有副本节点上的所有最小元张照片编号。X -Ngine引擎的每个索引都是LSM -Tree，因此索引了Metasnaphot版本编号。主要收集MetasNapshot版本编号，并计算资源回收操作的最小元数据。回收操作与slog日志中的副本节点同步。复制节点回收资源在返回日志中的资源回收利用时，需要将内存和磁盘资源分开。内存资源独立于每个节点，并且磁盘资源共享。因此，释放了节点。对于行 - 级别多元的回收，最小序列序列序列序列序列号序列序列序列序列序列是由主节点收集的，主节点通过comportion compaction任务消除了。polardb ack链接，但添加了X引擎的报告信息。
5 DDL物理复制如何实现
相对于逻辑复制的物理复制的关键优势是DDL。对于DDL，逻辑复制可以简单地理解为复制SQL语句，并且DDL将再次在库上重新执行。逻辑复制是繁重的DDL操作，例如Alter Table的影响。在主库中执行变更操作需要半小时。一个小时，此延迟对仅阅读库的读取服务有严重影响。
服务器层复制
DDL操作涉及服务器层和发动机层，包括字典，缓存和数据。最基本的DDL操作，例如
在多阅读体系结构下创建/删除操作考虑了诸如数据和数据字典，数据和字典缓存一致性之类的问题。阅读和阅读的基础是物理复制。物理复制日志仅在发动机层中流动，不涉及服务器层。因此，有必要添加一个新日志来解决由DDL操作引起的不一致问题的问题。我们添加了元信息更改的日志并将其同步到节点作为重做日志的一部分。此元信息更改日志主要包括两个部分，一个是字典同步，主要是同步的MDL锁，以确保主/复制节点词典是一致的；另一个是字典缓存同步。复制品上的内存是独立的，需要更新服务器层缓存的缓存字典信息。因此，有必要添加一个日志来进程，例如Drop Table/Drop db/Upite函数/Upite procepture。此外，需要同步复制的查询，以避免使用错误的查询缓存。
发动机层副本
X- ngine发动机是索引纸巾，例如InnoDB发动机。在X引擎内，每个索引都是LSM-Tree结构，在内部被称为串曲。所有写作均在“串曲”中执行。DDL操作密切相关。用户启动了制作式操作以产生款项。这是物理LSM-树结构的载体，然后可以进行随后的DML操作。同样，用户启动表删除操作后，应执行所有这些可符号的DML操作。创建/删除表操作涉及索引结构的生成和灭亡，这也将同时产生重做控制日志和slog日志。当播放时，需要解决重做控制日志和句号日志的时机。在此，我们将坚持在重做日志的LSN站点中，该站点与slog相对应。作为同步网站，播放了复制品时，可以协调两个播放链接。重做日志记录了前台操作。在背景操作中，需要同时完成两个链接，并且您需要避免重复复制链接以等待slog复制链接。例如，对于创建操作，当放置一个口号时，您需要等待相应的重做日志的LSN站点在LSN站点发布后将其推回去；对于下降操作，您需要等待背部以避免使用。
ONILINGDL复制技术
对于Alter Table操作，X-Engine实现了一组OnilinedDL机制。有关详细的实施原则，您可以参考内核月度报告。在多阅读体系结构下，X引擎引擎在处理此类更改操作时会使用物理复制。实际上，对于复制品而言，由于它是相同的数据，因此它不需要重新生成物理退出。它只需要同步元信息信息。就接受它。对于待机节点，索引需要在物理范围内复制它。当复制DDL时，它实际上包含基线和增量零件。DDLReplication充分使用该X引擎的分层存储和LSM-Tree结构的添加。获得快照后，使用快照直接构建L2作为基线数据。数据的这一部分通过重做通道传输到待机。增量数据与普通DML交易相同，因此整个操作是通过物理复制执行的，这大大提高了复制效率。仅在Alter操作过程中L2的压实。整个ONILINEDDL过程类似于InnoDB的OnlinedDL过程。它还包括3个阶段，准备阶段，构建阶段和提交阶段。其中，准备阶段需要获得快照。提交阶段元数据生效。它需要确保字典通过mdl lock.com与基于B+树的OnlinedDL副本相比，基线部分，B+Tree索引副本是一个物理页面，而LSM-Tree则复制物理范围；写重做；从Quantic日志到数据页面的日志以进行同步，LSM-Tree与通过DML前台进行重做的方式同步。
ONILINGDL副本
6双引擎技术
检查点网站促销
通过Wal-in-ReDo技术，我们将X-Ngine的Wal Log嵌入了InnoDB的重做中。首先要处理的问题之一是重做日志的回收问题。日志恢复首先涉及一个站点问题。集成到重做日志后，内部X引擎将恢复点定义为
数据字典和DDL
作为数据库引擎，X -Ngine具有自己的独立词典，InnoDB也有自己的词典。两个词典肯定会在系统中遇到问题。为了解决问题，这里有两个想法。一个是X -Ngine仍然保留其自己的数据字典。进行DDL时，通过2PC交易是一致的。需要协调的问题。在正常情况下，mySQL协调器是一个binlog日志，它是binlog关闭时的tclog日志。明显地，从功能和性能的角度来看，我们不会依靠binlog日志。我们已经采用了另一个。主意。X -Ngine不再使用自己的引擎存储元数据数据。通过InnoDB发动机，所有元数据数据都持久。X- ngine元数据实际上是InnoDB字典的缓存。在同一时间，元数据部分实际上仅涉及InnoDB发动机，这可以确保通过交易来确保DDL的原子量。
我们通过元数据解决了元数据的原子问题，但是X- ngine数据和InnoDB元数据如何确保一致性也是一个问题。由于表结构的变化在InnoDB词典中进行了修改，因此数据正在修改X引擎。这是一项跨发动机交易。协调员的实践一致性。为了避免将Binlog作为协调员引入，TCLOG作为协调员没有经历大规模的生产环境，我们选择了另一种处理方法的方法。具体而言，当涉及交叉引擎时，给出了x- ngine事务的优先级，然后给出X引擎交易，然后在交易之前给出x- ngine交易。Submitinnodb交易。对于DDL，它是“第一个数据，遵循-up数据”和元数据在真正表明DDL完成之前提交了元数据。如果它失败了，则与“延迟删除”机制结合在一起，以确保可以最终清理垃圾数据，并且InnoDB词典的字典基于后端任务X -Ngine Data和InnodB字典。发动机内存元信息，确认数据的这一部分是否有用。
CrashRecovery
X -Ngine是MySQL的插件，例如InnoDB引擎。X-Enigne作为可选的插件，从Innodb.EATE引擎开始以恢复阶段的重做日志来恢复数据库。无论是InnoDB引擎还是X引擎引擎，在阅读日志恢复时，都必须扫描整个重做日志，这相当于在整个恢复阶段进行两次扫描重做。这可能会使整个停机时间恢复过程很长，这降低了系统的可用性。为了解决此问题，我们对X -Ngine的恢复阶段进行了细分，并调整了发动机的起始顺序。在InnoDB开始之前，请完成X -Ngine的初始化和处于还原重做状态的SLOG的恢复过程。当InnoDB开始时，该日志根据类型分布在X -Engine Engine中。重做日志已经完成，InnoDB发动机的市区恢复过程，X引擎引擎本身已经完成，然后可以采取正常的XA恢复和恢复后阶段。此过程与以前的过程一致。
哈
在Polardb支持双引用引擎之后，将在整个提升过程中设置X -Ngine引擎的逻辑。例如，在将待机升级到RW之前，有必要确保X-Engine的释放流线完成，并且可以保留不令人满意的事务以通过XA_Recovery进行前进。当RW下降到Standby时，您需要等待X引擎编写流线线条。同时，如果没有决策交易，则需要在切换过程中穿越这一部分不合理的交易。
在上一节中，我们详细描述了基于LSM-Tree体系结构的存储引擎，实现了一个阅读多阅读所需的关键技术，并与Polardb双引擎结合使用，以引入一些项目实现。请参阅基于B+树和LSM-Tree的两个数据组织结构的技术比较。首先，您需要返回基本点。B+树已更新到位，并添加了LSM-Tree。区别在于，B+树的数据视图在内存和外部中具有缓存映射关系。这是叠加关系。因此，需要面对的技术问题是不同的。B+树需要肮脏，并且有一个双写（在Polarfs支持16K原子之后，消除了该极限）；LSM-TREE需要压实以回收历史版本。在多阅读模式下面临的问题也不同。例如，B+树引擎由单个重做日志复制，LSM-Tree引擎是双重域。B+树在处理平行背景版本时可以更有能力取得更大的成就。细化的页面 - 级别并发性，但是您需要处理SMO（SplitMerGeoperation）问题，以免阅读“过去的页面”或“未来页面”” .LSM-TREE是交易级别的并发水平。为了确保RW和RO节点的“内存+磁盘”的一致性视图，RW和RO需要在同一站点上进行记忆。将InnoDB引擎和X-Engine Engine作为示例，列出了一些关键差异。
目前，行业LSM -TREE型引擎相对热是RockSDB，其主要应用程序场景被用作KeyValue Engine.facebook将RocksDB引擎介绍给其MySQL8.0分支，类似于X -Ngine到Alisql，主要是服务他们的用户数据库UDB业务，存储用户数据和消息数据。在目前，我没有看到存储计算分离，并且可以读取更多内容。加法，GitHub拥有一个RockSDB-Cloud Project，该项目使用RockSDB作为基础和基础和在云服务（例如AWS）上提供NOSQL接口服务，这等同于分离存储计算，但不支持物理复制和一次性读取。在数据库领域，阿里巴巴的Oceanbase和Google Spanner的基础存储引擎基于LSM- 树结构，显示LSM-Tree作为数据库引擎的可行性。两个数据库均基于共享的架构。基于共享存储数据库，到目前为止还没有成熟的产品，Polardb（x-engine）是基于LSM-Tree结构的第一个一次性阅读解决方案。LSM-Tree的结构自然将内存与磁盘存储分开。我们充分利用磁盘存储的特性仅阅读。通过压缩成本优势，再加上阅读和阅读的能力，成本优势可用于极端。
X -Ngine引擎实现多阅读能力后，我们使用基准测试工具Sysbench查找性能。它主要比较RDS（X -Engine），Polardb（X -Engine）和Polardb（Innodb）的性能。
1个测试环境
测试客户端和数据库服务器都是从阿里巴巴云的官方网站购买的。Client使用ECS，规格是ECS.C7.8XLARGE（32 CORE，64G），测试SYSBENCH版本是Sysbench-1.0.20，测试数据库服务器包括测试数据库服务器。RDS（X-Engine），Polardb（X-Engine），PolardB（Innodb）（InnoDB）都采用8core32g规格，配置文件在线上采用默认配置。测试场景涵盖了完整内存的几个典型工作和io-io-------绑定。测试表的数量为250张，完整表的记忆数为25,000行，IO-BOND-BOND桌线的数量为300万行。
2个测试结果
RDS与Polardb
上图上图是一个小表完整的内存场景，右侧的图片是大桌IO-BOND BOND.POLARDB（X -NGINE）与RDS（X-Engine）相比，它主要改变。核心差异。是RDS主体系结构取决于BINLOG以复制，而PolardB表单仅需要重做log.com，并用RDS表格进行重复，将PoladeB表格的性能与RDS表格进行比较，包括在完整内存和IO-BOND中场景，都有很大的性能改进。
B+树与LSM-Tree
上图是一个小手表的完整记忆场景，下面的图片是io-bound的大型桌子。该差距主要来自范围查询。此外，通过更新场景而引起的多反转也将在更新时引起范围查询。这些因素导致读取和写作相关工作，InnoDB引擎比X引擎更好。在同一时间，我们可以看到，在IO结合的场景中，X-Engine Engine更有利。
Polardb（X -Ngine）解决方案解决了用户的存档存储问题，但还不够彻底。首先，尽管Polardb支持双引擎，但我们尚未完全合并两个引擎。可行的想法是集成在线档案。用户的在线数据使用默认引擎InnoDB。通过设置某些规则，PolardB将自动存档一些历史数据，并将一些历史数据转换为X引擎引擎存储。整个过程对用户透明至Useressences，而当前存储已落在Polarstore PolalStore上。为了进一步降低成本，X -Ngine引擎可以在OSS上存储一些冷数据。这对于分层存储非常友好和自然。实际上，基于LSM-Tree的存储引擎具有很强的可塑性。我们当前的工作只能使存储优势充分发挥作用。将来，可以进一步探索内存中的数据结构。