AWS 专用数据库的优势 Vlad Vlasceanu 问答

问题 1：什么是专用数据库？

Vlad：专用数据库专门针对特定工作负载和应用程序需求。 基于互联网的应用程序的引入改变了我们对数据库的需求。因此，开发人员现在可以比以往任何时候都更快地在全球范围内访问数据库。此外，云计算的兴起改变了技术上的可能性，因为我们可以通过经济的方式构建更具弹性、可扩展的应用程序。

关系数据库不再是所有数据库工作负载的唯一最佳答案。尽管关系数据库仍然必不可少（事实上，它们还在不断增长），但“仅关系”方法在当今世界已经不适用了。随着数据在数量、速度、种类、复杂性和互连性方面的快速增长，数据库需求也发生了变化。许多具有社交、移动、物联网和全球访问需求的新应用程序无法仅使用中央关系数据库进行扩展。

此外，向专用数据库迁移背后的关键应用程序架构转变是向微服务架构的转变。当前应用程序开发的最佳做法是将大型整体式应用程序拆分为多个微服务。每项服务都侧重于其核心领域，并且可以独立于应用程序的其余部分进行更改、扩展和停用。只要维护微服务之间的接口，微服务就会推动每项服务的端到端所有权，并与其他服务分离和隔离。 这使每项服务都能够灵活地使用最佳数据库来支持该服务的数据访问模式、规模、可靠性和性能需求。有些微服务需要存储数 TB 级到 PB 级的实时数据，另一些微服务需要亚毫秒级延迟，还有一些微服务则需要能够为世界各地的用户每秒处理数百万个请求。很难找到一个能够实现所有这些需求，甚至可以做更多事情的数据库，也很难找到一个可以同时做好所有这些事情的数据库。更重要的是，尝试将所有这些服务模式整合到单个数据库会降低开发人员的速度，因为他们必须相互协调服务更改。这种现实导致了数据库类型的爆炸式增长。

问题 2：专用数据库是否会因为我的架构现在需要更多数据库而增加复杂性？

Vlad：虽然在自我管理的部署中可能确实会增加复杂性，但对于 AWS 完全托管式服务，这已不再是问题。AWS 为您完成所有无差别的繁重工作，因此添加更多不同类型的数据库对 IT 组织运营产生的影响微乎其微。您还可以从整个 AWS 产品组合的集成中受益。有了完全托管式服务，对基础设施增加的复杂性很少。

还有另一种方法可以思考这种复杂性感知。我们都经历过运营大规模整体式数据库的难题，由于数据库不同部分的服务和业务优先级相互冲突，这些数据库很难有效地进行更改、升级和维护。仅仅保持正常运行就会给业务带来极大的复杂性和风险，更不用说延缓上市时间了。专用数据库架构降低了这些复杂性。

问题 3：什么是托管数据库？

Vlad：托管数据库服务是由 AWS 管理和维护的云数据库，使您的数据库管理员和开发团队可以专注于应用程序和架构管理。您可以将 IT 运营团队从服务器预置、高可用性、修补（包括安全漏洞修补）、扩展、备份和硬件维护等耗时的数据库任务中解放出来。AWS 完全托管式数据库服务提供持续监控、自我修复存储和自动扩展，帮助您专注于应用程序开发。AWS 托管数据库服务的许多核心组件都通过我们简化的控制面板和高级诊断机制实现了完全自动化。

问题 4：专用数据库是否会增加解决方案的总体成本？

Vlad：与此相反，根据我们 AWS 客户的经验，我们发现专用数据库可以大规模降低运营解决方案的成本。例如，视频流服务会尝试使用关系数据库来支持电影目录、内容发现功能、用户配置文件、订阅组件、用户查看会话状态更新等。他们必须将关系数据库设置为超大大小，以便组合起来适应所有这些工作负载的峰值负载和不同的访问模式，更不用说协调任何模式更改的影响，以支持所有团队之间的新功能。相反，视频流服务可以选择使用图形数据库来支持内容发现和推荐，其规模是该服务所需的规模，并且使用低延迟、高吞吐量、可扩展的键值数据存储来处理查看进度和查看会话状态，或者使用全球分布式数据存储来管理数据更改频率相对较低的全球用户群的用户配置文件和订阅。

其他显著的成本节省来自于 AWS 自动执行预置、扩展、可用性、更新等管理任务。 我们有数百种机制来确保一切安全、可靠和可用。我们可以将所有这些运营自动化带来的节省回馈给客户。 此外，我们在全球数据中心配备了人员并培养了专业的运营技能。

通过迁移到 AWS 托管数据库服务，将开源数据库的灵活性和低成本与商业数据库的强大企业功能集结合起来，成千上万的客户已经能够节省成本。

问题 5：迁移到托管数据库的主要原因是什么？

Vlad：除了降低成本，借助托管数据库，可以消除所有无差别的繁重工作，因此开发人员和 IT 运营团队可以专注于更高价值的计划。可能包括更多地关注架构设计和其他任务，以优化应用程序的性能。可以在没有数据库维护束缚的情况下开始与组织数字化转型和演变相关的其他项目。您可以更快地进行创新，并更加关注真正使您的组织脱颖而出的核心计划。向托管数据库的迁移是一种摆脱束缚的转变。

问题 6：AWS 有多少种专用数据库？

Vlad：在所有云提供商中，AWS 拥有最广泛的托管数据库服务。AWS 总共提供超过 15 种数据库引擎，每种引擎都是为满足特定客户需求而构建。

问题 7：哪些是关系型，哪些是非关系型（NoSQL）？

Vlad：对于关系数据库，AWS 为运营和分析工作负载提供完全托管式服务。使用 Amazon RDS 处理运营工作负载，Amazon RDS 具有许多与商用和开源兼容的数据库引擎。商用数据库引擎包括 Oracle 和 SQL Server。与开源兼容的选项包括 Aurora、MySQL、PostgreSQL 和 MariaDB。Amazon Aurora 本身支持两个兼容开源的数据库引擎，即 MySQL 和 PostgreSQL。2022 年 5 月，Amazon Aurora 获得 Gartner 解决方案记分卡，包括 Amazon Aurora 获得 95 分的行业高分，包括必需功能的 100 分和首选功能的 94 分。 对于密集型分析工作负载，完全托管式关系数据仓库 Amazon Redshift 是您的最佳选择。

对于非关系数据库，AWS 提供了多种适合不同数据模型或使用案例的选项：DynamoDB（键值和文档数据模型）、DocumentDB（兼容 MongoDB，文档数据模型）、Neptune（图形数据模型）、Timestream（时间序列数据模型）、QLDB（不可变账本）、Keyspaces（兼容 Cassandra 的宽列数据模型）、ElastiCache（内存 Memcached 和 Redis 数据存储，键值数据模型）和 memoryDB（兼容内存 Redis 的持久数据库，键值数据模型）。

问题 8：谈到非关系（NoSQL）数据库，各种选项及其使用案例之间有什么区别？

Vlad：键值数据库使用简单的“键等于值”结构或其变体来存储数据，并利用简单的数据访问方法（Get、Put、Delete）。无论存储的数据量是多少，这种简单的存储模型和访问模式可确保数据访问操作始终具有已知、可预测的处理时间。它们很容易横向扩展到分布式系统，这些系统可以保持高水平的并发吞吐量和一致的性能。它们最适合实时竞价、购物车、存储和管理用户会话、广告服务、推荐、游戏（包括游戏状态、玩家数据、会话历史记录和排行榜）、物联网、产品目录、移动应用程序和低延迟查找。

文档数据库（如 Amazon DocumentDB）是一种特殊类型的键值数据库，它将值存储为嵌套文档（通常是 JSON 文档）。文档将经常访问的异构数据位汇集在一起，而不是将这些数据分散到多个规范化表中。文档数据库旨在大规模高效地存储、组织、访问、索引和聚合文档数据结构。虽然现代关系数据库也支持 JSON 数据类型，但文档数据库通常为文档访问模式提供更好的性能和可扩展性。您可以按文档中的任何属性搜索数据库，以及查询嵌套和数组字段、聚合或地理空间数据。您可以对任何键进行索引以提高性能。DocumentDB 是与 MongoDB 兼容的 API。典型的使用案例包括内容管理、个性化和用户首选项、用户配置文件管理、用户身份验证和移动应用程序。

像 Amazon Neptune 这样的图形数据库使数据关系与数据本身一样重要。节点代表实体，边缘存储实体之间的关系。您可以遍历对象之间的关系以查找数据之间的隐藏连接。通常，只需一次操作即可检索相关数据。节点和边缘都有可以查询的属性。 如果有将人员、交易和机构联系起来的图表，欺诈检测就容易得多。网络的图形数据库有助于及早识别和修复安全漏洞。其他常见使用案例包括社交网络、实时推荐引擎、知识图表、药物发现和畅销清单。

时间序列数据库（如 Amazon Timestream）每天可以轻松存储和分析数万亿个事件，速度提高了多达 1000 倍，成本仅为关系数据库的十分之一。时间序列数据库也是一种特殊类型的键值存储，其中键是时间戳，值可以是事件或传感器或监视器的状态。 时间序列数据库通常用于物联网应用、工业遥测和事件跟踪。时间序列数据库还提供丰富的上下文数据来帮助金融分析师。时间序列数据库使交叉引用数据变得容易，从而提供更丰富、更清晰的画面。

宽列数据库，例如 Amazon Keyspaces（Apache Cassandra 兼容），将数据分组为单独存储的列而不是行。宽列数据库非常灵活。它们可以高效地将大量数据存储在单列中。这样可减少磁盘资源的使用和缩短查询响应时间。宽列数据库也很容易横向扩展。 宽列数据库非常适合日志数据、物联网传感器、基于属性的数据（例如用户偏好或设备功能）以及实时分析。它们通常用于设备维护、实例集管理和路由优化的大规模工业应用程序。

分类账数据库 [如 Amazon Quantum Ledger Database（QLDB）] 维护着不可变、可加密验证的数据更改日志。这些数据库非常适合需要高度可追溯性的使用案例（例如银行交易）、跟踪物品以最大限度地减少丢失和失窃并确保没有假冒产品进入供应链，以及记录系统。

内存数据库在计算机内存中维持数据集。它们支持延迟敏感型工作负载，在这些工作负载中，需要在亚毫秒级范围内进行数据访问。它们使用内存效率高的键值数据模型。Amazon ElastiCache 用于在速度较慢的后端持久性数据存储之前进行缓存，但也经常用于存储快速变化的数据集，例如可以轻松重建的合计或排名。Amazon MemoryDB 是一个与 Redis 兼容的持久性内存数据存储。与任何 AWS 专用数据库服务相比，它提供了最低的数据访问延迟和完整的数据持久性。因为对查询的响应可能涉及多个微服务，所以支持基于微服务的应用程序架构的数据库需要超快的速度。因此，每个微服务的延迟对于总体应用程序延迟至关重要。Amazon MemoryDB 非常适合作为微服务的后备存储。

问题 9：如何选择合适的专用引擎？ 您能提供哪些实用技巧？

Vlad：在选择专用数据库时，要考虑的第一个广义特征是您的工作负载主要是事务性还是分析性工作负载。 繁重的分析工作负载是指聚合和汇总大量数据的使用案例，这些数据通常是从各种来源整合而来的。它们通常处理的并发查询要少得多，但在每个查询中操作更多的行。它们也称为在线分析处理（OLAP）工作负载。有几个 AWS 分析服务支持分析访问模式，例如关系数据仓库 Redshift、用于数据集成的 Glue、作为自然语言查询服务的 QuickSight、用于交互式查询的 Athena，用于大数据工作负载的 Elastic MapReduce、用于机器学习模型开发的 SageMaker，以及用于执行交互式日志分析、实时应用程序监控、网站搜索等的 OpenSearch。

事务性工作负载的特点是有大量并发操作，其中每个操作只读取或写入少量行。这也称为用于在线事务处理的 OLTP。 如果您的工作负载需要高度结构化的数据模型，具有参照完整性并支持复杂事务，那么关系数据库可能是这种 OLTP 系统的最佳选择。包括 Amazon Aurora 在内的 Amazon RDS 支持这个模型。 在关系数据库中，您可以将数据规范化为单独的表，并在查询时将相关实体组合在一起。当您有多个具有不同访问和更新模式的相关实体时，这是一个不错的选择。严格的模式验证和规范化数据模型有助于在整个应用程序中实现数据的参照完整性。

如果您的工作负载处理半结构化数据，不需要参照完整性，具有更简单的事务需求，或者在数据一致性方面具有灵活性，那么非关系（NoSQL）数据库可能更合适。此外，如果您的数据集具有某些界定特征，例如高度连接的数据、时间序列数据，或者需要不可变性和可验证性，那么这也是使用相关专用数据库引擎的有力指标。

要满足全局部署的性能要求，可能需要在终端用户附近建立本地数据库实例，以消除网络延迟的影响。如果您的服务正在为等待快速响应的用户提供关键工作负载，那么速度对您来说至关重要，并且您需要一个具有跨区域同步功能的数据库，以便能够从本地数据库实例传递响应。此外，在基础设施中的选定点添加内存层可以提高吞吐量和减少延迟。

问题 10：在选择最适合工作的数据库服务时，您有什么建议？

Vlad：如果工作负载特性无法促成作出明确的选择，则可以在此讨论中访问有关选择数据库的更多信息，或者访问这个专门讨论同一主题的微型网站。您也可以从这个统一数据库页面转到每个数据库的产品页。

问题 11：有关如何从旧版数据库迁移到云原生数据库，您有什么实际建议？

Vlad：您的最佳选择取决于您当前的情况和目标。我们看到了一种从通用数据库迁移到最佳适配、专用、完全托管式数据库的常见模式。这是最理想的迁移场景。数据层的现代化涉及一些前期重构，但它可以为您提供现代化应用程序所需的性能，并降低持续的管理成本。考虑到不对数据层进行现代化改造所带来的机会成本，借助 AWS 提供的工具、培训和专业服务，这个场景触手可及，而且极具吸引力。

我们也越来越多地看到希望摆脱与锁定、惩罚性许可政策以及频繁、代价高昂且耗时的审核相关的陈旧专有数据库的客户进行迁移。这些客户正在寻找能够提供深层功能的开源选项，并能以更低的成本帮助其业务继续增长。Amazon Aurora（兼容 MySQL 和 PostgreSQL）凭借其不折不扣的企业功能，成为这些客户的一个不错的目标。

其他客户渴望卸下日常的数据库管理任务，并从我们服务中内置的运营自动化带来的成本优势中受益。对于这两种客户，RDS 提供了一套丰富的数据库引擎和运营选项。

无论您的情况如何，AWS 都会提供工具和专家来帮助您评估、规划和构建适合贵公司的迁移路径。 推荐的方法是将源数据库和目标数据库的原生备份和还原功能与 AWS Database Migration Service（AWS DMS）和 AWS Schema Conversion Tool（AWS SCT）结合使用，以支持任何转换和尽量减少停机时间。在数据库迁移过程中必须迁移数据库代码对象（包括视图、存储过程和函数），或者必须在不同的数据库引擎或数据模型之间进行转换时，此方法非常有用。此解决方案适用于任何规模的数据库。它使数据库在迁移期间可供应用程序使用，并且您可以在将数据从源复制到目标的同时对迁移的数据执行验证，从而节省数据验证时间。

我们还提供其他计划和服务，从 AWS Professional Services（利用终身专业人员的深厚专业知识提供迁移协助）到 Database Migration Accelerator（DMA），收取固定费用的 AWS 专业人员团队为您处理数据库和应用程序的转换。AWS 还提供优化与许可评测（OLA）服务，帮助您评估迁移到云的选项。您可以根据自己的特定需求开始云之旅。单击此处进行注册，以便 AWS OLA 团队可以为您提供帮助。

问题 12：您还有什么想补充的吗？

Vlad：无论您是需要计算能力、数据库存储、内容分发，还是其他功能，AWS 都可提供适当的服务来帮助您构建复杂的应用程序，同时提高灵活性、可扩展性和可靠性。我们持续投资于提高服务之间的集成水平、缩短上市时间、降低成本，并使您能够通过快速迭代进行创新。您可以开启无限的可能性，并利用以前只有具有庞大 IT 预算的大型组织才能使用的战略选项。
………………………………………..

Vlad Vlasceanu 是 AWS 的首席数据库解决方案专家，工作地点为加利福尼亚州圣莫尼卡。Vlad 帮助客户采用云原生的专用数据库解决方案，并在 AWS 上部署大规模的高性能数据库架构。他专注于设计和实施可持续、经济高效且可扩展的数据库工作负载，充分利用 AWS 提供的最新最佳实践和功能。在加入 AWS 之前，Vlad 在设计和开发面向消费者的基于 Web 的应用程序以及面向能源行业的数据驱动型应用程序方面拥有超过 15 年的经验。Vlad 拥有贝勒大学的信息系统理学硕士学位。