Block as a Value for SQL over NoSQL

做者

Yang Cao,Wenfei Fan,Tengfei Yuan

University of Edinburgh,Beihang University SICS, Shenzhen University

{yang.cao@, wenfei@inf., tengfei.yuan@}ed.ac.uk

翻譯：陳祥春

摘要

本文介紹了Zidian，它是鍵值（K，V）的中間件存儲以經過NoSQL加速SQL查詢評估。如反對採用元組id或primary的常規作法，Zidian提出以鍵爲鍵，整個元組爲值值即塊模型BaaV。BaaV表示一個關係爲鍵控塊（k，B），其中k是B的塊（集合）B的鍵部分元組。咱們將關係代數擴展到BaaV。咱們發現，BAAV下，Zidian大大下降數據訪問和通信成本。咱們提供特徵（充分和必要的條件）以（a）保持結果查詢，便可用的BaaV商店覆蓋的查詢，（b）免掃描查詢，即無需評估便可查詢的查詢掃描任何表，以及（c）有界查詢，即查詢能夠經過訪問有限數量的數據來回答。

咱們證實，在並行處理中，Zidian保證（a）不掃描無掃描查詢，（b）通信受限有限查詢的費用；（c）並行可伸縮性，即添加處理器時加快速度。並且，Zidian能夠插入現有的SQL-No-SQL系統並保留水平可伸縮性。使用基準數據和真實數據，咱們憑經驗驗證Zidian改進了現有的SQL-over-NoSQL系統平均減小2個數量級。

1.引言

鍵值（KV）商店已在行業中普遍使用。KV商店支持相似字典的數據ac-檢索和將數據存儲爲鍵值對的必要性，從而提供了出色的可擴展性，容錯能力和透明分片。爲了支持大規模查詢，已經使用了多個SQL引擎。在KV商店頂部開發。畢竟有75％的業務數據被生成並存儲爲關係[43]，而且分析數據一般是經過SQL查詢執行的。這些系統一般基於基於SQL的NoSQL體系結構。它將數據持久存儲在KV存儲集羣中，並回答計算集羣中的查詢（做爲單獨的層）[29]。該架構已被Google的Spanner [20，12]，Facebook的MyRocks [25]，Hive [8]和SparkSQL [11]，以及其餘系統。雖然這些系統提供了潛在的KV優點，存儲，它們的性能不如傳統的DBMS在評估SQL查詢時，因爲如下緣由。

（1）掃描成本高。一般，大多數SQL over NoSQL系統基於元組即值（TaaV）模型。它存儲一個關係做爲一組KV對（k，t），其中k是內部元組t的ID或主鍵。這些KV對組織在分佈式哈希表（DHT）。DHT支持高效點經過給定鍵k的get進行訪問，獲取整個元組t。可是，對於大多數SQL查詢，咱們不知道提早相關元組。所以，咱們必須「盲目」掃描經過得到與表大小同樣多的獲取數獲得一個表。

（2）通信負荷大。正如[37]所觀察到的，不多SQL-No-NoSQL系統可以減小數據檢索經過例如將選擇謂詞下推到存儲層，而且沒有人能夠有效地執行掃描。結果是，一般須要大量數據（甚至是整個關係）從KV存儲器中檢索並由COM-處理放置層。這會致使數據通訊成本高昂在並行執行中改組。狀況更糟在非規範化數據庫的常見作法中[32，36]，即便用寬表或通用關係時。

咱們能夠減小過多的數據訪問和通訊嗎成本，並使現有的SQL-No-NoSQL系統有效在回答SQL查詢時是否像DBMS同樣有效？Zidian 爲了克服SQL-No-SQL的侷限性，咱們開發了Zidian（KV存儲的中間件）。底層Zidian是一個按價值計價的模型（BaaV）。與之相反KV商店的傳統TaaV模型，BaaV表明KV存儲中的關係做爲鍵控塊（k，B），其中k是部分元組的塊B的密鑰。在BaaV下，任意屬性能夠做爲鍵k，而k只能是TaaV下的id或主鍵屬性。

根據BAAV模式，Zidian提供如下。[1]高效的SQL。Zidian加快No-SQL上的SQL系統。經過減小get調用，不相關數據的檢索，以及所以，不管是計算成本仍是通訊成本。

（a）鍵控塊提供DHT中關係的數據局部性。只需一次獲取，就能夠檢索一組相關數據。

（b）BaaV爲KV商店提供便捷的索引編制功能，正如[37]所觀察到的那樣，KV商店尚未很好地支持它。經過明確使用索引，咱們可使查詢掃描-免費，無需掃描任何表格便可回答。免掃描查Q獲取並僅對所需數據的一部分進行操做用於回答Q，所以也下降了計算成本。

（c）經過推理鍵塊（k，B）和大小B。咱們能夠檢查一個查詢是否有界，只有不管有多大，都須要訪問有限數量的數據底層數據集是，所以能夠用有限的計算和通信成本。

[2]可擴展性。在並行處理中，Zidian保證（a）並行可伸縮性，即添加時保證加速計算節點到計算層；（b）有界受限查詢的通信費用。此外，（c）Zidian保留了SQL-No-SQL系統的水平可伸縮性，即，在將新節點添加到存儲層，其中吞吐量是指總數量每秒經過get [37]從全部存儲節點檢索的元組。

[3]易於使用。Zidian能夠創建在任何SQL-over-任何KV商店均可以使用NoSQL系統，無需進行黑客攻擊進入系統或更改其基礎KV存儲。那是的，Zidian能夠「插入」 No-SQL-No-SQL系統並幫助加快其SQL查詢的答覆速度。

貢獻和組織。本文提出Zidian和證實BAAV，從基礎到實踐中。

（1）  數據模型（第4節）。咱們介紹BaaV，將KV商店中的關係表示爲關鍵塊。咱們擴展關係代數到BaaV商店，以利用BaaV模型回答SQL查詢時。此外，咱們定義了BaaV查詢計劃中的免掃描查詢和有界查詢，加快No- SQL上SQL系統的SQL評估。

（2）  一個框架（第5節）。基於BaaV，咱們提出Zidian，一個加速現有 SQL 評估的框架SQL-No-NoSQL系統。它映射常規數據庫D到BaaV存儲D。它須要對D 進行SQL查詢Q，而後儘量在相應的BaaV商店D中向Q傾斜。咱們研究框架的基本問題。特別是，咱們提供了保存的特徵，也就是說，有足夠的必要條件來決定是否能夠在可用D中回答對D提出的查詢Q。

（3）咱們描述了無掃描（限定邊界）查詢的特徵，即，咱們開發了充分必要的條件來肯定SQL查詢在BaaV存儲上是否無掃描（限定邊界）。 雖然問題是沒法肯定的，但特徵描述提供了能夠有效檢查的此類查詢的有效語法。 此外，咱們提供了一種生成查詢計劃的算法，該算法可確保避免對無掃描（限制有界）的查詢進行掃描（限制訪問有限數量的數據）。

（4）並行化：有界和可擴展性（第7節）。咱們建議在並行回答查詢時交錯數據訪問和計算，而不是先獲取全部數據而後計算答案。經過這種策略，咱們代表zidian不須要掃描就能夠進行無掃描查詢，而且不須要爲受限查詢增長通訊成本。並且，在BaaV下，zidian保證了並行可伸縮性，並保留了SQL-No-SQL系統的水平可伸縮性。

（5）實現（第8節）。做爲概念證實，咱們已經實現了Zidian並將其部署到SoH（SparkSQLover-HBase [7]），SoK（SparkSQL-over-Kudu [7]）和SoC（SparkSQL-Cassandra [6]）。除了第5節的框架外，Zidian還包括：（a）一個模塊，用於在存儲約束下幫助設計BaaV模式（第8.1節）； （b）用於在現有KV系統上部署zidian的適配器。

（6）實驗（第9節）。使用基準TPC-H [42]和實際數據，咱們評估了Zidian的有效性。咱們平均發現如下內容。 1）Zidian的無掃描查詢效率分別比SoH，SoK和SoC高2.8×10二、1.7×102和8.1×102，非無查詢查詢分別高2.0×10二、1.5×102和3.6×102 。 2）使用Zidian，當數據集增加時，系統會爲有界查詢帶來穩定的計算和通訊成本。 3）Zidian具備平行可擴展性，而且能夠很好地與數據集進行擴展，例如，在SoH之上的Zidian平均對8名員工的128GB數據集進行freefree和non-free-free查詢分別須要27.7和65.4秒，而1.7×103和2.1× SoH沒有紫電的103秒。 （4）zidian保留了基礎KV系統的水平可擴展性，以應對KV工做量。

咱們將在第2節中討論相關工做，並複習SQL-over-第3節中的NoSQL。結果證實在[2]中。

2.相關工做

咱們將相關工做分類以下。

SQL-No-SQL。NoSQL的SQL體系結構是普遍用於支持可擴展的並行SQL處理商用機器，例如[34，12，40，19，35，41，25]，大寫字母-利用KV系統做爲存儲，例如Apache的Cassandra[6]，HBase [7]和Kudu [1]。扳手[20，12，40]開始這項工做，以支持大規模的分佈式事務。它基於BigTable [18]，它將關係存儲爲表TaaV下的KV對。這項工做以後是開源系統CockroachDB [19]，Nuodb [35]，MyRocks [25]和粒子[41]（支持SPJ）。SparkSQL [11]和Hive[8]還爲Spark和Hadoop提供相似SQL的查詢界面，基於KV數據集的KV系統。全部這些系統都遵循BigTable [18]的列族設計，經過處理每一個元組做爲具備指定行鍵的值。

儘管這些SQL-NoSQL系統可以經過OLTP事務進行擴展，但其效率卻受到KV商店掃描的影響，正如最近支持分析（OLAP）查詢的嘗試所觀察到的[3七、1五、33]。爲了克服這些限制，[37，15，33，1]經過設計提升掃描性能新的KV系統。他們專一於探索設計空間KV系統，以將掃描效率與其餘系統參數（例如更新，版本控制和查詢類型）進行權衡。其中，Tell [37]（最近針對掃描進行了優化的現代KV系統）和Apache的Kudu [1]也在KV商店中探索基於列的存儲關係。 這些努力對現有的KV存儲和SQL-No-NoSQL組合沒有幫助。

經過提出BaaV模型，這項工做採用了不一樣的方法。 它旨在提升現有SQL-No-SQL系統上的分析查詢的性能，而又不影響其可伸縮性。 它探索了現有系統能夠輕鬆支持的KV存儲中關係的新邏輯表示模型，並研究了其對查詢評估的影響，而無需更改KV存儲。

二級索引。BaaV模型提供了KV商店二級索引的功能，但它不只限於索引。不多有KV商店支持指數。在少數這樣作的過程當中，輔助索引被編碼爲經過填充鍵排序的關係[38]，所以仍然受到TaaV模型的限制。更具體地說，KV存儲中的關係R的非鍵屬性A上的二級索引一般實現爲KV對（k，v）的集合，其中鍵k是填充有內部id屬性I（或 R）的主鍵，所以AI值在TaaV下是不一樣的，所以能夠用做鍵；它們獲取R的整個元組。這是低效的，由於（a）對A的點訪問仍然會引發許多get調用，（b）不利於掃描，而且（c）引入了額外的索引維護成本。

相反，（a）BaaV經過使用DHT來支持索引KV系統，僅需獲取一組值對於屬性A上的同一點訪問。此外，它減小了在元組中獲取重複和沒必要要的屬性，而且所以減小了數據訪問和中間關係。的冗餘隨着鏈接迅速膨脹。（b）改善經過增長get的數據局部性和吞吐量進行掃描，同時保留水平和平行縮放的優點能力。（c）首先，做爲數據模型，BaaV公開了索引爲「方案」，並容許用戶明確使用用於優化的索引。（d）更好的是，咱們能夠推斷無掃描查詢和有界查詢，所有在查詢級別。這些都大大改善了計算和通訊尼克化。這些超出了傳統中學的範圍旨在僅加速數據檢索的索引。

物化視圖。物化視圖在DBMS中用於定製數據庫存儲並加快查詢評估速度[39]。從某種意義上說，世界客車聯盟和Zidian提供的功能KV商店的「物化視圖」。可是，有關鍵差別。（a）據咱們所知，沒有主要的SQL-over-NoSQL系統支持並在NoSQL存儲。（b）一我的可能想擴展示有的KV系統像DBMS同樣支持物化視圖。可是，這樣的擴展不能提供BaaV存儲的優點，若是視圖存儲在TaaV模型下。確實，視圖本質上是爲給定查詢量身定製的關係在DBMS中。所以，KV存儲查看（若是支持）也受到基本關係在傳統TaaV模式下的KV商店中遭受的相同限制。所以，BaaV是另外一種更有效的支持KV商店中的物化視圖（和基本關係）的方式。

有界評估。與這項工做有關的也是研究評估[26]，以規範規模獨立性在基數約束下[9，10，27，16]。那條線工做採用基數爲基礎的基於哈希的索引約束以肯定是否只有有限數量的使用索引來回答關係查詢須要數據僅在基數約束下經過查詢重寫來計劃。

這項工做在如下方面與有限評估不一樣。

（a）有界評估的重點是在給定一組基數約束及其關聯的基於哈希的索引的狀況下，決定能夠對哪些查詢進行有界評估。相反，咱們不須要基數約束。

（b）有限的評估僅在DBMS上有效，而BaaV和Zidian是爲SQL-over-NoSQL中的KV存儲開發的。

（c）有限評估未研究例如咱們爲Zidian開發的代數，並行化和數據映射。

3.前提

咱們回顧了SQL-No-SQL系統的基本符號。

鍵值存儲。KV存儲是鍵-值（KV）對（k，v）的集合，分別稱爲鍵和值屬性

它支持（a）get（k）來檢索KV對（k，v）鍵爲k，（b）put（k，v）添加KV對，以及（c）next（）遍歷全部鍵並獲取下一個鍵。

KV商店中的關係。關係R的元組t爲在TaaV（值即元組）下的KV商店中表示模型做爲KV對（k，v），其中k是id或主要R在t中的鍵，且v爲t。關係R存儲爲一組KV對共享相同的鍵和值屬性，其中每對錶明R的元組。一般封裝並稱爲例如寬列家庭商店，由於它們提供了關係的概觀。經過調用帶有如下內容的get操做來執行對R的掃描經過next（）提取的鍵，遍歷R中的全部鍵。

SQL-over-NoSQL。在這樣的系統中，如圖1a所示，在TaaV模型下，關係模式R的數據庫D做爲KV存儲存儲在存儲層中。 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存儲中的從新關聯關係做爲鍵控塊（第4.1節）。而後，咱們提出關於BaaV商店的代數（第4.2節）。

4.1 BaaV: Block-as-a-Value

BaaV商店。KV模式的形式爲R〈X，Y〉，其中X和Y是屬性集。R〈X，Y〉上的鍵控塊是KV對（k，B），其中k是屬性X和B是屬性Y上的一組元組。的KV實例DR〈X，Y〉是R上具備不一樣鍵的一組鍵控塊。D的度數，以deg（D）表示爲D中鍵控塊（k，B）的最大大小，即deg（D）=max （k，B）∈D | B |，其中| B | 是B中的元組數。

 

 

 

請注意，在TaaV模型下，nationalkey，suppkey和name不能做爲鍵屬性，由於它們不是對應關係的主鍵。 相反，在BaaV下，因爲BaaV值是元組塊，所以將它們用做鍵。

 

屬性。 BaaV具備如下優勢。

（1）與TaaV相比，BaaV存儲庫容許將任意屬性用做鍵。 實際上，當在鍵控塊（k，B）中，B是單個元組時，TaaV是BaaV的特例。

（2）與在TaaV下相比，每一個get調用在BaaV下能夠檢索更多的數據，所以在BaaV存儲上效率更高。

（3）BaaV存儲的程度表示KV存儲的DHT的數據局部性程度。 經過調整BaaV商店的程度，咱們能夠得到有限的查詢，並在BaaV下平衡KV商店的效率和更新成本。 關係數據庫和KV商店之間的映射。二者之間有一個方便的對應。

 

 

 

表1彙總了符號。

 

4.2 KBA：鍵控塊的代數