分布式 PostgreSQL 集群(Citus)官方示例 - 时间序列数据

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介: 分布式 PostgreSQL 集群(Citus)官方示例 - 时间序列数据
  • 在时间序列工作负载中,应用程序(例如一些实时应用程序查询最近的信息,同时归档旧信息。
  • 为了处理这种工作负载,单节点 PostgreSQL 数据库通常会使用表分区将一个按时间排序的大数据表分解为多个继承表,每个表包含不同的时间范围。
  • 将数据存储在多个物理表中会加速数据过期。在单个大表中,删除行会产生扫描以查找要删除的行,然后清理清空空间的成本。另一方面,删除分区是一种与数据大小无关的快速操作。这相当于简单地删除磁盘上包含数据的文件。
  • 将数据存储在多个物理表中会加快数据过期的速度。在一个大表中,删除行需要扫描以找到要删除的行,然后清空空的空间。另一方面,删除分区是一种与数据大小无关的快速操作。这相当于简单地删除磁盘上包含数据的文件。
  • image.png


  • 对表进行分区还可以使每个日期范围内的索引更小更快。对最近数据进行的查询很可能对适合内存的 hot 索引进行操作。这加快了读取速度。


  • image.png


  • 插入也有更小的索引要更新,所以它们也更快。
  • image.gif

image.png


  • 在以下情况下,基于时间的分区最有意义:
  1. 大多数查询只访问最近数据的一个非常小的子集
  2. 旧数据定期过期(删除/丢弃)
  • 请记住,在错误的情况下,读取所有这些分区对开销的伤害大于帮助。但是,在正确的情况下,它非常有帮助。例如,保留一年的时间序列数据并定期仅查询最近一周。


扩展 Citus 上的时间序列数据



  • 我们可以将单节点表分区技术与 Citus 的分布式分片相结合,形成一个可扩展的时间序列数据库。这是两全其美的。它在 Postgres 的声明性表分区之上特别优雅。
  • image.gif
  • 例如,让我们 distributepartition 一个包含历史 GitHub 事件数据的表。
  • GitHub 事件数据
  • GitHub 数据集中的每条记录代表在 GitHub 中创建的事件,以及有关事件的关键信息,例如事件类型、创建日期和创建事件的用户。
  • 第一步是按时间创建和分区(partition)表,就像我们在单节点 PostgreSQL 数据库中一样:


-- declaratively partitioned table
CREATE TABLE github_events (
  event_id bigint,
  event_type text,
  event_public boolean,
  repo_id bigint,
  payload jsonb,
  repo jsonb,
  actor jsonb,
  org jsonb,
  created_at timestamp
) PARTITION BY RANGE (created_at);


  • 注意 PARTITION BY RANGE (created_at)。这告诉 Postgres 该表将由 created_at 列在有序范围内进行分区。不过,我们还没有为特定范围创建任何分区。
  • 在创建特定分区之前,让我们在 Citus 中分布表。我们将按 repo_id 进行分片,这意味着事件将被聚集到每个存储库的分片中。


SELECT create_distributed_table('github_events', 'repo_id');


  • 此时 Citus 已跨工作节点为该表创建分片。在内部,每个分片是一个表,每个分片标识符 N 的名称为 github_events_N。此外,Citus 传播了分区信息,每个分片都声明了 Partition key: RANGE (created_at)
  • 分区表不能直接包含数据,它更像是跨分区的视图。因此,分片还没有准备好保存数据。我们需要创建分区并指定它们的时间范围,之后我们可以插入与范围匹配的数据。


自动创建分区



  • Citus 为分区管理提供了辅助函数。我们可以使用 create_time_partitions() 创建一批每月分区:


SELECT create_time_partitions(
  table_name         := 'github_events',
  partition_interval := '1 month',
  end_at             := now() + '12 months'
);


  • Citus 还包括一个视图 time_partitions,以方便地调查它创建的分区。
  • image.png


  • 随着时间的推移,您将需要进行一些维护以创建新分区并删除旧分区。最好设置一个定期 job 来运行带有 pg_cron 之类的扩展的维护功能:
  • pg_cron


-- set two monthly cron jobs:
-- 1. ensure we have partitions for the next 12 months
SELECT cron.schedule('create-partitions', '0 0 1 * *', $$
  SELECT create_time_partitions(
      table_name         := 'github_events',
      partition_interval := '1 month',
      end_at             := now() + '12 months'
  )
$$);
-- 2. (optional) ensure we never have more than one year of data
SELECT cron.schedule('drop-partitions', '0 0 1 * *', $$
  CALL drop_old_time_partitions(
      'github_events',
      now() - interval '12 months' /* older_than */
  );
$$);


  • 一旦设置了定期维护,您就不必再考虑分区了,它们可以正常工作。
  • 请注意,Postgres 中的原生分区仍然很新,并且有一些怪癖。对分区表的维护操作将获取可能会短暂停止查询的激进锁。目前在 postgres 社区中正在进行大量工作来解决这些问题,因此预计 Postgres 中的 time 分区只会变得更好。


使用列式存储归档



  • 一些应用程序的数据在逻辑上分为可更新的小部分和“冻结(frozen)”的较大部分。示例包括日志、点击流或销售记录。在这种情况下,我们可以将分区与列式表存储(在 Citus 10 中引入)结合起来压缩磁盘上的历史分区。Citus 柱状表目前是仅追加的,这意味着它们不支持更新或删除,但我们可以将它们用于不可变的历史分区。
  • 列式表存储
  • 分区表可以由行分区列分区的任意组合组成。在 timestampkey 上使用范围分区时,我们可以将最新的分区制作成行表,并定期将最新的分区滚动到另一个历史列式分区中。
  • 让我们看一个例子,再次使用 GitHub 事件。我们将创建一个名为 github_columnar_events 的新表,以消除前面示例中的歧义。为了完全专注于列式存储方面,我们不会分布此表。
  • 接下来,下载示例数据:


wget http://examples.citusdata.com/github_archive/github_events-2015-01-01-{0..5}.csv.gz
gzip -c -d github_events-2015-01-01-*.gz >> github_events.csv


-- our new table, same structure as the example in
-- the previous section
CREATE TABLE github_columnar_events ( LIKE github_events )
PARTITION BY RANGE (created_at);
-- create partitions to hold two hours of data each
SELECT create_time_partitions(
  table_name         := 'github_columnar_events',
  partition_interval := '2 hours',
  start_from         := '2015-01-01 00:00:00',
  end_at             := '2015-01-01 08:00:00'
);
-- fill with sample data
-- (note that this data requires the database to have UTF8 encoding)
\COPY github_columnar_events FROM 'github_events.csv' WITH (format CSV)
-- list the partitions, and confirm they're
-- using row-based storage (heap access method)
SELECT partition, access_method
  FROM time_partitions
 WHERE parent_table = 'github_columnar_events'::regclass;


  • image.png


-- convert older partitions to use columnar storage
CALL alter_old_partitions_set_access_method(
  'github_columnar_events',
  '2015-01-01 06:00:00' /* older_than */,
  'columnar'
);
-- the old partitions are now columnar, while the
-- latest uses row storage and can be updated
SELECT partition, access_method
  FROM time_partitions
 WHERE parent_table = 'github_columnar_events'::regclass;


  • image.png


  • 要查看柱状表的压缩率,请使用 VACUUM VERBOSE。我们三个柱状分区的压缩比相当不错:


VACUUM VERBOSE github_columnar_events;


INFO:  statistics for "github_columnar_events_p2015_01_01_0000":
storage id: 10000000003
total file size: 4481024, total data size: 4444425
compression rate: 8.31x
total row count: 15129, stripe count: 1, average rows per stripe: 15129
chunk count: 18, containing data for dropped columns: 0, zstd compressed: 18
INFO:  statistics for "github_columnar_events_p2015_01_01_0200":
storage id: 10000000004
total file size: 3579904, total data size: 3548221
compression rate: 8.26x
total row count: 12714, stripe count: 1, average rows per stripe: 12714
chunk count: 18, containing data for dropped columns: 0, zstd compressed: 18
INFO:  statistics for "github_columnar_events_p2015_01_01_0400":
storage id: 10000000005
total file size: 2949120, total data size: 2917407
compression rate: 8.51x
total row count: 11756, stripe count: 1, average rows per stripe: 11756
chunk count: 18, containing data for dropped columns: 0, zstd compressed: 18


  • 分区表 github_columnar_events 的一个强大之处在于它可以像普通表一样被完整地查询。


SELECT COUNT(DISTINCT repo_id)
  FROM github_columnar_events;



  • 只要分区键上有一个 WHERE 子句,它可以完全过滤到行表分区中,条目就可以被更新或删除。


将行分区归档到列式存储



  • 当行分区已填满其范围时,您可以将其归档到压缩的列式存储中。我们可以使用 pg_cron 自动执行此操作,如下所示:


-- a monthly cron job
SELECT cron.schedule('compress-partitions', '0 0 1 * *', $$
  CALL alter_old_partitions_set_access_method(
    'github_columnar_events',
    now() - interval '6 months' /* older_than */,
    'columnar'
  );
$$);


  • 有关详细信息,请参阅列式存储。
  • 列式存储
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
4月前
|
机器学习/深度学习 分布式计算 算法
联邦学习是保障数据隐私的分布式机器学习方法
【6月更文挑战第13天】联邦学习是保障数据隐私的分布式机器学习方法,它在不暴露数据的情况下,通过在各设备上本地训练并由中心服务器协调,实现全局模型构建。联邦学习的优势在于保护隐私、提高训练效率和增强模型泛化。已应用于医疗、金融和物联网等领域。未来趋势包括更高效的数据隐私保护、提升可解释性和可靠性,以及与其他技术融合,有望在更多场景发挥潜力,推动机器学习发展。
81 4
|
5月前
|
存储 分布式计算 搜索推荐
【专栏】数据之海,分布式计算、数据存储与管理、数据分析与挖掘成为关键技术
【4月更文挑战第27天】在大数据时代,数据量爆炸性增长、类型多样及处理速度需求提升带来挑战。分布式计算、数据存储与管理、数据分析与挖掘成为关键技术,如Hadoop、Spark、HDFS、NoSQL等。实际应用包括互联网搜索、推荐系统、金融科技、智能城市等领域,大规模数据处理发挥关键作用,持续推动创新与奇迹。
112 3
|
1月前
|
存储 运维 应用服务中间件
阿里云分布式存储应用示例
通过阿里云EDAS,您可以轻松部署与管理微服务应用。创建应用时,使用`CreateApplication`接口基于模板生成新应用,并获得包含应用ID在内的成功响应。随后,利用`DeployApplication`接口将应用部署至云端,返回"Success"确认部署成功。当业务调整需下线应用时,调用`ReleaseApplication`接口释放资源。阿里云EDAS简化了应用全生命周期管理,提升了运维效率与可靠性。[相关链接]提供了详细的操作与返回参数说明。
|
2月前
|
数据采集 分布式计算 并行计算
Dask与Pandas:无缝迁移至分布式数据框架
【8月更文第29天】Pandas 是 Python 社区中最受欢迎的数据分析库之一,它提供了高效且易于使用的数据结构,如 DataFrame 和 Series,以及大量的数据分析功能。然而,随着数据集规模的增大,单机上的 Pandas 开始显现出性能瓶颈。这时,Dask 就成为了一个很好的解决方案,它能够利用多核 CPU 和多台机器进行分布式计算,从而有效地处理大规模数据集。
69 1
|
2月前
|
运维 安全 Cloud Native
核心系统转型问题之分布式数据库和数据访问中间件协作如何解决
核心系统转型问题之分布式数据库和数据访问中间件协作如何解决
|
28天前
|
关系型数据库 数据库 网络虚拟化
Docker环境下重启PostgreSQL数据库服务的全面指南与代码示例
由于时间和空间限制,我将在后续的回答中分别涉及到“Python中采用lasso、SCAD、LARS技术分析棒球运动员薪资的案例集锦”以及“Docker环境下重启PostgreSQL数据库服务的全面指南与代码示例”。如果你有任何一个问题的优先顺序或需要立即回答的,请告知。
47 0
|
3月前
|
canal 缓存 NoSQL
Redis常见面试题(一):Redis使用场景,缓存、分布式锁;缓存穿透、缓存击穿、缓存雪崩;双写一致,Canal,Redis持久化,数据过期策略,数据淘汰策略
Redis使用场景,缓存、分布式锁;缓存穿透、缓存击穿、缓存雪崩;先删除缓存还是先修改数据库,双写一致,Canal,Redis持久化,数据过期策略,数据淘汰策略
Redis常见面试题(一):Redis使用场景,缓存、分布式锁;缓存穿透、缓存击穿、缓存雪崩;双写一致,Canal,Redis持久化,数据过期策略,数据淘汰策略
|
2月前
|
Java 数据库连接 微服务
揭秘微服务架构下的数据魔方:Hibernate如何玩转分布式持久化,实现秒级响应的秘密武器?
【8月更文挑战第31天】微服务架构通过将系统拆分成独立服务,提升了可维护性和扩展性,但也带来了数据一致性和事务管理等挑战。Hibernate 作为强大的 ORM 工具,在微服务中发挥关键作用,通过二级缓存和分布式事务支持,简化了对象关系映射,并提供了有效的持久化策略。其二级缓存机制减少数据库访问,提升性能;支持 JTA 保证跨服务事务一致性;乐观锁机制解决并发数据冲突。合理配置 Hibernate 可助力构建高效稳定的分布式系统。
48 0
|
2月前
|
监控 中间件
分布式链路监控系统问题之当某个Segment数据缺失时还原调用树的问题如何解决
分布式链路监控系统问题之当某个Segment数据缺失时还原调用树的问题如何解决
EMQ
|
3月前
|
传感器 人工智能 安全
EMQX 与 MQTT: AI 大模型时代的分布式数据中枢
在以数据为核心的 AI 时代,基于 MQTT 协议的消息服务器 EMQX 能帮助企业更好的利用人工智能和机器学习模型,是智能化系统中核心的数据基础软件。
EMQ
189 10
下一篇
无影云桌面