citus調研（三）- 優勢與限制
當前調研基於citus7.5
開源協議
citus的開源協議是GPL v3， 意味著修改和使用其程式碼都需要開源，但是這是建立在軟體分發的基礎上，如果使用程式碼作為服務提供，而不分發軟體，則不需要開源。
功能優勢
- 只是PostgreSQL的一個extension；基本相容PostgreSQL的sql處理能力、管理工具、效能優化和功能擴充套件等
- 支援分散式事務；citus使用2pc保證資料的最終一致性
- 支援兩種執行器；real-time(預設)和task-tracker執行器，可根據實際應用場景選擇執行器
- 橫向擴充套件方便；citus增加worker節點非常方便，只需要簡單的幾步操作即可完成擴充套件
- 分片表管理簡單；分片表刪改與普通表差別不大，且citus提供了大量的函式檢視分片表的狀態，管理分片
- 支援並行查詢；citus在接收到分散式請求之後，會生成分散式執行計劃，並將各個子任務下發到相應的worker節點執行
- 支援聚合下推； citus執行聚合時先在涉及到的worker節點進行初步處理，再在coordinator節點彙總計算。
- 成功案例較多；蘇寧、cisco等
- 支援批量資料載入；
- 支援實時增刪改查；
- 支援常用DDL；
real-time執行器是coordinator節點直接與worker節點互動，容易造成併發大，可能導致資源瞬間增長
task-tracker執行器是coordinator節點與worker節點上的task-tracker程序互動，由task-tracker程序負責worker上的任務排程，支援資料重分佈，併發數可控
功能限制
- 不能保證全域性的一致性讀；2pc的最後一步，一部分子事務還未提交時，讀取資料庫可能會得到不正確的結果
- 社群版不支援平滑擴容；citus新增新的worker節點後，現有的分片表和參考表卻不會自動分佈到新加的worker上。
- 社群版CN可能成為效能瓶頸；社群版只支援一個coordinator
- 本地表不能與分片表、參考表混用；
- 分片列不支援更新；
- SQL限制；
【平滑擴容問題】
如果要手工處理，需要以下幾步：
- 新增節點；
- 複製分片；將原有的worker上的分片移動一部分到新節點上（邏輯複製）
- 切換元資料；分片資料同步完成後，鎖表，修改元資料中的分片資訊
- 清理原有worker上已被複制的分片和publication，清理新節點上的subscription
注意：citus的分片表之間存在親和性關係，具有親和性的所有分片表的同一範圍的分片其所在位置必須相同。因此移動某個分片時，必須將這些親和分片捆綁移動。
企業版可以利用master_move_shard_placement()函式遷移分片，我們可以也實現一個介面類似的函式（未進行嚴格測試，且不支援多CN架構）來實現分片遷移
【CN效能瓶頸問題】
citus的架構中正常只有1個CN節點，有時候CN會成為效能瓶頸。在citus的具體實現中，CN和worker的區別就在於是否儲存了相關的元資料，如果把CN的元資料拷貝一份到worker上，那麼worker也可以向CN一樣工作，這個多CN的模式早期被稱做masterless。當前的citus版本，有一個開關，開啟後，會自動拷貝CN的元資料到Worker上，讓worker也可以當CN用。 這個功能官方稱做Citus MX，社群版雖然沒有公開說支援，但也沒有從程式碼上限制這個功能，也可以用（已驗證）
SQL限制
查詢
- Join限制（已驗證）
- 不支援2個非親和分片表的outer join
- 僅task-tracker執行器只是2個非親和分片表的inner join
- 分片表和參考表outer join時，參考表只能再left join的右邊或者right join的左邊
- 子查詢限制
- 不能出現order by ,limit,offset
- 不支援的特性
- CTE
- 視窗函式
- 集合操作，比如union
- 非分片列的count(distinct)
更新
- 不支援跨分片的更新SQL (有疑問）
- 不支援跨分片的事務(有疑問)
- insert into ... select from ...的支援有限制
- 源和目標表必須是親和分片表
- 不允許出現Stable and volatile函式
- 不支援LIMIT,OFFSET,視窗函式，集合操作，Grouping sets, DISTINCT
DDL
ALTER TABLE只支援以下子命令 Only ADD|DROP COLUMN, SET|NOT NULL, DEFAULT, CONSTRAINT Only ADD|DROP COLUMN, SET|NOT NULL, DEFAULT, CONSTRAINT FOREIGN KEY and TYPE subcommands are supported.
效能
官方資料
citus與原生PostgreSQL效能對比：
| citus | PostgreSQL(9.6.4) | |
| 測試資料 | 114萬行（表結構未知） | |
| 測試環境 |
coordinator(4 vcpus/7.5G/1T) (+1HA) worker(8 vcpus/61G/1T)*4 (+4HA) |
未知 |
| copy寫入 | 94秒/88秒 | 454秒/109秒 |
| 建立索引 | 109秒 | 8秒 |
| 查詢效能 | 941毫秒 | 68毫秒 |
| 查詢延時 | 2毫秒 | 37毫秒 |
第三方資料
citus與原生PostgreSQL效能對比
環境配置：（ECS 32核，128G記憶體，2TB 雲盤) * 9
| 環境 | test case | TPS | coordinator 節點CPU資源消耗 | worker節點CPU資源消耗 |
|---|---|---|---|---|
| citus(1+8) shard=8 | 1億 tpc-b 只讀 | 16.3萬 | (0% IDLE) | (92% IDLE) |
| citus(1+8) shard=128 | 1億 tpc-b 只讀 | 16.4萬 | (0% IDLE) | (91% IDLE) |
| local PG | 1億 tpc-b 只讀 | 49萬 | - | (0% IDLE) |
| citus(1+8) shard=8 | 1億 tpc-b 讀寫 | 1.28萬 | (45% IDLE) | (91% IDLE) |
| citus(1+8) shard=128 | 1億 tpc-b 讀寫 | 1.11萬 | (36% IDLE) | (91% IDLE) |
| local PG | 1億 tpc-b 讀寫 | 3.98萬 | - | (0% IDLE) |
citus與原生PostgreSQL隨機更新效能對比
環境配置：未知，citus 8 worker
| 部署方式 | TPS | 備註 |
| 單機PostgreSQL | 134030 | |
| citus | 55717 | coordinator是效能瓶頸 |
| citus(不解析SQL） | 75973 | 改citus程式碼 |
| citus(masterless) | 20W+ |
注：把coordinator的元資料拷貝一份到worker上，那麼worker也可以向CN一樣工作，這個多CN的模式早期被稱做masterless。上述測試資料中masterless場景CN的個數未知。
citus與Deepgreen效能對比
環境配置：（ECS 32核，128G記憶體，2TB 雲盤) * 9
【TPC-B】
| citus | DeepGeen | |
| TPC-B(只讀) | 16.4萬 tps | 187 tps |
| TPC-B(讀寫) | 1.11萬 tps | 17 tps |
【TPC-H】
| query序號 | citus（秒 ） | DeepGreen（秒 ） |
| 1 | 12 | 3 |
| 3 | 77 | 4 |
| 4 | 2 | 7 |
| 5 | 234 | 2 |
| 6 | 1 | 0 |
| 7 | 465 | 23 |
| 8 | 415 | 5 |
| 9 | 837 | 12 |
| 10 | 116 | 4 |
| 14 | 67 | 5 |
| 15 | 232 | 6 |
| 19 | 76 | 3 |