citus
轻巧灵活的分布式数据库的最佳选择
关于citus
当业务产生的数据量突破单机数据库承载极限，以及由此带来的海量数据存储、大表瓶颈、计算效率低下等性能问题时，分布式数据库是解决单机数据库问题的另一方案。
Citus是一款基于PostgreSQL的开源分布式数据库，自动继承了PostgreSQL强大的SQL支持能力和应用生态（不仅仅是客户端协议的兼容还包括服务端扩展和管理工具的兼容）。和其他类似的基于PostgreSQL的分布式方案，比如GreenPlum，PostgreSQL-XL，PostgreSQL-XC相比，Citus最大的不同在于Citus是一个基于PostgreSQL的插件扩展而不【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目是对postgresql内核的修改。
因此，citus可以用很小的代价和更快的速度紧跟PostgreSQL的版本演进，同时又能最大程度的保证数据库的稳定性和兼容性。
本篇文章主要围绕citus的架构设计、高可用实现、客户端流量切换、数据分片、数据迁移（分片迁移、数据热点/数据倾斜）等几个方面进行阐述。
架构
图1 citus架构设计
Citus的架构如图1所示，包含两种类型的节点：
• Coordinator协调者节点CN；
•负责接收来自客户端的交互请求，并生成分布式执行计划；
•本地维护Metadata元数据，例如Shard分片信息，节点存储位置信息等；
• Worker工作节点WN，也叫数据节点；
•实际的【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目计算和存储节点，可水平拓展。
表和索引
Citus 三种类型的表：
表2 citus表类型
如表2所示，包括Distributed Tables（分布式表）、Reference Tables（参考表）以及Local Tables（本地表），每种类型用于不同的目的：
分片表
Citus主要有两种分片方式：
·hash分片：采用一致性哈希原理，[-2^32,2^32-1]平均分成n个区间，通过对分片字段key取值hash_int32(key)计算具体所属区间。是使用较多的分片方式；
hash分片比较常见于多租户场景、查询多围绕某列的场景，对多租户应用一般选择租户id作为分片键进行分区。
·range分片：分片大小增【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目加到一定量自动创建新的分片，需人工指定每个分片范围。Range分片使用较少。
分片键的选择：
1) Where、JOIN出现频率高的列；
2) 高基数且值分布均匀的字段；
3) 日期（按天）通常不适合作为分片字段，业务往往倾向于访问最近的数据，容易形成热点；
此外，分片方式相同的表称为亲和表。亲和表的集合成为组，通常一个分片的运维操作，指的都是一个组内的所有亲和表。
参考表：
每个DN上有表的全部数据，用于解决跨节点JOIN问题，主要用于维度表、码表等经常需要和其它表做关联计算的表。
本地表
仅驻留在CN节点的表，用来存储数据量不大的表比如元数据表。
Citus索引：
依赖PG的索引，没有像Hbase插件phoen【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目ix那样的二级索引；
组合索引的第一列必须是分片键。
Citus高可用
高可用架构：
图3 citus高可用架构
高可用方案选型：
Citus集群由一个CN节点和N个Worker节点组成。
CN节点的高可用可以通过pg原生的流复制为CN节点配置主备2台PG机器；Worker节点的高可用也可以像CN一样采用PG流复制的高可用方案，此外还支持另一种多副本的高可用方案。
多副本高可用方案是Citus早期版本默认的Worker高可用方案（当时citus.shard_count默认值为2），这种方案部署非常简单，而且坏一个Worker节点也不影响业务。缺点是每次写入数据，CN节点需要在每个Worker上分别写数据，从而【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目带来数据写入性能下降、多副本数据一致性等问题，因此，Citus的多副本高可用方案适用场景有限。
因此，citus官方文档建议Citus和CN和Worker节点都使用PG的原生流复制部署高可用。
高可用工具选型：
如果追求更高程度的自动化，特别是自动故障切换，可以使用一些使用第3方的HA工具，目前有很多种可选的开源工具，下面几种算是比较常用的：
·l PAF(PostgreSQL Automatic Failover)
·l repmgr
·l Patroni
其中Patroni（python开发）采用DCS(Distributed Configuration Store，比如etcd，ZooKeeper，C【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目onsul等)存储元数据，能够严格的保障元数据的一致性，可靠性高，功能也比较强大。
客户端流量切换
CN主备切换后，访问数据库的客户端也要相应地连接到新的主库。目前常见的有下面几种方案：
HAProxy：
1）优点：
可靠、支持负载均衡
2）缺点：
性能损耗、需要配置HAProxy自身的HA
VIP：
1）优点：
无性能损耗，不占用机器资源
2）缺点：
主备节点IP必须在同网段
客户端多主机URL：
1）优点：
无性能损耗，不占用机器资源
不依赖VIP，易于在云环境部署
pgjdbc支持读写分离和负载均衡
2）缺点：
仅部分客户端驱动支持(目前包括pgjdbc，libpq和基于libpq的驱动，如python和php)；
如果数据库【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目层面没控制好出现了”双主”， 客户端同时向2个主写数据的风险较高。
针对以上三种方案，具体方案选择需结合项目实际情况，例如：对于java应用推荐采用客户端多主机URL访问Citus；对于citus CN连接Worker推荐使用VIP的方式。
数据迁移
分布式数据库解决了单机数据库的数据量、吞吐、并发、计算效率等问题，但数据分布方式的变化不可避免会带来新的问题，包括数据热点问题（数据的访问集中在某些分片上）、数据倾斜问题（数据分布不均匀集中在某些分片上）、分布式扩展能力（CN、DN的节点拓展）等等。
解决数据热点/数据倾斜、分布式线性拓展的问题，最重要的是数据迁移的能力。
分片迁移：
分片方式相同的表形成一【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目个分片组进行迁移。
图4 citus分片迁移
分片迁移的原理是迁移一个分片里的所有表然后修改元数据，Citus提供了两个方案：
方案一：COPY table + 修改集群元信息表，这种方案将源表的数据以二进制流写入目标表，速度很快，但是全程禁写，只适合离线使用。
方案二：逻辑订阅 + 修改集群元信息表，迁移时先全量再增量，割接时迁移的表只读。这种方案是online的，可以在线上使用。
数据热点/数据倾斜的解决：
如果某个分片数据存在热点数据导致数据倾斜，将倾斜的热点数据拆出来迁移到资源相对充裕的节点上。这里以hash分片为例说明：
hash分片使用一致性哈希，分片分裂需要将原有的一个分片拆成若干个个分片（具【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目体做法如下图）。这种情况适用于某个分片字段的数据过多，需要单独拿出来，例如多租户数据以user_id分片，某个user的数据量特别大，需要单独分裂出来，如下图示：
图5 分片分裂
02
分布式拓展：
随着业务的增长，数据量越来越大，需要添加更多的计算节点（CN）和存储节点（DN）。
1）CN节点拓展：
对于包含一个master CN和多个备份CN节点，只有master CN才可以修改集群元数据信息。元数据通常很小只有几个MB，不会经常更改。
如果master CN发生故障，使用PostgreQL的流复制能力备份元数据并复制到备份cn节点，备用节点升级为master cn。
但Azure基于Citus的商业化实【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目践里，只有单CN方式。一是这样管理比较简单，无论从用户使用还是后端运维。二是Azure认为CN节点的计算很轻量，CN不会成为计算瓶颈，Citus更倾向于将计算下推到DN上进行。
2）DN节点拓展：
新加一个DN节点，或者删除一个DN节点，都面临着数据的迁移。
图6 DN节点拓展
决定数据迁移的源端和目标端，需要一定算法支持。Citus提供了两种算法：
1）by_shard_count：尽可能让每个DN上的分片数量相同。针对上图示例，会在group1/2/3/4中选择一个迁移到Datanode3，默认选择第一个也就是group 1。
2）by_disk_size：尽可能让每个DN上的数据量相同。每个表的数据【我爱线报网】52线报网-专注分享活动首码线报优惠券零投网赚项目量直接使用了PG原生的统计信息。针对上图示例，会计算出哪些group迁移到Datanode 3后，每个datanode数据量相对平均。
总结
Citus在分布式上的实现与取舍，是以用户场景为导向，致力于使用上的灵活轻巧。总结如下：
·插件化实现：PG能力复用和代码耦合达到了很高的平衡；
·最大程度复用PG已有能力；
·代码耦合度很低，可以快速适配新的PG大版本（对比GreenPlum）。
更多好文：
纸短情长
冬日
内外网间P2P通信背后的NAT穿透技术有哪些
浅谈Web身份识别技术
星海逐浪丨江苏省创新创业大赛参赛感想
