Timescale 实时分析架构

Timescale 为时序数据上的实时分析提供了一个强大的应用程序数据库。它与 PostgreSQL 生态系统无缝集成，并通过自动基于时间的表分区、混合行-列式存储和向量化执行来增强它，从而实现高摄取性能、亚秒级查询以及大规模的完整 SQL 支持。

通过利用增量更新的物化视图和高级分析函数，Timescale 减少了计算开销并提高了查询效率。开发人员可以继续使用熟悉的 SQL 工作流和工具，同时受益于专为快速、可扩展分析而构建的数据库。

Timescale 结合了 TimescaleDB（一个开源的 PostgreSQL 扩展）和 Timescale Cloud（一个云原生数据库服务）。

本文档概述了 Timescale 的架构选择和优化，这些选择和优化在保持 PostgreSQL 的可靠性和事务保证的同时，提升了 Timescale 的性能和可扩展性。

想在您的电脑上舒适地阅读这份白皮书吗？

实时分析使应用程序能够在数据生成和累积时处理和查询数据，为决策提供即时和持续的洞察。与依赖批处理和延迟报告的传统分析不同，实时分析支持同时对新数据进行即时查询以及对历史趋势进行快速探索——以亚秒级查询性能驱动应用程序处理庞大、持续增长的数据集。

许多现代应用程序依赖实时分析来驱动关键功能

• 物联网 (IoT) 监控系统随时间跟踪传感器数据，识别长期性能模式，同时在异常出现时立即显示。这使得企业能够优化维护计划、降低成本并提高可靠性。
• 金融和商业智能平台分析当前和历史数据以检测趋势、评估风险和发现机会——从跟踪股票一天、一周或一年的表现到识别数百万笔交易中的消费模式。
• 交互式客户仪表板使用户能够无缝探索实时和历史数据——无论是提供业务运营实时分析的 SaaS 产品，还是分析内容参与度的媒体平台，抑或是根据近期和过去行为显示个性化推荐的电子商务网站。

实时分析不仅仅是关于对最新数据的反应，尽管这至关重要。它还关乎在所有数据中提供快速、交互式和可扩展的洞察，从而实现更好的决策和更丰富的用户体验。与分析师使用的传统即席分析不同，实时分析驱动应用程序——大规模地推动动态仪表板、自动化决策和面向用户的洞察。

为实现这一目标，实时分析系统必须满足几个关键要求

• 低延迟查询确保即使在高负载下也能实现亚秒级响应时间，为仪表板、监控和警报提供快速洞察。
• 低延迟摄取最大限度地减少了数据创建与数据可用于分析之间的时间滞后，确保了最新和准确的洞察。
• 数据可变性允许高效的更新、更正和回填，确保分析反映数据的最准确状态。
• 并发性和可扩展性使系统能够处理高查询量和不断增长的工作负载而性能不下降。
• 无缝访问近期和历史数据确保了跨时间的快速查询，无论是分析实时流数据，还是对数天或数月的信息运行深度历史查询。
• 查询灵活性提供完整的 SQL 支持，允许进行包含联接、筛选、聚合和分析函数的复杂查询。

Timescale 是一个高性能数据库，为应用程序带来实时分析能力。它结合了快速查询、高摄取性能和完整的 SQL 支持——同时确保可扩展性和可靠性。Timescale 通过 TimescaleDB 扩展增强了 PostgreSQL。它能够在海量传入数据上实现亚秒级查询，同时提供为持续更新数据集设计的优化。

Timescale 通过以下优化实现这一点

• 高效数据分区：自动透明地将数据分区成块，确保快速查询、最小的索引开销和无缝的可扩展性
• 行-列式存储：为事务提供行式存储的灵活性，为分析提供列式存储的性能
• 优化查询执行：使用块和批处理排除、列式存储和向量化执行等技术来最小化延迟
• 连续聚合：预计算分析结果，实现快速洞察，无需昂贵的重复处理
• 云原生操作：计算/存储分离、弹性按使用量付费存储、横向扩展、数据分层到对象存储
• 操作简易性：提供高可用性、连接池和自动化备份，以实现可靠和可扩展的实时应用程序

借助 Timescale，开发人员可以构建低延迟、高并发的应用程序，无缝处理流数据、历史查询和实时分析，同时利用 PostgreSQL 的熟悉度和强大功能。

当今的应用程序需要一个能够处理实时分析和事务查询的数据库，同时不牺牲速度、灵活性或 SQL 兼容性（包括表之间的联接）。Timescale 通过 超表 (hypertables) 实现这一点，超表提供自动分区引擎；以及 hypercore，一个混合行-列式存储引擎，旨在 PostgreSQL 内部提供高性能查询和高效压缩（高达 95%）。

Timescale 提供超表 (hypertables)，这是一种表抽象，它自动实时将数据分区成块（使用时间戳或递增 ID），以确保随着数据集的增长实现快速查询和可预测的性能。与需要手动分区的传统关系型数据库不同，超表自动化了分区管理的所有方面，即使在高摄取负载下也能保持最小的锁定。

在摄取时，超表通过自动按时间分区数据，确保 PostgreSQL 能够处理持续的数据流，而不会出现表膨胀和索引退化。由于每个数据块都按时间排序并拥有自己的索引和存储，写入通常被隔离到小型的、最近的数据块中——这使得索引大小保持较小，提高了缓存局部性，并减少了 vacuum 和后台维护操作的开销。这种局部写入模式最大限度地减少了写入放大，并确保了持续高摄取性能，即使总数据量增长。

在查询时，当分区列用于 WHERE 子句时，超表会有效地将不相关的块从执行计划中排除。这种架构确保了快速的查询执行，避免了非分区表随着累积数百万行而逐渐变慢的问题。块局部索引使索引开销最小化，确保索引操作扫描无论数据集大小如何都保持高效。

展开图片

超表是 TimescaleDB 所有实时分析能力的基础。它们实现了无缝数据摄取、高吞吐量写入、优化查询执行以及基于块的生命周期管理——包括自动化数据保留（删除数据块）和数据分层（将数据块移动到对象存储）。

传统数据库在快速插入（行式存储）和高效分析（列式存储）之间强制进行权衡。Hypercore 消除了这种权衡，允许在不牺牲事务能力的情况下进行实时分析。

Hypercore 根据数据的生命周期动态地以最有效的格式存储数据

• 用于近期数据的行式存储：最近的数据块（可能更多）始终存储在行式存储中，确保快速插入、更新和低延迟的单记录查询。此外，行式存储还用作列式存储插入和更新的直写层。
• 用于分析性能的列式存储：数据块会自动压缩为列式存储，优化存储效率并加速分析查询。

与传统列式数据库不同，hypercore 允许数据在任何阶段进行插入或修改，使其成为单个数据库中高摄取事务性工作负载和实时分析的灵活解决方案。

TimescaleDB 的列式存储布局通过在磁盘上高效组织数据、减少扫描时间并最大化压缩率来优化分析查询性能。与传统行式存储（数据按行顺序存储）不同，列式存储按列组织和压缩数据，允许查询以批处理方式仅检索必要的字段，而不是扫描整个行。但与许多列式存储实现不同，Timescale 的列式存储支持完全可变性——包括插入、upsert（存在则更新，不存在则插入）、更新和删除，甚至在单个记录级别——并提供事务保证。数据一旦写入，即可立即对查询可见。

展开图片

TimescaleDB 在行式存储中使用列式共置和列式压缩来优化分析查询性能，同时保持与 PostgreSQL 的完全兼容性。这种方法确保了高效存储、高压缩比和快速查询执行。

展开图片

行式存储块通过将行集（通常最多 1000 行）成功分组到一个批次中，然后将该批次转换为列式形式，从而转换为列式存储块。

每个压缩批处理执行以下操作

• 将列式数据封装在每列最多 1,000 个值的压缩数组中，作为底层压缩表中的单个条目存储
• 在批处理中使用列主序格式，通过将相同列的值共置，并允许选择单个列而不读取整个批处理，从而实现高效扫描
• 在列级别应用高级压缩技术，包括行程长度编码、增量编码和 Gorilla 压缩，以显著减少存储占用空间（高达 95%）并提高 I/O 性能。

虽然行式存储和列式存储批处理的块间隔通常保持不变，Timescale 也可以组合列式存储批处理，使它们使用不同的块间隔。

这种架构提供了列式存储的优势——优化扫描、减少磁盘 I/O 和提高分析性能——同时与 PostgreSQL 的基于行的执行模型无缝集成。

为了优化查询性能，TimescaleDB 允许显式控制数据在列式存储中的物理组织方式。通过有效地组织数据，查询可以最大限度地减少磁盘读取并更有效地执行，并在可能的情况下使用向量化执行进行并行批处理。

展开图片

• 将相关数据分组以提高扫描效率：将行组织成逻辑段，确保按特定值过滤的查询只扫描相关数据部分。例如，在上述示例中，查询特定 ID 的速度特别快。（通过 SEGMENTBY 实现。）
• 在段内对数据进行排序以加速范围查询：定义一致的顺序减少了查询后排序的需要，使基于时间的查询和范围扫描更加高效。（通过 ORDERBY 实现。）
• 减少磁盘读取并最大化向量化执行：结构良好的存储布局能够实现高效的批处理（单指令多数据，或 SIMD 向量化）和并行执行，从而优化查询性能。

通过结合分段和排序，Timescale 确保列式查询不仅快速，而且资源高效，从而实现高性能实时分析。

传统数据库在快速更新和高效分析之间强制进行权衡。在数据需要更改的实际应用中，完全不可变存储是不切实际的。异步可变性——即更新仅在批处理后才可见——会引入延迟，从而破坏实时工作流。就地可变性虽然理论上是理想的，但在列式存储中却非常慢，需要昂贵的解压缩、分段、排序和重新压缩循环。

Hypercore 通过混合方法解决了这些权衡，该方法允许即时更新而无需就地修改压缩的列式存储数据。通过在临时行式存储块中暂存更改，hypercore 允许高效地进行更新和删除，同时保持列式存储的分析性能。

展开图片

所有将要进入列式存储块的新数据首先写入一个临时行式存储块，确保高速摄取和即时查询能力。与需要通过压缩管道进行摄取的完全列式系统不同，hypercore 允许新数据保留在快速的行式结构中，之后再像往常一样在有序批处理中压缩为列式格式。

查询透明地访问行式存储和列式存储块，这意味着应用程序无论其存储格式如何，都能立即看到最新数据。

当修改或删除现有数据时，hypercore 避免了异步更新和就地修改的低效率。它不直接修改压缩存储，而是将受影响的批次解压缩并暂存到临时行式存储块中，在那里立即应用更改。

这些修改后的批次保留在行式存储中，直到它们被重新压缩并重新集成到列式存储中（这通过后台进程自动发生）。这种方法确保了更新立即可见，但避免了解压缩和重写整个数据块的昂贵开销。这种方法避免了

• 不可变存储的刚性，它需要版本控制或写时复制等变通方法
• 异步更新的延迟，其中修改后的数据仅在批处理后才可见
• 就地可变性的性能损失，这使得压缩存储在频繁更新时变得非常慢
• 某些数据库对不允许更改分段或排序键的限制

实时分析不仅仅是原始速度——它关乎高效执行查询、减少不必要的工作并最大化性能。Timescale 优化了查询生命周期的每一步，以确保查询只扫描必要的数据，利用数据局部性，并并行执行，从而在大数据集上实现亚秒级响应时间。

Timescale 最大限度地减少了查询所触及的数据量，从而减少了 I/O 并提高了执行速度

查询根据主分区键（通常是时间戳）自动跳过不相关的分区（块），确保它们只扫描相关数据。

展开图片

最小/最大元数据允许对相关维度（例如，order_id 或次级时间戳）进行过滤的查询排除不包含相关数据的块。

展开图片

与许多数据库不同，Timescale 支持对列式存储数据（当前是 B 树和哈希，在使用 hypercore 表访问方法时）的标准 PostgreSQL 索引，允许查询在基于行和压缩列式存储中高效定位特定值。这些索引可实现快速查找、范围查询和过滤操作，进一步减少不必要的数据扫描。

展开图片

在每个块内，压缩的列式批处理使用 SEGMENTBY 键组织并按 ORDERBY 列排序。索引和最小/最大元数据可用于快速排除不符合查询条件的批次。

展开图片

组织数据以实现高效访问可确保查询以最优顺序读取，减少不必要的随机读取并减少对不需要数据的扫描。

展开图片

• 分段：列式批处理使用 SEGMENTBY 进行分组，以将相关数据保持在一起，从而提高扫描效率。
• 排序：每个批次内的数据使用 ORDERBY 进行物理排序，从而提高扫描效率（并减少 I/O 操作），实现高效的范围查询，并最大限度地减少查询后排序。
• 列选择：查询只读取必要的列，减少磁盘 I/O、解压缩开销和内存使用。

一旦查询以最优顺序仅扫描所需的列式数据，Timescale 就能够通过并行执行最大化性能。除了使用多个工作进程外，Timescale 还通过使用单指令多数据 (SIMD) 向量化来加速列式存储查询执行，从而允许现代 CPU 并行处理多个数据点。

展开图片

Timescale 对 SIMD 向量化的实现目前支持

• 向量化解压缩，高效地将压缩数据恢复为可用于分析的形式。
• 向量化过滤，快速地将过滤条件应用于数据集。
• 向量化聚合，同时对多个数据点执行聚合计算，例如求和或平均值。

实时聚合大型数据集可能成本高昂，需要重复扫描和计算，从而占用 CPU 和 I/O。虽然有些数据库试图在运行时暴力执行这些查询，但计算和 I/O 始终是有限资源——随着数据量的增加，这会导致高延迟、不可预测的性能以及不断增长的基础设施成本。

连续聚合是 Timescale 对增量更新物化视图的实现，它通过将计算从每次查询执行转移到数据摄取后的一次异步步骤来解决此问题。只有接收新数据或修改数据的时间桶会被更新，并且查询会读取预计算结果而不是扫描原始数据——这大大提高了性能和效率。

展开图片

当您提前知道所需的查询类型时，连续聚合允许您在有意义的时间间隔内（例如每分钟、每小时或每日汇总）预聚合数据，无需即时计算即可提供即时结果。

连续聚合还避免了耗时且易出错的手动汇总维护过程，同时继续提供数据可变性以支持高效的更新、更正和回填。每当已物化块中插入或修改新数据时，Timescale 会存储失效记录，表明这些结果已过期并需要重新计算。然后，一个异步进程会重新计算包含失效数据的区域，并更新物化结果。Timescale 跟踪连续聚合及其底层数据之间的血缘和依赖关系，以确保连续聚合定期保持最新。这以资源高效的方式进行，并且多个失效可以合并为一次刷新（而不是在写入时通过触发器等方式刷新任何依赖关系）。

连续聚合本身存储在超表中，它们可以转换为列式存储以进行压缩，并且可以删除原始数据，从而减少存储空间和处理成本。连续聚合还支持分层汇总（例如，从每小时到每天再到每月）和实时模式，该模式将预计算结果与最新摄取的数据合并，以确保准确、最新的分析。

这种架构实现了可扩展、低延迟的分析，同时保持资源使用可预测——非常适合仪表板、监控系统以及任何具有已知查询模式的工作负载。

实时分析不仅仅需要基本的 SQL 函数——随着数据集的规模和复杂性增长，高效计算至关重要。超级函数 (Hyperfunctions) 可通过 timescaledb_toolkit 扩展获得，它们提供高性能、SQL 原生函数，专为时序分析量身定制。这些函数包括用于数据填充、百分位数估算、时间加权平均值、计数器校正和状态跟踪等高级工具。

超级函数的一个关键创新是它们支持部分聚合，这使得 Timescale 能够存储中间计算状态而不仅仅是最终结果。这些部分聚合可以在以后合并以高效地计算汇总，避免原始数据的昂贵重复处理并减少计算开销。这与连续聚合结合使用时尤其有效。

考虑一个现实世界中的例子：监控数千个应用程序实例的请求延迟。您可能希望计算每分钟的 p95 延迟，然后将其汇总为每小时和每日百分位数，用于仪表板或警报。使用传统 SQL，计算百分位数需要对所有底层数据进行完整扫描和排序——这使得多级汇总在计算上非常昂贵。

使用 Timescale，您可以在连续聚合中使用 percentile_agg 超级函数来计算并存储每分钟的部分聚合状态。该状态高效地总结了该时间桶的延迟分布，而无需存储或排序所有单个值。稍后，要生成每小时或每日百分位数，您只需合并存储的部分聚合——无需重新处理原始延迟值。

这种方法为基于百分位数的分析提供了一个可扩展、高效的解决方案。通过将超级函数与连续聚合相结合，Timescale 使实时系统能够在高摄取、高分辨率数据集上提供快速、资源高效的洞察——而不会牺牲准确性或灵活性。

实时分析需要一个可扩展、高性能且成本效益高的数据库，它能够处理高摄取速率和低延迟查询而无需过度配置。Timescale Cloud 专为弹性设计，实现了存储和计算的独立扩展、工作负载隔离和智能数据分层。

实时应用程序生成连续数据流，同时需要即时查询最新和历史数据。传统数据库强迫用户预先配置固定存储，导致不必要的成本或意外限制。Timescale Cloud 通过根据实际使用情况动态扩展存储来消除这一限制

• 存储会随着数据的添加或删除而自动扩展和收缩，避免了手动干预。
• 基于使用量的计费确保成本与实际存储消耗保持一致，消除了大量前期分配。
• 计算可以独立扩展以优化查询执行，确保对最新和历史数据进行快速分析。

凭借这种架构，数据库随着数据流的增长而增长，从而实现对实时和历史洞察的无缝访问，同时高效管理存储成本。

在同一系统上平衡高摄取速率和低延迟分析查询可能会产生争用，从而降低性能。Timescale Cloud 通过允许读写工作负载独立扩展来缓解此问题

• 主数据库可高效处理摄取和实时汇总，而不会中断。
• 读取副本可单独扩展查询性能，即使在繁重的工作负载下也能确保快速分析。

展开图片

这种分离确保了对新数据的频繁查询不会干扰摄取，从而更容易支持实时监控、异常检测、交互式仪表板和警报系统。

并非所有实时数据都同样有价值——最新数据被不断查询，而较旧的数据则访问频率较低。Timescale Cloud 可以配置为自动将数据分层到更便宜的无限对象存储中，确保热数据可即时访问，同时历史数据仍然可用。

展开图片

• 近期、高速度数据保留在高性能存储中，用于超快速查询。
• 较旧、访问频率较低的数据会自动移动到经济高效的对象存储中，但仍可查询并可用于构建连续聚合。

尽管许多系统支持数据冷却的概念，但 Timescale 确保数据无论其当前位置如何，都可以从同一个超表中查询。对于实时分析而言，这意味着应用程序可以在不担心存储限制的情况下分析实时数据流，同时在需要时仍能访问长期趋势。

实时分析不仅仅需要快速查询——它还需要理解查询为什么快或慢、资源在哪里被使用以及性能如何随时间变化的能力。这就是 Timescale 内置深度可观测性功能的原因，它为开发人员和操作员提供了对其数据库工作负载的全面可见性。

这种可观测性的核心是 Insights，Timescale 的内置查询监控工具。Insights 实时捕获我们整个集群的每查询统计信息，准确显示您的数据库在负载下的行为。它跟踪执行时间、规划时间、读取和返回的行数、I/O 使用量以及缓冲区缓存命中率等关键指标——不仅针对整个数据库，还针对每个单独的查询。

Insights 允许您执行以下操作

• 即时识别缓慢或资源密集型查询
• 发现长期性能退化或趋势
• 了解查询模式及其随时间的变化
• 查看 schema 更改、索引或连续聚合对工作负载性能的影响
• 监控和比较同一查询的不同版本以优化执行

所有这些都通过直观的界面呈现，直接在 Timescale Cloud 中可用，无需任何仪器或外部监控基础设施。

除了查询级可见性之外，Timescale 还公开了有关服务资源消耗、压缩、连续聚合和数据分层的指标，让您能够跟踪数据如何在系统中移动——以及这些后台进程如何影响存储和查询性能。

总而言之，这些可观测性功能为您提供了大规模运行实时分析数据库所需的洞察力和控制力，让您充满信心、清晰且性能值得信赖。

保持高可用性、高效资源利用和数据持久性对于实时应用程序至关重要。Timescale 提供强大的操作功能，以确保在不同工作负载下的无缝性能。

• 高可用性 (HA) 副本：部署多可用区 (multi-AZ) HA 副本以提供容错能力并确保最短停机时间。如果主节点发生故障，副本会自动提升以保持服务连续性。
• 连接池：通过高效管理和重用数据库连接来优化它们，从而减少开销并提高高并发应用程序的性能。
• 备份和恢复：利用连续备份、时间点恢复 (PITR) 和自动化快照来防止数据丢失。高效恢复数据，以最大程度地减少故障或意外删除情况下的停机时间。

这些操作能力确保 Timescale 即使在要求严苛的实时工作负载下也保持可靠、可扩展和弹性。

实时分析对于现代应用程序至关重要，但传统数据库难以在高摄取性能、低延迟查询和灵活数据可变性之间取得平衡。Timescale 扩展了 PostgreSQL 来解决这一挑战，结合了自动分区、混合行-列式存储和智能压缩，以优化事务性和分析性工作负载。

借助连续聚合、超级函数和高级查询优化，Timescale 确保即使在结合了当前和历史数据的海量数据集上也能实现亚秒级查询。其云原生架构通过独立的计算和存储扩展、工作负载隔离以及经济高效的数据分层进一步增强了可扩展性——使应用程序能够无缝处理实时和历史查询。

对于开发人员而言，这意味着可以构建高性能的实时分析应用程序，而无需牺牲 SQL 兼容性、事务保证或操作简易性。

Timescale 提供了 PostgreSQL 的最佳特性，并为实时分析进行了优化。