分布式|分布式 PostgreSQL - Citus 架构及概念
文章图片
节点
Citus
是一种 PostgreSQL
扩展,它允许数据库服务器(称为节点)在“无共享(shared nothing)”
架构中相互协调。这些节点形成一个集群,允许 PostgreSQL
保存比单台计算机上更多的数据和使用更多的 CPU
内核。 这种架构还允许通过简单地向集群添加更多节点来扩展数据库。
- 扩展
- https://www.postgresql.org/docs/current/external-extensions.html
每个
cluster
都有一个称为 coordinator(协调器)
的特殊节点(其他节点称为 worker
节点)。应用程序将它们的查询发送到 coordinator
节点,coordinator
节点将其转发给相关的 worker
并累积结果。对于每个查询,
coordinator
要么将其路由到单个 worker
节点,要么将其并行化到多个节点,具体取决于所需数据是位于单个节点上还是多个节点上。coordinator
通过查阅其元数据表知道如何做到这一点。这些 Citus
特定表跟踪 worker
节点的 DNS
名称和运行状况,以及跨节点数据的分布情况。分布式数据 表类型
Citus
集群中有三种类型的表,每种表都以不同方式存储在节点中,并且用于不同的目的。类型 1:分布式表 第一种类型,也是最常见的,是
分布式表
。对于 SQL
语句而言,它们看似是普通的表,但在 worker
节点之间水平分区。文章图片
这里
table
的行存储在 worker
的表 table_1001
、table_1002
等中。 组件 worker
表称为分片(shards)
。分布列
Citus
使用使用分片算法将行分配到分片。基于表列(称为分布列(distribution column)
)的值执行分配,此分配具有确定性。集群管理员在分布表时必须指定此列。做出正确的选择,这一点对于性能和功能有重要影响。类型 2:引用表
引用表
是一种分布式表,其全部内容都集中到单个分片中,并在每个 worker
上复制。因此,对任何 worker
的查询都可以在本地访问 引用
信息,无需从另一个节点请求行,因此也不会产生此类网络开销。引用表
没有分布列
,因为无需区分每行的各个分片。引用表
通常很小,用于存储与在任何工作节点上运行的查询相关的数据。例如,订单状态或产品类别等枚举值。当与
引用表
交互时,我们会自动对事务执行两阶段提交 (2PC
)。 这意味着 Citus
确保您的数据始终处于一致状态,无论您是在写入
、修改
还是删除
它。- 2PC
- https://en.wikipedia.org/wiki/Two-phase_commit_protocol
Citus
时,您连接并与之交互的 coordinator
节点是安装了 Citus
扩展的常规 PostgreSQL
数据库。 因此,您可以创建普通表并选择不对其进行分片。 这对于不参与连接查询的小型管理表很有用。 一个示例是用于应用程序登录和身份验证的用户表。创建标准
PostgreSQL
表很容易,因为它是默认值。这是你运行 CREATE TABLE
时得到的。在几乎每个 Citus
部署中,我们都会看到标准 PostgreSQL
表与 distributed
和 reference
表共存。事实上,如前所述,Citus
本身使用本地表来保存集群元数据。Shards
上一节将分片描述为在
worker
节点内的较小表中包含分布式表的行的子集。本节详细介绍了技术细节。协调器
上的 pg_dist_shard
元数据表包含系统中每个分布式表的每个分片的行。该行与分片 ID
相匹配,分片 ID
的范围是一组哈希整数 (shardminvalue
, shardmaxvalue
)。SELECT * from pg_dist_shard;
logicalrelid| shardid | shardstorage | shardminvalue | shardmaxvalue
---------------+---------+--------------+---------------+---------------
github_events |102026 | t| 268435456| 402653183
github_events |102027 | t| 402653184| 536870911
github_events |102028 | t| 536870912| 671088639
github_events |102029 | t| 671088640| 805306367
(4 rows)
如果
coordinator
节点要确定哪个分片包含 github_events
行,它将对行中分布列的值执行哈希算法。然后此节点检查哪个分片的范围包含此哈希值。 定义范围后,哈希函数的image(图像)
就是两者的并查。分片放置 假设分片
102027
与相应的行关联。在某个 worker
中的 github_events_102027
表中读取或写入此行。是哪个 worker
?这完全由元数据表确定。分片映射到 worker
的过程称为分片放置(shard placement)
。【分布式|分布式 PostgreSQL - Citus 架构及概念】
coordinator
节点将查询重写为引用特定表(例如 github_events_102027
)的片段,并对相应 worker
运行这些片段。 下面的查询示例在后台运行,旨在查找分片 ID
为 102027
的节点。SELECT
shardid,
node.nodename,
node.nodeport
FROM pg_dist_placement placement
JOIN pg_dist_node node
ON placement.groupid = node.groupid
AND node.noderole = 'primary'::noderole
WHERE shardid = 102027;
┌─────────┬───────────┬──────────┐
│ shardid │ nodename│ nodeport │
├─────────┼───────────┼──────────┤
│102027 │ localhost │5433 │
└─────────┴───────────┴──────────┘
在
github_events
示例中,有四个分片。每个表的分片数量在其在集群中分布时是可配置的。最后请注意,
Citus
允许复制分片以防止数据丢失。有两种复制“模式”:Citus
复制和流复制。前者创建额外的备份分片放置并针对所有更新它们的所有它们运行查询。后者效率更高,利用 PostgreSQL
的流式复制将每个节点的整个数据库备份到一个 follower
数据库。这是透明的,不需要 Citus
元数据表的参与。共置 由于可以根据需要将分片及其副本放置在节点上,因此将包含相关表的相关行的分片放在同一节点上是有意义的。 这样,它们之间的连接查询可以避免通过网络发送尽可能多的信息,并且可以在单个
Citus
节点内执行。一个示例是包含商店、产品和购买的数据库。如果所有三个表都包含 - 并且由 -
store_id
列分布,那么限制在单个存储中的所有查询都可以在单个工作节点上高效运行。即使查询涉及这些表的任意组合也是如此。并行性 跨多台机器分散查询允许一次运行更多查询,并允许通过向集群添加新机器来扩展处理速度。此外,如上一节所述,将单个查询拆分为片段可以提高专用于它的处理能力。 后一种情况实现了最大的并行性,这意味着
CPU
内核的利用率。读取或影响均匀分布在多个节点上的分片的查询能够以
“实时”
速度运行。 请注意,查询的结果仍然需要通过协调器节点传回,因此当最终结果紧凑时(例如计数和描述性统计等聚合函数),加速效果最为明显。查询执行 在执行多分片查询时,
Citus
必须平衡并行性的收益与数据库连接的开销(网络延迟和工作节点资源使用)。要配置 Citus
的查询执行以获得最佳的数据库工作负载结果,它有助于了解 Citus
如何管理和保存协调节点和工作节点之间的数据库连接。Citus
将每个传入的多分片查询会话转换为称为任务的每个分片查询。 它将任务排队,并在能够获得与相关工作节点的连接时运行它们。对于分布式表 foo
和 bar
的查询,下面是连接管理图:文章图片
coordinator
节点为每个会话都有一个连接池。每个查询(例如图中的 SELECT * FROM foo
)仅限于为每个 worker
的任务打开最多 citus.max_adaptive_executor_pool_size
(整数)个同时连接。 该设置可在会话级别进行配置,以进行优先级管理。在同一连接上按顺序执行短任务比为它们并行建立新连接更快。 另一方面,长时间运行的任务受益于更直接的并行性。
为了平衡
短任务
和长任务
的需求,Citus
使用 citus.executor_slow_start_interval
(整数)。 该设置指定多分片查询中任务的连接尝试之间的延迟。 当查询首先对任务进行排队时,这些任务只能获取一个连接。 在每个有待处理连接的时间间隔结束时,Citus
会增加它将打开的同时连接数。通过将 GUC
设置为 0
,可以完全禁用慢启动行为。当任务完成使用连接时,会话池将保持连接打开以供以后使用。缓存连接避免了
coordinator
和 worker
之间重新建立连接的开销。但是,每个池一次打开的空闲连接不超过 citus.max_cached_conns_per_worker
(整数)个,以限制 worker
中空闲连接资源的使用。最后,设置
citus.max_shared_pool_size (integer)
充当故障保险。它限制了所有任务之间每个 worker
的总连接数。更多
- Citus 简介,将 Postgres 转换为分布式数据库
推荐阅读
- 听说(分布式ID不能全局递增())
- PostgreSQL|PostgreSQL 的字段类型和表操作笔记
- 新浪开源轻量级分布式RPC框架motan简单示例解析
- skywalking分布式服务调用链路追踪APM应用监控
- Redisson分布式锁的实现原理及源码
- 好家伙,分布式配置中心真好用
- 基于Redis分布式BitMap的应用
- 好家伙,分布式配置中心这种组件真的是神器
- 人人都能看懂系列:《分布式系统改造方案——老旧系统改造篇》
- 分布式文件上传导致服务假死了()