TimescaleDB入门-数据压缩策略(翻译整理)
TimescaleDB 自带原生压缩功能，可让您分析和查询数据库内的海量历史时序数据，同时节省存储成本。
TimescaleDB 使用的压缩算法和一种新颖的方法来创建混合行/列存储。这提供了高达 96% 的无损压缩率，并加快了对旧数据的常见查询。压缩数据会增加数据“有用”的时间（换句话说，在数据库中而不是在低性能对象存储中），而不会相应增加存储使用量和账单。
提示
所有 PostgreSQL 数据类型都可以用于压缩。
在高层次上，TimescaleDB 的内置作业调度程序框架将近的数据从未压缩的基于行的形式异步转换为跨 TimescaleDB 超表块的压缩列形式。
在下一步中，对您的超表启用压缩并学习两种压缩数据的方法：使用自动策略或手动。
在超表上启用 TimescaleDB 压缩
与连续聚合一样，TimescaleDB 有两种压缩数据的方法：手动、通过一次性命令或使用压缩策略按计划自动压缩数据。
压缩数据简单的方法是使用压缩策略。让我们创建一个策略来压缩所有超过 10 年的数据。
这将启用对超表的压缩weather_metrics。
-- Enable compressionALTER TABLE weather_metrics SET (timescaledb.compress,timescaledb.compress_segmentby = 'city_name');
该segmentby选项确定访问压缩数据的主键。特别是，引用segmentbyWHERE 子句中的列的查询非常有效。因此，选择正确的列集很重要segmentby。在这种情况下，选择city_name该segmentby 选项，因为在很长一段时间内只查询一个城市的旧数据是很常见的。
提示
要了解有关 TimescaleDB 中压缩的更多信息segmentby和orderby选项以及如何选择正确的列，请参阅TimescaleDB 压缩文档中的详细说明。
您可以使用 compression_settings信息视图查看我们的超表的压缩设置，该视图返回有关每个压缩选项及其orderby属性segmentby的信息：
-- See info about compressionSELECT * FROM timescaledb_information.compression_settings;
复制
现在启用了压缩，根据上面定义的设置安排一个策略来自动压缩数据。使用以下查询设置压缩 10 年以上数据的策略：
-- Add compression policySELECT add_compression_policy('weather_metrics', INTERVAL '10 years');
复制
就像连续聚合的自动化策略一样，我们可以在以下两个信息视图中查看有关我们的压缩后台作业的信息和统计信息：
手动压缩
虽然我们建议使用压缩策略来自动压缩数据，但在某些情况下您可能需要手动压缩块。这是一个手动压缩完全由超过 10 年的数据组成的块的查询：
----------------------------------------------------- Manual compression---------------------------------------------------SELECT compress_chunk(i)FROM show_chunks('weather_metrics', older_than => INTERVAL ' 10 years') i;
使用以下查询在应用压缩之前和之后查看压缩块的大小：
-- See effect of compressionSELECT pg_size_pretty(before_compression_total_bytes) as "before compression",pg_size_pretty(after_compression_total_bytes) as "after compression"FROM hypertable_compression_stats('weather_metrics');
压缩的好处
节省磁盘空间
压缩让您享受节省磁盘空间的乐趣，因此您可以在固定数量的磁盘空间中存储比在其他数据库中更多的数据（例如，TimescaleDB 使用 10% 的磁盘空间来存储相同数量的时间序列作为 MongoDB 的指标）。
这在考虑备份和高可用性副本时特别有用，因为您可以节省所有数据库的磁盘空间和存储成本。
更好的查询性能
除了节省存储空间和成本之外，压缩数据可能会提高某些类型查询的查询性能。压缩数据往往是较旧的数据，而较旧的数据往往具有与近数据不同的查询模式。
较新的数据往往以浅而宽的方式进行查询。在这种情况下，shallow 指的是时间长度，wide 指的是查询的列的范围。这些通常是调试或“整个系统”查询。例如，“显示过去 2 天内所有城市的所有指标。” 在这种情况下，PostgreSQL 原生的未压缩、基于行的格式为我们提供了佳的查询性能。
较旧的数据往往以深入而狭窄的方式进行查询。在本例中，deep 指的是时间长度，而narrow 指的是查询的列的范围。随着数据开始老化，查询在本质上往往变得更具分析性并且涉及的列更少。例如，“显示 A 市过去 20 年的年平均气温”。这种类型的查询极大地受益于压缩的列格式。
TimescaleDB 的压缩设计让您可以两全其美：近的数据以未压缩的行格式摄取，以进行高效的浅层和宽查询，然后在数据老化后自动转换为压缩的列格式，并且常使用深度查询和狭窄的查询。
这是一个对压缩数据进行深入而狭窄的查询的示例。它计算 2010 年之前数据集中所有年份的纽约市平均气温。这些年份的数据被压缩，因为您使用上述策略或手动压缩方法压缩了 10 年以上的所有数据。
-- Deep and narrow query on compressed dataSELECT avg(temp_c) FROM weather_metricsWHERE city_name LIKE 'New York'AND time < '2010-01-01';
相关文章