【51CTO.com快譯】這年頭幾乎每個(gè)人都在這樣那樣抱怨性能。數(shù)據(jù)庫管理員和程序員不斷發(fā)現(xiàn)自己處于這種情形：服務(wù)器遇到了瓶頸，或者查詢起來沒完沒了，這種情況并不少見。這種郁悶對我們所有人來說司空見慣了，解決方法不一。

最常見的一幕就是看一眼查詢后，責(zé)怪程序員在查詢方面沒有做得更好。也許他們原本可以使用合適的索引或物化視圖，或者干脆以一種更好的方法重寫查詢。而有時(shí)候，如果貴公司使用云服務(wù)，你可能要多啟用幾個(gè)節(jié)點(diǎn)。在其他情況下，如果服務(wù)器被太多慢騰騰的查詢搞得不堪重負(fù)，你可能要為不同的查詢設(shè)置不同的優(yōu)先級，那樣至少比較緊迫的查詢（比如***執(zhí)行官的查詢）更快地完成。如果數(shù)據(jù)庫不支持優(yōu)先級隊(duì)列，管理員甚至?xí)∠愕牟樵?，騰出一些資源，用于更緊迫的查詢。

不管你遇到過上述哪種情況，可能熟悉這種痛苦的經(jīng)歷：不得不等待慢騰騰的查詢，或者購買更多的云實(shí)例，或者購買更快速、更龐大的服務(wù)器。大多數(shù)人熟悉傳統(tǒng)數(shù)據(jù)庫調(diào)整和查詢優(yōu)化方法。這些方法有利也有弊。所以，我們在這里不會談?wù)撃切┓椒āＮ覀冊诒疚闹惺且務(wù)摳路f的方法，它們不大為人所知，但在許多情況下確實(shí)可以有機(jī)會大大提升性能，并節(jié)省成本。
 

首先，不妨考慮這些場景：

場景1（探索性分析）——你是名分析員，要對數(shù)據(jù)進(jìn)行交叉分析，尋找洞察力和模式，或者測試針對你的公司、客戶或服務(wù)所作的不同假設(shè)。在這種情況下，你通常不知道自己究竟會看到什么。你運(yùn)行查詢，查看結(jié)果，然后決定是否需要運(yùn)行不同的查詢。換句話說，你執(zhí)行一系列探索性即席查詢，直至找到所需的結(jié)果。你運(yùn)行的查詢中只有一些會用來填充公司報(bào)表、填寫表單，或者為客戶生成圖形。但每當(dāng)你提交查詢，可能要等幾分鐘才能得到答案，時(shí)間的長短要看數(shù)據(jù)大小及集群中其他并行查詢的數(shù)量。等待過程中，你通常無所事事，無法決定下一個(gè)查詢，因?yàn)檫@取決于你仍在等待執(zhí)行完畢的前一個(gè)查詢的輸出結(jié)果！

解決辦法：等待過程中，你可以立即看到“幾乎***”的答案。我這里所說的“幾乎***”的答案是啥意思？不妨比較下面這兩張圖。

 這些是同一款商業(yè)智能工具在運(yùn)行從后端數(shù)據(jù)庫裝入數(shù)據(jù)的查詢后的輸出結(jié)果。由于使用全部10億個(gè)數(shù)據(jù)點(diǎn)，右邊這張圖耗時(shí)71分鐘才完成，而左邊這張圖只使用100萬個(gè)數(shù)據(jù)點(diǎn)，只花了3秒鐘就完成！當(dāng)然，左邊這張圖相比右邊的***版本有點(diǎn)模糊。但要想一想：這么做值不值得？不用等待71分鐘，你立即可以獲得幾乎一樣的答案，然后決定是否想再等71分鐘獲得完整的答案，還是不等了，去做其他事情！

這肯定不是一個(gè)新想法！實(shí)際上，所有的Web瀏覽器已經(jīng)在這么做。下次你試圖在瀏覽器上加載高分辨率圖像時(shí)，注意Web瀏覽器如何先試圖加載和顯示一個(gè)模糊的圖像，圖像逐漸變得越來越清晰。但是將同樣的原則運(yùn)用于數(shù)據(jù)庫和SQL查詢處理卻鮮為人知。

于是，現(xiàn)在你可能有幾個(gè)問題：我們實(shí)際上如何獲得這種提速？即便你的數(shù)據(jù)分布呈偏態(tài)，這一招管用嗎？你仍看到異常數(shù)據(jù)？你需要使用特定的數(shù)據(jù)庫來享用速度和準(zhǔn)確性之間這種類型的取舍嗎？我會在文章末尾回答所有這些問題，但我先說說另外幾個(gè)場景，你可能發(fā)覺同樣這個(gè)想法很有吸引力：立即見到準(zhǔn)確性達(dá)到99.9%的結(jié)果，但速度要快200倍！

場景2（超載集群）——與如今的大多數(shù)數(shù)據(jù)庫用戶一樣，你可能沒有一個(gè)集群專門供自己使用。換句話說，你與你的團(tuán)隊(duì)共享集群，甚至共享其他報(bào)表和商業(yè)智能工具。這些工具對同一個(gè)共享的數(shù)據(jù)庫資源池執(zhí)行SQL查詢。如果這些共享的集群超載，實(shí)際上就會發(fā)生下面三種情況中的一種：

A.全面沮喪。你什么都沒做，任由每個(gè)人遭受一樣的痛苦。換句話說，一旦數(shù)據(jù)庫查詢積壓，CPU核心處于滿載狀態(tài)，沒人能夠足夠快地完成查詢。

B.局部沮喪。你做得比較巧妙，終止或暫停優(yōu)先級較低的查詢，讓更緊迫的查詢（比如你經(jīng)理的那些查詢）先完成。換句話說，你確保幾個(gè)更重要的人滿意，但是讓其他人很生氣！

C.如果這種情況頻繁發(fā)生，可能要購買更多更大的服務(wù)器，或者遷移到云端，按需要啟用更多的節(jié)點(diǎn)。當(dāng)然，這種方案要花一定的費(fèi)用，也不方便。另外，它也通常不是短期的解決辦法。

大多數(shù)人沒有認(rèn)識到的一點(diǎn)是，還有第四種方法比前面兩種方法更好，而且不像第三方方法，也不要你花錢。那么這種方法是什么呢？第四種方法如下：

為低優(yōu)先級查詢返回99.9%準(zhǔn)確的答案，為其余查詢返回100%準(zhǔn)確的答案！這之所以可行，是由于按照統(tǒng)計(jì)定律，你只要使用0.1%的數(shù)據(jù)和處理，通常就能獲得99.9%準(zhǔn)確的答案。這就是為什么犧牲0.1%的準(zhǔn)確性意味著，實(shí)際上速度可以提升100倍至200倍。我知道沒人想要湊合著使用99.9%的準(zhǔn)確性，但是你需要考慮其他的選擇：終止查詢，被列入長長的等待名單，或者無所事事，等待查詢完成。正如我在場景1下提到的那樣，在許多情況下，你仍可以獲得完整的答案，在等待完整答案的同時(shí)就使用99.9%準(zhǔn)確的答案。我會在文章末尾回過來探討“如何實(shí)現(xiàn)”的問題。不過眼下，記?。?9.9%的準(zhǔn)確性并不意味著你錯(cuò)失0.1%的輸出結(jié)果。通常你仍看到一切，但是實(shí)際數(shù)字可能偏差0.1%，這意味著在大多數(shù)情況下，你甚至看不出區(qū)別所在，除非你確實(shí)瞇著眼在打量。比較這兩個(gè)圖：

這些是使用著名的紐約市出租車數(shù)據(jù)集，詢問打車到鬧市區(qū)所用總時(shí)間的查詢輸出。

你能區(qū)別哪個(gè)是100%準(zhǔn)確的答案，哪個(gè)是99.9%準(zhǔn)確的答案嗎？在大多數(shù)人看來，這兩個(gè)一樣。但是上面那個(gè)查詢只花了1.7秒，而下面這個(gè)查詢卻花了42.7秒。這意味著，若犧牲0.1%的準(zhǔn)確性，你的CPU時(shí)間可以節(jié)省25倍！不妨談?wù)?**一種場景，然后我會告訴你“如何實(shí)現(xiàn)”這部分。

場景3（機(jī)器學(xué)習(xí)和數(shù)據(jù)科學(xué)）——如果你是機(jī)器學(xué)習(xí)專家或數(shù)據(jù)科學(xué)家，會常常發(fā)現(xiàn)要訓(xùn)練統(tǒng)計(jì)模型、調(diào)整參數(shù)，或者做一些特征選擇和工程。這方面最常讓人沮喪的問題之一是，你需要嘗試大量的參數(shù)或特性，而訓(xùn)練機(jī)器學(xué)習(xí)模型要花很長時(shí)間。集群不斷忙于訓(xùn)練和測試不同的模型，這就限制了數(shù)據(jù)科學(xué)家可以試用的一組不同模型和參數(shù)，或者至少減慢了這個(gè)過程。

在許多應(yīng)用中，你不需要完全準(zhǔn)確的答案，就能做出相當(dāng)合理的決策。A/B測試、根源分析、特征選擇、可視化、噪聲數(shù)據(jù)或值缺失的數(shù)據(jù)庫都屬于這種情形。只有你是計(jì)費(fèi)部門的人，才不想要這么做！

我可能會寫另一篇文章來介紹如何加快參數(shù)調(diào)整或特征選擇。

但是我們“如何”才能讓查詢加快200倍，但又只犧牲一點(diǎn)極小的準(zhǔn)確性？

答案在于一種名為近似查詢處理（簡稱AQP）的技術(shù)。有不同的方法來實(shí)現(xiàn)AQP，但是最簡單的辦法是使用表的隨機(jī)樣本。結(jié)果是，如果你的數(shù)據(jù)呈偏態(tài)，你不想使用隨機(jī)樣本，因?yàn)檫@會錯(cuò)失可能存在于原始表中的大多數(shù)異常數(shù)據(jù)和罕見項(xiàng)。所以，實(shí)際上更常見的是一種名為“分層樣本”的樣本。分層樣本是什么？不妨看看下面這張圖：

假設(shè)你想對這個(gè)表運(yùn)行下列查詢：
SELECT avg(salary) FROM table WHERE city = ‘Ann Arbor’

當(dāng)然你可以運(yùn)行這個(gè)查詢，但是如果這個(gè)表有數(shù)億行，或者它跨多個(gè)機(jī)器來分區(qū)，可能要好幾分鐘才能完成。相反，你可以決定只對表的隨機(jī)（即統(tǒng)一）樣本運(yùn)行查詢，比如說：    

正如你所見，由于Ann Arbor元組相比原始表中的NYC元組很罕見，你很可能在樣本表中很少看到Ann Arbor或根本就看不到。相反，分層樣本會先根據(jù)City對表進(jìn)行分層（即分區(qū)），然后隨機(jī)采樣顯示每個(gè)城市的行：
ID　 City　　   Age　 Salary　　Sampling Rate
3　　NYC　 　  67　　62,492　　1/4
***nn Arbor   25    120,242   1/2

結(jié)果發(fā)現(xiàn)，不用深入分析統(tǒng)計(jì)數(shù)據(jù)，諸如此類的分層樣本會確保：通過處理一小部分的原始元組，你就能獲得非常高的準(zhǔn)確性。

現(xiàn)在，下一個(gè)問題是如何創(chuàng)建這些樣本？又如何衡量準(zhǔn)確性？有自動(dòng)方法可以這么做。市面上有幾款產(chǎn)品，可以用來隱藏這種復(fù)雜性，那樣你只要摁一下按鈕，它們就會幫你從頭搞到尾，以極快地速度返回答案，有一些甚至為你提供旋鈕，只要轉(zhuǎn)動(dòng)旋鈕，就可以決定想要多高的準(zhǔn)確性以換取多快的提速。

BlinkDB / G-OLA
雖然外面有許多AQP方案，但是BlinkDB可能是***個(gè)成為開源項(xiàng)目的分布式（大規(guī)模并行）AQP引擎。本著完全披露的精神，我參與這個(gè)項(xiàng)目，所以我在這里可能有偏見，因?yàn)槲掖_實(shí)很喜歡BlinkDB的方法，我認(rèn)為它確實(shí)影響了后面介紹的許多學(xué)術(shù)方案和行業(yè)方案。Databricks（商業(yè)化Apache Spark的公司）在繼續(xù)開展BlinkDB方面的工作。Databricks不久前宣布了BlinkDB的擴(kuò)展方案，將逐步完善其查詢答案，直至用戶滿意為止。這個(gè)擴(kuò)展方案名為G-OLA。G-OLA之前從未公開發(fā)布過，BlinkDB有好長時(shí)間沒有更新了。

SnappyData
SnappyData是一種開源內(nèi)存混合分析平臺，它在一個(gè)引擎中提供了OLTP、OLAP和數(shù)據(jù)流（Streaming）。數(shù)據(jù)庫引擎本身是通過擴(kuò)展Apache Spark而構(gòu)建的（因而它與Spark全面兼容）。內(nèi)存核心還通過精選的分層采樣及其他概率結(jié)構(gòu)提供了AQP。查詢語法類似BlinkDB，這讓用戶可以指定所需的準(zhǔn)確性。這意味著你可以把準(zhǔn)確性當(dāng)作可調(diào)節(jié)撥盤。比如，如果你想要準(zhǔn)確答案（這是默認(rèn)行為），可以要求100%的準(zhǔn)確性；但如果想要快速的答案，也可以在一秒左右的時(shí)間內(nèi)獲得99%準(zhǔn)確性的答案。在我看來，SnappyData的一大優(yōu)點(diǎn)是，它使用精選的分層樣本。這意味著，你可以在幾秒內(nèi)運(yùn)行分析查詢，即便是在查詢數(shù)TB的數(shù)據(jù)，在筆記本電腦上運(yùn)行，或者在共享集群中運(yùn)行（有另外眾多并行查詢）。它還內(nèi)置了支持?jǐn)?shù)據(jù)流的功能，這讓你可以構(gòu)建樣本，并且實(shí)時(shí)更新樣本，以響應(yīng)入站數(shù)據(jù)流。

SnappyData的另一個(gè)出色功能是，它隨帶許多高級用戶接口，這意味著你不需要精通數(shù)據(jù)統(tǒng)計(jì)，就可以使用其AQP功能。比如，現(xiàn)在它有一種免費(fèi)的云服務(wù)iSight，它使用Apache Zeppelin作為前端，以便在后臺運(yùn)行完整查詢的同時(shí)，立即顯示查詢響應(yīng)。

Presto
Facebook的Presto有一項(xiàng)試驗(yàn)功能，可以近似處理基本的聚集查詢。我其實(shí)不知道***版本是不是擁有這項(xiàng)功能，但缺點(diǎn)是，你不得不使用不同的語法（即修改SQL查詢），那樣才能調(diào)用那些近似聚集功能。如果你有現(xiàn)有的商業(yè)智能工具或應(yīng)用軟件并不使用這一種特別的語法，那很麻煩，因?yàn)樗鼈儫o法得益于潛在的速度提升，除非對它們重寫，以便可以使用這種新的語法。

InfoBright
InfoBright提供了近似查詢功能（名為IAQ）。不像其他系統(tǒng)，IAQ根本就不使用樣本。遺憾的是，近似功能如何工作，它們提供什么樣的準(zhǔn)確性保證方面公布的細(xì)節(jié)不多，不過在看了其博客后，我認(rèn)為他們在構(gòu)建底層數(shù)據(jù)的模型，并使用那些模型來回答查詢，而不是使用樣本。我也不是很了解IAQ，因?yàn)樗皇情_源，我在其官方網(wǎng)站上也找不到許多詳細(xì)信息，不過聽起來它像是一種值得關(guān)注的方法。

ABS
分析引導(dǎo)系統(tǒng)（ABS）是另一種近似查詢引擎，它使用樣本和高效的統(tǒng)計(jì)方法，以估計(jì)誤差。***代碼有點(diǎn)過時(shí)了，只適用于Apache Hive的早期版本。這個(gè)項(xiàng)目目前不活躍。

Verdict
Verdict是一種中間件，介于你的應(yīng)用程序或商業(yè)智能工具與后端SQL數(shù)據(jù)庫之間。你只要對現(xiàn)有數(shù)據(jù)庫執(zhí)行與以前一樣的查詢，立即就能獲得近似的答案。原則上，可以將Verdict與任何SQL數(shù)據(jù)庫結(jié)合使用，這意味著你不會受制于任何特定的數(shù)據(jù)庫管理系統(tǒng)（DBMS）。但目前，它只隨帶面向Spark SQL、Hive和Impala的驅(qū)動(dòng)程序。優(yōu)點(diǎn)在于，它是通用的，可以與任何SQL數(shù)據(jù)庫兼容，而且是開源的；缺點(diǎn)是由于它是中間件，可能不如InfoBright或SnappyData等一些商用解決方案來得高效。

Oracle 12C
Oracle 12C推出了approximate count distinct和近似百分比功能。這些近似聚集提升了性能，計(jì)算時(shí)少占用內(nèi)存。Oracle 12C還提供了物化視圖支持，那樣用戶甚至可以預(yù)先計(jì)算近似聚集。雖然近似百分比和count distinct查詢大有用處，實(shí)際上也很常見，但是并不廣泛支持其他類型的查詢。但是考慮到Oracle的龐大用戶群，連這些有限的功能也會讓許多用戶從中得益。不過，據(jù)我所知，其他許多數(shù)據(jù)庫廠商長期支持approximate count distinct查詢（比如使用HyperLogLog算法）。

原文標(biāo)題：How To Make Your Database 200x Faster Without Having To Pay More?，作者：Barzan Mozafari

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】