Apache Ignite performance of multi-tenant approaches

Question

I'm working in a project that must maintain a lot of records in cache (Apache Ignite), this records are divided by companies.

Ex:

Company; product; quantity

CompA; A; 15

CompA; B; 10

CompB; A; 20

CompB; B; 12

My doubt is about performance between create entries in the same cache appending tenant with key (company + product) and create a new cache for each tenant like:

CacheConfiguration<String, String> cfgCompanyA = new CacheConfiguration<>();
cfgCompanyA.setName("CompanyA");
IgniteCache<String, String> cacheCompanyA = ignite.getOrCreateCache(cfgCompanyA);

CacheConfiguration<String, String> cfgCompanyB = new CacheConfiguration<>();
cfgCompanyB.setName("CompanyB");
IgniteCache<String, String> cacheCompanyB = ignite.getOrCreateCache(cfgCompanyB);

Answer 1

I would recommend to create separate caches per tenant. Performance with these two approach should not be different, but the data will be better isolated from each other which will simplify the code.

Answer 2

It depends on your requirements. I am not an Apache Ignite expert, so I'll address that on a general level.

Arguments for separate caches:

• The access is more efficient, there is no tenant in the key
• Caches and processing for one tenant can be co-located and more easily moved
• The cache configuration is per client, which enables you to control the guaranteed latency and the resource usage per client

Arguments against separate caches:

• A shared cache gives you a controllable and optimum resource usage over all. If you have separate caches for tenants, a cache might use up resources even the tenant isn't using your application for months
• If tenants should be added dynamically, you need to come up with a concept to manage all the cache configurations

A good alternative is to use use a mixture of both:

• Put the tenant in the cache key all the time
• Implement a cache pool that may take each tenants data
• Allow for multiple cache pools and the ability to assign a cache pool to a tenant

This allows you to:

• Have a single cache pool for development and (unit) testing even with multiple tenants. Simplifying the development setup.
• Assign a high volume tenant to a exclusive cache pool
• Assign low volume tenants to a shared cache pool, optimizing on the resource usage
• New tenants start in the shared pool or may be you have a "freemium" and "trial" pool with other resource limits.
• Low volume tenants can come and go without changing the cache configuration