對於在單個表中包含每個使用者數十億行的 sql 數據庫，最有效的設計模式是什麼？
我在一個相對較大的系統上工作，該系統已經開始遇到針對多個使用者擴展的性能問題。
該系統是一個 .NET 應用程序，因此查詢是使用 ORM（實體框架）編寫的，並且數據庫是 Azure SQL 數據庫。
我是開發人員而不是 DBA；通常，當我們達到性能限制並儘我們所能優化查詢時，但如果我們仍在限制數據庫，我會擴展到更高的層以增加我們的 DTU，問題就解決了。
我們現在處於為個人使用者提供自己的數據庫而不是進一步擴展的情況下會更便宜。
我不會詳細介紹我們所做的事情，但基本上我們有一個恆定的數據流從我們的使用者發送，平均每個使用者每天將大約 100,000 行數據寫入同一個表。我們的使用者需要快速訪問這些數據，這通常需要一次載入一個月到一年的數據。
我的問題是 - 在這種情況下，我有什麼選擇來維持我們的表現。
據我所知，我唯一的選擇是：
1 - 在數據庫中為每個使用者生成他們自己的表（如果可能的話），所以我只需要在查詢時為每個使用者處理幾十億行（每年 35b）。
2 - 我為每個使用者生成自己的數據庫（這應該有助於提高並發查詢的性能，但管理起來將是一場噩夢）
3 - 我只是繼續在 azure 上投入更多資金，直到技術上無法進一步擴展？
謝謝。
我喜歡你的問題，我會盡力為你找到解決方案。
您的場景是 Entity Framework 和其他 ORM 帶來像您這樣的應用程序的地方。“只寫程式碼，不要考慮數據庫” ……直到你不得不考慮數據庫。
正如評論中所說，僱用 DBA 是下一步。
無論如何，讓我們看看我們可能會採用的解決方案：
多租戶架構（同一數據庫上的所有客戶）
- **Azure 超大規模：**適用於多租戶架構（您的情況是，所有客戶都在同一個數據庫上），但您需要了解是否比 Azure SQL 數據庫更貴或更便宜。請記住，一旦擴展到Azure 超大規模，就無法切換回 Azure SQL 數據庫。
- **Cosmos DB：**您已經在使用 ORM 了，對吧？無論如何，這個想法並不關心數據庫。讓我們看看您是否可以非規範化您的數據庫架構並將您的 Azure SQL 數據庫移動到專為重負載量身定制的 Cosmos DB。
單租戶架構（每個客戶一個數據庫）
- **Azure SQL 數據庫：**你已經選擇了這個選項，當你擴大規模時，問題就解決了。然而，DTU 價格昂貴，問題通過燒錢解決。嘗試提取一些客戶並模擬負載，看看它是否昂貴。
- Azure SQL 邊緣： *“$$ … $$每個使用者每天寫大約 100,000 行數據”*這對我來說聽起來像是一個物聯網，所以為什麼不接近為數據流而設計的Azure SQL Edge。在這裡你也必須在完全移動之前對其進行測試。
現在回答您的每個問題：
- **在數據庫中為每個使用者生成自己的表：**請不要這樣做。數據庫仍將承受壓力，您將無法解決問題。
- **我為每個使用者生成自己的數據庫：**這就是我的解決方案，從多租戶轉移到單租戶：Divide et Impera。如果您已經在 Azure SQL 數據庫上，這並不難做到。如果您有Customer1、Customer2和Customer3 ，您只需要製作 3 個您已經擁有的數據庫的副本，並且如果您將相同的 .NET 應用程序指向每個數據庫，則該應用程序將工作。然後，您需要
DELETE從每個數據庫中獲取與其他客戶相關的所有數據，瞧，您從多租戶架構傳遞到單租戶架構。- **我只是不斷地向 azure 投入更多的錢：**這是不切實際的。
因此，我的解決方案是將多租戶遷移到單租戶架構，並在 Azure SQL 數據庫或 Azure SQL Edge 之間做出選擇。
但是，請僱用一名 DBA。