在这篇文章中，我们将使用docker和 参数配置文件模版 这一新特性来运行IRIS集群且轻松配置好。
在 UNIX® 和 Linux 上，您可以使用声明式参数配置合并文件来修改默认的 iris.cpf。合并文件是一个部分 CPF，在实例启动时为任何数量的参数设置所需的值。CPF 合并操作对每个实例只起一次作用。
我们的集群架构非常简单，它将由一个主节点（Node1）和两个数据节点（检查所有可用角色）组成。不幸的是，docker-compose不能部署到几个服务器上（尽管它可以部署到远程主机上），所以这对本地开发分片的数据模型、测试等很有用。如果是生产的InterSystems IRIS集群部署，你应该使用ICM云管理器或IKO K8S调度器。
大家好，
正如我在上一个帖子分片评估（第 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 类参数运行批量更新。
希望本文有助于你的分片实施。