雲中的 SQL GUID 或身份
跟進我之前的問題SQL Server Identity Column in the Cloud：
有沒有一般的指導方針？是否應該在雲中為 SQL Server 2016 使用聚集索引標識或 GUID？我們公司很多部署到雲（亞馬遜AWS、GoogleCloudcloud）中，以任何類型（PaaS、DBaas、VM），不確定是哪個。“公司戰略是能夠在任何地方部署的。” 我們每年僅使用 500 萬 (70GB) 行。
注意：如果曾經水平彈性擴展數據庫，我們可以使用範圍標識或位置/儲存 ID 管理標識列（DB1 獲得 1Trillion-2T，DB2 獲得 2Trillion-3T）。與 Identity 相比，Guid 具有更高的寫入速度和碎片，但可以在水平規模的數據庫中合併。使用 Identity，8 位，增量，插入速度更快。如果使用 Guid，我們的 API 將生成 Newid()，而不是 NewSequentialId。
哦，天哪，你在這裡有很多問題。我會試著把它們全部解開。
問：什麼是“雲中的 SQL Server”？
“雲”這個詞太籠統了——你可能會說“網路上的 SQL Server”。在雲中部署 SQL Server 有很多不同的方法，其中一些功能與本地伺服器完全相同（只是其他人正在為您管理伺服器。）
如果可以，請盡量避免使用諸如“雲中的 SQL Server”之類的籠統陳述，因為您不會得到好的答案。您的問題越具體，您獲得的建議就越相關。（更不用說更少的反對票了，哈哈哈。）
問：集群鍵有通用規則嗎？
通常，您希望您的集群密鑰遵循 SUN-E 原則：
- 靜態- 不會更改的欄位，因此您不必更新非聚集索引
- 唯一- 因此 SQL Server 不必在幕後添加唯一標識符
- 狹窄- 所以很多數據不會復製到您的非聚集索引中
- 不斷增加- 在最後創建一個熱點，保證您插入的位置通常在記憶體中（儘管這是人們在極其繁重的並發期間故意違反的一條規則，例如每秒數万次插入）
標識欄位匹配所有 4 (SUN-E)，而 GUID 欄位僅匹配 SU 部分。有人可能會爭辯說，與連結在一起的多個 GUID 或 NVARCHAR(250) 相比，單個 GUID 有點窄，但它與 INT 的窄度無關。
問：IaaS 中的數據建模準則會發生變化嗎？
Amazon EC2、Google Compute Engine 和 Microsoft Azure VM 等基礎設施即服務提供商只是在其他人的電腦上執行的 VM。數據建模規則在這裡沒有改變。
問：PaaS 中的數據建模準則會發生變化嗎？
平台即服務提供商略有不同。
Amazon RDS 只是由其他人託管和管理的 SQL Server，因此不需要更改數據建模。
Microsoft Azure SQL DB 不完全是“只是由其他人託管和管理的 SQL Server”——它有一些與傳統盒裝產品不同的優點和缺點。但是，如果您只是在 Azure SQL DB 中為單個數據庫建構應用程序（而不是擴展到多個數據庫），則適用正常規則。
問：“雲”何時會影響數據建模指南？
當您想要跨多個數據庫和/或伺服器擴展單個應用程序時。這種設計模式稱為分片，跨主機拆分單個相同的表（或表集）。
需要明確的是，您可以在本地執行相同的設計模式 - 現在在雲中更加流行，因為啟動多個伺服器或數據庫要容易得多。
您注意到您的數據庫每年僅使用 70GB - 這遠低於我什至遠端考慮分片的數字。
問：分片時，我會有哪些數據建模問題？
首先，您的應用程序必須知道要命中哪個分片才能獲取相關數據。（您不希望應用程序訪問數據庫來為每個查詢發現這些數據 - 畢竟，您將立即支持單個數據庫伺服器的可伸縮性限制。）
您可以按客戶位置進行分片——比如一個分片用於北美，另一個用於歐洲，另一個用於亞洲。但是，您的客戶可能會在不同位置之間移動，或者他們的位置可能分佈在不同的內容中。
您可以按客戶名稱進行分片 - 例如 A、B、C、D - 但由於負載，您將擁有一些比其他分片更熱的分片。（假設您的一位客戶進行世界杯促銷活動——該伺服器可能會在其他人閒置時倒下。）當然，客戶可以更改名稱。
您可以按活動日期（例如銷售日期）進行分片，但與其他分片相比，今天的分片當然會熱得離譜。
到現在為止，您現在開始明白為什麼您的問題如此廣泛且難以回答。獲得可操作、有用的答案的最佳選擇是提供盡可能多的細節。但是，既然您要求設計為每年 70GB 的數據，請保持簡單：堅持 SUN-E 原則。