分片评估（第 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 类参数运行批量更新。

希望本文有助于你的分片实施。