数据速率估计和缓存大小设置
OIBus通过北向连接器如 OIBus 和 OIAnalytics,支持两种独特的发送模式,以传输值到目标应用程序:
- 文件端点:数据可以通过存储在文件中,然后通过文件端点进行传输。
- JSON 负载端点:或者,数据可以通过值端点作为 JSON 负载进行传输。
估计合适的缓存大小对于确保平稳和可靠的存储并转发操作至关重要,它取决于包括要发送的数据类型和选择的发送模式在内的各种因素。以下是有效估计缓存大小的一些提示:
- 数据量:分析您的 OIBus 实例需要传输的数据量。考虑单个数据元素的大小和数据更新的频率。
- 发送频率:评估数据需要发送的频率。频繁传输可能需要更大的缓存来容纳连接中断时的临时数据。
- 传输模式:所选择的发送模式(文件或 JSON 负载)可以影响缓存大小的要求。由于它们的结构化格式,JSON 负载可能会消耗更多内存。
- 网络可靠性:如果到目标应用程序的网络连接不稳定或经常中断,可能需要更大的缓存来在停机期间储存数据。
- 延迟容忍度:考虑从数据生成到交付到目标应用程序之间可以接受的延迟。较大的缓存可以帮助减少由于网络问题而造成的延迟。
- 保留策略:确定数据在缓存中保留多长时间后尝试重新发送。这个保留期将影响缓存大小的要求。
- 资源可用性:评估 OIBus 机器上可用的资源,包括 RAM 和存储,因为这些将影响您分配足够大小缓存的能力。
- 监控和测试:定期监控和测试您的缓存系统,以确保它满足您的数据传输过程的实际需要。根据实际性能情况,适当调整缓存大小。
通过仔细考虑这些因素,您可以做出有关支持 OIBus 高效可靠数据传输所需缓存大小的明智决策。
发送文件(CSV)
像 SQL 这样的协议可以让您组织生成文件中的数据。以下是一些了解其如何影响生成文件大小的提示。
根据提供的假设,您可以计算由 OIBus 生成的 CSV 文件将占用的大致空间。让我们分解关键参数并根据给定示例计算文件大小:
- 采样频率:每分钟一个点,这意味着每小时有 60 个数据点。
- 文件发送频率:每 30 分钟发送一个文件,每小时结果为 2 个文件。
- 时间戳格式:ISO 8601 格式,大小为 24 字节。
- 数据值格式:有小数点分隔符的 3 位数字,数据大小为 4 字节。
- 数据引用大小:数据引用的格式为 "DataXXX",其中 XXX 代表三个数字字符。因此,每个引用的大小为 7 字节。
行文件
当传输的不同数据没有相同的采样频率时,这种格式特别合适。在示例中,我们假设所有数据具有相同的采样率。
Timestamp Reference Value
2020-02-01T20:04:00.000Z Data001 12.0
2020-02-01T20:04:00.000Z Data002 10.0
2020-02-01T20:04:00.000Z Data003 10.0
2020-02-01T20:05:00.000Z Data001 10.0
2020-02-01T20:05:00.000Z Data002 19.0
2020-02-01T20:05:00.000Z Data003 10.0
2020-02-01T20:06:00.000Z Data001 10.0
2020-02-01T20:06:00.000Z Data002 10.0
2020-02-01T20:06:00.000Z Data003 14.0
...
现在,让我们计算每个行文件 CSV 的大小:
时间戳 (24 字节) + 数据引用 (7 字节) + 数据值 (4 字节) + 3 个分隔符 (3 字节) = 每个数据点 38 字节
。
以每小时 60 个数据点计算,每小时数据大小为:数据点 38 字节 * 60 数据点 = 每小时 2280 字节
(不含表头)。
每小时发送 2 个文件,每小时文件大小为:每小时 2 个文件 * 每个文件 2100 字节 = 每小时 4560 字节
。
请记住,这个计算提供了一个基于指定假设的估计值,实际文件大小可能会根据诸如数据值格式等其他因素而有所不同。
列文件
对于重复共享相同时间戳的数据,这种格式特别适合,与将每个数据点放在单独行上的格式相比,可以节省空间。
Timestamp Data001 Data002 Data003
2020-02-01T20:04:00.000Z 12.0 10.0 10.0
2020-02-01T20:05:00.000Z 10.0 19.0 10.0
2020-02-01T20:06:00.000Z 10.0 10.0 14.0
...
让我们计算每个列文件 CSV 的大小:
时间戳 (24 字节) + 数据值 (4 字节) * 3 + 4 个分隔符 (4 字节) = 每个数据点 40 字节
。
以每小时 60 个数据点计算,每小时数据大小为:数据点 40 字节 * 60 数据点 = 每小时 2400 字节
(不含表头)。
每小时发送 2 个文件,每小时文件大小为:每小时 2 个文件 * 每个文件 2400 字节 = 每小时 4800 字节
。
列行文件
此格式结合了基于列格式的文件结构的好处,并允许将数据标识符(001、002、003)和它们的引用整合在一起,尽管在 这种情况下,仅使用 "Data"。这结果在引用如 Data001、Data002 和 Data003。
Timestamp Reference 001 002 003
2020-02-01T20:04:00.000Z Data 12.0 10.0 10.0
2020-02-01T20:05:00.000Z Data 10.0 19.0 10.0
2020-02-01T20:06:00.000Z Data 10.0 10.0 14.0
...
让我们计算每个列行文件 CSV 的大小:
时间戳 (24 字节) + 数据引用 (4 字节) + 数据值 (4 字节) * 3 + 5 个分隔符 (5 字节) = 每个数据点 45 字节
。
以每小时 60 个数据点计算,每小时数据大小为:数据点 45 字节 * 60 数据点 = 每小时 2700 字节
(不含表头)。
每小时发送 2 个文件,每小时文件大小为:每小时 2 个文件 * 每个文件 2700 字节 = 每小时 5400 字节
。
发送值(JSON 负载)
格式
当北向连接器检索值并将它们传输到值端点(OIBus 北向连接器或 OIAnalytics)时,它们按以下数组格式呈现:
[
{"timestamp": "2020-02-01T20:04:00.000Z", "pointId":"Data001", "data": {"value": "12.0", "quality": "192"}},
{"timestamp": "2020-02-01T20:04:00.000Z", "pointId":"Data002", "data": {"value": "10.0", "quality": "192"}},
{"timestamp": "2020-02-01T20:04:00.000Z", "pointId":"Data003", "data": {"value": "10.0", "quality": "192"}}
]
每个字段传达以下信息:
- timestamp:表示值的时间戳,ISO 8601 格式。
- pointId:用作值的参考。
- data:一个 JSON 对象,包含记录的值(value)及其质量(quality)或其他字段。
我们的主要关注点将是 JSON 文件格式中的数据。在这方面,其大小取决于多个参数,包括:
- 数据采样频率。
- 分组在一起传输的点的数量(由 Group Count 定义)。
- 传输频率(由 Send Interval 定义)。
- 数据和质量的格式,特别是用于精度的字符数。
- 数据引用的大小。
大小估计
可以根据以下标准估计单个值所占用的空间:
- 时间戳大小为 39 字节(
"timestamp": "2020-02-01T20:00:00.000Z"
)。 - pointId 大小以
"pointId": "DataXXX"
的形式,将 13 个字节添加到引用的字节数中(在本例中,"DataXXX" 为 7 个字节)。 - data 字段大小为 10 字节(
"data": {...}
),加上其内容:- value 字段遵循
"value": "10.0"
的格式,增加了 11 个字节外加编码值所需的可变字节数(本例中为 4 字节)。 - quality 字段的格式为
"quality": "192"
,增加了 13 个字节外加编码质量所需的可变字节数(这里为 3 个字节)。
- value 字段遵循
因此,表示一个值的对象大小可以拆分如下:
- 对象的固定大小:39 + 13 + 10 + 11 + 13 + 6 = 92 个字节(6 对应于不同元素间的分隔符,如逗号)。
- 引用的大小:7 个字节
- 值的大小:4 个字节
- 质量的大小:3 个字节
因此,一个待发送的单个对象的总大小就是单个值的106 字节。
以每分钟采样一个点和 3 个数据点,群发数量等于 1000,发送间隔等于 60000 毫秒,OIBus 将每分钟传输一个带有 3 个数据点的 JSON,总共 318 个字节。
在一天的时间里,这会达到 318 x 60 = 19080 字节