Yes, you have to go with JOIN and create better index for your query.
Sergi
2017-05-03 16:27 GMT+03:00 kmandalas :
> @Andrey: there is reason that I have selected REPLICATED over PARTITIONED
> cache due to my business case. Custom Affinity is under investigation,
> however seems over complicated
@Andrey: there is reason that I have selected REPLICATED over PARTITIONED
cache due to my business case. Custom Affinity is under investigation,
however seems over complicated for my scenario for starters. Now, even if
PARTITIONED is used and things get done in parallel, the Network I/O is
involved
Sergi,
AFAIK, you suggest to make query run on replicated cache in similar way as
on partitioned.
Do you mean that query will run on one node in single thread as it works
now?
On Wed, May 3, 2017 at 3:39 PM, Sergi Vladykin
wrote:
> Andrey,
>
> In 2.0 queries over replicated cache still work in
Andrey,
In 2.0 queries over replicated cache still work in a single thread.
Kyriakos,
I see that only index on TYPE is used which is not the most selective
obviously.
I suggest to create a group index on (TYPE, CATEGORYID, GEOCHANNELID, WEEK)
and make sure it is used in query plan.
Sergi
201
Hi,
As you use REPLICATED cache, the query will run on one node in single
thread. This should be fixed in 2.0
The only workaround for now is to convert cache to PARTITIONED, to make the
query to be run on several nodes, that will significantly increase
performance.
Also, you can try to add more f
