评估数据库BI/分析工作负载的最佳基准是TPC-DS。EsgynDB已与Apache ORC深度集成并优化了性能,虽然处理TPC-DS型工作负载的结果还有待提高,但目前的结果还是较为可观。

在处理运营型工作负载领域,目前EsgynDB还未棋逢对手。在进行TPC-DC测试时,EsgynDB使用Hive(利用Tez引擎)与ORC进行性能对比。

TPC-DS基准测试的数据量是10TB。EsgynDB能够执行全部的99个TPC-DS查询,而Hive只能执行65个查询。

 

b

EsgynDB的速度是Hive的5倍。EsgynDB完成99个查询的时间甚至短于Hive完成65个查询的时间。

值得注意的是,这些测试是在8节点和12节点的系统上运行的。如果后者性能是前者性能的1.5倍,那么EsgynDB能达到线性扩展的要求。EsgynDB的结果是1.4倍,已非常接近线性扩展的要求。这表明随着集群增长,BI/分析工作负载(难以实现线性增长)的性能曲线也能和OLTP的性能曲线一样,将呈线性增长。

目前还未有任何数据库厂商在典型BI和分析环境中运行单个查询流,因此,我们想展示多并发查询性能的比较。我们首先选取了20个最快查询集的随机查询,再将这些查询集从单个流或单个用户渐进式地平均扩展到20个并发用户(扩展4次,即1个用户、5个用户、10个用户、15个用户和20个用户)。根据TPC-DS的要求,针对不同的并发流,EsgynDB执行不同顺序的组合查询,因此,不同并发流的性能也不同。

无论执行何种并发测试,EsgynDB的性能均是Hive的3-5倍。另一个亮点是性能斜率曲线,EsgynDB是Hive的2.8倍。这表明并发度增加时,如果想达到相同的性能,Hive需要更多资源。

而在相同资源条件下,EsgynDB能提供更优异的性能和更高的并发度。

b

EsgynDB取得优异性能的原因
以下是基准中用于处理各类查询的比较/差异化功能总结(仅简单描述哪些功能为哪些查询提供优化),排名不分先后:
• EsgynDB从Tandem继承的技术财富和自身几十年的技术经验使EsgynDB支持ANSI SQL功能,在执行99 TPC-DS查询时,EsgynDB只需修改少量语法。
• 无共享架构具有透明的扩展力,能随集群或数据的增长而扩展。数据从1TB到10TB的扩展只需少量调优。
• 基于成本、从上至下的优化器高效地为复杂查询探索巨大搜索计划空间。一些查询具备十几种join,一些查询具备大型聚合。最佳执行计划应能高效执行复杂查询。测试时,编译查询未设置特定提示或使用特殊配置。
• 基于灵活规则的优化能检查标准Schema模式,例如,范式、星型Schema和雪花Schema。TPC-DS使用雪花Schema,该测试使用的数据模型包括星型Schema(反范式)和第三范式。
• 管理所有列的等高直方图和所有表的键列组合,这有利于优化器获取每列数据分布或列组合的更准确的视图。TPC-DS日期维度表跨越几十年,然而事实表仅拥有几年的数据。EsgynDB为join和其他运算符预估基数,使用从ORC数据分区收集的直方图和列统计信息,根据日期范围,预估事实表和日期维度表join后的行数。
• 执行基于数据流架构,它的查询片段包括动态调度的不同操作。通过指针队列,数据在片段中的操作符之间进行交换、无需复制。在集群网络环境中,数据在片段间通过TCP进行数据交换。
• 如果内存压力过大、没有足够内存完成操作,那么可以将中间数据溢出到磁盘。处理查询时,大数据量的join和聚合可以溢出到磁盘。某些数据库由于不具备充分使用内存的动态模型,且仅在内存不足时溢出,如果没有足够内存处理需要大量内存的操作(例如,大型hash join或排序、物化中间结果至磁盘),则其他数据库引擎会失败。
• 根据复杂度和数据交换需求,每个查询将被拆分成几个执行片段,一个或多个片段将在不同进程中执行。多个片段在单个节点上同时执行,从而允许使用节点中所有core。
• 基于LLVM(Low Level Virtual Machine)的原生表达式估值能高效执行大量消耗CPU的查询。
• 维度表和事实表的数据以压缩和柱状ORC格式存储,将简单谓词的估值下推至ORC子系统,从而最小化IO。
• 在日期列上的ORC数据水平分区允许对事实表进行分区裁剪,以减少某些查询的IO。EsgynDB支持静态分区裁剪(基于查询的字面值) 和动态分区裁剪(基于仅在执行期间的可用值)。
• 根据ORC统计信息,每个扫描进程读取ORC文件的部分条带,例如:
O 每个并行扫描处理等量数据,因此,完成扫描的时间相同。
O 进程读取的数据存储在该进程运行的节点本地,从而减少了节点间数据交换的开销。
• 由于嵌套join能随机访问事实表的某些行,所以它很适合处理星型Schema。嵌套join能高效处理以下场景:对DATE_DIM小表和SALES大表执行join(特别是根据SS_SOLD_DATE_SK列上的值对SALES大表进行分区)和对DATE_DIM小表使用非连续日期的本地谓词执行查询(例如,1999,2000和2001年中的所有周一)。
• 在该基准测试中,EsgynDB广泛地应用了匹配分区和Broadcast Join,提高join性能同时最小化网络流量。
• 通过在每个查询片段中对可用数据执行部分GROUP BY操作,部分聚合(Partial Aggregation)能减少网络中的数据流。所有片段的结果将被合并,用于计算所有分组的最终结果。在该基准测试中,EsgynDB广泛地应用了部分分组。
• EsgynDB支持GROUP BY的两种实现:Hash和排序。如果已对数据进行排序,则排序GROUP BY能更高效地处理聚合,而且它不会溢出到磁盘。
• 由于相关子查询的执行成本很高,所以查询无法在合理时间范围内完成。而EsgynDB编译器能将相关子查询转换成hash join,这是一项非常强大的技术。
• 窗口函数(使用分区或顺序表达式)中的聚合能并行执行。
• 并发度由查询复杂度、在同一查询内流经操作的数据量和操作复杂度决定,这能确保为复杂查询提供足够资源,而简单查询能使用较少资源快速执行,从而使系统能在多个并发用户之间高效分享。
• 通过发送join列的最小值和最大值,最小优化/最大优化减少hash join中大表扫描访问的数据量。执行查询时,扫描小表(join中的小表)决定最小值/最大值。如果join列是数据分区列,则最小值/最大值能动态裁剪更大表的整个分区。
• 由于被扫描的大部分数据存储在集群中的同一节点,因此,执行大型扫描的多个执行器进程在该节点上运行。本地化访问能大幅减少节点间的网络流量。
• 对LIMIT子句而言,编译器合成谓词,使用直方图统计数据(它为每个运算符计算预估基数),限制查询中每个运算符处理的行数不小于在LIMIT clause中指定的行数。如果未能执行该步骤,则必须执行全部查询,并将LIMIT clause应用至仅由查询返回的行。该功能可以大幅减少流经查询的数据。
• LIMIT子句和ORDER BY使用Top-N排序,仅保留排序结果的前N行。因此,对许多行进行排序时,不会溢出到磁盘。
• 当GROUP BY能大幅减少数据时,使用EXISTS/IN或INTERSECT的查询将被转换成GROUP BY和join的执行计划。
• 如果每张表有许多数据文件,则通过扫描ORC文件收集统计信息和位置数据的成本会很高,这将增加编译时间。对文件采样和将收集的元数据存放在基于磁盘的缓存中能减少编译时间。
• EsgynDB仅通过一条INSERT语句启动多执行器进程并行插入至Hive ORC表,并允许创建和插入若干分区。
• 数据倾斜的方式有多种。最常见的是“最流行值”数据倾斜,当列中的某些值用于join或聚合且出现的次数远远多于其他值时,这种情况就会发生。在join列中的值会变得非常倾斜(即,大部分行有相同值)。高效的hashing 算法能跨节点平均分配值。但如果hash列中拥有相同值的行数过多(数据倾斜),这些行将会在同一节点上被处理。一个或少量节点将会过度工作,而其他节点只有少量工作。Skew Buster功能可以识别查询某些操作的数据倾斜状况,并对倾斜值和其他值采用不同的分配方法,从而确保数据跨所有处理节点平均分配。

综上所述,EsgynDB的架构能高效处理混合事务/分析处理工作负载。Esgyn正在规划未来工作和融合其他技术,将为EsgynDB提供前所未有的性能。