Separate vs shared caches for different value types?
I've seen recommendations for using separate caches for different business types, e.g. Organization, Person, Department. I can see that doing so would allow for different policies for each type, but if a single policy will suffice, what's the rationale for preferring multiple caches over a single common cache with an (indexed) "type" query field? That would seem to add an additional layer of overhead if there are a lot of different types, and significantly complicate managing type hierarchies.
More concretely, if I wanted to manage objects of type Employee and User, both of which are sub-types of Person, how would I effectively query all Persons by last name if the sub-types are in separate caches? What if I wanted to join to/from other entity types, e.g. SecurityGroup? I understand there's no direct support for type hierarchies in Ignite (that I've seen), but my needs are simple and I can fake it with a single monolithic cache and careful query construction. Doing so across multiple caches seems much harder.
Re: Separate vs shared caches for different value types?
Having separate caches is not a requirement, it's just more flexible approach. Different data types are separated from each other, can be configured differently, etc. Unless you have hundreds of caches, having several of them should not introduce big overhead or any issues.
As for the queries, an SQL table is created per data type, not per cache. So if you have both Person and Organization in a single cache, you will still have two tables and queries will not change.
BTW, note that two sub-types of the same type are treated as different types from SQL standpoint and will results in creation of two separate independent tables.