数据压缩是一种在保留数字数据中包含的基本信息的同时减少其大小的过程。可以使用算法对数据进行压缩，以消除数据中的冗余或不相关性，使其更易于存储和更有效地传输。压缩是 Timescale 的基石功能，Timescale 是我们基于您熟悉和喜爱的 PostgreSQL 构建的快速且可扩展的云数据库。以至于我们甚至允许使用大型数据集的开发人员压缩不可变数据，从而节省大量存储空间和成本。
阅读我们的文档以了解更多关于压缩的信息，或查看受益于此功能的用户讲述的一些故事。
数据压缩主要有两种类型：无损压缩和有损压缩。
数据压缩是一种用于最大程度地减少数字数据量、最大程度地提高存储效率和提高数据传输速度的技术。这是通过各种算法实现的，这些算法旨在识别和消除冗余或无关紧要的数据元素，而不会牺牲其所体现的核心信息。
在数据库领域，这些算法通常生成可以完美解压缩以获得原始有效负载的数据，这称为无损压缩。当我们试图将文件或数据存储在较小的空间中，但我们关心这些数据时，通常使用无损压缩。关系数据库和时间序列数据库（如 PostgreSQL 和 Timescale）几乎完全使用无损压缩来减少数据库总大小。
压缩算法也可以是**有损的**——它会创建一个更小（或压缩）版本的数据，为了更高的压缩率而牺牲了重建原始数据集的能力。这在音频和视频处理中最常见，为了减小总大小而牺牲质量。
我们也可以在数据库中看到这种情况，当我们对数据进行下采样时，我们会获取原始数据并缩减其大小，同时保留统计或视觉属性（这几乎就是 Timescale 通过连续聚合实现的目标，我们版本的自动更新和增量物化视图）。
有趣的是，这在某些领域非常普遍；例如，在物联网工作负载中，历史数据库通过简单地删除操作员不太感兴趣的点来压缩数据。我们无法恢复这些点，但它们符合一定的阈值，这让我们有理由认为它们是不重要的噪声。
数据压缩可用于一系列场景中，例如减少图像、视频或文本文件的大小——当你处理具有底层模式的大量数据时（即使你自己看不到这种模式！），它特别有用。
在这个数据无处不在且价值非凡的世界中，存储大量的时序数据或类似时序的工作负载变得越来越具有挑战性。就像时间总是向前推进一样，表示随时间变化的数据的规模也在不断地增长。
从一个输入来源获得一个月的数据很快就会变成来自多个输入来源的数年数据。千兆字节可以变成兆兆字节，然后很快变成需要配置的拍字节存储空间。这些数据可能非常有价值（毕竟，它是新的石油），而且我们通常不知道明天想要查询什么样的见解。
因此，保留我们的数据对企业来说至关重要，但同时也需要付出巨大的成本，尤其是在云计算中，每个字节的数据都有直接的成本。
当我们使用无损算法压缩数据时（这样我们就可以恢复原始数据），我们减少了所需的存储量，同时仍然保留了查询数据的能力。使用现代压缩技术，这并不意味着手动压缩和解压缩；这是在我们查询数据时实时处理的。我们以额外的 CPU 成本节省了存储空间和 I/O。
由于输入/输出（I/O）和磁盘速度可能是系统的主要瓶颈之一，因此减少我们读取和写入的数据量实际上可以加快查询速度，即使我们考虑到额外的 CPU 周期。这就像魔法（但实际上只是数学）！
压缩率表示通过压缩节省的数据量。10 倍的压缩率意味着 100 GB 的数据被压缩到 10 GB 的数据。我们可以通过将初始数据大小除以压缩数据大小来计算此值，例如上面的例子中是 100/10。
PostgreSQL 提供了数据压缩选项，你可以使用这些选项来减少存储需求、节省磁盘空间并提高性能。这些选项包括以下内容
TOAST（超大属性存储技术）：在 PostgreSQL 中，一行必须适合单个页面，默认情况下是 8 kB（除非使用不同的页面大小编译）。较大的字段值可以存储在行外并进行压缩以克服此限制。这种机制，即 TOAST，对用户来说是透明的，但只支持具有可变长度表示的数据类型。
为了优化 PostgreSQL 数据库中的存储压缩，你可以使用 PostgreSQL 的几个调节旋钮来影响其 TOAST 行为。你可以选择以下策略之一
PLAIN：防止压缩或行外存储。
EXTENDED（默认）：尝试压缩，但如果行不太大，则存储在行外。
EXTERNAL：允许行外存储，但关闭压缩。
MAIN：允许压缩，但不允许行外存储。
可以使用 ALTER TABLE ... SET STORAGE 在每列的基础上配置每个策略。
只有当行大小超过 TOAST_TUPLE_THRESHOLD（默认情况下为 2 kB，在编译时定义）时，PostgreSQL 才会尝试对值进行 TOAST 处理。可以使用 TOAST_TUPLE_TARGET（默认情况下为 2 kB）控制 TOAST 处理后的行大小目标。
此外，从 PostgreSQL 14 开始，你可以使用 ALTER TABLE ... SET COMPRESSION 选择压缩方法。
Timescale 是 100% 的 PostgreSQL，但通过针对时序和类时序工作负载的先进算法和优化扩展了其功能和可扩展性。
作为客户喜爱的功能，我们的压缩功能已经让软件工程师们印象深刻了一段时间。经常听到 客户设法将数据压缩高达 97% 或 实现 26 倍以上的压缩率。
以下是 Timescale 压缩可以在节省存储空间和成本的同时提高性能的一些方法
与 PostgreSQL TOAST 不同，后者单独压缩列值，而 Timescale 压缩整个列（原生列式压缩），最大限度地利用各个值之间的相似性来实现更高的压缩率。
此外，Timescale 还实现了 针对时序数据中常见数据类型的特殊压缩算法。对于**浮点数据类型**，我们支持 Gorilla 压缩，对于**整数和时间数据类型**，我们支持 delta-delta 压缩。此外，可以在压缩之前按辅助列对列值进行分组，以进一步提高压缩率。为 compress_segmentby 选择一个合适的值对于实现最佳压缩性能至关重要。
**提示：**由于压缩算法是特定于数据类型的，因此你的模式设计会极大地影响你实现的压缩率。遵循 PostgreSQL 的模式设计最佳实践将帮助你实现这一点。特别是对于压缩，建议不要使用 decimal/numeric 数据类型，因为这些数据类型在 Timescale 中没有经过优化的压缩算法。
而且不要忘记，Timescale 还通过允许你 修改已压缩或不可变的数据 来改变时序数据管理。
还不信？请查看我们的压缩对比，了解 Postgres TOAST 与 Timescale 压缩 的完整比较——数字说明一切！
