《UniBench A Benchmark for Multi-Model Database Management Systems》阅读笔记

说明：论文地址

多模型数据库（Multi-Model Database, MMDB）是数据库管理系统的一个新兴趋势，它利用单一平台来管理存储在不同模型中的数据，如文档、图、关系和键值对。

数据库Benchmark是评估和比较DBMS的重要工具。然后，近些年很少有专门针对多模型数据库设计的Benchmark。

评估MMDBs的两大挑战：

生成合成的多模型数据设计多模型工作负载

多模型数据库的演变：

第一阶段：多克隆持久化（Polyglot Persistence）方法，利用大量数据库来处理不同形式的数据，并将其集成以提供统一的接口，但操作复杂，成本高。第二阶段

许多SQL-extension或NoSQL系统整合额外的引擎或函数到一个统一的平台，转变为多模型系统。许多原生的多模型系统出现，如ArangoDB、OrientDB和AgensGraph，这些系统利用单个存储来管理多模型数据，使用统一或混合的查询语言。

多模型数据库Benchmark生成的相关工作：TPC-DI（XML，CSV和文本）、Big-bench（TPC中的结构数据、半结构数据日志和无结构数据评论）。

已有工作的缺陷：都没有考虑JSON和图数据，但这两类数据如今非常常见。只考虑简单的工作负载（wordload），如CRUD操作、聚合、图深度遍历，但没考虑涉及多模型特征的复杂工作负载。

为此，作者设计了可以生成五类模型数据的数据生成器，以及专门为多模型数据库设计的工作负载（包括10个查询和2种事务），并在两个多模型数据库ArangoDB和OrientDB上进行了测评。

针对多模型数据生成，作者提出了三阶段数据生成框架，三个阶段如下图所示：

购买阶段（Purchase）：从元数据仓库中获取数据，生成图以及人的兴趣。

传播购买阶段（Propagation-Purchase）：根据前一阶段的数据，生成冷启动（cold-start）顾客的兴趣。

再购买阶段（Re-purchase）：根据CLVSV模型为所有的顾客生成兴趣。

在每个阶段，根据顾客的兴趣生成事务数据，然后将三个阶段生成的数据整合成一个多模型数据集。

LDBC生成人们的兴趣。每个人事务的数量等于兴趣数除常量 c c c，每个事务的大小由参数为 λ lambda λ的泊松分布决定，每个事务的产品是随机从兴趣中选取的。对应事务生成JSON格式的订单，与此同时使用相同的信息生成XML格式的发票。此外，会从亚马逊数据集中随机选择产品的真实评论和评级作为反馈。

本阶段的数据由5个模型组成：社交网络（Graph）、供应商和顾客（Relation）、订单和产品（JSON）、发票（XML），反馈（键值对）。

LDBC是一个社交网络benchmark。

该阶段主要是为没有兴趣的人生成相应的事务，其兴趣来源于朋友，依据是具有相同属性的人更有可能有相同的行为，人们也信任朋友的产品推荐。 具体做法以朋友评级过的产品作为候选集，然后利用公式（1）计算相应的分数，选择前 n n% n作为当前人的兴趣，并生成相应的事务。
S u i = ∑ k k × Pr ⁡ ( R u i = k ∣ A = a u ) + E ( R v i : ∀ v ∈ N ( u ) ) (1) S_{u i}=sum_{k} k times operatorname{Pr}left(R_{u i}=k mid A=a_{u}right)+Eleft(R_{v i}: forall v in N(u)right) tag{1} Sui​=k∑​k×Pr(Rui​=k∣A=au​)+E(Rvi​:∀v∈N(u))(1)
公式（1）中 ∑ k k × Pr ⁡ ( R u i = k ∣ A = a u ) sum_{k} k times operatorname{Pr}left(R_{u i}=k mid A=a_{u}right) ∑k​k×Pr(Rui​=k∣A=au​)表示目标用户 u u u对产品 i i i的评分的概率期望，其中 A = { a 1 , a 2 , . . . , a m } A = {a_1, a_2, ...,a_m } A={a1​,a2​,...,am​}是根据朴素贝叶斯方法计算的用户属性集，朴素贝叶斯模型的训练是以Purchase阶段的数据作为训练集进行训练的。 E ( R v i : ∀ v ∈ N ( u ) ) Eleft(R_{v i}: forall v in N(u)right) E(Rvi​:∀v∈N(u))是 u u u的朋友对目标产品的评分的期望，其中 N ( u ) N(u) N(u)是 u u u的朋友的集合，产品 i i i来自朋友在Purchase阶段的事务。

本阶段主要生成用户再次购买的数据。作者提出了一个新概率模型CLVSC（Customer Lifetime Value in Social Commerce, 社会商务中的顾客终身价值 ），通过结合客户的品牌社交活动来进行细粒度预测。该模型由三个部分组成：

期望的行为数量期望的货币价值客户期望的积极社会参与度

CLVSC同样定义了一个关于顾客和品牌的打分模型（公式2），用来估计顾客对品牌的兴趣，然后从前 n n n个品牌获取 m m m个兴趣，并生成与购买阶段相同的兴趣。
S i b ( C L V S C ) = E ( X ∗ ∣ n ∗ , x ′ , n , m , α , β , γ , δ ) × ( E ( M ∣ p , q , v , m x , x ) + E ( S ∣ s ˉ , θ , τ ) ) S_{i b}(C L V S C) =Eleft(X^{*} mid n^{*}, x^{prime}, n, m, alpha, beta, gamma, deltaright) times left(Eleft(M mid p, q, v, m_{x}, xright) + E(S mid bar{s}, theta, tau)right) Sib​(CLVSC)=E(X∗∣n∗,x′,n,m,α,β,γ,δ)×(E(M∣p,q,v,mx​,x)+E(S∣sˉ,θ,τ))
该公式的第一部分 E ( X ∗ ∣ n ∗ , x ′ , n , m , α , β , γ , δ ) Eleft(X^{*} mid n^{*}, x^{prime}, n, m, alpha, beta, gamma, deltaright) E(X∗∣n∗,x′,n,m,α,β,γ,δ)表示顾客基于历史行为数据在接下来 n n n个时段内期望的行为数，其中 ( x ′ , n , m ) (x',n,m) (x′,n,m)表示顾客行为的历史数据，而 ( α , β ) (alpha,beta) (α,β)和 ( γ , δ ) (gamma, delta) (γ,δ)分别表示活跃概率和非激活概率的beta分布参数，行为包括购买和发布两种。该公式的第二部分 E ( M ∣ p , q , v , m x , x ) Eleft(M mid p, q, v, m_{x}, xright) E(M∣p,q,v,mx​,x)表示期望的货币价值。而公式的第三部分 E ( S ∣ s ˉ , θ , τ ) E(S mid bar{s}, theta, tau) E(S∣sˉ,θ,τ)表示客户的期望社会参与度 ，作者假设其服从一个参数为 λ lambda λ的泊松过程， λ lambda λ中的异质性在客户中遵循形状参数 θ theta θ和速率参数 τ tau τ的伽马分布。

数据库工作负载：All the SQL statements that execute against a database comprise the workload for that database. 即针对数据库执行的SQL构成该数据库的一个工作负载。

UniBench从商业案例和技术角度定义了相关的多种工作负载，其中相关的SQL都涉及至少两种数据模型，旨在覆盖不同的商业案例和技术角度。

作者定义的工作负载中，即有传统的OLTP查询，也有OLAP查询。

从商业案例的角度，工作负载分为如下4个层级：

个体（individual）：多个数据源获取数据来构建用户画像。Q1会话（conversation）：分析用户的半结构和结构数据，从反馈中捕捉用户情绪，然后调整在线广告或运营策略。Q2和Q3社区（community）：挖掘社区常见的购买模式和分析社区对个人购买行为的影响。Q4、Q5和Q6商业（commerce）：分类优化和性能透明。Q7、Q8、Q9和Q10。

具体Query参见原论文，限于篇幅就不列了。

UniBench的的工作负载设计基于瓶颈技术，在处理查询时测试数据库的许多方面。通常，这些方面可能涉及数据库的不同组件，例如查询优化器、执行引擎和存储系统。此外，该工作负载不仅涉及传统数据库系统常见的查询处理挑战，还包括多模型查询处理的一些新问题。作者列出了3个关键点：

选择合适的联结类型和联结顺序：由于涉及不同的数据模型，不同连接顺序和类型的执行时间可能会有数量级的差异。主要测试查询优化器是否能够找到最优的联结顺序和类型。执行复杂聚合：面向复杂数据结构的聚合，聚合的嵌套。这些聚合涉及多个数据模型数据的合并。确保一致性和效率：测试数据库的ACID特性。主要测试执行引擎和存储系统寻找合适并发控制技术来保证一致性和效率的能力，对于MMDB还需要保证数据模型的一致性。 例子

作者在论文中以Q5为例，其对应的查询是：

给定一个起始用户和一个产品目录，寻找他在Graph中的3阶朋友，以及他们购买的包含在给定目录下的产品，最后返回这些产品5星评级的反馈。

该查询涉及3个数据模型：Graph、JSON和KV，涉及三种Join操作：Graph-Graph、Graph-JSON和JSON-KV，该查询带来的挑战：图的递归路径查询、JSON的嵌入式数组操作，以及键值的复合键查找。

实验的数据库：OrientDB和ArangoDB

作者生成了三个数据集，其相关数据如下：

针对不同大小的系统，Unibench定义了一组比例因子（SF）。上述三个数据集分别包含1GB、10GB和30GB的数据。

作者首先测试对比了两个不同数据库对三个数据集SF1、SF10和SF30的导入时间，导入时间结果如下：

额外时间是指联结操作的代价，OrientDB需要使用CREATE link命令在关系数据和JSON数据之间创建反向链接

结论：对于SF1、SF10和SF30，ArangoDB的导入分别比OrientDB快7.5、3.4和3.8倍。

两个数据库都不支持原生XML，所以没有对XML进行测试，KV的导入合并到了Relational中。

作者对比测试了两个数据库在Q1~Q10等10个多模型查询上的处理时间，对比结果如下：

结论：除了Q5，其它查询的处理都是ArangoDB更快。

作者还对比测试了两个多模型数据库在普通OLTP事务上的性能，其中ArangoDB是异步处理，而OrientDB是同步处理，其对应于两种事务New Order和Payment的吞吐量展示如下：

结论：ArangoDB在写重（write-heavy）事务（Payment）方面更好，OrientDB在执行读重（read-heavy）事务（New Order）方面更高效。