手册

全球电子商务平台，要求跨多个大洲提供 ACID 事务、强一致性和 99.999% 的可用性。

→采用多区域配置（例如，nam-eur-asia）的 Cloud Spanner。

原因: Spanner 是唯一提供大规模全球分布式、强一致性 ACID 事务且具有 99.999% SLA 的 GCP 托管服务。

参考↗

迁移一个大型、高性能的 Oracle OLTP 数据库，该数据库具有复杂的存储过程和分析查询需求。

→适用于 PostgreSQL 的 AlloyDB。

原因: AlloyDB 提供卓越的 PostgreSQL 性能、Oracle 兼容性功能以及用于加速分析查询 (HTAP) 的列式引擎，且不影响事务性工作负载。

参考↗

高吞吐量（每秒数百万次操作）的时间序列数据（例如 IoT、日志）摄取，要求低延迟读取和自动数据过期。

→使用行键设计为 `(entity_id)#(reverse_timestamp)` 和垃圾回收策略的 Cloud Bigtable。

原因: Bigtable 专为大规模、低延迟的键/值工作负载而设计。行键中的反向时间戳将最新数据共置，以实现高效扫描。垃圾回收处理 TTL。

参考↗

需要灵活的 schema、实时数据同步到客户端和离线支持的移动或 Web 应用程序。

→原生模式下的 Firestore。

原因: Firestore 专为这种无服务器应用后端模式而构建，通过其客户端 SDK 提供开箱即用的实时监听器和离线持久性。

参考↗

需要低于 100 毫秒延迟的 AI/ML 应用（例如 RAG、推荐）的大规模（1000 万+ 向量）相似性搜索。

→带有 pgvector 扩展和 ScaNN 索引的适用于 PostgreSQL 的 AlloyDB。

原因: AlloyDB 集成了 Google 的高性能 ScaNN 算法，用于近似最近邻 (ANN) 搜索，在大规模下优于标准向量搜索实现。

为写入密集型工作负载设计 Cloud Spanner schema，以防止单个服务器出现热点。

→设计主键时，不要使用单调递增的值（例如，序列 ID、时间戳）作为键的第一部分。而是使用 UUID、哈希值或位反转序列。

原因: Spanner 按主键字典序分布数据。顺序键将所有写入定向到单个拆分，从而创建热点。随机分布的键将写入分散到所有拆分。

参考↗

Spanner schema 具有强父子关系（例如，客户和订单），并且查询经常会获取父级及其所有子级。

→使用交错表，使用 `INTERLEAVE IN PARENT` 定义子表。

原因: 交错在存储中将子行与其父行物理共置。这使得父子联接效率极高，因为它成为单个拆分上的高度优化的范围扫描。

跟踪大量车队（每秒 5 万+ 写入）的实时位置，并能够查询特定地理区域内的车辆。

→使用以车辆位置的 GeoHash 作为前缀的行键的 Cloud Bigtable。

原因: Bigtable 处理极高的写入吞吐量。GeoHash 编码将 2D 坐标转换为 1D 字符串，其中前缀表示地理邻近度，从而实现高效的地理空间范围扫描。

存储和分析 PB 级数据（例如基因组数据、日志），并进行复杂的分析性 SQL 查询。

→将原始数据存储在 Cloud Storage 中，并使用外部表直接从 BigQuery 查询，或加载到 BigQuery 原生存储中。

原因: BigQuery 是一个专为 PB 级分析而构建的无服务器数据仓库。其存储和计算分离为 OLAP 工作负载提供了无与伦比的查询性能和成本效益。

一个用于复杂数据结构（哈希、集合）的高可用内存缓存，具有用于缓存失效的 pub/sub 功能。

→带有读取副本的 Memorystore for Redis 标准层。

原因: 标准层提供 99.9% 的 SLA 和自动故障转移。与 Memcached 不同，Redis 支持复杂数据类型和 pub/sub。读取副本可以扩展读取吞吐量。

在 Spanner 上设计一个多租户 SaaS 应用程序，要求每个租户具有强大的数据隔离和性能保证。

→将 tenant_id 作为所有表主键的第一个组成部分。为了更强的隔离性，在单个 Spanner 实例中使用每个租户一个数据库的模型。

原因: tenant_id 前缀自然地将单个租户的所有数据共置，优化查询并允许 Spanner 按租户拆分数据。每个租户一个数据库提供最强的逻辑隔离。

Cloud SQL 数据库遇到查询性能缓慢和 CPU 使用率高的问题。

→使用 Query Insights 识别资源消耗最高的查询，分析其执行计划，并找出缺失的索引或低效的模式。

原因: Query Insights 是 Cloud SQL 中用于诊断查询性能的主要内置工具。它可视化查询负载，识别等待事件，并帮助无需第三方工具即可查明根本原因。

一个组织需要一个单一的仪表板和警报策略集，用于跨多个 GCP 项目的数十个数据库实例。

→在中心项目中创建一个 Cloud Monitoring 工作区，并配置其“指标范围”以包含所有包含数据库实例的项目。

原因: 指标范围允许单个 Monitoring 工作区聚合和显示来自多个项目的指标，提供统一视图，无需数据重复或复杂配置。

需要在开发、预发布和生产环境中一致地、并使用版本控制来预配和管理 Cloud SQL 实例。

→将 Terraform 与 Google Cloud provider 结合使用。定义一个 Cloud SQL 模块，并为每个环境使用单独的 `.tfvars` 文件。

原因: Terraform 提供基础设施即代码 (IaC)，实现可重复、可审计和版本控制的部署。这避免了手动配置错误并确保了跨环境的一致性。

承包商需要临时提升的数据库访问权限，该权限必须在 4 小时后自动撤销。

→使用包含基于时间表达式 (`request.time < timestamp(...)`) 的 IAM Condition 授予必要的 IAM 角色。

原因: IAM Conditions 提供了一种原生的、安全的方式来授予有时限的访问权限，而无需容易出错的手动清理。时间戳过期后，访问权限会自动拒绝。

安全策略要求所有数据库磁盘加密都使用客户管理的密钥 (CMEK) 并进行受控轮换。

→将 Cloud SQL 或 AlloyDB 实例配置为使用来自 Cloud KMS 的密钥。配置 KMS 密钥的自动轮换。

原因: CMEK 提供对用于静态加密的密钥的控制和可审计性。Cloud KMS 无缝处理密钥生命周期管理，包括自动轮换。

合规性要求捕获在 Cloud SQL for PostgreSQL 实例上执行的所有 SQL 查询，并将日志保留 7 年。

→在该实例上启用 `pgaudit` 扩展。配置用于数据访问的 Cloud Audit Logs。创建从 Cloud Logging 到 BigQuery 的日志接收器，用于长期保留和分析。

原因: pgaudit 提供详细的 SQL 级别审计。将日志接收到 BigQuery 是实现超出 Cloud Logging 默认设置的长期、可搜索日志保留的标准且经济高效的模式。

数据分析师需要在生产 Cloud SQL 数据上运行繁重的分析查询，而不影响事务性工作负载。

→创建一个读取副本并将所有分析查询定向到它。对于更复杂的分析，可对读取副本使用 BigQuery 联合查询。

原因: 读取副本将分析读取流量与主实例完全隔离，从而保护 OLTP 性能。联合允许使用 BigQuery 强大的引擎，而无需单独的 ETL 管道。

Bigtable 集群显示 CPU 负载不均匀，一些节点利用率高，而另一些则空闲，表明存在性能瓶颈。

→使用 Cloud Console 中的 Key Visualizer 工具分析访问模式，并识别访问过于频繁的特定行键范围（热点）。

原因: Key Visualizer 是用于 Bigtable 性能问题的专用诊断工具。它提供了键访问的热力图，可以轻松识别需要通过 schema 重新设计来解决的热点。

需要将 Cloud SQL OLTP 数据库中的更改近乎实时地复制到 BigQuery 数据仓库。

→使用 Datastream 配置从源 Cloud SQL 实例直接到 BigQuery 的变更数据捕获 (CDC) 流。

原因: Datastream 是一种托管式、低延迟的 CDC 服务，可读取数据库日志，最大限度地减少对源的影响。它处理 schema 漂移并将更改可靠地传输到 BigQuery。

Cloud Run 应用程序由于流量高峰期间的快速扩展而耗尽数据库连接。

→将 Cloud SQL Auth Proxy 作为 sidecar 容器部署，并将其配置为连接池（或与 PgBouncer 等专用连接池器一起使用）。

原因: 无服务器平台可以扩展到数千个实例，从而超出数据库连接限制。连接池器将这些众多短暂的应用程序连接多路复用到一组小而稳定的数据库连接上。

将一个大型（5TB）的本地 MySQL 数据库迁移到 Cloud SQL for MySQL，最大停机时间为 30 分钟。

→使用数据库迁移服务 (DMS) 配置连续复制作业。DMS 执行初始加载，然后流式传输更改直到切换。

原因: DMS 是实现最小停机时间迁移的托管解决方案。连续复制意味着唯一的停机时间是停止写入、等待最终同步并将应用程序指向新数据库所需的时间。

参考↗

将 Oracle 数据库迁移到 AlloyDB for PostgreSQL，包括复杂的 PL/SQL 存储过程。

→使用 DMS 进行数据迁移。使用 schema 转换工具（如 Ora2Pg 或 DMS Schema Conversion）将 schema 和 PL/SQL 转换为 PL/pgSQL，然后进行手动审查和测试。

原因: 异构迁移需要数据迁移（由 DMS 处理）和 schema/代码转换。自动化工具处理大约 80% 的转换，但对于 Oracle 特定功能，始终需要手动工作。

将数据库从本地数据中心迁移到 Google Cloud 后，需要验证数据完整性和完整性。

→使用开源数据验证工具 (DVT)。将其配置为比较源和目标之间的行数、列级聚合（最小值、最大值、总和）和行级哈希值。

原因: DVT 提供了一个全面、可扩展、可定制的数据验证框架，它超越了简单的行计数，可以捕获细微的数据损坏或转换问题。

将分片的 MySQL 应用程序迁移到单个全局一致的数据库。

→使用多个并行 Dataflow 作业将每个分片并发迁移到单个 Cloud Spanner 数据库中。重新设计 schema 以消除应用程序级分片的需要。

原因: Spanner 旨在取代复杂的分片架构。使用 Dataflow 的并行迁移方法是将大型分片数据集整合到 Spanner 中最省时的方式。

将使用 Windows 身份验证 (Active Directory) 的 SQL Server 数据库迁移到 Cloud SQL for PostgreSQL。

→使用 IAM 数据库身份验证将 Cloud SQL 与 Cloud Identity 集成。通过 GCDS 将 AD 组同步到 Google Groups，并将数据库角色映射到这些组。

原因: 这种方法以云原生的方式复制了 AD 的集中式、基于组的访问控制模型，避免了手动用户/密码管理并利用了现有的身份结构。

将应用程序从 Amazon DynamoDB 迁移到 Cloud Bigtable。

→将 DynamoDB 复合主键（分区键 + 排序键）映射到由分隔符（例如，`partitionKey#sortKey`）分隔的串联 Bigtable 行键。

原因: 这种行键设计保留了 DynamoDB 复合键的查询能力，允许通过分区键前缀进行高效查找以及对排序键部分进行范围扫描。

连接到高可用性 Cloud SQL 实例的应用程序必须在没有手动干预的情况下经受住区域故障转移。

→使用 Cloud SQL Auth Proxy 和实例连接名称 (project:region:instance) 连接到数据库，而不是使用静态 IP 地址。

原因: 实例 IP 地址在故障转移期间会发生变化。Auth Proxy 和实例连接名称提供了一个稳定的端点，可以自动解析到当前主实例的 IP 地址。

参考↗

一个全球性的 Spanner 应用程序在北美和亚洲都有用户。写入主要来自北美，但亚洲用户需要低延迟读取。

→使用多区域配置，主区域位于北美 (`nam*`)。亚洲的读取将由本地只读副本提供服务。

原因: Spanner 中的写入通过主区域路由，因此将其放置在写入源附近可最大限度地减少写入延迟。其他区域的读取副本为全球分布式用户提供低延迟读取。

一个由 AlloyDB 支持的应用程序具有 10:1 的读写比，需要在保持 99.99% 可用性的同时扩展以处理高读取流量。

→将主实例配置为高可用性，并添加多个读取池实例。将读取流量直接路由到读取池。

原因: AlloyDB 高可用性提供 99.99% 的 SLA。读取池实例专为横向读取扩展而设计，将流量从主实例卸载到专用的读取优化节点。

一个带有 SSD 存储的对延迟敏感的 Cloud SQL 实例，其 I/O 性能不足。

→增加实例的预配存储大小。

原因: 在 Cloud SQL 中，读取和写入 IOPS 都与预配的持久磁盘存储量线性扩展。增加磁盘大小是提高可用 IOPS 的直接方法。

需要将有风险的 schema 更改部署到关键的 Cloud SQL 数据库，并具备快速回滚能力。

→创建生产（蓝色）实例的读取副本。将副本提升为独立实例（绿色），应用并验证 schema 更改。然后，将应用程序流量重定向到绿色实例。保持蓝色实例运行以备回滚。

原因: 此模式允许在生产规模的数据副本上充分测试更改，而不会影响实时系统。流量可以即时切换，回滚就像将流量指向蓝色实例一样简单。

需要每季度测试数据库灾难恢复计划，而不影响生产环境。

→通过从最近的生产备份中恢复来创建临时测试实例。在此测试实例上执行文档化的 DR 过程，包括模拟故障转移和应用程序重新连接测试。

原因: 在恢复的备份上进行测试提供了一个真实的环境来验证 RTO/RPO 和恢复过程，而不会有导致生产中断的风险。

Cloud Run 服务需要安全地连接到 Cloud SQL 实例，而流量不通过公共互联网。

→为 Cloud SQL 配置私有 IP。在同一 VPC 中创建一个 Serverless VPC Access 连接器，并配置 Cloud Run 服务以通过它路由流量。

原因: 这是将无服务器计算连接到 VPC 原生资源的标准安全模式。连接器桥接无服务器环境和您的 VPC，使所有流量都保留在 Google 的私有网络上。

在不停机的情况下，向一个大型、活跃写入的 Cloud Spanner 表添加一个新的、非空列。

→1. 将列添加为可为空。2. 更新应用程序代码以写入新列。3. 使用 Dataflow 批量回填现有行。4. 回填后，将列更改为 NOT NULL。

原因: 这个多步骤过程是大型表的标准在线 schema 更改模式。它避免了长时间锁定表，也避免了在单个事务中导致大规模、影响性能的回填操作。