Bigtable 内存层实现亚毫秒级读取延迟

标题：通过 Bigtable 内存层扩展实时性能

来源 URL：http://cloud.google.com/blog/products/databases/scaling-real-time-performance-with-bigtable-in-memory-tier/

发布日期：2026-05-07

Markdown 内容：

在数字基础设施的高要求世界中，速度不仅仅是一个指标——它是一种资源。在 Google Cloud Next ‘26 上，我们宣布推出 Bigtable 内存层，这是我们完全托管的云数据库服务的一项突破，它带来了以下优势：

• 亚毫秒级读取延迟，适用于对时间敏感的数据

• 每美元点读吞吐量提升约 10 倍，显著降低总体拥有成本（TCO）

• 热点抵御能力，支持在单行上每秒处理 120,000 次查询，轻松应对高并发。

更多信息请参阅 Bigtable 性能文档。接下来，我们来看看 Bigtable 内存层如何影响您的工作负载性能和运维流程。

缓存未命中噩梦：一个熟悉的故事

想象一下现在是凌晨 2:00。您的促销活动突然爆红，流量激增。然而，您的数据库架构却像纸牌屋一样脆弱：一个主数据库艰难应对请求，还有一个单独的缓存层作为保护。

突然，您遇到了热键问题：所有人都在访问相同的热门内容。您的缓存节点达到饱和。您被迫升级到更大的节点或添加只读副本。您和您的团队筋疲力尽。不仅需要管理两个不同的系统，维护复杂的缓存旁路逻辑（并祈祷缓存中的数据与数据库保持同步），还要应对实际的故障。为此，您过度配置 CPU 来应对峰值，并增加更多 RAM，以确保所有内容都能放入内存，从而避免缓存旁路的复杂性。现在，您为实际上并不需要驻留内存的“温热”数据支付了高昂的费用。虽然理论上您的每美元吞吐量看起来很好，但 90% 的资源大多数时间都处于空闲状态。

Bigtable 内存层登场

Bigtable 内存层结束了这一循环。通过将数据分层从内存（RAM）扩展到固态硬盘（SSD）和机械硬盘（HDD），并在统一的服务中采用混合存储架构，我们去除了中间层。

结果如何？ 您可以享受到缓存级别的原始吞吐量和速度，同时保留 Bigtable 设计之初就具备的持久性和扩展性。当流量激增时，Bigtable 会自动将热点行数据移入内存来应对负载。没有 CPU 骤升，也没有性能下降。如果流量继续增长，Bigtable 集群也会通过提供更多内存读取容量来扩展。您不再需要为闲置的 RAM 或缓存节点支付高昂费用；Bigtable 智能地管理您的数据，仅将热点数据保留在内存中，并确保内存层与 SSD 存储之间的数据一致性。

总体拥有成本（TCO）的收益是显而易见的，但也许更重要的是它带来的安心——这是无价的。

一窥幕后

几乎每个数据库服务器都会使用内存，以便 CPU 能够快速访问对延迟敏感且频繁访问的数据，例如索引和布隆过滤器（Bloom filters）。您可能会问，这次发布有什么不同？

秘密在于 远程直接内存访问（RDMA），这是一种高性能网络技术，允许计算机在不涉及操作系统或 CPU 的情况下，直接在彼此内存之间传输数据。我们的架构使用 RDMA 提供高速直通服务器内存的路径，因此内存层的吞吐量和延迟不再受限于服务器 CPU，从而带来显著的性能优势。就像 Data Boost 为机器学习训练等重负载工作负载提供直接磁盘访问一样，RDMA 为实时处理提供了高速直接内存访问。

想象一下，您运营着一个热门的社交媒体网站，其中 98% 的用户关注者数量少于 250 人，而最受欢迎的用户则拥有超过一亿的关注者。60% 的用户每周发帖不到一次，而前 10% 的用户贡献了 80% 的内容。虽然一篇普通帖子获得 500 次浏览，但热门帖子可以获得数千万次浏览。

为了高效应对这种使用场景，您希望实现如下数据分层：

• 内存：拥有大量关注者的用户内容

• SSD：近期内容、活跃用户资料

• HDD：较旧内容、非活跃用户资料

幸运的是，在 Bigtable 中实现这一点非常简单。只需为您的集群启用内存层，并在发出数据库请求时使用启用了内存的应用程序配置文件，即可自动管理热点数据生命周期。您还可以设置基于时间的策略，将冷数据分层到低频访问层。在这种配置下，当某条内容被读取时，它会从持久存储提升到内存层，并一直保留在那里，直到被其他最近读取的内容替换。完全无需人工干预；即使一篇五年前的帖子突然再次爆红，您也无需担心。

但假设您希望对缓存内容进行更细粒度的控制。您有一份热门内容创作者名单，并希望仅将其中一小部分帖子保留在内存中。只需通过启用了内存的应用程序配置文件路由这些用户的流量，而其他内容则使用未启用内存的配置文件。

再看一次缓存未命中噩梦

让我们倒带重放之前的缓存未命中场景，但这次启用 Bigtable 内存层。现在是周日凌晨 2:00。您的促销活动刚刚爆红，流量激增，您需要在接下来的一小时内额外处理 80,000 次读取请求。您不会收到任何告警通知。您在上午 11 点醒来，听着鸟鸣声，享受宁静的早餐。这是美好的一天。唯一表明凌晨 2-3 点之间流量激增的证据，是您的账单上多出了 0.40 美元的费用。

幂律支配着多个行业中应用程序请求的分布，因此这种场景并不仅限于社交媒体。例如，证券交易所交易数千种证券，但通常前30只最活跃股票的交易量就占到了总交易量的40%以上。与此同时，最新数据点（最近成交价、买/卖报价）被频繁请求，且期望得到低延迟的响应；而历史数据的访问频率则低得多，对延迟的容忍度也更高。我们可以将这个例子拆解为 Bigtable 的数据分层：

• 内存层：最受关注股票的最新价格

• SSD 层：近期历史数据、聚合指标（每小时、每天、每月等）

• HDD 层：较旧的数据、原始事件，如单笔交易

这种能力的潜在用例列表非常长。自动化交易系统从内存中访问最新价格，而零售投资者则使用 SSD 上的数据构建他们的K线图，量化分析师则通过 Data Boost 功能访问 HDD 上的历史数据以进行模型回测。所有这一切都在一个数据库中完成，互不干扰。你可以将金融时间序列数据替换为遥测数据、传感器网络或数字孪生，故事也不会有太大不同。

此外，使用 Bigtable 的内存分层并不会影响其他企业级功能，例如高可用性、扩展性、审计、治理和访问控制，这些功能通常会带来显著的开销。即便有这些企业级需求，仍然能实现亚毫秒级延迟，这令人印象深刻。通过优化我们的客户端和网络，我们还成功将 SSD 层的 p50 延迟降低至 2 毫秒以下。

开始使用 Bigtable Enterprise Plus

Bigtable 的内存分层仅作为全新的 **Bigtable Enterprise Plus 版本** 的一部分提供，该版本还提供许多其他功能，专为需要最高性能和管理效率的企业设计。

今天就将你的技术栈升级到 Bigtable Enterprise Plus 和内存分层，从此告别基础设施管理，开始构建未来！

了解更多

• 想要了解更多关于 Bigtable Enterprise Plus 版本以及内存分层之外的功能，请前往 Google Cloud 控制台 创建新集群或升级现有集群进行体验。

• 如果你是 Bigtable 的新用户，现在可以通过新的 Bigtable 免费试用 来体验 Google 首创的 NoSQL 数据库。你将获得专用的企业版节点、500GB 存储空间以及 Bigtable 使用导览。

• 如需获取更多入门指南、技术规格和区域可用性信息，请访问官方 Bigtable 产品页面。

发布于

• 数据库
• BigQuery
• Google Cloud Next