postgres 数据库 citus 集群分片

标签：除了   add   提升   定位   href   用户   cut   实例   项目   

 文档结构：

以下前言来自网络

前言

什么时候需要考虑做数据切分？

1、能不切分尽量不要切分

1. 并不是所有表都需要进行切分，主要还是看数据的增长速度。切分后会在某种程度上提升业务的复杂度，数据库除了承载数据的存储和查询外，协助业务更好的实现需求也是其重要工作之一。
2. 不到万不得已不用轻易使用分库分表这个大招，避免"过度设计"和"过早优化"。分库分表之前，不要为分而分，先尽力去做力所能及的事情，例如：升级硬件、升级网络、读写分离、索引优化等等。当数据量达到单表的瓶颈时候，再考虑分库分表。

2、数据量过大，正常运维影响业务访问

这里说的运维，指：

1. 对数据库备份，如果单表太大，备份时需要大量的磁盘IO和网络IO。例如1T的数据，网络传输占50MB时候，需要20000秒才能传输完毕，整个过程的风险都是比较高的
2. 对一个很大的表进行DDL修改时，会锁住全表，这个时间会很长，这段时间业务不能访问此表，影响很大。在此操作过程中，都算为风险时间。将数据表拆分，总量减少，有助于降低这个风险。
3. 大表会经常访问与更新，就更有可能出现锁等待。将数据切分，用空间换时间，变相降低访问压力

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 表了。

4、数据量快速增长

1. 随着业务的快速发展，单表中的数据量会持续增长，当性能接近瓶颈时，就需要考虑水平切分，做分库分表了。此时一定要选择合适的切分规则，提前预估好数据容量

5、安全性和可用性

鸡蛋不要放在一个篮子里。在业务层面上垂直切分，将不相关的业务的数据库分隔，因为每个业务的数据量、访问量都不同，不能因为一个业务把数据库搞挂而牵连到其他业务。利用水平切分，当一个数据库出现问题时，不会影响到100%的用户，每个库只承担业务的一部分数据，这样整体的可用性就能提高。

6、索引效率

随着数据量的增加，通过辅助索引查找的数据越来越多，大部分是需要进行回表操作，不能直接通过辅助索引找到数据，当数据量非常大时，回表查找将会消耗大量的时间，由于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

步骤在所有节点上执行（我是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);

子节点：

主节点：

已经同步正常。

postgres 数据库 citus 集群分片

标签：除了   add   提升   定位   href   用户   cut   实例   项目   

原文地址：https://www.cnblogs.com/hmwh/p/11651333.html