Google Cloud 架构框架中的本文档提供了根据数据库设计部署系统的最佳实践。您将学习如何设计、迁移和扩缩数据库、加密数据库信息、管理许可以及监控数据库中的事件。
关键服务
本文档在架构框架系统设计类别中提供了包含各种 Google Cloud 数据库服务的最佳实践。下表简要介绍了这些服务：
| Google Cloud 服务 | 说明 |
|---|---|
| Cloud SQL | 一项全代管式数据库服务，可让您设置、维护、管理和控制使用 Cloud SQL for PostgreSQL、Cloud SQL for MySQL 和 Cloud SQL for SQL Server 的关系型数据库。Cloud SQL 可提供出色的性能和扩容潜力。它托管在 Google Cloud 上，能为在任何地方运行的应用提供数据库基础架构。 |
| Bigtable | 可以扩展到数十亿行和数千列的表，让您能够存储 TB 级甚至是 PB 级的数据。每行中都会有一个被编入索引的值；这个值称为行键。使用 Bigtable 以极短的延迟时间存储大量单键数据。它可以低延迟地支持高读写吞吐量，是 MapReduce 操作的数据源。 |
| Spanner | 专为云端打造的一款可扩缩的全球分布式企业数据库服务，融合了关系型数据库结构与非关系型数据库横向扩容能力的优势。这种优势上的融合可以跨行、跨区域、跨洲实现高性能事务和强一致性。Spanner 提供可用性高达 99.999% 的服务等级协议 (SLA)，它没有计划内停机时间，同时拥有企业级安全性。 |
| Memorystore | 一项适用于 Google Cloud 的全代管式 Redis 服务。在 Google Cloud 上运行的应用可以使用高度可用、可扩缩的安全 Redis 服务来提高性能，而无需管理复杂的 Redis 部署。 |
| Firestore | 一个 NoSQL 文档数据库，能够自动扩缩、具备出色的性能，并且易于进行应用开发。虽然 Firestore 界面具有许多与传统数据库相同的功能，但它是 NoSQL 数据库，它与传统数据库在描述数据对象间关系的方式方面有所不同。 |
| Firebase Realtime Database | 托管在云中的数据库。Firebase 以 JSON 格式存储数据，并实时同步到每个连接的客户端。当您使用 Google、iOS、Android 和 JavaScript SDK 构建跨平台应用时，所有的客户端共享一个实时数据库实例，并自动接收包含最新数据的更新。 |
| 开源数据库 | Google 合作伙伴提供不同的开源数据库，其中包括 MongoDB、MariaDB 和 Redis。 |
| AlloyDB for PostgreSQL | 与 PostgreSQL 兼容的全代管式数据库服务，适用于要求苛刻的企业工作负载。与标准 PostgreSQL 相比，处理事务性工作负载的速度快至 4 倍，运行分析型查询的速度快至 100 倍。AlloyDB for PostgreSQL 利用支持机器学习的 Autopilot 系统简化了管理。 |
选择数据库
本部分提供选择数据库以支持您的系统的最佳实践。
考虑使用代管式数据库服务
在安装您自己的数据库或数据库集群之前，请先评估 Google Cloud 代管式数据库服务。安装自己的数据库涉及维护开销，包括安装补丁程序和更新以及管理每日运营活动，例如监控和执行备份。
使用正常运行和无法正常运行的应用要求来推动数据库选择。考虑短延迟时间访问、时间序列数据处理、灾难恢复和移动客户端同步。
如需迁移数据库，请使用下表中描述的某款产品：
| 数据库迁移产品 | 说明 |
|---|---|
| Cloud SQL | 一项区域服务，支持远程区域中的读取副本、短延迟时间读取和灾难恢复。 |
| Spanner | 一款多区域产品，提供外部一致性、全球复制和可用性高达 99.999% 的服务等级协议 (SLA)。 |
| Bigtable | 一项全代管式可扩缩的 NoSQL 数据库服务，用于处理大规模分析和运营工作负载，可用性达 99.999%。 |
| Memorystore | 一项全代管式数据库服务，提供了两种常用的代管版开源缓存解决方案：Redis 和 Memcached。 |
| Firebase Realtime Database | Firebase Realtime Database 是一种托管在云中的 NoSQL 数据库，可让您实时存储和同步用户数据。 |
| Firestore | 一个 NoSQL 文档数据库，能够自动扩缩、具备出色的性能，并且易于进行应用开发。 |
| 开源 | 替代数据库选项，包括 MongoDB 和 MariaDB。 |
数据库迁移
当您将现有工作负载迁移到 Google Cloud 时，为确保用户的应用不发生停机，请务必选择支持您的要求的数据库技术。如需了解数据库迁移方案和最佳实践，请参阅数据库迁移解决方案和同构数据库迁移最佳实践。
规划数据库迁移包括以下操作：
- 评估和发现当前数据库。
- 定义迁移成功标准。
- 设置适用于迁移和目标数据库的环境。
- 在目标数据库中创建架构。
- 将数据迁移到目标数据库。
- 验证迁移，以验证所有数据都已正确迁移并且位于数据库中。
- 创建回滚策略。
选择迁移策略
选择适当的目标数据库是成功迁移的关键因素之一。下表提供了一些使用场景的迁移方案：
| 使用场景 | 建议 |
|---|---|
| Google Cloud 中的新开发项。 | 选择专为云构建的某个代管式数据库（Cloud SQL、Spanner、Bigtable 或 Firestore），以满足您的使用场景要求。 |
| 直接原样迁移。 | 选择兼容的代管式数据库服务，例如 Cloud SQL、MYSQL、PostgreSQL 或 SQLServer。 |
| 您的应用需要对 CloudSQL 不支持的数据库进行精细化访问。 | 在 Compute Engine 虚拟机上运行数据库。 |
使用 Memorystore 支持缓存数据库层
Memorystore 是支持亚毫秒级延迟的全代管式 Redis 和 Memcached 数据库。Memorystore 与开源 Redis 和 Memcached 完全兼容。如果您在应用中使用这些缓存数据库，则无需在代码中进行应用级更改即可使用 Memorystore。
使用 Bare Metal 服务器运行 Oracle 数据库
如果您的工作负载需要 Oracle 数据库，请使用 Google Cloud 提供的 Bare Metal 服务器。此方法适用于直接原样迁移迁移策略。
如果需要将工作负载迁移到 Google Cloud 并在基准工作负载正常运行后进行现代化改造，请考虑使用 Spanner、Bigtable 和 Firestore 等代管式数据库选项。
专为云构建的数据库是在云基础架构上自下而上构建的现代化代管式数据库。这些数据库提供了独特的默认功能，如可扩缩性和高可用性，如果您运行自己的数据库，则很难实现这些功能。
对数据库进行现代化改造
无论您是在云中设计新应用，还是要将现有数据库迁移到云中，请在系统设计过程中尽早规划您的数据库策略。Google Cloud 为开源数据库（例如 Cloud SQL for MySQL 和 Cloud SQL for PostgreSQL）提供代管式数据库选项。我们建议您在迁移过程中对数据库进行现代化改造，并将其准备它以支持未来的业务需求。
将固定数据库与现成的应用配合使用
现成商业 (COTS) 应用需要固定类型的数据库和固定配置。直接原样迁移通常是最适合 COTS 应用的迁移方法。
验证团队的数据库迁移技能组合
根据团队的数据库迁移功能和技能组合选择云数据库迁移方法。使用 Google Cloud Partner Advantage 寻找在整个迁移过程中为您提供支持的合作伙伴。
设计数据库以满足 HA 和 DR 要求
在设计数据库以满足高可用性 (HA) 和灾难恢复 (DR) 要求时，请评估可靠性与费用之间的权衡取舍。专为云构建的数据库服务会在一个区域或多个区域中创建数据的多个副本，具体取决于数据库和配置。
某些 Google Cloud 服务具有多区域变体，例如 BigQuery 和 Spanner。如需应对区域级故障，请在设计中尽可能使用这些多区域服务。
如果您在 Compute Engine 虚拟机上设计数据库，而不是在 Google Cloud 上使用代管式数据库，请确保运行数据库的多个副本。如需了解详情，请参阅“可靠性”类别中的在设计时确保可扩缩性和高可用性。
指定云区域以支持数据驻留
数据驻留描述静态存储数据的实际位置。请考虑选择特定的云区域，以根据您的数据驻留要求部署数据库。
如果您在多个区域中部署数据库，则它们之间可能存在重复数据，具体取决于您如何配置数据库。选择将数据静态保存在所需区域内的配置。某些数据库（如 Spanner）提供默认的多区域复制功能。您还可以通过设置包含资源位置限制条件的组织政策来强制执行数据驻留。如需了解详情，请参阅限制资源位置。
设计数据驻留时包含灾难恢复
在数据驻留方案中添加恢复时间目标 (RTO) 和恢复点目标 (RPO)，并考虑 RTO/RPO 与灾难恢复解决方案费用之间的权衡取舍。RTO/RPO 数字越小，费用就越高。如果您希望系统更快地从中断中恢复，则系统运行费用会增加。此外，请将客户满意度纳入灾难恢复方法中，以确保您的可靠性投资是合适的。如需了解详情，请参阅 100% 可靠性是错误的目标和灾难恢复规划指南。
让数据库符合 Google Cloud 的规定
为工作负载选择数据库时，请确保所选服务符合运营所在的地理区域以及数据实际存储位置的规定。如需详细了解 Google 的认证和合规标准，请参阅合规产品。
加密
本部分提供确定加密要求并选择加密密钥策略以支持您的系统的最佳实践。
确定加密要求
加密要求取决于多个因素，包括公司安全政策和合规性要求。默认情况下，存储在 Google Cloud 中的所有数据均采用 AES256 进行静态加密，您无需执行任何操作。如需了解详情，请参阅 Google Cloud 中的静态加密。
选择加密密钥策略
确定您是否要自行管理加密密钥，还是要使用代管式服务。Google Cloud 支持这两种场景。如果您希望全代管式服务来管理您在 Google Cloud 上的加密密钥，请选择 Cloud Key Management Service (Cloud KMS)。如果您希望管理加密密钥以更好地控制密钥的生命周期，请使用客户管理的加密密钥 (CMEK)。
如需在 Google Cloud 外部创建和管理加密密钥，请选择以下任一选项：
- 如果您使用合作伙伴解决方案来管理密钥，请使用 Cloud External Key Manager。
- 如果您在本地管理密钥，并想使用这些密钥在 Google Cloud 上加密数据，请将这些密钥导入到 Cloud KMS，作为 KMS 密钥或硬件密钥模块 (HSM) 密钥。使用这些密钥在 Google Cloud 上加密数据。
数据库设计和扩缩
本部分提供设计和扩缩数据库以支持您的系统的最佳实践。
使用监控指标评估扩缩需求
使用现有监控工具和环境中的指标建立一个基准，以便基本了解数据库大小和扩缩要求，例如，为数据库实例合理调整容量和设计扩缩策略。
对于新的数据库设计，请根据传送应用的预期负载和流量模式确定扩缩数量。如需了解详情，请参阅监控 Cloud SQL 实例、使用 Cloud Monitoring 进行监控和监控实例。
网络和访问权限
本部分提供管理网络和访问权限以支持您的系统的最佳实践。
在专用网络中运行数据库
在专用网络中运行您的数据库，并且仅向需要与数据库交互的客户端授予受限访问权限。您可以在 VPC 内创建 Cloud SQL 实例。Google Cloud 还提供 VPC Service Controls for Cloud SQL、Spanner 和 Bigtable 数据库，以确保只有授权 VPC 网络中的客户端可以访问这些资源。
向用户授予最低权限
Identity and Access Management (IAM) 用于控制对 Google Cloud 服务（包括数据库服务）的访问权限。为了将未经授权的访问风险降至最低，请向用户授予最小数量的权限。如需获得数据库的应用级访问权限，请使用权限数量最少的服务账号。
自动化和合理调整容量
本部分提供定义自动化和合理调整容量以支持您的系统的最佳实践。
将数据库实例定义为代码
迁移到 Google Cloud 的好处之一是能够自动执行基础架构以及工作负载的其他方面（例如计算和数据库层）。借助 Google Deployment Manager 和 Terraform Cloud 等第三方工具，您可以将数据库实例定义为代码，从而应用一致且可重复的方法来创建和更新数据库。
使用 Liquibase 对数据库进行版本控制
Cloud SQL 和 Spanner 等 Google 数据库服务支持 Liquibase，它是数据库的开源版本控制工具。Liquibase 可帮助您跟踪数据库架构更改、回滚架构更改以及执行可重复的迁移。
测试和调整数据库以支持扩缩
对数据库实例执行负载测试并根据测试结果进行调整，以满足应用的要求。通过对关键性能指标 (KPI) 进行负载测试或使用源自当前数据库的监控 KPI，来确定数据库的初始规模。
在创建数据库实例时，请从基于测试结果或历史监控指标的大小开始。使用云中预期的负载来测试数据库实例。然后微调实例，直到数据库实例上预期的负载获得所需的结果。
根据扩缩要求选择合适的数据库
扩缩数据库与扩缩计算层组件不同。数据库具有状态；若数据库的实例无法处理负载，请考虑采用适当的策略来扩缩数据库实例。扩缩策略因数据库类型而异。
请参阅下表，以了解适合扩缩使用场景的 Google 产品。
| 使用场景 | 推荐产品 | 说明 |
|---|---|---|
| 当您需要纵向扩充服务容量和存储空间时，请向数据库添加节点来横向扩缩数据库实例。 | Spanner | 专为云构建的关系型数据库。 |
| 添加节点以扩缩数据库。 | Bigtable | 全代管式 NoSQL 大数据数据库服务。 |
| 自动处理数据库扩缩。 | Firestore | 适用于进行移动、Web 和服务器开发的灵活且可扩缩的数据库。 |
| 为处理更多查询，请纵向扩充 Cloud SQL 数据库实例，使其具有更多计算和内存容量。在 Cloud SQL 中，存储层与数据库实例相分离。您可以选择在存储层容量快满时自动对其进行扩缩。 | Cloud SQL | 全代管式数据库服务，可帮助您在 Google Cloud 上设置、维护、管理和控制关系型数据库。 |
运维
本部分提供用于运营以支持您的系统的最佳实践。
使用 Cloud Monitoring 监控数据库并设置提醒
使用 Cloud Monitoring 监控数据库实例并设置提醒，以通知事件的相应团队。如需了解高效的提醒功能最佳实践，请参阅构建高效的提醒。
所有专为云构建的数据库都提供日志记录和监控指标。每项服务都提供了一个信息中心，用于直观呈现日志记录和监控指标。所有服务的监控指标都与 Google Cloud Observability 集成。Spanner 提供查询自检工具，例如用于调试和根本原因分析的 Key Visualizer。Key Visualizer 提供以下功能：
- 通过为数据库生成可视化报告来帮助您分析 Spanner 使用模式。这些报告按行范围显示一段时间内的使用模式。
- 深入了解大规模使用模式。
Bigtable 还提供了一个 Key Visualizer 诊断工具，可帮助您分析 Bigtable 实例使用模式。
许可
本部分提供购买许可以支持您的系统的最佳实践。
在购买按需许可和现有许可之间进行选择
如果您使用 Cloud SQL for SQL Server，则不支持自带许可。您的许可费用根据每小时每核心的用量计算。
如果您想使用现有的 Cloud SQL for SQL Server 许可，请考虑在计算虚拟机上运行 Cloud SQL for SQL Server。如需了解详情，请参阅 Microsoft 许可和在购买按需许可和自带现有许可之间进行选择。
如果您使用 Oracle，并且要迁移到适用于 Oracle 的裸金属解决方案，则可以自带许可。如需了解详情，请参阅规划裸金属解决方案。
迁移时间轴、方法和工具集
本部分提供规划和支持数据库迁移以支持您的系统的最佳实践。
确定数据库现代化改造的就绪情况
评估您的组织是否已准备好对数据库进行现代化改造，并使用专为云构建的数据库。
在规划工作负载迁移时间轴时，请考虑对数据库进行现代化改造，因为现代化改造可能会影响您的应用端。
在规划迁移时纳入相关的利益相关方
如需迁移数据库，请完成以下任务：
- 设置目标数据库。
- 转换架构。
- 设置源数据库和目标数据库之间的数据复制。
- 调试在迁移过程中出现的问题。
- 在应用层和数据库之间建立网络连接。
- 实现目标数据库安全。
- 确保应用连接到目标数据库。
这些任务通常需要不同的技能组合，并且需要整个组织中的多个团队协作来完成迁移。在规划迁移时，请纳入所有团队（例如应用开发者、数据库管理员、基础架构和安全团队）中的利益相关方。
如果您的团队缺乏支持此类迁移的技能，则 Google 的合作伙伴可以帮助您执行迁移。如需了解详情，请参阅 Google Cloud Partner Advantage。
确定用于同构迁移和异构迁移的工具集
同构迁移是指在采用相同数据库技术的源数据库和目标数据库之间进行数据库迁移。异构迁移是指目标数据库与源数据库不同的迁移。
异构迁移通常需要执行额外的步骤，以将架构从源数据库转换到目标数据库引擎类型。数据库团队需要评估架构转换过程中遇到的难题，因为它们取决于源数据库架构的复杂性。
测试并验证数据迁移中的每个步骤
数据迁移涉及多个步骤。若要最大限度地减少迁移错误，请在迁移到下一步之前测试和验证迁移中的每个步骤。以下因素推动了迁移过程：
- 迁移是同构迁移还是异构迁移。
- 您必须拥有哪些类型的工具和技能组合才能执行迁移。
- 对于异构迁移，您需要有目标数据库引擎的使用经验。
确定持续数据复制要求
制定最初的数据迁移方案，然后将数据从源数据库持续复制到目标数据库。继续复制，直到目标稳定且应用完全迁移到新数据库为止。此方案可帮助您在数据库切换期间发现潜在的停机时间，并相应地进行规划。
如果您计划从 Cloud SQL、Cloud SQL for MySQL 或 Cloud SQL for PostgreSQL 迁移数据库引擎，请使用 Database Migration Service 以全代管式方式自动执行此过程。如需了解支持其他类型的迁移的第三方工具，请参阅 Cloud Marketplace。
建议
如需将架构框架中的指导应用到您自己的环境，建议您执行以下操作：
数据库的多租户涉及将多个客户的数据存储在共享基础架构上（在本例中为数据库）。如果您向客户提供基于软件即服务 (SaaS) 的产品，请务必了解如何以逻辑方式隔离属于不同客户的数据集，并支持其访问权限要求。此外，根据隔离级层评估您的要求。
对于 Spanner 和 Cloud SQL 等关系型数据库，您可以使用多种方法来隔离租户的数据，例如在数据库实例级层、数据库级层、架构级层或数据库表级层进行隔离。与其他设计决策一样，隔离程度与其他因素（例如费用和性能）也存在权衡取舍。IAM 政策可控制数据库实例的访问权限。
根据数据模型要求选择合适的数据库
选择键值以避免键出现 hotspotting 问题。“热点”是指表中的某个位置，该位置收到的访问请求数量超过其他位置。如需详细了解热点，请参阅架构设计最佳实践。
尽量对数据库实例进行分片。
使用连接管理最佳实践，例如连接池和指数退避算法。
避免非常大型的事务。
设计并测试应用对数据库维护更新的响应。
保护并隔离与数据库的连接。
调整数据库的规模和增长预期，以确保数据库支持您的要求。
测试 HA 和 DR 故障切换策略。
执行备份和恢复以及导出和导入操作，以便熟悉过程。
Cloud SQL 建议
- 使用专用 IP 地址网络 (VPC)。为增强安全性，请考虑以下事项：
- 使用 Cloud SQL Auth 代理支持专用网络。
- 限制公共 IP 地址访问权限
constraints/sql.restrictPublicIp。
- 如果您需要公共 IP 地址网络，请考虑以下事项：
- 使用具有有限或小范围 IP 地址列表的内置防火墙，并确保 Cloud SQL 实例要求传入连接使用 SSL。如需了解详情，请参阅配置 SSL/TLS 证书。
- 为增强安全性，请考虑以下事项：
- 不授予一般访问权限；请改用 Cloud SQL Auth 代理。
- 限制已获授权的网络
constraints/sql.restrictAuthorizedNetworks。
- 为数据库用户授予有限的权限。
后续步骤
了解数据分析最佳实践，包括以下内容：
探索架构框架中的其他类别，例如可靠性、卓越运营以及安全性、隐私权和合规性。