0 摘要
本文介绍了Zidian，它是一种用于键值（KV）存储的中间件，可以加快位于NoSQL上的SQL查询。 与采用元组id或主键作为键并以整个元组作为值的常规做法相反，Zidian提出了一个将block做值的模型BaaV.BaaV用带键值的块（k，B）来表示一个关系，where k is a key of a block (a set) B of partial tuples 。 我们将关系代数扩展到BaaV。
我们表明，在BaaV下，Zidian大大降低了数据访问和通信成本。 我们提供以下特征去证明这一点
（a）结果保留查询（即可用涉及到BaaV store的查询），
（b）免扫描查询（即无需扫描任何表即可进行评估的查询）
（c）有界查询的特征（查询可以通过存取一定范围内的数据而得到响应）
我们证明，在并行处理中，Zidian保证
（a）不扫描免扫描查询
（b）有界查询的通信成本也比较低；
（c）并行可伸缩性，即在添加处理器时加快速度。
此外，Zidian可以插入现有的SQL-over-NoSQL系统中，并保持水平的可伸缩性。 使用基准数据和实际数据，我们凭经验验证Zidian将现有的SQL-over-NoSQL系统平均提高了2个数量级。
1 介绍
键值（KV）存储已在行业中广泛使用[22、34、6、18、7、40]。KV store支持类似字典的数据访问，将数据以键值对的形式去检索和存储，从而提供了出色的可扩展性，容错能力和透明分片能力。
为了支持大规模查询，已经在KV stores上开发了几个SQL引擎。 毕竟，75％的业务数据是作为关系的形式去生成和存储的[43]，并且通常通过SQL查询来进行数据分析。这些系统通常基于SQL-over-NoSQL架构[37]，该架构将数据持久存储在KV存储集群中，并且通过计算集群（作为单独的层）并行地去响应查询[29]。 Google的Spanner [20，12]，Facebook的MyRocks [25]，Hive [8]和SparkSQL [11]等系统都采用了这种架构。
尽管这些系统提供了底层KV存储的好处，但由于以下原因，在评估SQL查询时的性能时并不如传统的DBMS。
（1）扫描成本高。 通常，大多数SQL-over-NOSQL系统都基于（TaaV）模型。 它将关系存储为一组KVpairs（k，t），其中k是元组t的内部ID或主键。 这些KVpairs被组织在分布式哈希表（DHT）中。 DHT对给定的键值k通过get接口提供高效的点查，去获取整个的元组t。然而，对于大多数SQL查询，我们事先都不知道相关元组的键值。 因此，我们不得不为了去产生和table中元组个数相同的get操作，而去盲目的扫描table。
（2）通讯负载(Communication Load)过大。 正如[37]所观察到的那样，很少有SQL-over-NoSQL系统能够减少数据检索，例如，将选择谓词推送到存储层，而且没有一个系统能够有效地执行scan。 因此，经常会从KV存储中检索到大量数据（甚至整个关系），并由计算层进行处理。 对于并行执行中的data shuffing[李子健1] ，这将导致沉重的通信成本。 在对数据库进行非规范化的常规做法中[32、36]，甚至在使用wide tables或通用关系[李子健2] 时，情况甚至更糟。
当涉及到SQL查询时，是否可以减少过多的数据访问和通信成本，并使现有的SQL-over-NoSQL系统与DBMS一样有效？
Zidian. 为了克服SQL-over-NoSQL的局限性，我们开发了KVS的中间件Zidian。 Zidian的底层是将block作为value的存储模型。 与传统的KV存储区的TaaV模型相反，BaaV在KV存储区中表示由带键值的块（k，B）组成的关系，其中k是包含了关系部分元组的block B的键值。 在BaaV存储模型下，任意属性都可以用作键值k，而在TaaV模型下k只能是id或主键属性。
在BaaV存储模型下，Zidian提供以下功能：
[1] Efficient SQL. Zidian通过减少get接口的调用，以及减少无关数据的检索和计算成本和通信成本来加快SQL-over-NOSQL系统的运行。
（a）Keyed block提供了DHT中关系的数据局部性。通过一个get操作，可以检索一整个块的相关数据
（b）BaaV为KV stores提供方便的索引，如[37]所指出的那样，KV stores还没有很好的支持索引。通过显式使用索引，我们可以使查询免扫描，而无需扫描任何表即可对查询进行相应。一个免扫描查询Q仅提取和操作相应Q所需的部分数据，因此也降低了计算成本。
（c）通过推理keyed blocks（k，B）和B的大小，我们可以检查查询是否有界，不管基础数据集有多大都只需要访问有限数量的数据，因此可以用有界计算和通讯成本来相应查询。
[2]可扩展性。 在并行处理中，Zidian保证：
（a）并行可伸缩性，即在将计算节点添加到计算层时保证加速;
（b）有界查询的更少的通信成本。此外，
（c）Zidian保留了SQL-over-NoSQL系统的水平可扩展性，即在将新节点添加到存储层时提高了吞吐量，其中吞吐量是每秒从所有存储节点检索的元组总数[37]。
[3] 易于使用。Zidian可以构建在任何SQL-over-NoSQL系统中的任何KVstores之上，而无需侵入系统或更改其底层的KV存储。 也就是说，Zidian可以“插入”现有的SQL-over-NoSQL系统之中，并有助于加快其SQL查询的响应速度。
贡献&组织。 本文提出了Zidian并从基础到实践证明BaaV的合理性。
（1）数据模型（第4节）。 我们介绍BaaV，该模型将KV存储中的关系表示为keyed blocks。 我们在BaaV存储之上拓展关系代数，让其在回答SQL查询时发挥BaaV模型的作用。 此外，我们从BaaV query的角度计划定义了免扫描查询和有界查询，以加快在NoSQL上的SQL查询。
（2）框架（第5节）。 在BaaV的基础上，我们提出了Zidian，这是一个可以加快对现有SQL-over-NoSQL系统的SQL查询的框架。将传统的数据库D映射了BaaV存储的D‘。它接受D上的SQL查询Q并在可能的情况下在相应的BaaV存储D’中回答Q 。我们尽可能研究框架底层的基本问题。特别是，我们提供了保留的特征，即一个充分必要的条件，用于确定一个基于D的查询Q是否可以在D’上被相应。
（3）免扫描数据访问（第6节）。 我们描述了无扫描（有界）查询的特征，即，我们开发了一个充分必要的条件来确定基于BaaV store上的SQL查询是否无扫描（有界）。 虽然问题是无法确定的，但特征描述提供了此类查询的有效语法，可以有效地对其进行检查。 此外，我们提供了一种生成查询计划的算法，该算法可避免对无扫描（有界）的查询进行扫描（对有界查询访问有限的数据量）。
（4）并行化：有界和可伸缩性（第7节）。 我们建议在并行响应查询时交错的进行数据访问和计算，而不是首先获取所有数据然后计算答案。 通过这种策略，我们表明Zidian对不需要扫描的查询不进行扫描，而对有边界的查询则减少了通信成本。 而且，在BaaV下，Zidian保证了并行可伸缩性，并保留了SQL-over-NoSQL系统的水平可伸缩性。
（5）实现（第8节）。作为概念证明，我们已经实现了Zidian并将其部署到SoH（SparkSQL-over-HBase [7]），SoK（SparkSQL-over-Kudu [7]）和SoC（SparkSQL-over-Cassandra [6]）。除了第5节的框架外，Zidian还包括：
（a）一个模块，用于在存储约束下帮助设计BaaV模式（第8.1节）；
（b）一个用于在现有KV系统上部署zidian的适配器。
（6）实验（第9节）。使用基准TPC-H [42]和实际数据，我们评估了Zidian的有效性。我们平均发现以下内容。
1）Zidian的无扫描查询效率分别比SoH，SoK和SoC高2.8×102、1.7×102和8.1×102，非无查询查询分别高2.0×102、1.5×102和3.6×102 。
2）使用Zidian，当数据集增长时，系统会为有界查询带来稳定的计算和通信成本。
3）Zidian具有平行可扩展性，并且可以很好地与数据集进行扩展，例如，在SoH之上的Zidian平均对8名员工的128GB数据集进行scan-free和non-scan-free查询分别需要27.7和65.4秒，而SoH 却需要1.7×103和2.1×103。
4）zidian保留了基础KV系统的水平可扩展性，以应对KV工作量。
我们将在第2节中讨论相关工作，并第3节中复习SQL-over-NoSQL。在[2]中证明结果。
2 相关工作
我们将相关工作分类如下。
SQL-No-SQL。NoSQL-over-NOSQL体系结构是被广泛用于支持可扩展的并行SQL处理商用机器，例如[34，12，40，19，35，41，25]。比较典型的利用KV系统作为存储的系统有，Apache的Cassandra[6]，HBase [7]和Kudu [1]。Spanner[20，12，40]开始这项工作，以支持大规模的分布式事务。Spanner基于BigTable [18]，它将关系存储为表TaaV下的KV对。许多开源系统，例如CockroachDB [19]，Nuodb [35]，MyRocks [25]和Partiqle [41]（支持SPJ）都是跟随这个项目来的。SparkSQL [11]和Hive[8]还为Spark和Hadoop提供类似SQL的查询界面，Hadoop基于KV数据集的KV系统。所有这些系统都遵循BigTable [18]的列族设计，通过处理每个元组作为具有指定行键的值。
尽管这些SQL-over-NoSQL系统能够拓展到可以处理OLTP事务，但其效率却受到KVstore扫描的影响，正如[37、15、33]所观察到的最近支持分析（OLAP）查询所做的尝试。为了克服这些限制，[37，15，33，1]通过设计提高扫描性能新的KV系统。他们专注于探索设计空间KV系统，以将扫描效率与其他系统参数（例如更新，版本控制和查询类型）进行权衡。其中，Tell [37]（最近针对scan进行了优化的现代KV系统）和Apache的Kudu [1]也在KVstore中探索基于列的存储关系。 这些努力对现有的KV存储和SQL-over-NoSQL结合没有帮助。
通过提出BaaV模型，这项工作采用了不同的方法。 它旨在提高现有SQL-over-NoSQL系统上的分析查询的性能，而又不影响其可伸缩性。 它探索了现有KV stores系统中关系的新逻辑表示模型可以轻松的得到支持，并研究了其对查询评估的影响，而无需更改KV storage。
二级索引。BaaV模型为KVstores提供了二级索引的功能，但它不仅限于索引。很少有KVstore支持指数。在少数支持二级索引的系统中，辅助索引被编码为通过填充键排序的关系[38][李子健3] ，因此仍然受到TaaV模型的限制。更具体地说，KV存储中的关系R的非键属性A上的二级索引通常用KV对（k，v）的集合的形式实现，其中键k是一个带有内部id属性I（或 主键R）的填充属性。因此AI值在TaaV下是不同的，因此可以用作键；TaaV系统通过键值获取R的整个元组。这是低效的，因为
（a）对A的点访问仍然会引起许多get调用
（b）不利于扫描，并且
（c）引入了额外的索引维护成本。
相反，（a）BaaV通过使用DHT来支持索引KV系统，对于属性A上的点查询只需要一个get操作就能获得一整个块的值。此外，它减少了在元组中获取重复和不必要的属性，并且因此减少了数据访问和intermediate relation以及随着join操作迅速膨胀的冗余。（b）通过增加get的数据局部性和吞吐量改善scan的性能，同时保留水平和平行缩放的优势能力。（c）首先，作为数据模型，BaaV公开了索引为“schema”，并允许用户显式的使用用于优化的索引。（d）更好的是，我们可以在查询层次上推断无扫描查询和有界查询，。这些都大大改善了计算和数据通信。这些超出了传统辅助索引的范围旨在去加速数据检索的索引。
物化视图。物化视图[李子健4] 在DBMS中用于定制数据库存储并加快查询评估速度[39]。从某种意义上说，BaaV和Zidian为KVstore提供物化视图的的功能。但是，有些关键点存在差异。（a）据我们所知，主要的SQL-over-NoSQL系统并不支持在NoSQL存储上使用物化视图的功能。（b）一个人可能想扩展现有的KV系统让其像DBMS一样支持物化视图。但是，如果视图存储在TaaV模型下，这样的扩展不能提供BaaV存储的优势，。确实，视图本质上是在DBMS中为给定查询量身定制的关系。因此，基于KV存储的view（如果支持）也受到基本关系在传统TaaV模式下的KVstores中遭受的相同限制。因此，BaaV是另一种更有效的支持KVstores中的物化视图（和基本关系）的方式。
有界评估。与这项工作有关的也是研究有界查询[26]，以规范在基数约束下[9，10，27，16]的规模独立性。That line ofwork adopts a hash-based index guided by the cardinalityconstraints to determine whether only a bounded amount ofdata is required for answering relational queries with index-only plans, by query rewriting under cardinality constraints。这项工作在以下方面与bounded evaluation不同。
（a）bounded evaluation的重点是在给定一组基数约束及其关联的基于哈希的索引的情况下，决定可以对哪些查询进行bounded evaluation。相反，我们不需要基数约束。
（b）bounded evaluation仅在DBMS上有效，而BaaV和Zidian是为SQL-over-NoSQL中的KV存储开发的。
（c）bounded evaluation没有研究例如，我们为Zidian开发的代数，并行化和数据映射等等功能。
3 前提
我们回顾一下SQL-over-NOSQL系统中的一些概念：
键值存储。KV存储是键-值（KV）对（k，v）的集合，分别称为键和值属性
它支持：
（a）get（k）来检索KV对（k，v）键为k，
（b）put（k，v）添加KV对，以及
（c）next（）遍历所有键并获取下一个键。
KVstore中的关系。关系R的元组t为在TaaV（值即元组）模型下的KVstore中表示作为KV对的形式（k，v），其中k是id或者关系R中t的主键，而v就是元组t。关系R以一组共享相同的键和值属性的KV对存储，其中每个kv对代表关系R中的一个元组。KVstore中的关系通常被封装为wide-column family stores，因为它们提供了表和视图的关系。通过调用带有get操作来执行对R的扫描以及通过next（）提取的键值，遍历R中的所有键。
SQL-over-NoSQL。在这样的系统中，如图1a所示，在TaaV模型下，关系模式R的数据库D作为KVstores存储在存储层中。 SQL-over-NoSQL系统向用户公开R，然后用户可以通过R发出Q查询。对Q的评估由计算群集（称为SQL层的单独层中）进行。SQL层由SQL解析器，计划器和执行器组成，以生成Q的查询计划ξ。计划ξ仅通过get操作访问D的KV存储中的数据。
SQL-over-NoSQL系统的工作方式如下。 在接收到SQL查询Q后，存储层将检索Q中涉及的所有关系，并将数据移至SQL层。 然后，SQL层为Q生成并行查询计划ξ，并在所有计算节点上并行执行该计划。
存储和计算的分离使SQL-over-NoSQL一下特点
（a）由于繁重的计算任务而不会影响存储，所以具有高可用性，并且
（b）易于扩展，因为我们可以随需扩展。但是，它附带一个开销：数据访问通常会导致缓慢的完整关系扫描，并且因此，SQL层的通信负载很重。
4 BaaV模型
在本节中，我们首先介绍BaaV模型，去表示在KV存储中作为keyed blocks（第4.1节）的关系。然后，我们提出关于BaaV stores的关系代数（第4.2节）。
4.1 BaaV: Block-as-a-Value
