Amazon RDS SQL 伺服器規範
我即將在 Amazon RDS 上啟動一個內部報告和分析 SQL Server 實例，希望有人能幫助我解答有關實例規範的幾個問題。這是實例的規格。
- 用於 100 - 500 人的中小型企業的內部報告，具體取決於增長情況。
- 在接下來的 3 年中，總 DB 大小不應超過 10TB - 這是慷慨的。
- 在業務高峰期，每天的數據輸入不應超過 10GB。ETL & Processing 通常會在員工上班前的清晨完成。
- DB 將僅用於報告和分析——沒有面向客戶或關鍵業務的應用程序，儘管它將用於面向業務、微觀和戰略決策。SSRS、SSAS、一些機器學習，但主要是報告。
這是我的問題 - 抱歉，如果它們看起來有點隨機。
- 您會推薦什麼大小的 RDS 實例？我一直在看 db.m4.2xLarge（8vCPUs 32GB RAM），但也有 r3、r4 和 m3。價格差異相當大 - 每年幾千。差異會對我的使用者產生影響嗎？
- 單可用區和多可用區之間的成本差異巨大。單個 AZ 多久出現一次故障？如果每月 < 1 小時，那麼我有什麼理由打擾 Multi AZ 嗎？
- 通用 SSD 就足夠了嗎？我認為吞吐量不會保證預置 IOPS。在 Ts&Cs 中它說你得到“基線是每 GiB 3 IOPS”，所以對於 2TB 的初始實例，無論如何我都會免費獲得 6,000 IOPS。我讀錯了嗎？
- 在非雲實例上，我通常會將數據、日誌和 tempdb 分離到不同的驅動器上。這在雲實例上是否必要？如果是這樣，它會怎麼做？
- 您多久拍攝一次實例快照而不是數據庫備份和日誌傳送？
我假設 SQL Server Standard 在這裡就足夠了。如果您認為我需要 Enterprise，請告訴我為什麼？
Amazon RDS（以及大多數平台即服務數據庫）最酷的地方在於，您不必在項目開始時就獲得所有答案。
只需從相對較小的實例大小開始。在進行項目開發時，您將能夠看到查詢和表的執行情況，並隨著時間的推移對實例大小進行調整。
雲是關於靈活性的：順其自然。現在，說了這麼多，你問：
問：您會推薦什麼大小的 RDS 實例？
使用 ec2instances.info 進行快速比較，並從一些小的東西開始——比如 4 核、30GB RAM，比如 r3.xlarge。（如果您最初只是在進行表格設計，那麼在載入之前，您甚至可以開始比這更小。）按小時為未使用的東西付費是沒有意義的。
問：單可用區和多可用區之間的成本差異很大。單個 AZ 多久出現一次故障？如果每月 < 1 小時，那麼我有什麼理由打擾 Multi AZ 嗎？
首先詢問您的使用者他們想要的RPO 和 RTO。他們的使用者（和他們的錢包）決定了您需要多少高可用性和災難恢復。通常，對於內部報告應用程序，單個可用區很好，但您的使用者提出的 RPO/RTO 將指導您。
問：通用 SSD 就足夠了嗎？
這將取決於您的表、索引和查詢。我會從通用 SSD 開始開發，然後隨著時間的推移監控伺服器的等待統計資訊。隨著使用者查詢開始出現，您可以通過等待統計了解性能調整，以確定是否應該調整查詢、調整索引或在虛擬硬體上投入資金來解決問題。
問：在非雲實例上，我通常會將數據、日誌和 tempdb 分開到不同的驅動器上。這在雲實例上是否必要？
您想多了：RDS 的重點是他們為您管理這些事情。
問：您多久拍攝一次實例快照而不是數據庫備份和日誌傳送？
在 RDS 中，您不會做任何這些事情。平台即服務 (PaaS) 就像 DBA 即服務：他們為您做這些事情。
問：我假設 SQL Server Standard 在這裡就足夠了。如果您認為我需要 Enterprise，請告訴我為什麼？
從 2016 Standard SP1 開始您的開發，它為您提供了企業版的許多表設計功能，但沒有 DBA 工具。