View a markdown version of this page

PERF04-BP04 根據存取模式選擇資料儲存 - AWS Well-Architected 架構
實作指引資源

PERF04-BP04 根據存取模式選擇資料儲存

使用工作負載的存取模式和應用程式的要求，決定要使用的最佳資料服務和技術。

預期成果：已根據識別和記錄的資料存取模式，選取了資料儲存。這可能包括最常見的讀取、寫入和刪除查詢、對特定計算和彙總的需求、資料的複雜性、資料相依性，以及必要的一致性需求。

常見的反模式：

  • 您只選取一個資料庫廠商來簡化操作管理。

  • 您假設資料存取模式不會隨著時間改變。

  • 您在應用程式中實作複雜的交易、回復和一致性邏輯。

  • 資料庫設定為支援潛在的高流量爆增，這會導致資料庫資源大部分時間保持閒置狀態。

  • 使用共用的資料庫進行交易和分析用途。

建立此最佳實務的優勢：根據存取模式選取和優化您的資料儲存將有助於降低開發複雜性，並優化效能機會。了解何時使用讀取複本、全域表、資料分割和快取將協助您降低營運負擔，並根據您的工作負載需求進行擴展。

未建立此最佳實務時的風險暴露等級：中

實作指引

識別並評估您的資料存取模式，以選取正確的儲存組態。每個資料庫解決方案都有設定和優化儲存解決方案的選項。使用收集的指標和記錄，並嘗試使用選項來找出最佳組態。使用下表根據每個資料庫服務檢閱儲存選項。

AWS Services Amazon RDS Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Scaling Storage Storage can be scaled up manually or configured to scale automatically to a maximum of 64 TiB based on engine types. Provisioned storage cannot be decreased. Storage scales automatically up to maximum of 128 TiB and decreases when data is removed. Maximum storage size also depends upon specific Aurora MySQL or Aurora Postgres engine versions. Storage automatically scales. Tables are unconstrained in terms of size. Storage scales automatically up to maximum of 64 TiB. Starting Amazon DocumentDB 4.0 storage can decrease by comparable amounts for data removal through dropping a collection or index. With Amazon DocumentDB 3.6 allocated space remains same and free space is reused when data volume increases. Storage is in-memory, tied to instance type or count. Storage scales automatically can grow up to 128 TiB (or 64 TiB in few Regions). Upon data removal from, total allocated space remains same and is reused in the future. Organizes your time series data to optimize query processing and reduce storage costs. Retention period can be configured through in-memory and magnetic tiers. Scales table storage up and down automatically as your application writes, updates, and deletes data. Storage automatically scales. Tables are unconstrained in terms of size.

實作步驟：

  1. 了解交易、更新了連結、一致性、隔離行為和持續性 (ACID) 合規性以及一致性讀取的要求。並非每個資料庫都支持這些項目，並且大部分 NoSQL 資料庫都會提供最終一致性模型。

  2. 考慮全球分散式應用程式的流量模式、延遲和存取要求，以便識別最佳的儲存解決方案。

  3. 分析查詢模式、隨機存取模式和一次性查詢。還必須斟酌圍繞文字和自然語言處理、時間系列和圖形的高度專業化查詢功能的考量。

  4. 識別並記錄資料和流量的預期成長。

    1. Amazon RDS 和 Aurora 支援儲存自動擴增至記錄的限制。除此之外，考慮將較舊資料轉換到 Amazon S3 進行封存、彙總歷史資料進行分析，或透過碎片水平擴展。

    2. DynamoDB 和 Amazon S3 將自動擴展至近乎無限制的儲存容量。

    3. 可以手動調整在 EC2 上執行的 Amazon RDS 執行個體和資料庫大小，並且 EC2 執行個體可以在後來新增 EBS 容量以取得額外的儲存。 

    4. 可以根據活動中的變更來變更執行個體類型。例如，您可以在測試時從較小的執行個體開始，然後在您開始接收服務的生產流量時擴展執行個體。Aurora Serverless V2 會自動擴展以回應負載中的變更。 

  5. 根據正常和尖峰效能 (每秒交易數 TPS 和每秒查詢數 QPS) 和一致性 (ACID 和最終一致性) 設定基準要求。

  6. 記錄解決方案部署層面和資料庫存取要求 (例如全域複寫、多可用區域、讀取複寫和多個寫入節點)。

實作計劃的工作量：低。如果您的資料管理解決方案沒有日誌或指標，則需要在識別和記錄資料存取模式之前完成該操作。一旦了解您的資料存取模式，就能輕鬆選取並設定您的資料儲存。

資源

相關文件：

相關影片：

相關範例：