共计 2113 个字符，预计需要花费 6 分钟才能阅读完成。
一、背景
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/m… 留神，这里 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 仍然须要寄存在磁盘。磁盘空间占用会和数据量无关，个别举荐配置为内存预估值的 三倍 。
5.2 CPU
CPU 资源次要和吞吐能力相干。绝大部分状况，资源瓶颈在内存耗费，CPU 并不会成为瓶颈。只有在多数状况下 CPU 可能会成为瓶颈，比方窗口数据量微小（百万级别）并且无奈应用预聚合优化、或者业务对于 QPS 需要极高。在这些状况下，须要进行程度扩容。
5.3 网络带宽
OpenMLDB 个别状况下并不是一个网络 IO 密集型的程序，对于网络没有特地要求。一般 10Gbps 网络带宽应该足够满足条件。
5.4 磁盘存储引擎
到此为止，咱们探讨的都是基于默认的内存存储引擎。如果是基于磁盘存储引擎（HDD 或者 SSD），则对于内存的压力较小，磁盘须要的空间数量大略是本文预估的内存消耗量的 2-3 倍。