我即将在 Amazon RDS 上启动内部报告和分析 SQL Server 实例，希望有人能帮我解答一些有关实例规格的问题。以下是该实例的规格。
- 旨在为拥有 100 - 500 名员工的中小型企业提供内部报告（具体取决于发展情况）。
- 未来 3 年内，总数据库大小不应超过 10TB - 这是很慷慨的。
- 在业务高峰期，数据输入不应超过每天 10GB。ETL 和处理通常在员工上班前的清晨进行。
- DB 将仅用于报告和分析 - 没有面向客户或业务关键的应用程序，但它将用于面向业务、微观和战略决策。SSRS、SSAS、一些机器学习，但主要是报告。
这是我的问题——如果它们看起来有点随意，请原谅。
- 您会推荐什么大小的 RDS 实例？我一直在研究 db.m4.2xLarge（8vCPU 32GB RAM），但也有 r3、r4 和 m3。价格差异相当大 - 每年几千美元。这种差异会对我的用户产生影响吗？
- 单可用区和多可用区之间的成本差异巨大。单可用区多久会宕机一次？如果每月宕机时间不到 1 小时，那么我还有理由使用多可用区吗？
- 通用 SSD 是否足够？我认为吞吐量不足以保证预配置 IOPS。在 Ts&Cs 中，它说您获得“基准是每 GiB 3 IOPS”，因此对于 2TB 初始实例，我将免费获得 6,000 IOPS。我读错了吗？
- 在非云实例上，我通常会将数据、日志和 tempdb 分离到不同的驱动器上。在云实例上有必要这样做吗？如果需要，该怎么做？
- 您多久会拍摄一次实例快照而不是数据库备份和日志传送？
我假设 SQL Server Standard 就足够了。如果您认为我需要 Enterprise，请告诉我原因？
答案1
Amazon RDS（以及大多数平台即服务数据库）的妙处在于，您不必在项目开始时就知道所有答案。
只需从相对较小的实例大小开始。在进行项目开发时，您将能够看到查询和表的执行情况，并随着时间的推移调整实例大小。
云的核心在于灵活性：顺其自然。现在，话虽如此，您问：
问：您推荐什么大小的 RDS 实例？
使用 ec2instances.info 进行快速比较，从小处着手 - 比如 4 核、30GB RAM，如 r3.xlarge。（如果您最初只是进行表设计，在进行加载之前，您甚至可以从比这更小的地方开始。）没有必要按小时支付不使用的东西的费用。
问：单可用区和多可用区之间的成本差异很大。单可用区多久会宕机一次？如果每月宕机时间不到 1 小时，那么我是否有必要使用多可用区？
首先询问用户他们想要什么RPO 和 RTO。他们的用户（和他们的钱包）决定了您需要多少高可用性和灾难恢复。通常，对于内部报告应用程序，单个 AZ 就足够了，但您的用户提出的 RPO/RTO 将为您提供指导。
问：通用 SSD 是否足够？
这将取决于您的表、索引和查询。我会从通用 SSD 开始开发，然后监控服务器的等待统计数据。随着用户查询开始出现，您可以通过等待统计数据了解性能调优，以确定是否应该调优查询、调优索引或投入资金购买虚拟硬件来解决问题。
问：在非云实例上，我通常会将数据、日志和 tempdb 分开到不同的驱动器上。在云实例上有必要这样做吗？
您想太多了：RDS 的意义在于他们为您管理这些事情。
问：您多久会拍摄一次实例快照，而不是进行数据库备份和日志传送？
在 RDS 中，您无需执行任何这些操作。平台即服务 (PaaS) 就像 DBA 即服务：他们为您完成这些操作。
问：我假设 SQL Server Standard 就足够了。如果您认为我需要 Enterprise，请告诉我原因？
从 2016 Standard SP1 开始您的开发，它为您提供了企业版的许多表设计功能，但不提供 DBA 工具。