在 SQL Db 中儲存 ~700 Tb
總的來說，我是 Db 的新手，我遇到了一個教程，其中我們需要在幾年內儲存約 700 Tb 的數據。有人提到，針對這種數據限制擴展 SQL 並不是最好的方法，因此在教程中他們繼續使用 NoSQL。對此我有幾個疑問：
- 是否可以將這樣的 Tb 儲存在一台機器中，據我了解，SQL 中不可能進行水平縮放。如果我錯了，請更正。
- SQL 與 NoSQL 的延遲比較是多少。由於水平擴展，像 DynamoDB 這樣的 noSQL 數據庫會比 SQL 數據庫提供更低的延遲。
是否可以將此類 Tb 儲存在一台機器中
確實。儘管那台機器變成了一個大的單點故障。
建構一個高效且容錯的 PB 級儲存系統本身就是一個挑戰，以成本效率實現這一目標更是如此。我認為作為“數據庫新手”也意味著您對儲存解決方案也不是特別有經驗，因此您不想嘗試將自定義建構放在一起。
一個不常見的安排是讓幾台集群機器執行您選擇的 DBMS（SQL Server 等），使用“現成的”基於 SAN 的儲存系統。我對“PB SAN”的第一個搜尋結果進行了快速計算，大約 700Tb 的設備價格約為 40,000 英鎊，這只是儲存單元和填充它的驅動器：添加到機架上以容納所有東西，體面的規格集群數據庫伺服器的機器，可能需要的企業許可，……這種級別的儲存永遠不會便宜。您還需要考慮持續成本：為所有設備供電的電力和所需的空調、發生故障時更換驅動器以及監控和維護所有設備的人力！
您幾乎肯定會更好地查看託管解決方案，也許與較大的雲提供商之一合作，讓他們為您擔心很多擴展、冗餘、可靠性、電源等問題。對於這種規模，您不太可能找到“現成”價格，因此您需要直接與他們交談。請注意：這種儲存量，特別是對於快速訪問，具有良好的彈性（就數據安全性和服務可用性而言）不會太便宜，這是不可能的。
根據我的理解，在 SQL 中水平縮放是不可能的。如果我錯了，請更正。
這是可能的，但與其他選項相比是否實用取決於您的數據和訪問模式。
SQL 與 NoSQL 的延遲比較是多少。
由於水平擴展，像 DynamoDB 這樣的 noSQL 數據庫會比 SQL 數據庫提供更低的延遲。
以上所有問題都只能用“它取決於”來回答，而沒有關於您需要儲存的數據的更多資訊，並且至少對預期的檢索模式和其他要求有一個模糊的概念。
僅了解數據的大小和預期增長還不足以進行更詳細的討論。
雖然問題有一個 dynamodb 的標籤，但是您可以根據需要儲存盡可能多的內容。它在 N.Virginia 地區有 400K/item 和 80K WCU 和 RCU 的限制，可以通過支持提升。本地二級索引也有限制，最大可達10gb，全域二級索引沒有限制。
另一方面，問題本身更多的是關於 SQL，而 dynamodb 不是 SQL。如果您需要類似 SQL，那麼您應該檢查