SQL On A Partitioned Cache
Hazelcast showed that a get goes to one member. Ignite puts on the same shape, and SQL is full of queries that name no key.
Those cannot be answered by one member. They go to every member, and the answer is not ready until the last one replies.
The point read measured 0.018, 0.017, 0.019 and 0.022 ms at 2, 4, 8 and 16 members. The fan-out, with each member doing the same work, measured 0.103, 0.145, 0.242 and 0.398 ms.
The first question about any query on a partitioned store is whether it names the partition key. That single fact decides whether the cluster size is in its cost, and it decides it before anything about indexes or tuning is relevant.
The coordinating member sends the query to every member holding a partition, then waits. Five fast replies and one slow one is a slow query, and nothing about the five fast ones improves it.
Two Sweeps That Disagree
The obvious question is whether adding members helps or hurts a fan-out. The lab measured it twice, and the answer depends entirely on what is held constant.
Every number is a real socket round trip between real processes. Ignite itself is a JVM product and is not installed here, so its own behaviour is quoted as documentation and never as measurement.
With the total data fixed, every member added means each one holds fewer rows and does less work. That works right up to the point where the coordination costs more than the work being split.
