内存数据库的自动优化方法？

内存数据库的自动优化方法？

以一个直观的例子来解释这个问题，我们以全内存分布式数据库RapidsDB为例，要检查特定表的已排序行段组的当前状态，请在CLI环境中运行SHOW COLUMNAR MERGE STATUS FOR <table_name>来查看：

让我们仔细看结果的第一行，我们知道存储在分区0上的表的切片具有3个有序的行段组，一个由741个行段组成，一个由16个行段组成，最后一个由1行段组成，共计758个行段。考虑这种有序的行段组对非常简单查询的影响：

根据排序行段组的定义，第一个排序的行段组最多包含一个包含user_group = 15的行的行段，除非user_group = 15位于两个行段的边界上，或者如果存在较大数据倾斜并且几个行段仅由user_group = 15的行组成。类似的，第二排序行段组中最多一个行段包含相关行。这样，总共758个行段中只有三个将被打开和具体化。虽然本例中的查询非常简单，但类似的推理同样适用于复杂查询中。

现在我们看一下分区2上有序的行段组。很明显，它的优化程度远远低于剩下的2个，类似上面所示的选择查询将会导致物化8个行段。如果启用了background merger，并且没有或者少量工作负载同时运行，那么这个分区将会在几秒钟内得到优化。然而，在数据库执行大量的增删改任务时，background merger的处理性能会被影响。在这种情况下，不如通过手动触发pessimistic merger，让增删改任务和后台优化任务前后脚独立完成更合理：

如果当我们执行OPTIMIZE TABLE时运行SHOW COLUMNAR MERGE STATUS，那么我们将会看见其作用：

新出现的一行代表分区3上正在进行一个手动合并，此时已经完成了53.12%的工作任务。当完成合并任务后，现在情况更好了：

请注意，在本例中，没有任何分区被合并到单个有序的行段组中。其原因是，两种不同的合并方式均采用一种高级算法，该算法被优化为在并发写入的情况下进行小的分批次工作，并将数据保持在几个有序的行段组中，而不是试图将所有数据合并到单个有序的行段组中。如果可以牺牲一些数据处理时间来获得更高的查询性能，则可以运行手动命令，将每个分区上的数据合并到一个有序的行段组中：

此时，任何选择查询将只具体化每一个分区的一个行段。当向列式表中插入少量行时，使用内存中行存储支持的段来存储行。当这个以行存储为基础的段被填满时，后台刷新程序background flusher会定期将这些行刷新到磁盘中。通过运行OPTIMIZE TABLEFLUSH，可以手动将受行存储支持的段刷新到磁盘中。

至此，例子中数据表t的后台自动排序完成了。整个过程中，数据库无须用户干预，仅通过自动优化实现了高性能。