一、背景
OpenMLDB 線上計算的最大優勢為可以低延遲（毫秒級）高效處理實時特征計算請求。其中，為了達到低延遲，OpenMLDB 預設使用了基于記憶體的存儲引擎。但是，當業務增長時，對于記憶體資源消耗以及通路吞吐需求的壓力也會上升。本篇文章主要介紹基于 記憶體存儲引擎 的資源預估（磁盤引擎見最後的說明），可以幫你更好的預估、配置用于部署 OpenMLDB 的機器資源。
二、模型概覽
2.1 參數說明
為了友善表述，我們先把所有使用到的參數符号以及含義彙總在以下表格。
表一：預估模型所使用的的符号和意義
2.2 概覽
OpenMLDB 的資源瓶頸一般會是在記憶體消耗和吞吐能力上，是以本篇文章重點介紹這兩個資源的預估，在最後對其他資源做一個簡單介紹：
- 記憶體消耗：記憶體是一般情況下 OpenMLDB 的資源瓶頸。
- 吞吐能力：每台機器的吞吐能力有限（在記憶體不是資源瓶頸的前提下，一般 CPU 會是吞吐能力的瓶頸），如果業務增長需求更多的吞吐，則需要進行水準擴容，增加機器數量。
簡單期間，在水準擴容下，我們假設所有機器的配置都是一樣旳（如不一樣原理類似）。是以，可以使用如下公式來估算針對某一場景所需要的機器台數 n：
我們可以看到，由于 MEM_PER_SERVER 為一個常數，是以整個模型中最重要的是估算出記憶體消耗總量 mem_total，以及吞吐能力 qps_total 和 qps_per_server，以下我們分别介紹。
三、記憶體預估模型
在絕大多數的情況下，記憶體消耗會是資源的瓶頸（而非吞吐），我們首先來看記憶體消耗預估。我們提供一基于經驗的快速預估模型，以及一個較為複雜的分析型模型。
3.1 記憶體預估經驗模型
我們首先給出一個基于經驗預估的模型。該模型适用于對資料規模和業務場景還沒有明确需求的前提下，想大緻預估一下記憶體占用的場景。對于大部分的時序資料場景，該公式可以預估記憶體消耗最多部分。即實際的記憶體消耗一般會略高于預估值。如果想得到較為準确的預估，請參考後面 3.2 章節的分析模型。
基于表一的符号定義，該經驗模型表示如下：
可以看到，該公式主要和資料 schema，資料規模，以及索引個數有關。如果索引個數如果較難預估，基本上可以按照經驗認為，在普遍情況下，主表的索引在三個左右，每張副表有一個索引 。
3.2 記憶體預估分析型模型
記憶體消耗也可以基于實作原理分析出發，進行較為準确的預測。但是該預測需要較多的資訊，計算過程也較為複雜，在沒有深入使用之前較難操作。适合于上線生産環境之前，需要對資源做精細化估算使用。
該分析模型涉及到了兩個額外的參數
- C：該參數對于不同類型的表格取值不同。如果是 latest 和 absorlat 表，取值為 70；如果對于 absolute 表以及 absandlat 表，取值為 74。不同表格和 TTL 設定有關，見說明 https://openmldb.ai/docs/zh/main/reference/sql/ddl/CREATE_TABLE_STATEMENT.html#columnindex 注意，這裡 C 的取值 70 和 74，是兩個和編碼格式有關的 overhead，其實也是預估值。精确值的計算方式較為複雜，并且在不同場景下也會有所差別，在這裡不做展開描述。
-
K: 如果不同索引的資料落在同一節點和分片下, 他們會共享資料（但是這個機率不大）。是以 K 代表了真實存放的資料份數，其可能的取值範圍為 [1, n_index]
注意，這個模型假設基于記憶體存儲引擎（磁盤存儲引擎說明見本文最後），沒有打開預聚合功能下的消耗。如果打開了預聚合，會有額外的少量記憶體消耗，相比較于上述的主體消耗基本可以忽略不計。
四、吞吐預估模型
雖然大部分情況下記憶體會是瓶頸，在某些高并發場景下，吞吐也可能成為資源瓶頸。
首先，對于吞吐的需求 qps_total，該參數取決于業務使用方，不在這裡做展開。
對于每台機器提供的吞吐能力（qps_per_server），由于吞吐會和機器配置、資料集、SQL 複雜程度、以及延遲要求強相關，較難通過分析的方式給出。以下建議兩種預估方式：
- 實測肯定是較為準确的預估方式，但是在項目初期較難實施
- 可以通過我們的性能報告 實時引擎性能測試報告（第一版） ，進行經驗預估。該測試使用了三台機器，其基準測試得到在 TP999 < 10ms 以内的延遲下，折算成單台 QPS 在 8,000 左右，是以可以使用其作為參考值 qps\_per\_server=8,000
五、其他資源預估
5.1 磁盤空間
對于記憶體存儲引擎來說，雖然索引和資料存放于記憶體，但是其 binlog 以及 snapshot 依然需要存放在磁盤。磁盤空間占用會和資料量有關，一般推薦配置為記憶體預估值的 三倍。