Easysearch 容量規劃建議

基於容量估算

主要問題：

• 每天將索引多少原始資料（GB）？保留資料多少天？
• 原始資料膨脹率
• 您將強制執行多少個副本分片？
• 您將為每個資料節點分配多少記憶體？
• 您的記憶體:資料比例是多少？

原則

• 保留 +15% 以保持在磁碟水位以下。
• 保留 +5% 用於誤差和後臺活動的餘量。
• 保留相當於一個資料節點的資源來處理故障。

公式：

總資料量 GB = 原始資料 GB/天 * 保留天數 * 膨脹率 * (副本數 + 1)

總儲存 GB = 總資料 GB * 1.15（包括磁碟 watermark threshold 和誤差範圍）

總資料節點數 = ROUNDUP(總儲存 GB / (每個資料節點的記憶體 * 記憶體/資料比例)) + 1（用於故障轉移）

舉例：

假設 需要儲存的源資料 50TB 大小

膨脹率 10% 副本數 1

每個節點 256G 記憶體

計算出：

總資料量 TB

= 50TB * (1 + 0.10) * (1 + 1)

= 110TB

總儲存 TB

= 110TB * 1.15（考慮磁碟 watermark threshold 和誤差範圍）

= 126.5TB

如果有 256GB 的實體記憶體，128GB 會用於 JVM 堆，剩下的 128GB 將用於作業系統、檔案快取和其他系統程式。

按照常見的 1:30 的 RAM 到磁碟比例來計算，那麼每個節點能處理的資料儲存大約是：

256GB 記憶體 * 30 = 7680GB，大約等於 7.68TB

總資料節點數

= ROUNDUP(126.5TB / 7.68TB) + 1（用於故障轉移）

= ROUNDUP(16.47) + 1

= 18

基於搜尋吞吐量估算

在儲存容量層面之外，還要考慮搜尋響應時間和搜尋吞吐量的目標，這些目標可能需要更多的記憶體和計算資源。

搜尋響應時間受太多變數的影響，無法預測任何給定容量計劃會如何影響它。但透過經驗性測試搜尋響應時間並估計預期的搜尋吞吐量，我們可以估算出滿足這些需求所需的叢集資源。

主要問題：

• 你每秒的最高搜尋次數是多少？
• 你的平均搜尋響應時間（毫秒）是多少？
• 你的資料節點上有多少個核心和每個核心有多少個執行緒

經驗方法：

與其確定資源將如何影響搜尋速度，不如將搜尋速度視為一個常數，透過在計劃的硬體上進行測量來處理。然後確定叢集需要多少個核心來處理預期的搜尋吞吐量峰值。最終目標是防止執行緒池佇列增長速度超過它們被消耗的速度。如果計算資源不足，搜尋請求有被丟棄的風險。

公式：

峰值執行緒數 = 向上取整（每秒的峰值搜尋次數 * 平均搜尋響應時間（毫秒） / 1000 毫秒）

執行緒池大小 = 向上取整（（每個節點的物理核心數 * 每個核心的執行緒數 * 3 / 2） + 1）

總資料節點數 = 向上取整（峰值執行緒數 / 執行緒池大小）

舉例：

假設每秒 2 萬搜尋請求，平均響應時間 50 毫秒，每個節點有 16 個執行緒數，計算需要多少節點

峰值執行緒數 = 20000 * 50 /1000 = 1000

執行緒池大小 = (16 * 1 * 3/2) + 1 = 25

總資料節點數 = 1000 / 25 = 40

大概需要 40 個資料節點來處理每秒 2 萬的搜尋請求，平均響應時間為 50 毫秒，每個節點有 16 個執行緒。這是一個粗略的估計，實際需求可能會因多種因素而有所不同。建議進行實際測試以確認這些數字。

Hot, Warm, Frozen

根據索引使用情況不同，通常分為種儲存。
這是一種經濟高效的方法，用於儲存大量資料，同時最佳化了對較新資料的效能。在容量規劃期間，每個層次必須獨立進行規模確定，然後進行合併。

層面	目標	示例儲存	示例記憶體：儲存比
Hot	搜尋為主	SSD DAS/SAN (>200Gb/s)	1:30
Warm	儲存為主	HDD DAS/SAN (~100Gb/s)	1:100
Frozen	存檔為主	Cheapest DAS/SAN (<100Gb/s)	1:500

實際情況要把搜尋吞吐量估算和容量估算結合考慮。