效能改善秘訣

本節為 Amazon DocumentDB 提供五種效能最佳化策略，以改善應用程式效率和查詢執行。

1. 使用 $match 作為彙總管道中的第一階段

一律將 $match 作為在彙總管道中篩選的第一個階段，以最大化效能。當 $match 領導管道時，Amazon DocumentDB 將有效利用索引，讓資料庫能夠及早篩選資料並減少處理開銷。

// Optimized approach
db.orders.aggregate([
  { $match: { status: "active", category: "electronics" } }, // Index utilization
  { $group: { _id: "$category", total: { $sum: "$price" } } },
  { $sort: { total: -1 } }
])
      

影響：早期篩選可減少後續管道階段中處理的文件數量，進而加快查詢執行速度並降低資源消耗。

2. 在彙總管道中使用 $project 將管道資料大小降至最低

僅透過彙總管道階段攜帶必要欄位，以將資料大小降至最低並改善效能。以策略方式使用 $project，只包含您需要的資料。

// Efficient pipeline design
db.orders.aggregate([
  { $match: { orderDate: { $gte: new Date("2024-01-01") } } },
  { $project: { customerId: 1, totalAmount: 1, status: 1 } }, // Only needed fields
  { $group: { _id: "$customerId", totalSpent: { $sum: "$totalAmount" } } }
])
      

影響：較小的文件可減少記憶體用量並改善管道處理效率，進而提升整體查詢效能。

3. 為更低的儲存成本、I/O 成本和改善的查詢效能啟用文件壓縮

從叢集參數群組啟用文件壓縮，以降低儲存成本、I/O 成本並提升查詢效能。Amazon DocumentDB 會將壓縮文件存放在磁碟和 RAM 中，以減少記憶體佔用量和 I/O 成本。

Impact: (影響：)

• 更多文件適用於可用的記憶體

• 降低磁碟讀取速度，加快資料存取速度

• 降低儲存成本、I/O 成本並改善查詢效能

注意

Amazon DocumentDB 預設不會為 5.0 版啟用壓縮。您可以在 5.0 叢集的集合或叢集層級啟用壓縮。使用 Amazon DocumentDB 的壓縮檢閱公用程式來分析集合的壓縮比率。

對於 Amazon DocumentDB 8.0，預設會啟用壓縮。

4. 利用索引獲得最佳查詢效能

確保您的查詢一律使用索引來獲得最佳效能。Amazon DocumentDB 提供多種索引類型，以符合不同的使用案例。

索引原則：

• 每個查詢都應利用適當的索引

• Amazon DocumentDB 提供多種索引類型

• 複合索引支援具有單一索引的各種查詢形狀，可提供最大的彈性

• 設計索引以同時支援排序和篩選操作

了解索引字首：複合索引適用於索引字首 - Amazon DocumentDB 可以使用索引欄位的任何left-to-right子集。例如，索引會{ category: 1, price: -1, inStock: 1 }建立這些可用的字首：

• { category: 1 } - 僅支援依類別篩選的查詢

• { category: 1, price: -1 } - 支援依類別篩選查詢，以及依價格排序/篩選

• { category: 1, price: -1, inStock: 1 } - 支援完整的複合查詢

僅查詢價格、inStock 或 inStock 將不會使用此索引，因為它們不是以第一個欄位 （類別） 開頭。

如何識別未使用索引的查詢：使用 explain() 方法來分析查詢執行，並識別執行集合掃描的查詢，而不是使用索引。

影響：沒有索引使用率的查詢會導致集合掃描，導致執行個體的記憶體和 CPU 壓力增加，以及查詢延遲增加。

5. 根據查詢模式最佳化資料模型

讓您的資料模型與您的應用程式查詢和更新資料的方式保持一致。資料建模是高效能 Amazon DocumentDB 應用程式的基礎。

最佳化策略：

效能內嵌

• 當相關資料經常以單位形式存取時，請將相關資料存放在一起

• 一律一起擷取的內嵌文件

• 適合one-to-few的關係

// Embedded approach for frequently accessed data
{
  _id: ObjectId("..."),
  customerName: "John Doe",
  address: {
    street: "123 Main St",
    city: "Seattle",
    zipCode: "98101"
  },
  recentOrders: [
    { orderId: "ORD001", amount: 99.99, date: "2024-01-15" }
  ]
}
      

彈性參考

• 使用大型或不常存取資料的參考

• 建議與大型資料集建立one-to-many關係

• 防止文件膨脹並改善更新效能

集合分割策略

當大型文件中只有幾個欄位經常更新時，或當大型不常存取的資料膨脹文件時，請考慮分割集合：

• 在個別、較小的集合中保留經常更新的欄位

• 在另一個集合中存放靜態或不常存取的資料

• 視需要將它們與參考連結

// Before: Large document with mixed access patterns
{
  _id: ObjectId("..."),
  productId: "PROD123",
  name: "Wireless Headphones",        // Frequently accessed
  price: 99.99,                      // Frequently accessed
  inventory: 45,                     // Updated frequently
  lastSold: "2024-01-15",           // Updated frequently
  detailedSpecs: { /* large object */ }, // Infrequently accessed
  manualPDF: "base64...",           // Large, rarely accessed
  reviewHistory: [/* large array */] // Infrequently accessed
}

// After: Split into collections based on access patterns
// products collection (frequently accessed data)
{
  _id: ObjectId("..."),
  productId: "PROD123",
  name: "Wireless Headphones",
  price: 99.99,
  inventory: 45,
  lastSold: "2024-01-15"
}

// product_details collection (infrequently accessed data)
{
  _id: ObjectId("..."),
  productId: "PROD123",           // Reference to products collection
  detailedSpecs: { /* large object */ },
  manualPDF: "base64...",
  reviewHistory: [/* large array */]
}
      

效能提升：文件越小表示更新速度越快、記憶體用量越低，快取效率也越好。

影響：低效率的資料建模會導致查詢不佳、文件大小增加和記憶體用量增加，進而降低應用程式效能並提高營運成本。