資料庫的未來-HTAP，軟體、硬體、雲生態的融合

標籤

PostgreSQL , GPU , FPGA , CPU , TPU , PL/language , 科研 , 嵌入式計算 , UDF , CUDA , 資料庫嵌入式程式設計 , 流式計算 , 科學計算 , 軟硬一體 , PostGIS , 點雲 , 開發者生態 , python library , CRAN , R

---

背景

資料庫經過了幾十年的發展，未來的路怎麼走？從硬體、軟體技術的發展，結合業務的需求出發我們可以從中看出一些端倪。

一、資料型別多樣化

隨著技術的普及，越來越多以前需要很高的成本才能獲取的資料，現在觸手可及。

1. 點雲（點的位置座標+RGB+其他屬性），以前只有軍用領域在使用，比如《普羅米修斯》這部電影，通過一些小的飛行器（點雲感測器裝置）飛入未知的通道後，傳回獲取的點雲資料，從而構建通道的全系影像。

現在民用領域，也有很多點雲的類似應用。例如：掃地機器人，無人車，消防（探測房屋結構），VR（通過點雲資料構建全息影像）等等。

2. 氣象資料 （位置、日照、溫度、雨量、風量等），氣象資料往往是柵格型別的資料，一個柵格包含了一片區域的日照、溫度、雨量、風量等資料，柵格可以切分和聚合。

氣象資料的有非常多的用途，例如：

光伏電廠的選址，需要分析某區域某個時間段，日照資料統計。

多個柵格的資料聚合，或者一個柵格資料的部分擷取等。比如一個包含了浙江省的柵格資料，如果只需要杭州市區的資料，那麼可以在讀取時將杭州的區域切分出來。

在時間維度上分析，在地理位置維度上分析，在其他屬性維度分析，多個維度的分析。

生成時序動態圖等。

歷史柵格資料不斷的積累，不停的上傳新的資料使得歷史資料越來越多。

3. 地震資料（高頻波，傅立葉變換），地震資料是一些包含了地理位置屬性的XYZ三個方向的高頻波形資料，收到資料後，需要對其進行快速的資料轉換，預測和告警。

同時還需要對歷史的資料進行挖掘。

4. 天文資料（尋天，星系，軌跡比對），從古至今，人類一直沒有停止對外太空的探索，天文臺就是一個最為直接的探索外太空的裝置。

有一個專案叫“尋天”，每天這些望遠鏡需要對天球座標進行全方位的拍攝，拍攝的資料以柵格型別存入資料庫，以備後續的分析。比如定址超新星，尋找類太陽系等。其中尋找類太陽系就需要對單個柵格的多個歷史資料進行比對，通過行星執行軌跡對光線造成的細微影響找出類太陽系的星體。

涉及到大量的時間、空間維度的運算。

5. 室內定位（孤立座標系、相對座標系），實際上現在室內定位也非常的成熟了，例如你站在某個商場中，商場有若干個WIFI熱點，只要你的手機開啟了WIFI，那麼通過3個WIFI熱點與你的手機之間的訊號強弱，就可以定位到你的位置。除了通過WIFI進行定位，還有磁場、聲波、視覺等定位方法。定位後，資料以座標+誤差範圍的形式存入資料庫，這個座標是相對座標。

室內定位有什麼商業用途呢？例如可以獲取某個時間點的人群分佈，哪個商場或者站臺附近聚集了人群，進行營銷效果的挖掘。

又比如，在時間+空間維度上，統計分析人流量，平均的駐留時間等。

6. 室外定位（定位方法：GPS、基站訊號強弱等），人群踩踏事件預測，非法聚眾預測，事件預測，某個位置的人群駐足時間（廣告效應報告）等。

7. 生物型別、化學型別、影像特徵型別、IOT的發展衍生了更多的資料型別。

8. 其他，民用，軍用

還有那些喜聞樂見的應用，o2o, 地圖, 導航, 位置交友, 都帶有很強的時間、空間、業務資料屬性。

面向這麼多的軍用轉民用技術，民用的軟體技術有沒有準備好？資料庫有沒有準備好接招呢？

二、查詢維度多樣化 – 時間、空間、業務等維度 – 儲存與計算的挑戰

1. 業務資料型別越來越豐富，例如大多數業務基本上都會包含空間資料。

2. 大多數的資料具備時序屬性，例如金融資料、物聯網感測資料、氣象資料、天文資料、地震監測資料等。

3. 資料查詢維度（篩選條件）越來越多，（時間、空間、業務維度等），例如

在2017-01-01 ~ 2017-02-01這個月，某個點附近方圓30公里發生的事件。

在某個時間段，所有區域發生的事件。

在某個時間段，某個區域，某些使用者發生的事件。

4. 資料的計算需求越來越複雜，參與計算的資料量越來越龐大，計算離資料太遠導致傳輸效率浪費。

越來越多計算下推的需求。

5. 業務對資料計算的時效性越來越高，越來越多的計算被前置（如流計算，資料清洗等）。

6. 業務對資料深度學習的需求越來越多，而計算與資料的距離使得效率低下。

傳統的儲存與計算分離，使得整體的計算效率偏低。越來越多的計算前置、計算下推需求，來提升儲存計算分離這種架構下的效率。

三、資料庫的認知

由於資料庫發展緩慢，並沒有跟上業務對資料庫的需求，大多數的處理邏輯、運算都通過應用程式來解決，甚至“沒有什麼問題是加一層不能解決的”使得資料離計算越來越遠，路徑的增加使得效率越來越低下。

這也使得大多數的人對資料庫的認知變成這樣的：

1、傳統資料庫

就是支援SQL介面的資料儲存。

儲存和計算分離，讓大多數計算在應用層實現。

2、因為資料庫的處理能力弱，設計時產生妥協

對業務分層，例如加入訊息佇列、流計算、K-V快取 等等，減輕資料庫負擔。

3、能耗比降低

分層越多，應用離資料越遠，路徑越長、能耗比越低。

4、傳統資料庫挑戰

資料型別、內建的函式、型別的操作符、支援更多型別的索引

支援更大資料量的儲存和計算

可程式設計能力，資料庫只有SQL介面是不夠的，SQL的功能有限

硬體的利用能力，有多少硬體資源，就能用多少硬體資源，絕不手軟。

軟體生態的對接，開發者構築了強大的軟體生態，如何更好的對接？

四、HTAP 的挑戰

綜合前面的分析，業務對資料庫的需求分為這幾個層面：

1、資源的有效利用

當使用者需要時（例如半夜跑報表），資料庫可以利用一切可以利用的資源(CPU多核GPU、磁碟吞吐、網路吞吐等)，快速的幫使用者完成請求。

2、資源的控制和隔離

如果滿足了條件1，那麼就會引發第二個問題，資源的隔離，例如A使用者正在跑報表，它把所有資源都用掉了，而有一些需要實時響應的業務可能因此受到影響。

類似Linux的CPU公平排程中的realtime 和 普通的程式，realtime程式在QoS時可以優先獲得CPU時間片，不受大量資源使用的干擾。

3、能耗比

這個很好理解，提高能耗比是高精尖的活。例如CPU向量計算指令的利用，光這一項就有可能提升10倍的資料分析效率。

4、天花板

不管怎麼優化，怎麼擴容，單機一定是有天花板的。所以除了發揮單機能力，還需要具備水平擴充套件能力。

5、軟體生態

開發者辛辛苦苦積累的LIB庫，例如python的科學計算library，R的CRAN等。

資料庫用的是SQL語言，沒有辦法與這些library對接。如何突破SQL的限制，對接開發者的生態，讓開發者用起來更爽。

每個行業都有各自的特點，每個行業都有對行業理解深厚的ISV（地頭蛇），每個行業都有各自的積累（開發框架、Lib庫等）。

例如

在科學計算這個領域，有很多的python, R, go, julia語言相關的第三方庫。這些行業第三方庫是開發人員、科研人員對行業的理解與積累。（這些科學計算Lib庫可能被廣泛應用於氣象預測、地震預測、金融等眾多行業。）

如果這些Lib庫可以與資料緊密的結合，大大的拉近了計算與資料的距離，直接提升計算效率並且降低了成本，開發人員一定會很高興。

<Python常用科學計算相關外部庫>

以往是這樣算（資料從資料庫拉取到應用程式，應用程式再對其進行計算）：

現在是這樣算（使用科學計算相關的Lib庫，就在資料庫裡面算）：

資料庫與程式開發語言、以及對應的LIB庫打通，是一件很美妙的事情。

除了開發者生態，還有一個不容忽視的生態圈，雲生態，也是未來資料庫需要對接的生態。讓資料庫和雲上資料可以無縫融合，是非常關鍵的。

例如阿里雲RDS PG與OSS物件儲存，就實現了無縫融合，使用者可以在資料庫中直接讀寫OSS，將OSS作為無限容量的儲存來使用，將歷史資料儲存到OSS，未來要分析時還可以直接進行讀寫。

6、硬體生態

以往大多數的軟體都是圍繞CPU在設計，但是現在已經邁入了計算密集型的時代，CPU正在逐漸的喪失市場核心的位置，GPU、FPGA、TPU等處理器正在逐漸的成為核心。

這些處理器都有對應的SDK，也會有對應的程式語言。

未來資料庫如何與這類硬體更好的整合，利用它們的計算能力，是非常重要的。

通常我們理解的計算單元就是CPU，然而隨著技術的發展，越來越多專業的硬體，例如顯示卡計算單元GPU，例如可燒錄，可程式設計的FPGA，還有隨著AI火起來的面向機器學習的定製晶片TPU。

谷歌硬體工程師揭祕，TPU為何會比CPU、GPU快30倍？

老黃嘔心之作，英偉達能憑藉Tesla V100技壓群雄嗎？

深入理解 CPU 和異構計算晶片 GPU/FPGA/ASIC 1

深入理解 CPU 和異構計算晶片 GPU/FPGA/ASIC 2

那麼資料庫能否跟上這波硬體發展的浪潮呢，或者說如何抓住硬體發展的紅利呢？

五、PostgreSQL HTAP之路

1、資源的有效利用

1、支援CPU多核並行

2、支援流式計算

3、精細鎖粒度，提高併發處理能力

2、資源的控制和隔離

1、PG有一個引數可以控制全域性並行度資源，控制並行查詢的CPU的使用率，例如伺服器有128核，分配給平行計算的限制到96。確保預留足夠TP資源。

2、PG可以在程式級進行資源控制(iops,cpu,mem,network,…)

PostgreSQL是程式模型，這方面可以結合docker, cgroup等手段實現資源的控制。

3、能耗比

1、程式碼優化，可以提高執行效率，從而提高能耗比。例如運算元複用。

2、LLVM -> 3~5x faster

PG 10已將JIT框架整合到核心中，未來會支援更多的運算元。

3、向量計算 -> 10x+ faster

目前通過VOPS外掛可以支援向量計算，利用CPU的向量計算指令，達到批處理的目的，大幅度提升OLAP效能。

4、列式儲存 -> 壓縮，更好的支援LLVM，向量計算

通過瓦片式儲存實現列存，或者通過FDW實現列存，例如cstore。

5、流式計算 -> smooth化，減少怠速開銷

伺服器即使不做任何運算，也要耗電，就像汽油發動機一樣，怠速時，也會費油。PostgreSQL通過pipelinedb外掛，實現流計算，可以有效的利用怠速的自有，從而實現高效的計算。

4、天花板

1、垂直擴充套件

CPU、GPU、FPGA 。。。

RDMA、BLOCKDEVICE、NETWORK

2、水平擴充套件

sharding – inherit, fdw, partition, proxy,…

MPP – citus, xl, GPDB

垂直擴充套件和水平擴充套件都有成熟的解決方案。

5、軟體生態

1、打破SQL語言侷限性，對接行業Lib生態 – 提升開發、執行效率，降低成本

PostgreSQL的PL框架實現了這一點，目前已支援plcuda, plpython, plr, pljava, plperl, pltcl, C等非常多的內建程式語言，（通過介面，還可以支援更多的地球程式語言）。

PLpythonu用法舉例

這個UDF用於獲取檔案系統的使用情況      
    
create or replace function get_fs_info() returns void as $$    
import os      
import statvfs    
phydevs = []      
f = open("/proc/filesystems", "r")      
for line in f:      
  if not line.startswith("nodev"):      
    phydevs.append(line.strip())      
  retlist = []      
f = open(`/etc/mtab`, "r")      
for line in f:      
  if line.startswith(`none`):      
    continue      
  fields = line.split()      
  device = fields[0]      
  mountpoint = fields[1]      
  fstype = fields[2]      
  if fstype not in phydevs:      
    continue      
  if device == `none`:      
    device = ``      
  vfs=os.statvfs(mountpoint)    
  available=vfs[statvfs.F_BAVAIL]*vfs[statvfs.F_BSIZE]/(1024*1024*1024)    
  capacity=vfs[statvfs.F_BLOCKS]*vfs[statvfs.F_BSIZE]/(1024*1024*1024)    
  used=capacity-available    
  plpy.notice(`mountpoint`,mountpoint,`capacityGB`,capacity,`usedGB`,used,`availableGB`,available)    
$$ language plpythonu;    

使用pl程式設計後，資料與計算水乳交融，效率大增。

2、打破資料孤島，對接雲生態。

雲端有很多非常便捷的服務，例如搜尋、MQ、SLS、CACHE、物件儲存、quickBI、訊息服務、訂閱…。讓資料庫和雲上資料可以無縫融合，是非常關鍵的。

阿里雲RDS PostgreSQL與OSS物件儲存，實現了無縫融合，使用者可以在資料庫中直接讀寫OSS，將OSS作為無限容量的儲存來使用，將歷史資料儲存到OSS，未來要分析時還可以直接進行讀寫。

3、開放介面

開放型別、操作符、函式介面，開放索引介面，開放資料掃描介面，…

支援多樣化的資料型別（包括存取、搜尋、處理、UDF等多方面），再也不用擔心有不支援的型別了。

4、開放SQL流計算介面

有效利用伺服器的怠速開銷。

6、硬體生態

1、CPU

CPU的發展趨於緩慢，可以挖掘的潛能主要包括 :

擴充套件指令集，（如向量計算指令，已被PostgreSQL利用來加速OLAP資料分析場景，約有10倍的效能提升），例如

《PostgreSQL 向量化執行外掛(瓦片式實現) 10x提速OLAP》

增加CPU計算單元，（例如PostgreSQL已支援多核平行計算，提升OLAP資料分析場景的效能，多核並行，一條SQL可以充分利用多個CPU核，縮短單條SQL的響應時間，特別適合OLAP業務），例如

《分析加速引擎黑科技 – LLVM、列存、多核並行、運算元複用 大聯姻 – 一起來開啟PostgreSQL的百寶箱》

2、對接新硬體生態（GPU、FPGA、TPU、…）

2.1 GPU

GPU與CPU的對比如下，GPU在核心數、FFLOPS、記憶體頻寬方面，相比CPU有非常明顯的優勢。

PostgreSQL通過pl/cuda語言介面，使用者可以在資料庫中直接使用GPU的計算能力。

pl/cuda用法參考：

https://github.com/pg-strom/devel

pg-strom的作者Kaigai也從NTT出來，加盟了以GPU為核心的Hetero-DB(Next Generation High-Performance Database Systems)。

http://hgpu.org/?p=14236

pg-strom外掛，使用開放的掃描介面，利用GPU提升多表JOIN的效能。

http://strom.kaigai.gr.jp/manual.html

2.2 FPGA

FPGA作為一種高效能、低功耗的可程式設計晶片，可以根據客戶定製來做針對性的演算法設計。所以在處理海量資料的時候，FPGA 相比於CPU 和GPU，優勢在於：FPGA計算效率更高，FPGA更接近IO。

FPGA不採用指令和軟體，是軟硬體合一的器件。對FPGA進行程式設計要使用硬體描述語言，硬體描述語言描述的邏輯可以直接被編譯為電晶體電路的組合。所以FPGA實際上直接用電晶體電路實現使用者的演算法，沒有通過指令系統的翻譯。

FPGA的英文縮寫名翻譯過來，全稱是現場可程式設計邏輯閘陣列，這個名稱已經揭示了FPGA的功能，它就是一堆邏輯閘電路的組合，可以程式設計，還可以重複程式設計。

PostgreSQL 社群，xilinx都有這方面的結合產品。

https://www.pgcon.org/2015/schedule/track/Hacking/799.en.html

2.3 TPU

在Google I/O 2016的主題演講進入尾聲時，Google的CEO皮採提到了一項他們這段時間在AI和機器學習上取得的成果，一款叫做Tensor Processing Unit（張量處理單元）的處理器，簡稱TPU。在大會上皮採只是介紹了這款TPU的一些效能指標，並在隨後的部落格中公佈了一些使用場景：

Google一直堅信偉大的軟體將在偉大的硬體的幫助下更加大放異彩，所以Google便在想，我們可不可以做出一款專用機機器學習演算法的專用晶片，TPU便誕生了。

TPU的靈感來源於Google開源深度學習框架TensorFlow，所以目前TPU還是隻在Google內部使用的一種晶片。

https://www.leiphone.com/news/201605/xAiOZEWgoTn7MxEx.html

2.4 UDF

硬體總有SDK，SDK總有對應的開發語言，通過PL/$LANGAGE介面，PostgreSQL可以通過UDF的方式利用這些硬體的能力。

pl$language

plCUDA

C

PostgreSQL以其擴充套件介面(pl/language, customscan, operator, type, index擴充套件)，可以非常方便的對接以上各種硬體計算單元，讓資料和計算緊密的結合，提高能效比。

通過利用指令集、多核計算對接CPU，通過PL/CUDA，customscan對接GPU，通過customscan對接FPGA，等等，一切都是為了提升計算能力。

PostgreSQL 通過 CPU多核並行、向量計算、JIT、GPU、FPGA等手段擴充套件單體計算能力。通過sharding、MPP等手段橫向擴充套件。消滅瓶頸。

六、回顧資料庫的發展

關聯式資料庫發展了幾十年，最核心的功能，依舊是支援可靠的資料存取、支援SQL介面。

隨著社會的進步，資料庫正在新增越來越多的功能，比如GIS就是其中之一。

為什麼要將GIS功能新增到資料庫中呢？在應用層實現不好嗎？

這個問題很有意思，在應用層實現當然是可以的，但不是最好的。

舉個例子，我們儲存了一批使用者、商鋪的位置資料，要求某個使用者周邊的其他商鋪，如果要在應用層實現這個功能，需要將位置資料都下載到程式端，然後計算距離，並輸出周邊的商鋪。而使用者請求的併發可能較高，請求的位置可能都不一樣。在應用層實現這個功能，效率非常低下，因為每一次請求，都需要將資料載入應用層，同時需要計算每條記錄的距離。印證了一句古話“遠水解不了近渴”。

在資料庫層實現GIS這個功能遵循了兩個宗旨：

1. 資料和計算在一起，每次請求不再需要move data，提升了整體效率。

2. 讓資料庫支援GIS型別和GIS索引，讓每一次距離查詢都可以通過索引檢索，提升查詢效率。

可以看出，資料庫的發展實際上也是遵循了以上原則，在保證資料庫不會成為瓶頸的前提下，讓整體的效率得以提升。

1 PostgreSQL 哪些手段解決瓶頸問題？

1. 提升計算能力

充分利用硬體的能力提升計算能力。例如結合 CPU指令、CPU多核協作、GPU、FPGA。。。

2. 提升開發效率

SQL標準的相容性越好，開發用起來越爽。

支援的型別、function、索引越豐富，開發用起來越爽。

支援的程式設計介面越豐富，開發人員越爽，例如通過plpython對接PyPI，通過plR對接CRAN，通過plcuda對接GPU開發生態。

支援的開發框架越多，開發人員越爽。

3. 提升擴充套件能力

分為兩個部分的擴充套件，一部分是計算能力的擴充套件，另一部分是開發能力的擴充套件。

擴充套件計算能力：

通過sharding，水平擴充套件節點，擴充套件整體效能。

通過MPP外掛，擴充套件跨庫計算能力。

擴充套件開發能力：

通過擴充套件介面（型別、索引、PL語言、UDF、解析器、執行器），支援更多的資料型別、索引型別、程式語言等。GIS就是其中一個例子，擴充套件了GIS型別、索引、UDF等等。

3.1 如何擴充套件資料型別？

https://www.postgresql.org/docs/10/static/xtypes.html

3.2 如何擴充套件索引？

https://www.postgresql.org/docs/10/static/xindex.html

https://www.postgresql.org/docs/10/static/gist.html

https://www.postgresql.org/docs/10/static/spgist.html

https://www.postgresql.org/docs/10/static/gin.html

https://www.postgresql.org/docs/10/static/brin.html

3.3 如何嫁接程式語言？

https://www.postgresql.org/docs/10/static/plhandler.html

3.4 如何擴充套件操作符？

https://www.postgresql.org/docs/10/static/xoper.html

3.5 如何擴充套件UDF？

https://www.postgresql.org/docs/10/static/xfunc.html

3.6 如何擴充套件外部資料介面？

https://www.postgresql.org/docs/10/static/fdwhandler.html

3.7 如何擴充套件聚合UDF？

https://www.postgresql.org/docs/10/static/xaggr.html

2 PostgreSQL 如何提升業務整體效率？

1. 計算與資料在一起，減少move data。

前面舉的GIS的例子說明了一個問題，頻繁的移動資料使得程式的效率低下，如果將計算與資料結合起來，可以大幅的提升效率。

3 PostgreSQL 如何融合行業Lib生態

1. 計算與資料在一起，減少move data。

PostgreSQL內建了許多函式、資料型別、索引型別（已超越ORACLE支援的範疇），可以滿足大多數的業務場景需求。

如果記憶體的資料型別不能滿足業務需求，可以通過型別擴充套件介面，擴充套件資料型別以及型別配套的操作符、函式、索引等。

如果內建的函式、操作符無法滿足業務對資料處理的需求時，使用者可以通過plpython, plr, plcuda, pljava, plperl, pltcl等資料庫過程語言，不僅擴充套件了程式設計能力，同時還對接了程式語言生態。

例如PyPI, CRAN等庫，在資料庫中完成對資料的一站式處理。

這個章節描寫了如何擴充套件PostgreSQL：型別、函式、操作符、索引、聚合等。

https://www.postgresql.org/docs/10/static/extend.html

2. SQL介面流計算

pipelinedb是基於PostgreSQL的一個流計算資料庫，1.0版本將支援外掛化，PostgreSQL使用者可以通過安裝外掛的方式，支援流計算的功能。

SQL流計算有諸多好處，資料庫的SQL介面非常成熟，支援非常成熟的統計分析函式，統計分析語法。建立流的過程非常簡單。

《(流式、lambda、觸發器)實時處理大比拼 – 物聯網(IoT)金融,時序處理最佳實踐》

《流計算風雲再起 – PostgreSQL攜PipelineDB力挺IoT》

SQL介面的流計算，使用便捷，開發成本低，啟動成本低，擴充套件能力強，效率高。

除此之外，PostgreSQL還整合了CPUGPUFPGA等計算能力，整合了PL程式設計介面，流式處理的能力更加的強大。

比如氣象類應用，大量的用到了GIS + 科學計算（plpython）+ 流式計算 + GPU （pl cuda）的處理能力。使用PostgreSQL就非常的恰當。

《PostgreSQL 支援CUDA程式設計 pl/cuda》

《PostgreSQL 點雲應用》

七、小結

對企業來說，資料和計算是兩個不可分割的部分。

經歷了幾十年的發展，資料庫在資料的可靠存取、業務連續性方面成就卓越，企業也非常相信資料庫這方面的能力，通常會將資料都存入資料庫中。

同時企業對資料的計算需求也在膨脹，從最初的簡單計算，到現在越來越複雜的計算需求。計算的需求分為兩個部分，1、運算能力，2、程式設計能力。

1. 資料庫在運算方面的能力也在逐漸提高，但是在兼顧資料可靠性的前提下，彈性提升運算能力沒有想象中容易，大多數的關聯式資料庫僅僅依賴 CPU硬碟 等本地硬體能力的提升，運算能力提升非常有限，企業也不能等待資料庫在這方面的提升。

2. 資料庫在程式設計能力方面，有幾種提升手段，一種是擴充套件SQL語法，支援更多的資料型別、函式、索引等。另一種是語言的支援，通常資料庫會內建儲存過程語言，例如Oracle的PL/SQL，PostgreSQL的plpgsql，但是這些語言的程式設計能力有限。

所以市場中衍生出適合各種場景的資料庫或框架，以犧牲”併發能力、資料可靠性、一致性、易用性、事務、功能等”的某些部分為代價。例如 時序資料庫、流計算資料庫、NOSQL、大資料框架、分散式資料庫 等等。

那麼關聯式資料庫到底還能不能提升計算能力呢？

實際上還是和資料庫本身的框架有關，PostgreSQL的框架特別有意思，開放了眾多的介面，在保證資料庫核心功能不妥協的前提下，允許對其進行擴充套件。包括：

資料庫服務端程式語言(PLpython, java, perl, R, …)、型別、函式、操作符、索引、聚合、外部儲存、customScan等。

八、資料庫的未來 – HTAP，軟體、硬體、雲生態的融合

Hybrid Transactional/Analytical Processing (HTAP)是gartner提出的一個新名詞，代表一種既能處理線上事務，又能處理分析型請求的混合資料庫。

https://en.wikipedia.org/wiki/Hybrid_Transactional/Analytical_Processing_(HTAP)

比如在物聯網的邊緣計算場景，就非常的適合，成本低，效率高，一體成型。

要實現HTAP，必須打通資料、計算的任督二脈。PostgreSQL在這方面具有天然的優勢，從這幾年的發展也能看出端倪。

1. 通過PL(資料庫內建程式語言(PLpython, java, perl, R, …))對接行業生態，讓開發者積累的Lib得以傳承。

2. 通過擴充套件介面對接硬體生態，讓CPU,GPU,FPGA,TPU,ASIC等參與垂直的專業計算，提升效率，打破傳統的CPU ONLY的模式。

3. 通過流實現計算前置，解決資料的實時計算需求。

4. 通過FDW介面，儲存介面將計算下推，讓更多具備運算能力的單元參與運算，避免集中式運算的局面。提升大資料量的處理能力。

其中的代表包括postgres_fdw, 阿里雲的oss_fdw。

5. 通過sharding技術實現資料庫的水平擴充套件。

6. 通過MPP提升大規模計算協作能力。

7. BSD-like許可，已經有非常多的企業以PostgreSQL為基礎打造了更多的衍生產生，免去重複造輪子的過程。

8. 擴充套件型別、函式、操作符、索引介面，對接垂直行業生態。

PostGIS, 基因型別, 化學型別, 影像特徵型別, 全文檢索等外掛，就是非常典型的例子。支援更多的垂直行業應用。

9. 當資料庫可以無限擴充套件，具備強大的計算能力時，它已然不是一個傳統的只能存取資料的資料庫，而是一個提供了程式設計能力、計算能力、擴充套件能力的資料平臺(或資料工廠)，提升資料的使用效率、節約成本。

10. 即使資料庫可以無限擴充套件，還有一點需要注意，資源的控制。特別是開放了pl之後，使用者寫的程式碼可能把資源用盡。一個比較有效的資源排程：當系統有足夠的空閒資源時放開用，當系統資源不足時，按權重排程分配資源的使用。

11、通過開放的介面，與雲端無縫的融合。

九、參考

http://postgis.net/docs/manual-dev/

https://2016.foss4g-na.org/sites/default/files/slides/gbroccolo_FOSS4GNA2016_pointcloud_0.pdf

https://www.slideshare.net/kaigai/pgconfsv2016-plcuda/

https://github.com/pg-strom/devel

http://www.pgconfsv.com/program/schedule

http://kaigai.hatenablog.com/entry/2016/11/17/070708

http://www.pgconfsv.com/plcuda-fusion-hpc-grade-power-database-analytics-0

http://www.pgconf.asia/JP/wp-content/uploads/2016/12/20161203_PGconf.ASIA_PLCUDA.pdf

http://gohom.win/2015/08/10/python-good-lib/

《PostgreSQL 資料庫擴充套件語言程式設計 之 plpgsql – 1》

http://it.sohu.com/20170525/n494441009.shtml

https://www.leiphone.com/news/201704/55UjF0lafhIZVGJR.html