postgres 數據庫 citus 集羣分片

 文檔結構：

 

 

如下前言來自網絡

前言

何時須要考慮作數據切分？

一、能不切分儘可能不要切分

1. 並非全部表都須要進行切分，主要仍是看數據的增加速度。切分後會在某種程度上提高業務的複雜度，數據庫除了承載數據的存儲和查詢外，協助業務更好的實現需求也是其重要工做之一。
2. 不到萬不得已不用輕易使用分庫分表這個大招，避免"過分設計"和"過早優化"。分庫分表以前，不要爲分而分，先盡力去作力所能及的事情，例如：升級硬件、升級網絡、讀寫分離、索引優化等等。當數據量達到單表的瓶頸時候，再考慮分庫分表。

二、數據量過大，正常運維影響業務訪問

這裏說的運維，指：

1. 對數據庫備份，若是單表太大，備份時須要大量的磁盤IO和網絡IO。例如1T的數據，網絡傳輸佔50MB時候，須要20000秒才能傳輸完畢，整個過程的風險都是比較高的
2. 對一個很大的表進行DDL修改時，會鎖住全表，這個時間會很長，這段時間業務不能訪問此表，影響很大。在此操做過程當中，都算爲風險時間。將數據表拆分，總量減小，有助於下降這個風險。
3. 大表會常常訪問與更新，就更有可能出現鎖等待。將數據切分，用空間換時間，變相下降訪問壓力

三、隨着業務發展，須要對某些字段垂直拆分

舉個例子，假如項目一開始設計的用戶表以下：

id bigint #用戶的ID

name varchar #用戶的名字

last_login_time datetime #最近登陸時間

personal_info text #私人信息

….. #其餘信息字段

在項目初始階段，這種設計是知足簡單的業務需求的，也方便快速迭代開發。而當業務快速發展時，用戶量從10w激增到10億，用戶很是的活躍，每次登陸會更新 last_login_name 字段，使得 user 表被不斷update，壓力很大。而其餘字段：id, name, personal_info 是不變的或不多更新的，此時在業務角度，就要將 last_login_time 拆分出去，新建一個 user_time 表。

personal_info 屬性是更新和查詢頻率較低的，而且text字段佔據了太多的空間。這時候，就要對此垂直拆分出 user_ext 表了。

四、數據量快速增加

1. 隨着業務的快速發展，單表中的數據量會持續增加，當性能接近瓶頸時，就須要考慮水平切分，作分庫分表了。此時必定要選擇合適的切分規則，提早預估好數據容量

五、安全性和可用性

雞蛋不要放在一個籃子裏。在業務層面上垂直切分，將不相關的業務的數據庫分隔，由於每一個業務的數據量、訪問量都不一樣，不能由於一個業務把數據庫搞掛而牽連到其餘業務。利用水平切分，當一個數據庫出現問題時，不會影響到100%的用戶，每一個庫只承擔業務的一部分數據，這樣總體的可用性就能提升。

六、索引效率

隨着數據量的增長，經過輔助索引查找的數據愈來愈多，大部分是須要進行回表操做，不能直接經過輔助索引找到數據，當數據量很是大時，回表查找將會消耗大量的時間，因爲Oracle,MySQL,Postgresql查詢優化器是基於cost代價模型來設計的，當查詢返回值大於必定比例，執行優化器會選擇走全表掃描

 

Citus可以橫向擴展多租戶（b2b）數據庫，或者構建實時應用程序。citus使用分片，複製，查詢並行化擴展postgres跨服務器來實現這一點，它是之前 pg_shard的升級版本。

Citus適用兩種應用場景，這兩種應用場景對應兩種數據模型:對租戶對應程序和實時分析

多租戶適用於B2B應用場景。

 

一. 安裝citus集羣

有關蘇寧易購的citus:

http://postgres.cn/downfiles/pgconf_2018/PostgresChina2018_%E9%99%88%E5%8D%8E%E5%86%9B_citus%E5%9C%A8%E8%8B%8F%E5%AE%81%E7%9A%84%E5%A4%A7%E8%A7%84%E6%A8%A1%E5%BA%94%E7%94%A8.pdf

IP	操做系統	端口	Citus版本
192.168.10.41  /master	CentOS release 6.10	5432	7.2
192.168.10.51  /woker	CentOS release 6.10	5433	7.2
192.168.10.61  /woker	CentOS release 6.10	5434	7.2

 

步驟在全部節點上執行（我是root身份執行的）

curl https://install.citusdata.com/community/rpm.sh | sudo bash

 

 

 yum install -y citus72_10

 

##yum install -y citus83_11 （我安裝10的版本）

 

 

 

 

配置postgres環境變量

集羣官方網站來自：

https://docs.citusdata.com/en/stable/installation/multi_machine_rhel.html

單機：https://docs.citusdata.com/en/stable/installation/single_machine_rhel.html

如下是三臺都須要操做的步驟

實例初始化：

service postgresql-10 initdb || sudo /usr/pgsql-10/bin/postgresql-10-setup initdb

 

 

修改vi /var/lib/pgsql/10/data/postgresql.conf配置，加入如下內容：

shared_preload_libraries='citus'

若是又多個shared_proload_librarues，shared_preload_libraries='citus'排在第一。

修改其餘參數，好比監聽參數。

 

而且修改pg_hba.conf 參數（加入如下）。

hostnossl    all             all             0.0.0.0/0               trust

啓動postgres-10

service postgresql-10 start

chkconfig postgresql-10 on

 

 

配置環境變量：

export PATH=/usr/pgsql-10/bin:$PATH:

查看安裝的數據庫：

psql -p5432

 

 

create extension citus;

 

select * from pg_extension ;

 

 

二. 在協調節點(主節點)上執行的步驟

a. 節點常規操做

SELECT * from master_add_node('192.168.10.51',5433);

SELECT * from master_add_node('192.168.10.61',5434);

 

 

查看添加的節點：

SELECT * FROM master_get_active_worker_nodes();

 

 

若是須要時刪除節點：

好比說刪除61 5434：

 SELECT * from master_remove_node('192.168.10.61',5434);

查看：

 

 

 

已經刪除了，只剩一個了。

 

禁用某個節點：

select master_disable_node('192.168.10.51',5433);

 

 

 

只看導5434端口的節點了，5433的沒有活動。

 

從新啓用節點：

select master_activate_node('192.168.10.51',5433);

 

 

 

 

 

b. 分佈式集羣測試

創建分佈式表：

注意，cutis不可以建立數據庫：

create database test;  須要全部節點建立數據庫

create extension citus;   而且數據庫建立插件

 

 

 

主節點上操做：

create table test(id int, name varchar(16));

查看默認分片數：

show citus.shard_count;

 

 

 

默認分片數是32，默認是採用hash mod 的分佈方式，能夠根絕實際狀況進行調整，查了不少資料，官方建議OLTP場景(帶分片字段SQL)小負載（小於100GB）32；大負載64或128；我的比較贊同的是：cpu核數*物理節點的分片數*物理節點數

 

將表test 分片（主庫）

 SELECT master_create_distributed_table('test', 'id', 'hash');

 

 

 

設定分片個數（2）以及每一個分片副本數（2）

SELECT master_create_worker_shards('test', 2, 2);

 

 

 

執行完後查看節點表：

主節點：

 

 

 

能夠看出來，數據所有再子節點

節點2：

 

 

 

節點3：

 

 

 

好比我插入10條數據：

主節點

insert into test select *,'a' from generate_series(1,10);

 

發現工做節點兩便都是：

 

 

 

insert into test select id+10,name from test;

 

 

 

建索引：

 

 

 

子節點：

 

 

 

c. Citus參數以及試圖

查看試圖：

 

有關參數，大多數的經常使用的都是

pg_dist_ 前綴的參數。

查看元數據的幾個試圖：

pg_dist_partition

pg_dist_shard

pg_dist_shard_placement

 

參數：

set citus.enable_repartition_joins = on

這個能夠開啓，開啓分片表的親和，能夠優化設計奪標的sql和事務，也支持sql下推。

「Citus Maintenance Daemon」進程自動檢測和處理分佈式死鎖。

 

citus.shard_replication_factor 分片的副本，默認值1

citus.shard_count  分偏數量 默認值32

citus.task_executor_type 它值爲real-time 和task-tracker，默認爲real-time,在跨多個分片的聚合和共同定位鏈接的查詢性能最好。

idle_in_transaction_session_timeout 未防止鏈接資源被耗盡，能夠進行設置事務鏈接時間，默認毫秒。

 

查看根據對應的分零篇鍵值，查找分片：

select get_shard_id_for_distribution_column('t',100);

 

 

Id=100的值分片爲t_102018

 

查看建立分片函數：

create_distributed_table

 

d. Citus故障測試

若是主節點服務器壞點怎麼處理？

哈哈，這個最開始架構選取的時候，就應該設置主備模式，利用VIP，主節點的citus換掉了，備節點接管服務。

 

其餘節點點服務器down掉

 

模擬 51節點down 掉，主節點有數據進行插入。

 

 

 

 

 

插入數據的時候，有提示51上異常，可是仍是插入成功了。

 

起來以後，查看分片的狀況：

 

SELECT * from pg_dist_shard_placement order by shardid, placementid;

 

 

 

明顯應該都是1的，直接把節點2，102008，102009 這兩個從新同步一下

主節點執行：

把節點3的數據拷貝導節點2，主節點執行：

 

SELECT master_copy_shard_placement(102008, '192.168.10.61', 5434, '192.168.10.51', 5433);

SELECT master_copy_shard_placement(102009, '192.168.10.61', 5434, '192.168.10.51', 5433);

 

 

 

子節點：

 

 

 

主節點：

 

已經同步正常。

原文出處：https://www.cnblogs.com/hmwh/p/11651333.html