这开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内，可以解决你的问题。加群请微信联系 liuaustin3 ，（共2100人左右 1 + 2 + 3 + 4 +5） 新入群的将默认分配达到5群）,另欢迎 OpenGauss 的技术人员加入。
存储布局，上图显示了x-engine的架构，X-Engine 将每个表分成多个字表，并未每个字表维护一个LSM树，关联快照和索引，x-engine中的每个数据库中包含一个重做日志，每个LSM树由一个位于主存储器中的热数据层和一个位于NVM/SSD/HDD的数据处理层组层，热，温，冷不同的数据的层次在系统中存储在不同访问频率的层次中，热数据包含一个活动的内存表和多个不可变的内存表，他们是跳表，用于存储最近插入的记录，并缓冲热记录的缓存，这里不同访问频度的数据已树桩的结构组织数据，树的每个层级的存储有一个排序的extent序列来组织。extent 包含记录快以及关联的过滤器和索引。我们正在探索机器学习技术与数据访问拼读之间的关系。
X-Engine利用重做日志、元快照和索引来支持事务处理的多版本并发控制（MVCC）。每个元快照都有一个元数据信息。
索引跟踪快照中树的所有内存表和数据范围。树的一个或多个相邻层级形成一个层次结构，分别存储在NVM、SSD和HDD上。在X-Engine中，表被分成多个子表。每个子表都有自己的热、温和冷数据层（即LSM树）。X-Engine以行导向格式存储记录。我们设计了一个多版本的内存表来存储具有不同版本的记录，以支持MVCC（介绍见第3.2.1节）。在磁盘上，元数据索引跟踪存储在数据范围中的所有记录版本。我们在第3.1节介绍了数据结构的详细信息。
读路径。读路径是从存储中检索记录的过程。原始的LSM树设计在读性能上表现不佳。在查找时，首先搜索内存表。如果在内存表中未找到，则必须逐个遍历每个后续层级。在最坏的情况下，查找必须扫描所有层级直到最大层级，才能得出查询的记录不存在。为了加速这个过程，已经提出了一个清单文件来定位包含查询键的目标SST（排序字符串表）。布隆过滤器也应用于每个SST中，以便实现提前终止。
为了在电子商务交易中常见的点查询中实现良好的响应时间，我们优化了数据范围的设计，引入了一个跟踪所有内存表和数据范围的元数据索引，以及一组缓存来方便快速查找。我们还提出了一种增量缓存替换方法，在合并中减少因合并导致的不必要的缓存驱逐。我们引入快照来确保查询读取正确的记录版本。
写入路径，关于写入路径其中包含了物理访问路径以及在存储引擎中插入或更新记录的相关的过程，在LSM树KV存储中，在数据写入键值对呗追加或插入到活动的内存表中，一旦完全填满活动内存表就会切换成不可变的状态，等待刷新到磁盘上，与此同时，会创建一个新的活动的内存表，为支持高并发事物的处理，存储引擎需要在通过持久存储SSD中进行日志的记录，并在快速的插入信息到内存表中，从而使新记录持久，在这个过程中，区分了高延迟的磁盘I/O和低延迟的内存访问，并将他们组织在一个并行的数据传输机制中，减少每个传输管道中的空闲状态，提高整体的吞吐量。
刷新和合并，LSM 树以来与刷新和数据合并操作，将超过主存的数据从内存表合并到磁盘上，并保持合并后的数据按照顺序来写入，不可变的内存表被刷新到level0 , 期间记录被排序并打包成排序的徐鹏表，每个SST 占据一个独占的键的范围，因此一个层级可能包含多个SST，当level中的SST 达到阈值的情况下，他们会与上一层的level 进行合并，这个合并的过程中一些数据被压缩，并且合并数据，最后将合并后的数据写回到LSM树，这个过程中的问题在于大量消耗CPU和磁盘的I/O，同一条记录被多次的读取和写入导致写放大，即使记录的值不变，他也会使合并的记录的缓存内容失效。
在X-Engine中，我们首先优化不可变内存表的刷新，对于合并我们应用数据重用，减少合并的扩展数目，采用异步I/O使合并与磁盘I/O重叠，并使用FPGA卸载以减少CPU消耗。
优化总结：下表针对特定的问题设计了各种的优化措施，我们在下面进行更详细的介绍
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
