我在批处理作业中进行一些计算时正在运行IGNITE与存储过程性能的POC。批处理作业有以下步骤：
- 从缓存中读取（
SELECT带有INNER JOIN（主键上的2个表）和简单的WHERE子句（较小表上的日期列）） - 在循环中，进行一些计算（乘法）并将结果写回缓存。
＃1中返回的记录＃与＃2中写的记录＃成正比。与SQL Server相比，RDBMS。
我已经实施了用于读取和写入操作的IGNITE的代码。我在存储过程中实施了相同的操作。当我进行测试时，我发现IGNITE的速度要慢得多：在220,000个记录上，这是运行整个工作的总时间：
- SQL Server存储的过程：9秒
- 点火：2小时40分钟
注意：
- IGNITE配置设置为单个服务器节点上的
CacheAtomicityMode.TRANSACTIONAL和CacheMode.LOCAL。交易边界是每个步骤之前和之后的。 - 我验证了结果是相同的，即。他们正在做同样的事情，没有编码问题
- 机器有16GB RAM，CPU是i7
在运行测试之前，我已经期望IGNITE由于开销而变得较慢，而且没有其他东西能真正击败数据库中运行的存储过程（例如，由于DB优化）。但是，我很惊讶的是，差异很大。同样，对于整个点火作业，我的CPU粉丝不停地旋转，这很奇怪，因为计算是一个简单的乘法，并且缓存在RAM中（这是无声的）。
我还以CacheMode.PARTITIONED模式（2个服务器节点，其中一个远程， 1个客户端）在数据集上运行了作业（145K记录）。总的运行时间为1小时8分钟。将这时间投射到220k记录（与初始集合相同）为1小时43秒（大约），比CacheMode.LOCAL快，但仍然比预期的这类体积要慢得多。（220k不多）
如果您可以告诉我我需要实现或检查的任何配置，那就太好了吗？谢谢！
在IGNITE中，存储过程以计算网格任务的风味。您可以尝试根据任务重写测试案例吗？
如果您使用的是交易，请记住SQL当前非交易，因此您可能应该使用Transactional Put/Get。
我还认为您绝对应该使用PARTITIONED，因为这意味着您可以在保持可靠性的同时添加节点，而单词SQL无法提供。请记住，如果您要进行连接，则重要的是将数据划分，这意味着按Affinity键对齐数据。