Timescale Cloud:扩展,企业版

自托管产品

MST

Timescale 的分层存储架构包括高性能存储层和低成本对象存储层。您可以使用高性能层来存储需要快速访问的数据,使用对象层来存储不常使用的历史数据。分层策略会异步并定期将旧数据从高性能存储移动到低成本存储,省去了您手动操作的麻烦。单个超表的块,包括压缩块,可以跨越这两个存储层。

高性能存储是您的数据默认存储的地方,直到您启用分层存储将旧数据移动到低成本层。在高性能存储中,您的数据以块格式存储并针对频繁查询进行了优化。此层中提供的Hypercore 行列存储引擎专为实时分析而设计。它使您能够将高性能存储中的数据压缩高达 90%,同时提高性能。结合其他优化,Timescale Cloud 高性能存储确保您的数据始终可访问,并且您的查询以闪电般的速度运行。

Timescale Cloud 高性能存储有以下类型

  • 标准(默认):基于 AWS EBS gp3,专为一般工作负载设计。提供高达 16 TB 的存储和 16,000 IOPS。
  • 增强型:基于 EBS io2,专为高规模、高吞吐量工作负载设计。提供高达 64 TB 的存储和 32,000 IOPS。

查看底层 AWS 存储的区别。您根据需要在 Timescale 控制台中启用增强存储

一旦您启用分层存储,就可以开始将不常用数据移动到对象层。对象层基于 AWS S3,并以 Apache Parquet格式存储您的数据。在 Parquet 文件中,一组行被组合成一个行组。在行组内,多行中单个列的值存储在一起。您的服务中数据的原始大小,无论是压缩还是未压缩,都不直接对应其在 S3 中的大小。压缩的超表在 S3 中甚至可能比在 Timescale Cloud 中占用更多空间。

Apache Parquet 允许在更长的时间段内进行更高效的扫描,Timescale Cloud 使用其他元数据和查询优化来减少为满足查询而需要获取的数据量,例如:

  • 块跳过:排除落在查询时间窗口之外的块。
  • 行组跳过:识别 Parquet 对象中满足查询的行组。
  • 列跳过:只获取查询请求的列。

以下查询针对分层数据集,并说明了这些优化

EXPLAIN ANALYZE
SELECT count(*) FROM
( SELECT device_uuid, sensor_id FROM public.device_readings
WHERE observed_at > '2023-08-28 00:00+00' and observed_at < '2023-08-29 00:00+00'
GROUP BY device_uuid, sensor_id ) q;
QUERY PLAN
-------------------------------------------------------------------------------------------------
Aggregate (cost=7277226.78..7277226.79 rows=1 width=8) (actual time=234993.749..234993.750 rows=1 loops=1)
-> HashAggregate (cost=4929031.23..7177226.78 rows=8000000 width=68) (actual time=184256.546..234913.067 rows=1651523 loops=1)
Group Key: osm_chunk_1.device_uuid, osm_chunk_1.sensor_id
Planned Partitions: 128 Batches: 129 Memory Usage: 20497kB Disk Usage: 4429832kB
-> Foreign Scan on osm_chunk_1 (cost=0.00..0.00 rows=92509677 width=68) (actual time=345.890..128688.459 rows=92505457 loops=1)
Filter: ((observed_at > '2023-08-28 00:00:00+00'::timestamp with time zone) AND (observed_at < '2023-08-29 00:00:00+00'::timestamp with t
ime zone))
Rows Removed by Filter: 4220
Match tiered objects: 3
Row Groups:
_timescaledb_internal._hyper_1_42_chunk: 0-74
_timescaledb_internal._hyper_1_43_chunk: 0-29
_timescaledb_internal._hyper_1_44_chunk: 0-71
S3 requests: 177
S3 data: 224423195 bytes
Planning Time: 6.216 ms
Execution Time: 235372.223 ms
(16 rows)

EXPLAIN 说明了哪些块是从对象存储层拉取过来的

  1. 从对象存储层获取块 42、43 和 44 中的数据。
  2. 跳过行组并将获取限制为 Parquet 对象中可能匹配查询过滤器的偏移量子集。只获取 device_uuidsensor_idobserved_at 的数据,因为查询只需要这 3 列。

对象存储层不仅仅是一个归档解决方案。它还具有以下特点:

  • 成本效益高:以更低的成本存储大量数据。您只需为您存储的数据付费,查询无需额外费用。
  • 可扩展:突破甚至增强型高性能存储层的限制,实现更大规模的扩展。
  • 在线:您的数据始终存在,并且可以在需要时进行查询

默认情况下,当您从 Timescale Cloud 服务查询时,分层数据不包括在内。要访问分层数据,您需要为查询、会话甚至所有会话启用分层读取。启用分层读取后,当您运行常规 SQL 查询时,后台进程会透明地从数据所在的位置(标准高性能存储层、对象存储层或两者)拉取数据。您可以针对分层数据进行 JOIN 操作,构建视图,甚至在其上定义连续聚合。实际上,由于连续聚合的实现也使用超表,它们也可以分层到低成本存储中。

Timescale 仅对您的数据在 S3 中以 Apache Parquet 格式占用的存储空间收费,无论其在分层之前是否在 Timescale Cloud 中被压缩。不产生额外费用,如数据传输或计算费用。

低成本存储层具有以下限制

  • 有限的模式修改:某些模式修改不允许在包含分层块的超表上进行。

    允许的修改包括:重命名超表、添加带有 NULL 默认值的列、添加索引、更改或重命名超表模式以及添加 CHECK 约束。对于 CHECK 约束,只验证未分层的数据。列也可以删除,但您不能随后向分层超表添加与已删除列同名的新列。

    不允许的修改包括:添加带非 NULL 默认值的列、重命名列、更改列的数据类型以及向列添加 NOT NULL 约束。

  • 有限的数据更改:您无法插入数据到、更新或删除分层块。这些限制在块被安排分层后立即生效。

  • 非原生数据类型的查询规划器过滤效率低下:查询规划器通过使用元数据过滤掉不满足查询的列和行组来加速从对象存储层读取数据。这适用于所有原生数据类型,但不适用于非原生类型,例如 JSONJSONBGIS

  • 延迟:S3 的访问延迟高于本地存储。这可能会影响延迟敏感环境中查询的执行时间,特别是较轻量级的查询。

  • 维度数量:您不能将分层存储用于超过一个维度分区的超表。在启用分层存储之前,请确保您的超表仅按时间分区。

关键词

在此页上发现问题?报告问题 或在 GitHub 上编辑此页面