分片评估(第 2 部分)
大家好,
正如我在上一个帖子分片评估(第 1 部分)中所承诺的,我继续研究了分片数量的影响。
为了完成概览,我还添加了以下实例:
在 WIN (Server 2012 R2) 8 核上
- Cache for Windows (x86-64) 2016.2.2 - 12 GB 全局缓冲区
- IRIS for Windows (x86-64) 2018.1.1 - 400 MB 全局缓冲区,无分片
在 LINUX (Ubuntu 16.04 LTS) 2 核上
- IRIS for UNIX (Ubuntu Server LTS for x86-64) 2018.1.1 400MB 全局缓冲区
- 无分片、2 个分片、3 个分片、4 个分片。
我使用的表有 2650 万条记录,并且在所有具有相同索引的实例上均相同
查询:
- SELECT $LISTLENGTH($LISTFROMSTRING(LIST(<property>))) FROM ... WHERE ... %STARTSWITH <value>
这里使用了 2 个不同的值,结果为 47000 和 19000 次命中。
我将其称为简单查询 S47 和 S19
- SELECT $LISTLENGTH($LISTFROMSTRING(LIST(<property1>))) FROM ... WHERE ... %STARTSWITH <value1>
AND <attribute> %INLIST ( SELECT $LISTFROMSTRING(LIST(<property2>)) FROM ... WHERE. .. %STARTSWITH <value2>)
结果为大约 3000 次命中。
我将其称为复杂查询 CX3
- SELECT $LISTLENGTH($LISTFROMSTRING(LIST(<property1>))) FROM ... As A JOIN …… As B ON ……
WHERE ... %STARTSWITH <value1> and …. . .. %STARTSWITH <value2>
结果为大约 5500 次命中。
我将其称为复杂查询 CJ5
这个选择最接近实际应用。 其他查询的行为也很有趣,但与现实不太相关。
正如预期和要求的那样,所有测试查询在不同的配置下都提供了相同的结果。
我参考的基准是 WIN 上的 Cache。 结果以该基准的运行时百分比表示。
所有值都是至少 5 次运行的最后 3 次的平均值,以排除缓冲影响
我认为结果不需要过多解释:
- 分片越多,查询运行得越快
- 查询越简单,性能提升越大
- SQL 写得好看可能适得其反,而且可能需要复杂的分片键设计。
关于初始加载的其他观点:
我没能准确地测量出加载时间,因为一开始没有关注这一点。
总之,要填充的分片越多,需要的时间越长。
有点遗憾的是,我觉得加载 4 个分片的时间至少是加载 2 个分片的两倍,
加载 3 个分片的时间介于两者之间。 这并没有让我感到意外,因为
跨 ECP 移动那么大的数据量不可能很快也不会有很好表现。 但是如你所见,还是有回报的。
根据此研究,我认为要保持表为最新状态,有两个选项:
- 通过 SQL 直接 INSERT、UPDATE、DELETE
- 根据你的应用,使用 DSTIME 类参数运行批量更新。
希望本文有助于你的分片实施。