ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vkulichenko <valentin.kuliche...@gmail.com>
Subject Re: Ignite Design questions
Date Tue, 20 Dec 2016 18:27:46 GMT
Hi Chris,

See my comments below...

Chris Berry wrote
> *  How does a Clustered & Partitioned IgniteCache handle a
> `cache.getAll(Set<> keys)` behind the scenes ??
> Will it transparently fan those requests out to the appropriate Partition
> for me (from the Client – or is it a “double hop” — once to the Cluster,
> another to the appropriate shard)??
> How does it handle individual failures?? I can’t seem to find much detail
> about how all of the internal routing is handled in Ignite.

Ignite automatically routes any request to a proper node. getAll() will be
split into several requests accordingly. I.e. if set of keys includes 3
subsets routed to 3 different nodes, it will be 3 parallel round trips. In
case of failure you can get CachePartialUpdateException with the list of
keys that were not updated (note that this is true for ATOMIC cache only, in
case of TRANSACTIONAL cache you will have transaction committed or rolled
back, i.e. partial failure is not possible).

Chris Berry wrote
> * Would you build your own “artificial sharding” on top of the Rates. In
> other words; apply “affinity collocation” and use say Geo info.
> Something/anything so that the Rates collocate by some auxiliary key. That
> builds reasonably sized shards?? This is probably a given.

Hard to tell, this depends on how your data model is organized. Collocation
is generally used to minimize network traffic. For example, if there is a
computation that involves multiple entries that are related to each other,
it's a good idea to have them all on one node.

Chris Berry wrote
> * Is it possible to configure Ignite to, essentially, “always serve data”.
> E.g. even it if split-brains?? In other words, since my RatesEngine is
> read-only, and really doesn’t care (Rates are assumed to be eventually
> consistent) – as long as it can find Rates it will be happy. Only the
> Rates Injector is really concerned about fidelity. And may blow up. And as
> we piece back together the world, the Rates Engine can keep chugging along
> somehow. Does that make sense?? Perhaps another way to ask this is, what
> are the failure scenarios for an Ignite Cluster??

In case of segmentation you will have two separate clusters and clients will
be able to connect to any of them. In case of read-only this is probably not
a big problem, but in any case Ignite does not allow to merge clusters back.
You will have to manually restart one of them.


View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-Design-questions-tp9646p9653.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

View raw message