介绍

现代企业系统的复杂性使得可观测性对于有效运营至关重要。随着组织采用云原生、混合和分布式基础设施，实时处理和分析遥测数据的能力对于保持系统可靠性、性能和用户满意度至关重要。这些不断变化的需求带来了重大挑战，包括需要大规模摄取、存储和查询各种数据类型，同时优化成本并确保运营效率。

为了应对这些挑战，New Relic 数据库 （NRDB） 被开发为云原生、多租户数据库，针对可观测性工作负载进行了优化。NRDB 结合了高性能查询、故障隔离和经济高效的可扩展性，以满足动态业务环境的需求。其架构支持在统一框架内无缝分析各种数据类型，包括不可变遥测数据、可变业务数据和外部源。这些功能使 NRDB 能够提供实时分析所需的可靠性和性能，支持现代数据生态系统不断增长的需求。

本白皮书追溯了 NRDB 的演变，强调了其设计如何演变以满足大规模实时分析的需求。通过多租户架构和高效查询的进步，NRDB 体现了现代数据库如何设计以应对当今动态数据环境的挑战。

New Relic 数据库架构

从 2014 年到可扩展性的演变

2014 年，NRDB 架构走上了一条受 Dremel 论文启发的 道路 ，旨在创建一个大规模分布式数据库系统，用于在简单文件存储等传统架构上进行分析。当时，没有任何分析引擎可以在亚秒内生成查询结果。然后，生态系统的状态由分布式查询引擎组成，当作为批处理作业提交给它们时，这些引擎会在几分钟内生成结果。然而，可观测性 （o11y） 用例需要更多的“实时”查询结果。

为了满足这些要求，NRDB 架构的设计具有三个核心目标：易用性、极快的性能以及适用于不同数据类型的统一平台。

易用性

NRDB 架构在设计时考虑到了用户友好性。它消除了对预定义模式、索引要求和表的需求，简化了数据分析过程，并允许用户专注于获取见解而不是管理数据库结构。

大规模速度

速度是一个关键因素，该架构的目标是亚秒级的“玻璃化时间”和 50 毫秒的中位查询性能。目标是使用户能够通过一种受 SQL 启发的富有表现力的语言来分析数据，该语言允许快速高效的数据检索，而不会增加学习新查询语言的障碍。

一体化解决方案

NRDB 旨在成为一站式解决方案，用于从单个位置查询各种数据类型，包括指标、事件、日志和跟踪。这种整体方法可以对不同的数据流进行全面分析和监控。

初始架构

初始设置涉及大量裸机服务器上的 Java 虚拟机 （JVM），利用塞进机箱中的固态硬盘 （SSD），60-70% 的成本归因于存储。在 Amazon Simple Storage Service （S3） 中存储多个副本的做法导致存储成本膨胀，该服务用于灾难恢复而不是运营服务质量。

高级架构非常简单，我们有一个称为插入工作线程的 Worker 队列，用于将数据持久化到 S3 中，另一个称为 query worker 的 worker 队列将从存储中提供查询。为了确保插入和查询工作线程之间的一致性，实施了元数据层，使客户能够在摄取数据时查询数据。

Kafka 用于摄取处理、分区和路由

随着平台扩展以容纳更多数据和客户，摄取和查询工作负载开始相互干扰，架构必须投资以减少工作负载干扰。

一个关键策略是解耦摄取和查询作，利用消息队列和发布-订阅结构来允许异步处理而不减载。Kafka 是我们押注的一个关键架构组件，从其早期的测试版开始，它就对数据进行路由并在此过程中进行处理，以在将数据发送到插入工作程序之前从遥测（如实体） 中合成附加信息以进行持久化。

系统对数据进行分区以针对两个主要约束进行优化：

1. 将类似数据的大型梯级托管在租户的边界内，这些数据可能会一起查询，以提高使用列式存储的效率。

2. 减少给定客户的故障域。单个代理或插入工作程序或摄取路径上的任何组件中的故障不会影响所有客户。

在上图中，您会看到通过 us tream 服务从所有客户接收所有类型的数据的摄取路径，这些服务应用身份验证  检查并将数据划分为称为 New Relic 帐户的高级结构。然后，数据通过 Kafka 进行处理和使用，然后再将其持久化在对象存储中。

列式存储和存档文件格式

数据到达插入工作程序后，需要以一种高效的格式存储它，以便快速分析查询。很早的时候，我们采用了一种自定义的列式格式，称为“存档文件格式”，因为列式方法可以实现高效的数据存储和检索。由于数据是按列而不是行组织的，因此它通过最大限度地减少从存储读取的数据量来优化分析查询。  对于某些分析工作负载，这种方法可以将性能提高多达 200 倍 。

下图显示了自定义列格式的详细信息，包括如何组织数据以及创建哪些其他元数据以有效地查询文件中的数据。

为了满足数据分析和存储日益增长的需求，我们创建了一种称为存档文件格式的专用文件格式。此格式专为分析工作负载的效率、灵活性和性能而定制。以下是其主要特点和优势。

主要特点

• 针对分析工作负载进行了优化： 存档文件格式专为处理复杂的分析任务而设计。它支持高性能查询和大规模数据处理，非常适合需要从大量数据集中快速洞察的环境。

• 高效压缩和编码： 采用 LZ4、Zstd 等高级压缩技术在不牺牲数据质量的情况下显着减小文件大小。这种效率不仅节省了存储空间，还提高了数据传输速度。

• 多样化的编码技术：为了提高数据效率，存档文件格式采用了多种编码方法：

• 字典编码： 通过用较短的代码替换重复值来减少冗余。

• 增量编码： 存储顺序值之间的差异，这对于时间序列数据特别有效。

• 游程编码： 压缩重复值序列，优化具有许多重复项的数据集的存储。

• 无模式支持： 存档文件格式的一个突出特点是其无模式设计。与严格的模式驱动系统或结构化程度较低的模式读取方法不同，无模式实现可以高效存储和查询各种数据类型，而无需预定义的结构。

  无模式设计还允许快速载入新的遥测源和无缝处理不断变化的数据格式，这两者在动态企业环境中都很常见。通过最大限度地减少模式管理的运营负担，同时保持高性能，这种设计使企业能够更快地响应不断变化的数据需求，而不会牺牲效率或可扩展性。

• 高效的数据检索： 存档文件格式旨在促进快速数据访问。通过利用列式存储方法，它可以智能地组织数据，以最大限度地减少查询所需的时间并提高整体性能。这种有针对性的数据检索策略可确保该格式保持前面讨论的显着性能改进，使其对分析工作负载非常有效。

• 谓词下推： 谓词下推是优化查询性能的关键功能。它使查询引擎能够在存储级别过滤掉不必要的数据。通过降低过滤器和限制，仅从存储中读取相关数据，从而显着减少输入/输出 （I/O）作并加快查询执行速度。虽然这种方法现在在许多关系数据库管理系统 （RDBMS） 中很常见，但其以存档文件格式实现旨在应对可观测性工作负载的特定挑战，包括处理高数据摄取率和对海量数据集的实时分析查询。这确保了需要低延迟响应的场景中的效率和性能。

• 元数据存储：  除了强大的功能外，存档文件格式还包括全面的元数据存储。此元数据提供有关每个文件的结构和特征的基本信息，包括：

  这种丰富的元数据使查询引擎能够通过快速识别每个文件中的相关信息来优化访问。因此，查询响应更快，数据集分析效率更高。

• 列类型： 每个列的数据类型的详细信息，实现高效的处理和类型验证。

• 压缩设置： 有关每列如何压缩的信息，这有助于在数据检索期间解压缩。例如，高冗余列可能使用字典编码，而时间序列数据可能利用增量编码来实现最大压缩效率。

• 汇总统计信息： 每列的基本统计信息（如最小值、最大值、平均值），帮助查询引擎快速评估哪些文件包含相关数据。

处理数据的实时边缘

可观测性用例通常非常偏向于查询最新数据，我们称之为“数据的实时边缘”。这要求数据即使以列式格式存储，也可用于查询。

插入工作线程从分区的 Kafka 流中读取数据，并将其批量转换为存档文件。在将存档文件刷新到我们的云对象存储之前，数据以行格式写入块存储中，具有更快的 I/O。

实时边缘数据的挑战在于它仍在持久化过程中。通常，系统会等待将存档文件大小填满 26 MB 后再刷新，因为较小的文件会导致过度碎片化和文件读取效率下降。在此期间，数据驻留在单个插入工作程序中。但是，单个插入工作线程的硬件无法扩展以处理实时边缘数据经常吸引的不成比例的查询负载。

当查询访问实时边缘时，这在跨多个工作线程水平扩展查询负载方面提出了一个有趣的挑战。为了解决这个问题，需要一种高效的数据 传输方法。一种可以使用 sendfile 等 内存高效技术将数据从插入工作器磁盘传输到网络的一种 。 此外，它应该支持 HTTP 范围查询。

查询辅助角色在处理该特定文件的查询之前检查磁盘中的文件。如果在磁盘上找不到该文件，查询辅助角色将从 S3（或配置的备份存储）下载完成的存档文件，然后继续处理查询。

对于打开的归档文件，该文件仅存在于为高可用性而物理复制但附加到插入工作程序的块存储卷上。如果磁盘上不存在该文件，则会向拥有的插入工作程序发送完整下载请求，以检索为存档文件写入的完整字节，类似于已关闭文件的行为。如果存档文件已在磁盘上，则可能已向其附加了其他字节，因此 HTTP 范围查询可以检索任何剩余的字节，然后将其附加到文件中。追加字节后，查询可以继续。

这是一个重要的权衡，牺牲查询响应时间来换取水平可伸缩性。这已将中位延迟从 50 毫秒增加到 60 毫秒，凸显了快速实时边缘查询在可观测性工作负载中的重要性以及该层水平扩展的必要性。

查询处理

用于实时分析的查询处理体系结构的核心原则是最大限度地减少为完成查询而需要检查的数据量。传统的关系数据库模型通常依赖于索引扫描，这需要搜索索引的大部分内容。相比之下，这种架构通过战略查询路由来实现效率。

查询路由聚合来自插入辅助角色的有关要引入的分区和事件类型的数据。它还收集有关后台处理器执行的任何数据移动或为作目的所做的任何元数据更改的信息。然后，收集到的信息被转换为可查询的布隆过滤器，作为表示特定数据元素是否存在的有效方法。

这些 Bloom 过滤器对于查询网关非常有用，因为它们可以将查询精确路由到适当的分区。这种架构选择通过减少不必要的数据检查并优化整个系统的资源利用率来增强性能。

查询网关

执行查询的过程从解析和编译查询执行计划开始。使用的语言是 New Relic 查询语言 （NRQL），它的灵感来自 SQL，但通过 TIMESERIES 和 HISTOGRAM 等 附加功能进行了增强 ， 以提供更多的分析功能。

查询的解析和编译涉及几个关键步骤。最初，构建抽象语法树 （AST），然后应用各种编译时转换和优化。在此阶段，可能会保留一些未解析的节点，这些节点将在查询执行时得到解决。总体而言，该方法产生了一个细粒度的逻辑执行计划，其特点是未解析节点最少，从而确保了高效执行。

这种方法的关键架构优势之一是能够生成高度优化的执行计划，以适应不同的查询需求。将计划编码到 Thrift 中 有助于与查询工作人员的无缝通信，使他们能够跨分布式系统高效地执行任务。

元数据层

元数据层是现代数据架构的关键组件。它充当统一的力量，确保不同数据组件之间的无缝通信和协调。通过提供有关数据位置、状态和特征的一致且可靠信息的集中存储库，该层培育了一个有凝聚力的数据生态系统。

在架构上，元数据层扮演着几个关键角色。它充当抽象的战略层，解耦计算层和存储层并提高灵活性和可扩展性。这种抽象使数据能够独立于其物理位置进行访问和处理，从而显着增强数据管理和治理。此外，元数据层提供了对数据资产的宝贵见解。它为存档文件、索引和基本统计数据提供精确的位置信息，使数据分析师和工程师能够有效地定位和利用数据。对于客户来说，它提供了数据来源、质量和模式的透明度，并确保可以轻松访问数据以进行分析和决策。

元数据层还促进了与外部数据源和查询引擎的互作性。通过建立标准化的数据定义和格式，它可以实现跨不同系统和平台的无缝集成和数据交换。这不仅使组织能够充分利用其数据，而且还使系统能够支持未来与第三方平台的代理数据集成。随着此功能的成熟，客户将能够更无缝地将其 NRDB 遥测与外部系统连接起来，通过扩展的数据生态系统释放额外价值。

蜂窝架构

随着 NRDB 从每分钟摄取几千个事件扩展到每分钟 100 亿个事件，并在几 PB 数据之上提供查询，增加到每天 EB 的数据，它在其托管的开源组件（如 Kafka、ZooKeeper、Redis 和 MySQL）中遇到了新的扩展限制和故障域。

我们始终在可扩展性的边缘运行这些系统。这导致了运营问题，不仅难以调试和恢复，而且还阻碍了我们弹性扩展以满足业务需求。

我们开始细胞化是为了：

• 提高弹性和故障隔离： 通过创建包含特定边界内故障的隔离单元（单元）来增强系统弹性。这意味着，如果一个单元遇到问题（例如部署失败或数据损坏），则不会影响其他单元。这种隔离显着减少了故障的“爆炸半径”，使整个系统即使在单个组件发生故障时也能保持可用性和性能。

• 有限负载和可预测的性能： 蜂窝架构允许将工作负载划分为离散单元（单元），每个单元都有定义的资源限制。这种设计确保每个电池都可以处理特定的负载而不影响其他电池，从而实现可预测的性能特征。随着需求的增加，可以添加新的电池来适应额外的负载，确保整个系统在不同条件下保持性能和响应能力。这种有限负载方法有助于在整个系统中保持一致的性能指标，从而随着使用量的扩大，更轻松地预测容量需求和作行为。

为了实现这些目标，以下是如何将各种组件组织成单元格。

在高级系统图中，您会看到五种这样的单元类型来说明这个概念。这些不同的细胞类型中的每一种都旨在优化特定功能：

1. 摄取细胞：

• 实时数据摄取： 这些单元负责快速摄取数据并实时处理数据。目标是将“玻璃化时间”保持在 1 秒以下，确保从数据摄取到可视化的时间保持在此阈值以下。

• 流处理： 它们执行流处理作，例如从遥测数据合成和更新实体和关系。

• 共享状态：通过共享状态，这些单元可以有效地协调和优化数据处理。

2. 查询单元格：

• 低延迟查询处理： 这些单元经过优化，可实现高效的查询执行，旨在实现低查询延迟。

• 查询编排：它们编排查询处理管道，确保最佳性能。

3. 存储单元：

• 持久数据存储： 这些单元为各种数据类型（包括原始数据、元数据和索引）提供可靠且持久的存储。

• 性能优化：它们提供具有特定性能特征（例如，I/O 速度、复制）的不同存储类别，以满足不同的数据存储需求。

4. 存储计算单元：

• 摄取后处理： 这些单元处理各种摄取后任务，例如数据压缩、批处理、保留强制和索引管理。

• 数据转换和扩充：这些单元格还可用于数据转换和扩充。

5. 通用电池：

• 控制平面： 这些单元充当系统的控制平面，处理客户查询数据和执行管理任务的请求。

• 网关服务： 它们提供网关服务以向外部用户公开系统的功能。

数据和状态传输

单元之间的数据和状态传输通过 enclave 进行协调。飞地是专门用于管理不同蜂窝类型之间的通信和数据交换的专用组件。他们实现消息传递结构，例如 Kafka，以促进异步通信和数据共享机制，例如符合 ACID 的数据存储，以确保数据的一致性和可靠性。通过利用飞地，系统确保单元之间可靠、高效的数据传输，保持整体架构的完整性和性能。

限制和保护

在任何数据库系统中，尤其是像 NRDB 这样专为多租户设计的数据库系统中，实施限制和保护机制对于确保没有单个租户可以垄断资源或降低其他租户的性能至关重要。

• 资源配额：NRDB 对每个租户的资源使用情况实施配额，以防止过度消耗 CPU、内存或 I/O 带宽。这可确保跨租户公平分配资源。

• 速率限制：NRDB 采用行业标准的速率限制策略来防止可能使系统不堪重负的流量突然高峰。这些策略控制租户在指定时间范围内可以发出的请求数。虽然这些速率限制措施符合行业标准，但 NRDB 允许客户根据其特定需求调整这些限制，从而提供了灵活性。这种定制功能确保客户可以根据其独特的使用模式优化性能和资源分配。

• 数据隔离： 每个租户的数据在逻辑上是分离的，以防止未经授权的访问或干扰。此隔离在应用程序和存储级别强制实施。

单元内和单元格之间的自动缩放

NRDB 的架构支持在单个单元（部署单元）内和分布式环境中跨多个单元的自动扩展功能。

• 动态资源分配： 系统持续监控资源使用情况，并在需求增加时自动分配额外的资源。这确保了在峰值负载期间的最佳性能，无需人工干预。

• 水平扩展： 随着需求的增长，NRDB 可以通过添加更多单元来横向扩展，以在基础设施中均匀分配负载。这种水平扩展功能允许随着数据量的增加而无缝扩展。

• 单元生命周期管理： 每个单元独立运行，但可以与其他单元通信以实现负载平衡。这种设计最大限度地减少了缩放作期间的停机时间，同时保持了高可用性。

管理有状态数据，同时保持单元生命周期轻量级

在 NRDB 等分布式系统中，以轻量级方式处理有状态数据是一项重大挑战。该架构通过采用多种策略来解决这个问题：

• 无状态处理： 在可能的情况下，NRDB 使用无状态处理进行查询，以简化扩展并减少资源开销。无状态组件不会在请求之间保留信息，因此可以轻松地在多个节点之间复制它们。

• 轻量级状态管理： 对于需要有状态处理的作，例如会话管理或事务跟踪，NRDB 采用轻量级状态管理技术，例如缓存，可最大限度地减少资源消耗，同时确保在需要时提供必要的状态信息。

• 高效的数据序列化： 层间传输的数据被高效序列化，以最大限度地减少延迟和带宽使用。此过程将复杂的数据结构转换为紧凑、优化的格式，使其适合快速网络传输。通过减小传输数据的大小并简化系统组件之间的通信，序列化确保即使是有状态交互也能保持低延迟和高性能。

在工作负载中集成数据

在现代数据库系统中，查询可变数据和外部数据以及遥测数据带来了独特的挑战和机遇。遥测数据主要是不可变的，这使得数据库系统能够优化缓存效率。然而，现代遥测应用程序需要能够查询大量遥测数据以及较小的可变数据集，例如人员信息、销售指标或其他商业智能数据。为了满足这一需求，NRDB 改进了其查询层以促进此类复杂的查询，使用户能够有效地集成和分析可变和不可变数据集。这一进步增强了从不同信息来源获得可作见解的能力，从而支持各种业务环境中的明智决策过程。

我们处理了两个广泛的领域：

• 查询可变数据，这涉及使缓存失效并产生检索最新数据副本的成本。

• 查询单独的数据库引擎以获取该数据。

这两种情况都需要查询规划器了解要查询的数据类型。

平台中的每条数据都组织成一种事件类型，称为“eventTypes”。从查询规划器的角度来看，有三类;

• NRDB 内部且不可变的 eventType。

• NRDB 内部且可变的 eventType。

• NRDB 外部的 eventType。

高级架构如下：

该架构被设计为基于连接器的框架，其中每个连接器都运行一个专用的辅助角色（计算资源）队列，负责以最佳效率执行特定的查询段。每个连接器都配备了增强性能所需的逻辑，包括实现谓词下推等技术。这最终会导致更快的查询执行时间。

除了高效执行查询之外，每个连接器在针对其特定数据源量身定制的任务编排中也发挥着至关重要的作用。此编排涉及管理各种任务，例如在计算资源之间分配工作负载、处理数据检索过程以及确保查询的执行方式符合底层数据源的功能和约束。

此外，连接器与协调器和元数据 API 无缝交互。协调员监督整个查询执行过程，确保所有组件和谐地协同工作。同时，元数据 API 有助于访问有关数据结构、模式以及准确执行查询所需的其他相关详细信息的基本信息。

通过支持在遥测数据背景下查询外部数据，NRDB 正在引领可观测性领域的积极颠覆。此功能允许外部元数据提供有关数据结构和组织的重要上下文，使连接器能够优化查询执行，而无需复制或重塑数据。这种方法符合行业优先事项的互作性和处理现有数据的能力，这是行业目前正在积极探索的领域。

虽然这种方法引入了查询性能的可变性，增加了复杂性，并且不能确保强大的数据一致性，但它通过允许即时查询数据提供了显着的灵活性。以前，用户可能需要花费数天时间构建整个管道，以使此类数据可查询。通过利用连接器直接与外部数据源交互的能力，NRDB 显着减少了访问关键信息所需的时间。尽管这种灵活性可能会导致延迟略高，但它代表了对传统、耗时流程的实质性改进。当快速访问信息至关重要时，例如在事件响应期间，这种权衡尤其有价值。

查询平台还包含查询进度检查点功能（如果适用），这显着增强了用户体验和分析能力。此功能使用户能够在查询执行过程中接收增量结果，而不是等待整个数据集处理完毕后再获得任何输出。通过促进增量结果交付，用户可以在数据可用时开始分析数据，从而做出更动态、更灵敏的决策。这在处理极大的数据量时特别有利，因为它减轻了与完整处理此类数据集相关的挑战。此外，此功能允许用户以更流畅的方式与数据交互，从而支持实时分析查询。当用户收到部分结果时，他们可以根据从初始输出中获得的见解调整查询或完善分析。这种迭代方法不仅提高了效率，还增强了实时环境中数据探索和分析的整体有效性。

统一查询语言

通过该平台，我们使用一种类似 SQL 的查询语言供用户与数据进行交互。

这涵盖所有数据转换活动。用户可以  创建数据（或实体）合成规则 、数据删除（或  删除规则 ）或  混淆规则 ，所有这些规则都在客户环境或 New Relic 智能可观测性平台上执行。

摄取数据后，用户可以  配置警报或  定义服务级别 ，系统会按预定义的节奏进行评估。最后，用户可以  直接使用查询构建器、仪表板或 API 查询数据 。在所有这些活动中，使用相同的语言来减轻用户的认知负担。虽然支持的语法量可能略有不同，但它提供了一种与数据交互的直观方式。

结论

实时处理和分析大规模遥测数据的能力对于在云原生和分布式环境中运营的现代企业至关重要。然而，构建一个平衡可扩展性、容错性和成本效率的数据库并非没有挑战。解决不同数据类型的高效集成、繁重工作负载下的可预测性能以及资源优化等问题需要深思熟虑的架构选择。

本白皮书重点介绍了 NRDB 的架构如何专门用于正面应对这些挑战。其可扩展且有弹性的设计为满足现代可观测性工作负载的需求提供了坚实的基础，使组织能够通过实时分析实现运营效率。NRDB 的架构证明了我们在 New Relic 致力于提供世界一流的解决方案，帮助组织敏捷而自信地实现其业务目标。

New Relic 仍然致力于通过持续创新和满足客户不断变化的需求来进一步增强 NRDB 的能力。随着技术的进步，NRDB 将继续提供尖端的解决方案，确保客户能够释放其数据的全部潜力。