本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

考虑使用专用数据库

概述

运行基于 Microsoft 的工作负载所涉及的成本中，最大的一项支出来自于商业数据库（如 SQL Server）的许可费用。企业通常会将 SQL Server 作为首选的数据库平台加以标准化，并且这一选择会深深扎根于该组织的开发文化之中。无论使用案例如何，开发人员通常会选择基于关系型 SQL Server 的模型。原因包括：

专用数据库能够适应您的使用案例的数据访问模式。随着企业采用更为现代化的架构（如微服务架构）以及单个应用程序的范围逐渐缩小，这些数据库正越来越受到企业的青睐。

专门构建的数据库并不意味着必须采用关系模型，也不一定需要使用 NoSQL（非关系型）模型。事实上，当根据工作负载的特定需求进行选择时，关系数据库会被视为是专门构建的。使用专用数据库能够帮助团队降低与 .NET 应用程序相关的数据库成本，同时还能享受到诸如可扩展性、韧性以及减少不必要的繁重工作等标准的云优势。

下表显示了提供的专门构建的数据库。 AWS

采用专用数据库的一个重要驱动因素是由于不再需要支付商业许可费用。但是，DynamoDB（包括按需模式）、Aurora、Amazon Neptune 和 Amazon Keyspaces 等数据库的自动扩缩功能使您能够为一般情况而非峰值使用量来预调配容量。专用数据库（例如 Timestream）是无服务器的，无需任何预调配即可自动扩展以满足需求。

AWS 如果您想使用专门构建的、与开源兼容的关系数据库，但又无法或不愿对应用程序进行重大代码更改，则提供 Babelfish for Aurora PostgreSQL。在某些情况下，Babelfish 可让您使用现有的 SQL Server 访问代码，几乎无需进行任何修改。

在为应用程序选择专用的关系数据库时，务必保留您的应用程序所需的一致（或功能等效的）特征。此建议指出，专用数据库应作为应用程序的主要数据存储。特定应用程序（如缓存）在其他建议中进行了介绍。

成本影响

为.NET 工作负载采用专门构建的数据库虽然不太可能 consumption/cost 直接影响计算，但会直接影响.NET 应用程序使用的数据库服务成本。实际上，与敏捷性、可扩展性、韧性以及数据持久性所带来的诸多益处相比，节省成本可能只是次要目标。

本指南无法详尽阐述为应用程序选择专用数据库以及重新架构数据策略以有效利用它们的完整流程。有关更多信息，请参阅 AWS 教程目录中的专用数据库。

以下表格展示了将 SQL Server 替换为专用数据库后，会如何改变应用程序成本的几个示例。请注意，这些只是大致的估算值。需要对实际工作负载进行基准测试和优化，以便计算出确切的生产成本。

以下是一些常用的专用数据库估算方案，其中包括按需计算功能以及 100GB 的 SSD，以及 us-east-1 中的单实例数据库。许可费用包括 SQL Server 许可证以及软件保障费用。

下表显示了商业数据库示例的估算成本。

下表显示了专用示例的预估成本。

在采用专用数据库之前，我们建议您考虑成本影响。例如，将应用程序更新为使用专用数据库所需的费用与应用程序的复杂程度以及源数据库有关。在规划此次架构切换时，务必将总拥有成本纳入考虑范围。这包括重构您的应用程序、提升员工在新科技方面的技能，以及仔细规划每个工作负载预期的性能和消耗情况。从那里，您可以判断这项投资是否值得节省下来的成本。在大多数情况下，维护 end-of-support产品会带来安全和合规风险，修复产品的成本值得付出努力和初始投资。

成本优化建议

对于正在访问 SQL Server 的 .NET 应用程序，专用关系数据库有相应的替代库可供使用。您可以在您的应用程序中实施这些库来替代类似的 SQL Server 应用程序功能。

以下表格重点介绍了在多种常见场景中均可使用的部分库。

使用 Babelfish 连接到 Amazon Aurora PostgreSQL 不需要任何特殊编码即可连接。但是，所有代码在使用前都必须经过严格测试。

其他专用数据库还设有用于访问与 .NET 兼容的库的接口，这使得您能够访问这些专用数据库。例子包括：

如果您迁移到专门构建的数据库，则可以使用以下工具 AWS 来帮助完成迁移过程：

其他资源