本文根據digoal(德哥)在〖2017 Gdevops全球敏捷運維峰會成都站〗現場演講內容整理而成。

講師介紹

digoal(德哥)，現任職於阿里雲資料庫核心技術架構組。PostgreSQL中國社群發起人之一、常委、兼任社群大學校長，PostgreSQL中國社群杭州分會會長，PostgreSQL中國社群大學發起人之一。14項已授權專利。樂於分享，撰寫技術類文章幾千餘篇，狂熱技術分子，致力於PostgreSQL資料庫在中國的技術推廣與人才教育。

“超體”這個例子來源於一部電影，電影中探討當人的腦細胞被開發到100%的時候會達到一個什麼樣的現象。同樣的，今天我們以PostgreSQL為例，看看當資料庫被開發至100%會產生什麼，是不是可以解放程式猿的雙手，節約50%的開發時間去撩妹？(￢∀￢)σ

20%

1、物聯網、金融、日誌、運營商網管、行為軌跡類資料

20%的時候會是什麼樣子的？先來看一個場景，現在非常流行物聯網的場景，包括金融、運營商閘道器，還有電商，然後很多的一些O2O的平臺採集使用者的資訊。因為每一次手機上的操作，點選都會記錄下來，以便後面做一些使用者行為挖掘的動作。那麼這些資料有什麼樣的特徵？

行為資料的特徵包括追加寫，不停地寫入，同時在時間和維度上跟你的堆儲存存在一定的線性關係。行為資料的資料量是很大的，一個業務的日記錄數以億到百億記。

查詢需求方面，需求方可能需要查一個群體性資料在某一個時間點發生的行為，這是時間區間查詢的需求。第二個查詢需求可能是分析需求，比如群體性的特徵分析，這麼大一個數據量的情況下，會要求插入快，因為插入慢的話就有丟資料的風險（就像網路丟包一樣，可能導致重傳和擁塞，影響使用者體驗）。

儲存的要求，要支援壓縮，比如說我插的資料這麼大的量不能壓縮，在成本上可能是扛不住的，業務方想保留一年的資料，壓縮與不壓縮成本可能相差好幾倍。

資料種類的需求。隨著物聯網的發展，終端採集的資料越來越多樣化，傳統的數字、字串、時間是比較常見的，現在可能還會加入更多的型別，比如定位的資訊，而且事件的發生有時間和空間的維度在裡面，越來越多的使用者需要支援更多的資料型別。

2、PostgreSQL塊級別索引– BRIN

我們看一下檢索，假設一天產生幾十個G的資料，使用者想找到12點前後五分鐘的資料在哪裡，但想一想一天幾百個GB的資料，索引有多大呢，那麼什麼方法可以減少索引的大小？

在這裡可以使用塊級儲存，比如一個數據塊是一兆，這一兆的資料裡面覆蓋了某個欄位從幾點到幾點的資訊，塊級索引只需要儲存邊界值、COUNT、SUM等資訊，所以塊級索引會變得很小很小。使用了塊級別索引後你耗費的空間相比原來下降幾百倍，如果一個數據塊可以存兩百條記錄的話，你的索引會變成是原來兩百分之一那麼小，而檢索的速度是沒有受到影響的（前提是被索引的欄位資料的邏輯順序與對儲存的物理順序有線性相關性）。

從圖上看單步插入的速度，比原來使用快了很多。

接下來我們看一下看壓縮的需求。壓縮這一塊，其實有很多的演算法，有有失真壓縮（旋轉門壓縮）和無失真壓縮（列儲存：瓦片式/內建/FDW/IMCS）。比如說旋轉門的壓縮，這個是來自於一個做電力的監控系統：

一個發電廠有很多的感測器，這些感測器每十毫秒就上傳一個數據，資料量是非常龐大的。這裡有一個旋轉門壓縮轉盤，在這個資料庫裡面可以寫一個UDF實現一個同樣的功能。剛剛講的這個功能，有一個非常典型的應用就是在阿里的菜鳥中有一個跟蹤系統有用到這個產品裡面的特性。

第二個場景為搜尋類、多維度互動類的場景。比如說淘寶前端的頁面，我們在做一些搜尋的時候，我要找銷量大於多少的，還是按照店鋪名稱找，還是按照商品名找，或者是按照商品的地區搜尋等等。我們在搜尋時有很多選擇，但表設計好之後有幾十個欄位，每個欄位都有可能是客戶選擇的選項，如果是針對每一個欄位建索引的話，雖然你滿足了使用者的需求，但是會帶來很大效能的插入和更新效能的損耗。同時使用者可能是按照某一個欄位做模糊的搜尋。

在PostgreSQL資料庫裡面可以幫你做這件事情，它的原理非常簡單，就是通過這種倒排的方法做索引（GIN），還有其它的方法比如通過空間索引(GiST)，通過這種方法可以實現任意欄位的檢索。

現在許多開發者會使用JSON存取資料，當設計之初，也許無法固定結構設計，那麼可以用到PostgreSQL的JSON的資料型別，JSON內容的檢索與普通欄位的檢索方法一樣，同樣支援模糊查詢。

典型的使用者：在阿里裡面一個是淘系使用者，這個任意欄位檢索的特性用得比較多。還有萬網和阿里雲的官網。最後一個是相似的搜尋，比如說一篇文章裡面涉及到一百個商品，別人寫的文章裡面涉及50多個商品，你跟他有40個是重疊的，怎麼搜出來？這個是通過相似索引搜出來的，它達到的效果也是很高的，可以在幾個毫秒之內就在上億的資料裡面幫你搜索出與你提供的資料相似的資料。

3、高效率範圍查詢

再看看第三個場景——範圍資料。範圍資料出現最多的地方是物聯網。在物聯網裡面它的感測器要不停上報資料，但是比如說一些溫度感測器，或者是溼度等等指標的感測器，它的範圍波動是很小的。像電壓的波動，可能一直就在220左右波動的，假如一個小時上來的資料全部在這個範圍內波動，實際上在後臺根本沒必要每一個值都存下來，我可以直接存一個範圍，假設你的偏差精確到99.9%在業務上是可以容忍的，這時候我完全不需要把每一個精確的值存下來。

存取範圍，涉及到範圍型別，也是一個比較有趣的特性，比如說1到2，這種數值經常做什麼樣的檢索呢？今天所有的感測器上報的資料裡面，哪些是100-200之間的資料，按照原來的設計兩個欄位索引做搜尋，是可以實現的，但是效率比較差，如果使用範圍索引來做的話，實測效能提升20多倍。GiST對範圍資料做聚類劃分，搜尋時可以快速定位到需要搜尋的範圍。

範圍資料型別，典型應用場景是物聯網，以及智慧DNS。智慧DNS會根據你IP的來源落到某一個範圍裡，再去索引你到最近的庫裡面去。

接下來講一個比較有意思的場景，求資料差集，用到資料庫的遞迴查詢特性。比如說一張表是一億資料的，用車輛ID這個場景說明。業務背景是商用車輛的軌跡跟蹤，在一家企業裡面，假設有一百萬輛商用的車輛，一天可能上傳幾億的軌跡資料上來，但使用者想查今天沒有出勤的車輛，怎麼查？使用遞迴的方法可以做到0.幾毫秒，也是非常有意思的事情。而傳統的方法，使用left join，需要幾秒。

遞迴查詢，典型的使用者比如說區塊鏈，還有ERP系統裡面有很多的關係，特別是一個大資料，小資料的清洗。

40%

當資料庫發揮到40%功能的時候看一下是什麼樣的。

1、資料庫端程式設計

我們用傳統的方法去寫一個應用時，肯定就是讓資料庫做該做的東西，我要的時候告訴你要查出什麼樣的資料，但是一來一回，耗費在網路上的開銷就變得特別大。特別是在銀行這種系統裡面，開戶一開就是1個小時過去了，裡面可能跟資料庫互動多少次，那如果說這個時候你把這個程式邏輯寫到資料庫裡面去的話，實際很多場景裡面也在用的，特別是銀行這些事務處理非常複雜，同時要求資料可靠性、一致性很高的場景用得比較多。所以實際上儲存過程在銀行、運營商用得比較多。

一種方法是在外面用程式做，跟資料庫互動若干次，另一種方法是跟資料庫互動很少的次數，就是你把邏輯放到資料庫中，我們來看一下可以達到什麼樣的效果？

我們測試過萬兆網的場景，做事物的處理，20條Query使用互動式的方式，還有使用邏輯全部放在資料庫這一端做的，他們出來的差別可以看一下，使用邏輯資料庫可以達到100萬的QBS，如果把資料庫放到雲端的不同主機的話，資料庫延遲可能更大，所以如果業務對延遲響應苛刻、並且業務邏輯允許的情況下，建議你放到資料庫裡面。

2、非同步訊息

問大家一個問題，當你要監控上萬臺，或者幾十萬臺裝置時，你後端需要多少個數據庫？也是跟網際網路的感測器一樣，你有若干個監控指標，每一個裝置每一秒可能會產生上千個指標，傳到你的資料庫裡面去，當資料有異常的情況，通知服務端，這就是非同步訊息所在。資料不停往資料庫裡面插，發現有異常的時候，就通過非同步訊息告訴程式有異常，通過這種方法可以做到百萬的NVPS，這是一個數據庫可以做到的。然後硬體的話實際上也是用普通的X86場景。後面會詳細的講這個流式計算的功能。

這個是基於地理位置放了很多的感測器，這些感測器不停地上報資料，這些資料發生異常時，就告訴你這裡發生異常了，通過非同步的方式來實現。

3、資料泵

資料泵也是有意思的場景，特別是在一些歷史悠久的企業裡面，各種資料庫都有，這麼多的資料庫或者資料產品，他們要共享資料怎麼辦？最開始我的資料往關係資料庫裡寫的，但是如果要共享給其它的平臺，怎麼樣實時地分享？那就用資料泵，這個東西就是資料庫內建的一個訊息佇列的外掛，通過REDO的結合實時對外分享資料。

4、天文、地理

另外一個是現在需用到非常多資料的，特別是像O2O的產品，或者是基於位置的產品，商用車的管理、危化品車管理等。比如說一個綜合體裡面可能每一層都會有商鋪，實際上有很多的產品是有這個定位功能的，但是他現在只有高度，我在手機上搜索的時候，能告訴你所在層有哪一些商鋪。PostGIS是一個空間資料管理外掛，可以高效的儲存多維度資料。

比如基於這個位置附近搜人，最近我們菜鳥做效能跟蹤時，最後壓出來的結果讓我們很驚訝，PostGIS壓出來的效能比Redis好400%。但它差在什麼地方呢？它就差在索引的效率上面，所以最後菜鳥選擇了使用這個來做軌跡系統。

除了民用場景，在軍工和科研方面，還要存三格資料等等一系列的資料。許多從網際網路發展起來的資料庫產品不會考慮這些場景，但是PostGIS來自高校的，有比較深的科研背景，因此這一塊應用非常的廣泛。幾乎全球的宇航局、導航系統、氣象系統、天文研究、軍工方面涉及空間資料的場景，都在使用PostGIS。

這個是十二生肖的3D資料，實際上給一個物品做3D的掃描，3D掃描之後除了每一個位置資訊之外，還有屬性如材質、顏色等，這裡面存的不僅僅是位置資訊，還有其它的屬性在裡面，通過pgpointcloud可以把這些掃描值存到一個物件裡面。

最後還有一個特別重要的功能就是路由的功能，從A到B怎麼樣提供最優的路徑出來，在行進過程中不斷優化你的路徑。典型的應用場景，比如說物流等。

60%

1、流式處理

流式處理的話，剛剛提到了是監控的場景。流式處理每一條上報的監控 ，如果有異常的話，通過非同步訊息的方式來通知我們的應用程式。另一個非常有趣的例子，就在近日，三體高層架構發起的一次PCC效能大賽，場景是涉及到Facebook的關係，Like的場景，可以查到某一篇文章被Like的次數，或者是查出某一篇文章Like的好友中哪些是我的好友。這個關係說很繞，比賽的設計的目標是30萬的請求被Like的次數，還有被哪些人Like。使用流計算的話，查到某一篇文章被Like的次數，查被哪些人Like，均可以達到100萬的QPS，查出某一篇文章Like的好友中哪些是我的好友可以達到70萬的QPS，超出設計目標，而僅僅使用了PostgreSQL的一個流計算功能。

2、Zabbix

流計算與非同步訊息結合，可以達到什麼樣的效果呢？如果拿Zabbix來做流式監控的話就可以用這種方法。Zabbix原生是主動的詢問方式來了解是否發生了異常，很浪費資源。使用這種非同步機制，僅僅在真正有問題的時候，才會通知客戶端，大大減少了主動問詢的無用功開銷。

3、網狀關係搜尋應用、金融風控、公安刑偵、社會關係、人脈分析

這裡提到了一個關係的圖示查詢，這個的話之前也寫過一篇這樣的文章，寫得比較詳細，就是使用PostgreSQL怎麼樣做圖式搜尋。我測了一個一千億的關係，一億的使用者，每個人有一千條邊關係，達到的效能是什麼樣的，查兩個人最短關係路徑的時候，要看關係路徑有多遠，比如說4級以內的話在秒級以內響應，查詢N度人脈則可以做到毫秒級的響應。

4、相似內容判定、按標籤圈人

再看一下相似判斷，場景是導購平臺。現在我有上億的導購的文章，每一篇文章對應一些導購的商品，當有新的使用者發導購文章的話，我得確保他沒有盜文，也就是說必須找有沒有相似的導購文章，這個事情通過PostgreSQL來解決。

5、影象識別、AR紅包

圖象識別比較有意思，你只要把影象的特徵傳入到資料庫裡面，資料庫就可以幫你做這件事情。只要實現GIN或GIST索引裡面特定的幾個介面就可以使用索引來檢索相似的圖片，包括影象相似挖掘也是這樣的。這個效率也很高，我有測過大概是五千萬的圖片，查詢相似的圖片可以做到毫秒級的響應。

這個應用場景是比較有意思的，特別是現在興起的圖搜，在看電視劇時發現包包挺好看的，拍下來搜一下，這個搜一下的過程就是採集這張圖片，然後把它的特徵值根據資料庫反饋給我，告訴哪一個店在賣這個產品。

6、Real Sharding（無限制Sharding）

很多資料庫支援Sharding，但是並不是特別的完美，Sharding後的使用體驗與單機版本會不一樣。這也不能，那也不能，就像你原來的資料庫被閹割了一樣，對很多人來說很不爽。原來做什麼都可以，現在Sharding是不能這樣乾的，而PostgreSQL 10推出之後，在Sharding這一塊有特別多的增強。10做了幾件事情，一個是pushdown，就是在下面的資料庫裡面計算，所以可以幹跟原來一樣的事情，跨節點交易也是可以做的，包括一致性備份等等。

另外是多副本，基於事務這個級別，比如說A事務涉及到使用者的賬目資訊，要保證兩個副本才可以告訴寫成功。而如果你這個事物是日誌型的，要求RT比較低的，這時候你只要告訴他落到本地就可以的，這時候只需要寫一個副本。這個多副本的功能設計得非常靈活，可以滿足混合場景的需求。

80%

1、機器學習庫（MADlib）

再往後80%可以做機器學習，MADlib這個庫是MIT與Pivotal共同研發並開源的一個機器學習庫，使用起來是SQL的介面。你需要告訴它（UDF）訓練集表是哪個，輸出訓練結果到哪裡，使用什麼演算法等。比如說做資料的分析，關健詞的分析等等都可以做。

2、基因資料處理（存、取、檢索；型別、索引、操作符、函式、UDF）

化學物品也可以儲存在資料庫中，在資料庫中可以模擬化學品的合成，化學品的分析，約束等。

3、融合

融合是指將不同的資料來源打通，PostgreSQL的FDW介面，可以訪問世界上幾乎任何一種的資料來源，只要建立一個外部表就可以訪問外部資料了，訪問介面依舊是SQL介面。

FDW在雲端有什麼樣的用處？雲端很多的資料是以很多其他的形式存在的，比如說阿里有一個物件的儲存OSS，把歷史的資料用來做分析，不需要每時每刻查，這些資料做的操作全部是分析型的操作，我們把這種資料存到OSS裡面，這時候資料庫本身的儲存可以縮小，可以壓縮你的成本。

100%

最後100%這裡要表達的意思是你可以想象的功能都可以拓展出來。最後幾頁PPT是阿里雲的一些比較大的客戶經典的應用場景。比如說這個場景是做網路軌跡分析的，它的資料量達到幾百T，有大量資料存在OSS物件儲存裡面，RDSPostgreSQL與HybridDB PostgreSQL連線OSS的通道是並行的，比如說HybridDB PostgreSQL有一百個節點，每一個節點都可以訪問OSS，在做分析處理的時候，吞吐可以做到非常大。做到了計算與儲存的分離。

上面藍色和灰色的方框是說這個資料庫的計算能力有哪一些，能幹什麼事情，下面是資料庫的計算單元，再下面就是你外部儲存，你資料可以存在計算單元裡面，也可以儲存在OSS物件儲存裡面，取決於資料的熱度。當分析好之後，資料可以迴流到OLTP資料庫中。

計算與分離，除了成本上的優勢，另一個好處是擴容顯得更加從容，因為不再需要move資料了。

最後這張圖表示，資料的入庫通道，對應的頻寬和時延，使用者可以根據實際的需求選擇資料的通道。

Q&A

Q1：比如說我自拍一個再找相似度，是不存在的，會如何？

A1：關於圖片相似度的查詢，查詢條件中可以設定相似度的閾值，如果你拍的圖片根本不存在的話，通過閾值就可以排除，也就是說查詢不到結果。不管有沒有結果，都是走索引的，所以效率非常高。

Q2：把邏輯存放在資料裡面，資料庫伺服器的負載有時候併發量大的時候，負載是不是承受不起？

A2：不管邏輯放在資料庫裡面還是外面，負載取決於業務量，而業務的增長是可以預估的，不會說突然就暴漲（除了搞活動，但是也能預估），我們回到邏輯放到庫裡面的那張圖，達到的TPS實際上是更高的，如果邏輯在資料庫外面10萬的成本達到30萬TPS，同樣的成本放到資料庫裡面可以達到100萬的TPS，實際上放在外面時引入了更多的損耗，所以你怎麼看待這個問題呢？10萬塊錢已經幫你做了30多萬的事情。

文章來自微信公眾號：DBAplus社群