postgresql , llvm , jit , 并行 , 列存儲 , gpu , 向量計算 , hll , 流計算 , oss對象存儲結合
總量100tb，日增量1tb(日增約100億記錄)左右。這樣的體量應該可以覆寫目前絕大多數企業的資料庫體量。
提到100tb級别，oltp和olap的混合場景，大家可能會想到oracle的一體機extradata，沒錯oracle在這方面做得确實是非常棒的，但是價格也是很漂亮的。
oracle主要通過幾個方面來提升它在這個級别的性能：
共享存儲+rac架構，同時提升oltp和olap的擴充能力，（oltp：多個業務可以配置設定到多個主機上，但是需要注意資料庫維護緩存一緻性帶來的性能下降問題，是以通常不同的主機通路不同的資料塊是較好的設計），（olap：同一條sql可以使用單機cpu多核甚至多個主機的cpu計算能力）。
列存儲，提升olap的性能。
内部使用ib互聯，解決了網絡瓶頸的問題。
在單純的olap資料庫方面，代表作有greenplum, teradata, asterdata等mpp資料庫，比如gpdb就可以利用廉價的x86達到及其好的ap性能，我記得很多年前用6台4萬左右的x86搭建的gpdb叢集，以性能逾10倍多的差異幹掉了2台ibm p570頂配的oracle rac。
回到主題，開源界有沒有應對oltp+olap場景的資料庫呢？
大多數開源資料庫選擇了分而治之(sharding)的路線，因為大多數開源資料庫單機做不到像oracle那麼好的性能。
然而，sharding要做到體驗和單機一樣是非常困難的，包括分布式事務，全局一緻性，全局時間點恢複，跨節點join，節點間資料交換，資料重分布，擴容，視窗查詢，聚合下推等都是巨大的調整。目前還沒有哪個sharding技術敢說體驗和單機一樣，（通常sharding為了實作的便利，會閹割掉大量單機下面的功能）。
其二，要支援olap其實僅僅sharding是不夠的，還有大量的sql相容性的工作（例如多元分析、多表join、視窗查詢、遞歸查詢、科學計算等等）。
個人認為目前體驗做得最好的sharding應該屬greenplum了，但是也僅僅局限在純olap方面。
開源資料庫如果不走sharding路線，能穩定的扛住100tb+, 日增量1tb(日增約100億記錄)的oltp olap混合場景嗎？
以10萬左右的 32core + ssd 單機為例，聊一下單機能做到什麼樣的性能。
tpc-c是oltp的工業測試标準之一，商業資料庫，硬體廠商大都會用tpc-c的測試結果來彰顯自己的性能。
postgresql tpc-c在單機的一組測試資料(warehouses=3000, terminals=256)如下，（這組測試資料是機器上有其他混合應用時的測試資料，還有較大的提升空間，到120萬tpmc應該沒有問題。）。
<a href="https://github.com/digoal/blog/blob/master/201701/20170125_01.md">《資料庫界的華山論劍 tpc.org》</a>
postgresql的優化器完備（例如成熟的cbo體系，豐富的node運算方法等），線上事務處理能力方面，性能卓越。
tpc-h是ola的工業測試标準之一，有大量的join，group等大運算量的操作。大多數的商業ap資料庫會以tpc-h測試結果來彰顯自己的性能。
1、postgresql 10 1tb tpc-h在單機的一組測試資料(sf=1000，即1tb的量)。
這組測試非常具有代表意義，例如使用者每天新增1tb的資料增量，對增量進行統計，生成報表。
pg 10 分區表的并行度目前不支援alter設定，需要update pg_class,例如
從這組資料來看，日增量1tb的場景中，僅僅使用現有特性，pg已可以應付其olap需求。
2、另外，在同一主機上，測了一組deepgreen的性能，1tb tpc-h跑完約1小時。（deepgreen是一個完全相容greenplum的mpp資料庫，在列存儲、sql優化器、jit、向量計算方面有大幅增強）。
<a href="https://github.com/digoal/blog/blob/master/201707/20170703_01_explain.tar.bz2">deepgreen tpch explain result</a>
為什麼要測deepgreen？前面說了在olap性能方面，greenplum已經遠超oracle。而deepgreen的性能已在greenplum之上。我們可以将deepgreen作為一個标杆（dp實際上也是基于pg開發的mpp版本），postgresql将來在經過增強後olap方面有可能達到甚至超過dp的性能。
如果postgresql能達到dp的水準，超過oracle自然沒問題（沒有對比就沒有傷害，讀者可以試試同樣資料量的oracle性能）。
（postgresql 10目前僅使用了jit、多核并行、op複用、分區表、哈希聚合、哈希分組 等若幹對olap場景有較大性能提升的技術手段，還有列存儲、向量計算、appendscan并行等手段可以使用，預計至少還有10倍左右的性能提升空間。）
除了pg 10已經具備的 jit，多核并行、op複用、分區表、哈希聚合、哈希分組，等olap場景黑科技，postgresql還有哪些黑科技可用來大幅提升單機olap場景的性能？
llvm增強，目前pg 10已整合了jit架構，但是要支援更多的算子。
目前有一個pg插件，可以實作pg的向量計算。
已支援的向量計算類型如下
下面是一組使用向量化技術後的性能提升資料。
測試時確定資料均在shared buffer中.
使用向量化前，56秒。
使用向量化後，10秒。
pg 10采樣向量化插件提升了n倍性能，疊加并行化，甚至可以超過dp的性能。
使用向量化除了性能本身的提升，還可以更好的壓縮資料。
并行疊加向量計算的效果測試。
pg 10: 439毫秒。
相對應的deepgreen測試如下: 532毫秒.
pg 10 多核+向量計算組合後，已和deepgreen的分析性能持平甚至略好。（要知道測試中，pg10 還沒有使用正兒八經的列式存儲呢，還有提升的潛力。）
<a href="https://github.com/digoal/blog/blob/master/201707/20170703_01_vops.html">postgresql vops guide</a>
<a href="https://github.com/digoal/blog/blob/master/201702/20170225_01.md">postgresql vops 向量計算中文guide</a>
目前pg已支援大多數node的多核并行，例如seq scan，index scan，hash agg，sort等。将來會支援更多的node。
比如将要支援 append 并行，那麼多個分區表(或者多個繼承表、多個外部表、以及union查詢)都可以并行掃描，理論上這個feature加上後，性能和開源版本greenplum應該可以對齊。
同時還需要提供一種繞過os page cache的資料掃描方法，比如dio，在olap場景會非常有用。（例如突然發起一個大量資料的查詢請求，不至于把cache打亂。）
目前pg内置的是行存儲，要支援列存儲，可以安裝列存儲插件，例如imcs插件，cstore插件。
使用列存儲，可以提升資料壓縮比，同時降低列統計時的資料掃描量和deform開銷，提升列統計性能，以及更好的支援向量計算（目前vops向量計算通過新增資料類型，批量瓦片式存儲來實作，比較别扭）等。
列存插件如下：
<a href="https://github.com/knizhnik/imcs">https://github.com/knizhnik/imcs</a>
<a href="https://github.com/citusdata/cstore_fdw">https://github.com/citusdata/cstore_fdw</a>
期待未來的pg版本可以支援列存儲。
通過hhl插件，可以支援一些估值統計的問題，在使用者允許一些誤差的情況下，高效率的實作實時的pv,uv等查詢需求。例如實時查詢app的uv top 10。
hll的插件如下：
cpu的計算能力有限，通過gpu可以大幅提升olap的性能。pg-strom是一個利用postgresql scan api和gpu實作的olap加速插件。
<a href="https://github.com/pg-strom/devel">https://github.com/pg-strom/devel</a>
join幾十張大表毫無壓力。
通過流複制，可以建立postgresql的備庫，wal延遲接近于0。提升資料庫叢集整體的處理能力。
pipelinedb是基于postgresql開發的一個流計算資料庫，正在進行插件化，将來可以作為插件安裝到postgresql資料庫中。
使用流計算，可以将大量的計算任務分攤到全天，進而減少集中計算的運力需求。集中計算就好像春節放假，大量的人群流動。而流計算就好比城鎮化崛起，大家都不外出打工，都在家附近發展，杜絕了節假日的大遷徙。
<a href="https://github.com/digoal/blog/blob/master/201612/20161220_01.md">《流計算風雲再起 - postgresql攜pipelinedb力挺iot》</a>
阿裡雲的rds pg與雲對象存儲oss無縫結合，實作了資料的分層存儲。
<a href="https://help.aliyun.com/document_detail/44461.html">https://help.aliyun.com/document_detail/44461.html</a>
存放于oss的資料，通過oss_fdw插件，使用外部表進行通路，使用者通路pg外部表和通路本地表的sql文法完全一樣，無需修改應用。
存放于oss的資料，使用者不需要對其進行備份因為oss本身就是多副本存儲。進而減輕了資料庫備份的開銷和成本。
使用oss，pg實際上相當于實作了無限容量的存儲，拓展了單個資料庫的存儲邊界。
存放于oss的資料，不僅可以給一個pg執行個體使用，同時還可以給多個執行個體同時使用，例如可以建立一個rds執行個體，對接oss上的資料，分析師就可以在上面進行分析而不需要消耗線上資料庫的資源。
這個架構最早由亞馬遜aurora提出，目前已經推出了pg的aurora版本。
和oracle rac一樣，都使用共享存儲的架構，差别僅僅在于一寫多讀，oracle是多寫多讀。
存儲為多副本的設計，可以實作跨可用區的多副本一緻性，進而解決了ha、容災層面的問題，使用一寫多讀，還解決了讀性能擴充的問題。
結合postgresql本身的功能、性能等特性，aurora架構讓pg可以覆寫更多的企業場景。
相信會有更多的公司會跟進這樣的架構。
不推薦sharding，因為要犧牲一些功能層面的特性。但是不妨礙社群為了某些特定場景而推出的一些sharding插件。
例如citus插件，自帶節點間資料傳輸，join，透明的資料重分布功能。可以很好的支撐olap的橫向擴充能力。
<a href="https://github.com/citusdata/citus">https://github.com/citusdata/citus</a>
例如tp方面的sharding，基于fdw的sharding，可以解決tp的橫向擴充需求。
<a href="https://github.com/digoal/blog/blob/master/201703/20170331_03.md">《postgresql 10.0 preview sharding增強 - 支援分布式事務》</a>
<a href="https://github.com/digoal/blog/blob/master/201703/20170312_20.md">《postgresql 10.0 preview sharding增強 - pushdown 增強》</a>
<a href="https://github.com/digoal/blog/blob/master/201703/20170312_11.md">《postgresql 10.0 preview sharding增強 - 支援append節點并行》</a>
<a href="https://github.com/digoal/blog/blob/master/201703/20170312_07.md">《postgresql 10.0 preview sharding增強 - postgres_fdw 多節點異步并行執行》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161027_01.md">《postgresql 9.6 sharding based on fdw & pg_pathman》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161005_01.md">《postgresql 9.6 sharding + 單元化 (based on postgres_fdw) 最佳實踐 - 通用水準分庫場景設計與實踐》</a>
<a href="https://github.com/digoal/blog/blob/master/201610/20161004_01.md">《postgresql 9.6 單元化,sharding (based on postgres_fdw) - 核心層支援前傳》</a>
postgresql在olap sql相容性方面的支援是非常完備的，包括多元分析(grouping sets,cube,rollup,grouping等)，遞歸查詢，視窗查詢，多表join，科學計算，機器學習函數 等等。
開源軟體強大之處在于發展非常的迅速，非常的開放。同時postgresql這個産品本身的開源許可、設計很契合開發者，開放了大量的可擴充接口，是以我們可以看到postgresql生态中有特别多的插件，滿足各種場景的需求。
相比oracle，pg有哪些優勢？
1、雲生态融合，例如oss_fdw，就是一個資料庫和對象存儲融合的例子。
2、軟體生态融合，例如pl語言，使用者可以通過plpython, plr, plcuda等語言開發存儲過程，融合開發者的軟體生态。
3、硬體生态融合，例如與gpu結合，讓pg擁有更加強大的計算能力。
4、可擴充，通過開放的資料、索引、掃描、操作符、udf等接口，可以支援更多的使用者場景。
比如圖像特征值的存儲和搜尋，通過擴充就能支援，imgsmlr這個插件就是一個代表。
比如基因資料的存儲和搜尋，通過擴充就能支援，postbis這個插件就是一個代表。
比如化學資料的存儲和搜尋，rdkit。
機器學習插件，madlib。
gis插件，postgis。
時序資料插件，timescaledb。
hll估值插件。
5、流計算，通過pipelinedb，可以實作流式計算。
6、mpp，通過citus插件，可以實作mpp，多機并行計算。
7、llvm, 向量計算等優化手段，在olap方面有非常大的性能提升。
類rac架構，(aurora postgresql和這種形态非常類似，而且存儲層做得更加強大)。
<a href="https://github.com/digoal/blog/blob/master/201705/20170526_01.md">《資料庫的未來 - htap，軟體、硬體、雲生态的融合》</a>
現如今已不是商業資料庫獨舞，越來越多的開源産品在崛起，從穩定性、性能、功能各個方面包圍商業産品，postgresql 是一個非常典型的代表。
扛起100tb，日增量1tb 級别這個市場的oltp+olap混合場景htap的大旗，postgresql 值得擁有。
同時，在雲上，使用者不再需要擔心運維、高可用、備份、擴容、遷移、診斷、監控等問題，使用者隻管用，雲為使用者提供貼身服務。雲上的pg提供了更多的擴充（包括 與對象存儲的無縫結合，核心的優化，增值服務，類rac架構(越來越多的廠商會跟進aurora形态)等）。
如果使用者不想使用雲服務，沒有關系，在不改核心的情況下，你依舊可以使用目前社群版本提供的這些特性，來滿足你的需求（包括流計算、hll、讀寫分離、jit、向量計算、列存儲等）。
<a href="https://github.com/digoal/blog/blob/master/201702/20170225_01.md">《postgresql 向量化執行插件(瓦片式實作) 10x提速olap》</a>