Andrey,
In my previous reply I didn't mean that all the queries should be
replaced with native cache.get() calls.
In opposite I wanted to show that there is no need to parse a simple
query on sender side trying to optimize it by sending only to particular
nodes because majority of queries are more complex (like in your example
below).
Exactly because in most the cases queries are complex they all are sent
to all the nodes where they're actually executed.
However, it doesn't mean that Ignite SQL doesn't suite for OLTP or DWH.
It costs almost nothing to send a query to a remote node.
The biggest factor here is cluster size, actual type of query, proper
indexes usage, result set that is returned from every node.
--
Denis
On 1/27/2016 3:38 PM, Andrey Nestrogaev wrote:
Denis,
Do not take the examples as the real problem.
In real application sql can be more complex like this:
select a.*
from account a
join account_details b
on (b.id = a.id)
where b.type = 'TTT'
and (select nvl(sum(amount),0) from account_sums s where s.id = a.id) > 0
and a.id = 1
Do you recommend to replace all such queries with java code using native
cache's api?
Thus it appears that ignite sql inginte with partitioned caches can't scale
for OLTP queries (every query runs on every node), it only will good serves
for DWH workload?
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/Sql-query-performance-with-partitioned-caches-tp2700p2742.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
