Spanner 概念验证 playbook

本页面提供了一项策略,用于规划和运行 Spanner 概念验证 (POC)。它深入介绍了 POC 的关键方面,例如实例配置、架构设计、数据加载和性能评估。它重点介绍了评估 Spanner 功能的基本步骤,并帮助您确定与采用 Spanner 相关的潜在风险和益处。

除了验证 Spanner 的技术能力之外,POC 还具有以下两个用途:

  • 帮助您了解 Spanner 为您的应用场景带来的好处
  • 帮助您发现采用 Spanner 相关的风险

Spanner POC 包含各种评估方面,每个方面都经过自定义,以满足您的特定业务和技术目标,如下图所示。

Spanner 概念验证

本文档中的准则可帮助您评估上述各个方面。

  • 性能和可伸缩性可帮助您了解 Spanner 如何处理特定的工作负载、延迟时间要求以及各种实例配置的影响。这些测试可以展示 Spanner 的无缝扩缩能力。

  • 监控功能可帮助您评估 Spanner 是否提供有效数据库操作所需的分析洞见。此评估包括:

    • 用于分析查询执行计划的选项
    • 系统资源利用率
    • 用于配置提醒的选项

    POC 可以揭示需要解决的差距,以便全面优化运营效率。

  • 安全性和合规性是确定 Spanner 是否适合您的组织的关键。这包括各项评估,以确保 Spanner 在提供强大的合规性优势的同时,还能有效缓解安全风险,例如:

    • 加密选项,例如用于传输中数据和静态数据的 CMEK 或 EKM
    • 最小权限访问权限控制态势
    • 审核日志记录
    • 遵守法规要求
  • 备份和灾难恢复 (DR) 能力对于确保运营和数据恢复能力至关重要。POC 可以验证 Spanner 的灾难恢复功能,例如时间点恢复和可用性。

  • 迁移可行性是指了解从当前数据库解决方案过渡到 Spanner 的复杂程度。评估架构兼容性、迁移工具和应用变更有助于您量化所需投资,并确定采用 Spanner 的风险和益处。

在评估期间,建议您探索 Spanner 的功能集,以确保它满足您应用的功能要求。这可能包括测试其全局一致性、SQL 查询功能或与其他 Google Cloud 服务的集成。

虽然评估可以突出显示 Spanner 的独特优势(例如跨区域的一致性),但也可以发现潜在风险,例如与现有应用架构的集成工作。

POC 活动生命周期

此 POC 将引导您完成以下步骤。请按照本文档中的建议,针对您的特定应用场景设置和评估 Spanner。

生命周期包括规划、配置、规模调整、数据加载、负载测试、监控和优化。

规划 POC

规划步骤

成功的 POC 的基础在于确定明确且可衡量的目标,这些目标应与技术和业务优先级保持一致。避免使用模糊的目标,例如探索 Spanner 的潜力,因为这类目标往往会导致工作重点不明确,结果也不确定。您应将 POC 目标与具体目标相关联,例如实现 99.999% 的可用性、减少停机时间,或在将吞吐量提高 200% 的同时,将事务延迟时间保持在 20 毫秒以下。

Spanner 的独特架构非常适合需要超强可伸缩性的工作负载,因此根据您的应用场景评估可伸缩性是一个不错的起点。测试场景应包括:

  • 处理典型运营负载
  • 管理流量激增
  • 高效缩减

这些测试有助于您了解 Spanner 在不同条件下的性能,以及它是否满足您在可伸缩性方面的技术要求。具体可行的目标不仅有助于构建 POC,还能为评估成功与否奠定坚实的基础。

定义量化评估标准

包含清晰、可衡量的指标和离散成功标准的评分标准对于得出 POC 是否达到其目标的结论至关重要。例如,除了测试效果之外,您还应指定以下目标:

  • 提供特定的生产级 QPS(每秒查询次数)
  • 在预定义的峰值负载下,延迟时间始终在 20 毫秒以内
  • 处理明确定义的流量激增,且不会降低性能

明确定义的标准有助于您客观评估 Spanner 是否适合您的工作负载,并为后续步骤提供富有实用价值的分析洞见。具体说明读写操作延迟时间的百分位目标值(例如 p50 和 p95)。明确定义可接受的延迟时间阈值有助于您设计符合业务需求的 Spanner 性能测试。

评估标准示例可能如下所示:

评估方面 成功标准
可用性 99.999%
安全性 需要将 CMEK 与 EKM 结合使用
在发生区域性服务中断时,可保证恢复点目标 (RPO) 0
最关键事务的延迟时间限制 p50 低于 20 毫秒
面向用户的最关键查询的延迟时间 p50 低于 100 毫秒
可扩展性 演示在 1 小时内,可以将每秒 10,000 次事务的规模扩大到每秒 100,000 次事务,且 p50 延迟时间低于 20 毫秒

确定评估用例的范围

POC 不应需要进行全面迁移。而是应侧重于测试具有代表性的工作负载或系统的关键组件。例如,确定对您的运营至关重要的关键查询、关键事务形状或特定数据驱动型工作流。缩小范围以降低复杂性,同时确保结果的相关性和意义。这种方法提供了一种可管理的方式来评估 Spanner 的能力,而不会因整个系统迁移的复杂性而不堪重负。

选择 Spanner 实例配置

Spanner 配置步骤

创建用于评估的 Spanner 实例时,请选择满足您的业务要求的实例配置,包括地理位置和服务可用性 SLA。Spanner 提供各种配置,包括单区域、多区域和双区域。每种配置都旨在满足不同的延迟时间、可用性和冗余要求。

  • 单区域配置将数据存储在一个 Google Cloud 区域中,可在该区域内实现低延迟和高性价比。这些拓扑非常适合需要区域内可用区级冗余的工作负载,可提供 99.99% 的可用性。
  • 双区域配置会在一个国家/地区的两个区域之间复制数据,每个区域中都有一个见证者副本,用于故障切换。与单区域设置相比,此配置可提供更高的可用性 (99.999%) 和容错能力。这些拓扑非常适合具有严格合规性(例如数据驻留)或地理位置邻近性要求的工作负载。
  • 多区域配置可跨多个区域复制数据,确保极高的可用性和区域性服务中断恢复能力。这些拓扑非常适合需要地理位置冗余且可用性高达 99.999% 的应用。

跨区域实例中的延迟时间注意事项

在双区域和多区域配置中,Spanner 副本的地理分布可能会影响延迟时间。写入延迟时间取决于主要区域(用于协调读写事务)与其他区域(用于确认每次写入操作)的邻近性。将应用的计算资源放置在靠近主要区域的位置可减少往返延迟并最大限度地缩短延迟时间。

您可以修改数据库的主要区域,以满足您的应用的需求。对于只读操作,Spanner 可以从最近的副本处理过时数据读取,从而缩短延迟时间,而强一致性读取可能涉及主要区域,从而可能会增加操作延迟时间。为了优化多区域设置中的延迟时间,请战略性地选择主要区域,将服务的计算资源与主要区域放置在同一位置,并针对读取密集型工作负载利用过时数据读取。

满足应用要求的配置

为应用选择实例配置时,请考虑可用性、延迟时间和数据驻留要求等因素。例如,如果您的应用需要为特定地理区域的用户提供低延迟响应,则区域级实例可能就足够了。不过,对于需要更高可用性或为全球分布的用户提供服务的应用,多区域配置会更合适。

首先,请使用与应用的生产要求密切相关的配置来评估性能。请注意,不同配置的延迟时间和费用各不相同,因此请根据您的应用场景需求量身定制 POC 环境。对于多区域部署,请模拟地理服务分布并测试延迟时间,以确保配置符合您的生产要求。如需了解详情,请参阅 Spanner 多区域的主要区域布置指导

Spanner 规模调整

调整 Spanner 规模的步骤

为 Spanner 实例预配初始计算容量,以确保它能在 POC 期间有效处理评估工作负载。初始实例大小应与预期工作负载相符,并考虑每秒读取和写入查询次数 (QPS)、查询复杂性和并发级别。

从合理的假设开始,您可以建立基准,并根据观察到的性能逐步调整规模。您可以根据 Spanner 的参考基准中的规模调整指导来确定基准实例配置。

在 POC 期间,规模调整应是迭代的过程。首先进行初始设置,然后监控延迟时间和 CPU 利用率等关键指标,并根据需要调整分配的计算容量。这样可确保您在复制与生产环境类似的条件时,能够验证 Spanner 的可伸缩性和性能。

典型的工作负载模式(例如流量稳定与需求波动)应会影响规模调整方法。启用自动扩缩后,Spanner 会根据工作负载强度动态预配计算资源容量。

架构设计

架构设计步骤

架构设计是 Spanner POC 的一个关键方面,因为您组织数据的方式会直接影响性能和可伸缩性。

精心设计的架构是展示 Spanner 在 POC 中的功能的基础。负载测试通常会发现潜在的瓶颈或效率低下的问题,从而为创建最佳架构的迭代优化提供信息。

具备可扩缩的设计

为 Spanner 创建数据库架构时,务必要考虑其分布式架构。以下是一些关键的注意事项和优化措施:

  • 主键:选择可在键空间内均匀分布数据的主键,避免单调递增键(例如时间戳),以免在分块上造成热点。
  • 索引:设计索引以优化查询性能,同时注意它们对写入性能和存储费用的影响。过多或规划不当的索引可能会带来不必要的开销。
  • 表交织:使用表交织来优化相关数据的访问模式。这可能会减少跨进程通信并提高查询效率。

请参阅 Spanner 架构设计最佳实践,以避免常见误区,并设计支持高性能和可伸缩性的架构。

您可以在 Google Cloud 控制台中创建草稿架构,如下图所示。

在控制台中创建草稿架构。

使用 Spanner 迁移工具进行架构迁移

Spanner 迁移工具 (SMT) 可简化从关系型数据库(包括 MySQL 或 PostgreSQL)迁移时的架构创建过程。SMT 可自动生成架构,并提供基本优化,例如建议索引和架构调整。虽然 SMT 提供了一个良好的起点,但通常需要进行手动优化,以使架构符合您的特定应用场景或工作负载模式。

使用迭代式架构设计流程

虽然初始架构提供了起点,但它不太可能是完美的。为 POC 创建架构并非一次性任务,而是一个迭代过程,随着您从测试中获得更多分析洞见,架构也会不断演变。强大的架构对于应用性能至关重要;实现这一点需要经过深思熟虑的初始设计,利用 SMT 等工具,并根据负载测试结果进行迭代优化。按照此流程操作,您可以确保架构有效地满足应用的需求。您还将了解如何充分利用 Spanner 功能。

数据加载

成功的 Spanner POC 依赖于将代表性数据加载到数据库中,以验证架构设计并模拟应用工作流。我们推荐了几种可简化此流程的工具。如需加载您自己的数据,Spanner 提供以下选项:

  • BigQuery 的反向提取、转换和加载 (ETL) 到 Spanner 是一种易于使用的集成式数据加载机制,可让您使用基于 SQL 的转换将数据加载到 Spanner 中。此方法非常适合各种数据格式,包括 JSON 等半结构化数据。
  • 对于 MySQL 和 PostgreSQL 等关系型数据库,Spanner 迁移工具 (SMT) 可自动执行架构创建、数据类型映射和批量数据加载。
  • 对于扁平文件格式,Google 提供了 CSV 到 Spanner 和 Avro 到 Spanner Dataflow 模板,以便为批量数据加载创建手动架构定义。对于 JDBC 兼容的数据库,Google 提供了 JDBC 到 Spanner Dataflow 模板。

如需详细了解这些选项,请参阅自带数据

如果没有可用的示例数据,您可以使用合成数据生成工具(例如来自 Machmeter 的 JMeterQuickPerf)来帮助您创建适合您的架构和应用场景的数据集。如需了解详情,请参阅生成示例数据

自带数据

自带数据步骤

如果您有要用于 POC 的可用示例数据,则可以通过多种方式将该数据加载到 Spanner 中。

来源 工具 架构创建 转换 数据大小
MySQL SMT 自动 仅数据类型转换
PostgreSQL SMT 自动 仅数据类型转换
任何 JDBC JDBC 到 Spanner 手动 仅数据类型转换
CSV CSV 到 Spanner 手动 仅数据类型转换
BigQuery 反向 ETL 手动 支持复杂的转换
Avro Avro 到 Spanner 手动 仅数据类型转换
BigQuery 反向 ETL 手动 支持复杂的转换
JSON BigQuery 反向 ETL 手动 支持复杂的转换

BigQuery 反向 ETL 到 Spanner

借助 BigQuery 反向 ETL 到 Spanner,您可以快速注入各种数据源,并使用 SQL 将其转换为 BigQuery 表。然后,您可以将数据从 BigQuery 表导出到 Spanner 表。它对于半结构化数据(例如 JSON)特别有用,这些数据通常源自 NoSQL 数据源的导出。虽然 BigQuery 具有自动架构检测功能,但 Spanner 架构创建是手动完成的,需要您在加载数据之前定义架构。

Spanner 迁移工具

为了快速开始 POC,您可以使用 Spanner 迁移工具 (SMT) 将数据从 MySQL 和 PostgreSQL 来源迁移到 Spanner。SMT 可自动完成架构创建过程,将来源数据库中的数据类型映射到 Spanner 中的等效类型。它还会提供 Spanner 特有的架构优化建议。因此,对于自动架构转换足以满足需求的简单迁移,该工具特别有用。

SMT 提供了一个界面,可引导您完成迁移过程。在此过程中,您需要选择来源数据库,并查看有关架构设计的建议和选项。

Dataflow 模板

Dataflow 是一项全托管式服务,专为可伸缩的数据处理而设计,因此非常适合用于加载大量数据。

Google 针对常见加载模式提供了以下开源模板:

  • CSV to Spanner 可将存储在 Cloud Storage 中的 CSV 文件中的数据加载到 Spanner 中。
  • Avro to Spanner 可从 Cloud Storage 加载现有的 Avro 数据文件。
  • JDBC to Spanner 可从支持 JDBC 的数据库加载数据。

使用这些模板时,您需要在开始加载数据之前手动创建 Spanner 架构。

Dataflow 可自动横向扩缩以适应任何规模的数据集,即使是 TB 级数据集,也能确保将数据高效注入到 Spanner 中。这种可伸缩性需要付出一些代价:

  • Dataflow 流水线需要手动配置,以定义架构、数据映射和执行参数,从而实现最佳执行效果。
  • Dataflow 提供了大规模数据迁移所需的灵活性和强大功能,但与其他工具相比,可能需要投入更多精力进行设置和管理。

生成示例数据

生成示例数据步骤。

如果您没有示例数据,但有特定的应用场景,可以根据自己的需求对架构进行建模,并使用工具生成具有代表性的数据集。借助这些工具,您可以为 Spanner 填充有意义的数据,以验证架构设计和应用工作流。

来自 Machmeter 的 JMeter

来自 Machmeter 的 JMeter 提供了使用 JMeter 为 Spanner 生成示例数据的示例。Machmeter 侧重于应用场景驱动的示例,因此非常适合作为生成在结构上与预期生产架构类似的数据模式的起点。提供的示例包括用于批量插入和其他操作的脚本。您可以调整脚本,以大规模生成合成数据集。如需了解详情,请参阅 Machmeter 仓库文档

QuickPerf

QuickPerf 随 Spanner JDBC 驱动程序一起分发。QuickPerf 提供基于 SQL 的脚本,可快速创建具有代表性的数据集,用于测试架构完整性和数据库行为。这种方式只需少量工作即可快速生成中小型且不太复杂的数据集。

负载测试

负载测试步骤

通过负载测试,您可以观察 Spanner 在处理工作负载时的性能,确保数据库具有可满足生产需求的最佳配置。前面介绍的两个工具(来自 Machmeter 的 JMeterQuickPerf)在模拟工作负载和衡量吞吐量、延迟时间和资源利用率等性能指标方面特别有效。

Apache JMeter 通过 Machmeter 项目得到了增强,为使用 Spanner 进行分布式负载测试提供了一个强大的框架。Machmeter 包含预构建的 JMeter 配置,专门用于模拟 Spanner 工作负载。您可以调整这些配置,以执行具有代表性的查询、事务和批量操作,从而衡量 Spanner 在不同场景下的性能。

JMeter 能够模拟并发用户和事务,因此非常适合用于测试 Spanner 实例的可伸缩性和弹性。您可以使用 Kubernetes 或托管式服务 GKE 以分布式模式部署 JMeter,从而扩缩测试环境。这些结果可帮助您深入了解 Spanner 如何管理特定工作负载、在需求不断增加的情况下进行扩缩,以及在高峰负载期间的表现。

如需了解详情和配置示例,请参阅 Machmeter 仓库

QuickPerf 是一种轻量级基准化分析工具,旨在用于对 Spanner 进行性能测试。它侧重于以最少的设置生成性能指标,让您可以快速迭代优化。QuickPerf 易于配置,尤其适合小规模测试以及需要快速衡量特定架构或查询优化对性能的影响的场景。

负载测试最佳实践

在进行负载测试时,请务必遵循 Spanner 的最佳实践,以确保获得准确且切实可行的结果。

  • 预热期:在扩缩节点或引入新工作负载后,允许 Spanner 经历一段预热期(通常为 30 分钟或更长时间),以达到稳定状态。
  • 衡量相关指标:侧重于吞吐量(每秒操作数)、延迟时间百分位(例如 p50、p95)和 CPU 利用率等指标,以了解 Spanner 如何处理您的工作负载。
  • 运行长时间基准比较:为了获得更具代表性的结果,请运行长时间(例如超过 1 小时)的负载测试,以考虑重新平衡和后台维护任务等系统行为。
  • 扩缩测试:测试扩容和缩容场景,以观察 Spanner 在不同节点配置和峰值负载下的行为。

您可以结合使用 JMeter Machmeter 和 QuickPerf 等工具以及负载测试的最佳实践,有效地评估 Spanner 的性能、找出瓶颈并优化数据库,以满足工作负载的需求。

监控

监控步骤

为了在 POC 期间有效演示 Spanner 的性能和可伸缩性(尤其是在负载下),您需要深入了解其运行特征。Spanner 提供了一套全面的监控和诊断工具,旨在让您深入了解数据库性能的各个方面。此工具集提供了一系列资源,从指标信息中心到详细的系统表格,可帮助您找出瓶颈、验证设计选择并优化性能。

系统分析洞见可深入观测 Spanner 实例的性能和运行健康状况。它以可调整粒度级别提供多个方面的指标和分析洞见,包括 CPU 利用率、延迟时间、吞吐量等。在 POC 期间,这是在测试时观测 Spanner 行为的起点。借助系统分析洞见,您可以快速找出性能瓶颈,例如高 CPU 利用率或读写延迟时间增加。为后续调查奠定基础。

查询分析洞见提供自上而下的查询执行视图,首先根据 CPU 时间、执行次数和平均延迟时间等指标识别最频繁和最昂贵的查询。更深入地了解,查询分析洞见可让您检查详细的执行计划,包括查询每个步骤的统计信息,并找出导致速度变慢的特定操作。它还提供了一些功能,可用于调查历史性能趋势,以及比较不同时间段的查询性能。这有助于您识别回归或架构和代码更改的影响。其他工具(例如索引顾问)会分析您的查询,以推荐可提高查询性能的新索引或更改后的索引。

事务分析洞见可让您深入了解事务性能,其中包含事务延迟时间、提交等待时间、读取和写入的行数和字节数以及分布式事务中的参与者等详细指标。这些指标可发现高延迟或中止的事务,并提供有关其特征的详细信息。在 POC 负载测试期间,事务分析洞见对于评估系统在压力下的事务效率至关重要。这样,您就可以在负载增加时监控并发现任何性能下降。分析单个事务有助于您找出导致速度变慢的原因,例如长时间运行的事务阻塞其他事务,或者单个事务读取或写入的数据量过大。借助事务分析洞见提供的信息,您可以进行有针对性的调整,例如优化事务边界、优化事务内的查询,或调整架构以减少典型事务涉及的数据量。这样可确保 POC 能够展示 Spanner 在预期负载水平下保持事务一致性和性能的能力。

锁定分析洞见可让您深入了解事务锁定行为,帮助您识别和解决锁争用问题。它会显示有关锁等待的信息,包括导致问题的特定行键范围。在 POC 负载测试期间,锁分析洞见对于确定事务性锁冲突是否导致可伸缩性限制至关重要。随着并发负载的增加,事务可能会开始争相更新相同的数据,从而导致等待时间增加和吞吐量减少。此信息有助于您进行架构优化、事务边界修改和应用逻辑调整。这些操作可缓解争用,并确保 Spanner 数据库在预计的工作负载下保持性能,防止因锁定机制而导致性能下降。

热点分析洞见可发现因 hotspotting 情况而导致的性能瓶颈,尤其是延迟时间增加。当负载较高且不均匀时,通常会出现热点。热点的常见原因如下:

  • 架构设计欠佳
  • 主键选择
  • 将操作集中在一小部分数据,而不是在节点之间均匀分布的访问模式

在 POC 负载测试期间,热点分析洞见可帮助您确定在何处优化架构。例如,您可能需要调整主键或修改二级索引,以防止出现热点。

Key Visualizer 可直观地呈现数据库在一段时间内的使用模式,涵盖表和索引的整个键空间。它会生成显示读取和写入活动的热图,突出显示高强度区域和可能存在问题的模式。在 POC 期间,此工具可帮助验证架构设计并确定潜在的可伸缩性限制。随着负载的增加,您可以观察工作负载在键空间以及相应表和索引中的分布情况。

自省表(主要是其 Spanner_SYS 表系统)可提供有关数据库内部状态和性能的丰富信息。这些表会显示有关查询执行、事务行为、锁争用和架构详情的详细统计信息。在 POC 负载测试期间,除了上述数据分析工具之外,这些自省表还提供了一种数据驱动的性能诊断方法。例如,您可以使用它们来排查难以检测到的数据库中的锁定冲突的根本原因,并获得可用于优化的富有实用价值的分析洞见。

优化

优化步骤

负载测试是发现 Spanner 实现中的性能问题和潜在瓶颈的关键步骤。从这些测试中获得的分析洞见应指导您在架构设计、事务行为和查询性能方面进行优化,以确保 Spanner 满足您的工作负载需求。

优化架构设计

虽然初始架构设计遵循可伸缩性和性能方面的最佳实践,但在实际条件下执行工作负载时,通常会发现需要优化的方面。负载测试可提供有价值的分析洞见,您可以深入了解架构在特定条件下的性能,从而发现 hotspotting、数据分布不均或查询性能低效等问题。

优化侧重于对以下方面进行微调,以与应用的负载特征保持一致。

  • 主键调整:如果负载测试发现热点或数据分布不平衡,请查看主键设计。例如,考虑在键前缀中添加随机性,以便在各个节点之间更均匀地分布数据,同时保持查询效率。
  • 索引优化:通过负载测试可以发现,冗余索引或过度索引是否会对写入吞吐量产生不利影响。移除不必要的索引或重构现有索引,以提高查询性能。评估索引选择性,并确保它们与典型的查询模式保持一致。
  • 交织表和层次结构:分析相关表是否可以受益于表交织,以缩短查询延迟时间。根据测试期间观察到的访问模式调整交织决策。相反,如果层次结构导致意外开销,请考虑单独对这些表进行建模。

如需了解如何构建可伸缩的架构,请参阅 Spanner 架构设计最佳实践

优化事务语义和查询

负载测试通常会突出显示事务和查询执行方面的效率低下问题,例如高争用或锁定问题。优化事务语义和查询结构,可最大限度地提高吞吐量并最大限度地缩短延迟时间:

  • 事务模式:为每个工作负载操作使用适当的事务模式。例如,对于不修改数据的查询,请使用只读事务;对于批量更新和删除操作,请使用分区 DML。
  • 批处理:尽可能使用批量写入操作,以减少多次往返产生的开销。
  • 查询优化:重构查询以仅包含必要的列和行,充分利用索引,并在应用中使用查询参数来减少开销。

如需了解优化策略,请参阅事务概览SQL 最佳实践

迭代式负载测试

优化是一个迭代过程。每次对架构或查询进行重大更改后,都要进行负载测试,以验证改进效果并确保不会造成新的瓶颈。

模拟具有不同并发级别、事务类型和数据量的实际应用场景,以确认 Spanner 在峰值和稳态条件下能按预期运行。

要监控的关键指标

在优化期间,跟踪延迟时间(p50、p99)、吞吐量和 CPU 利用率等关键指标。

后续步骤