Apache Ignite производительность мультитенантных подходов

Я работаю над проектом, который должен хранить много записей в кеше (Apache Ignite), эти записи разделены по компаниям.

Ex:

Компания; товар; количество

КомпА; А; 15

КомпА; Б; 10

КомпВ; А; 20

КомпВ; Б; 12

Я сомневаюсь в производительности между созданием записей в одном кеше, добавлением арендатора с ключом (компания + продукт) и созданием нового кеша для каждого арендатора, например:

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);

java caching multi-tenant ignite
person Ramon Rosa    schedule 30.04.2016    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Я бы рекомендовал создавать отдельные кеши для каждого клиента. Производительность при этих двух подходах не должна отличаться, но данные будут лучше изолированы друг от друга, что упростит код.

person Valentin Kulichenko    schedule 30.04.2016

arrow_upward
1
arrow_downward

Это зависит от ваших требований. Я не эксперт по Apache Ignite, поэтому расскажу об этом в общих чертах.

Аргументы для отдельных кешей:

  • Доступ более оперативный, в ключе нет арендатора
  • Кэши и обработка для одного арендатора могут быть размещены вместе и их легче перемещать.
  • Конфигурация кеша предназначена для каждого клиента, что позволяет контролировать гарантированную задержку и использование ресурсов для каждого клиента.

Аргументы против отдельных кешей:

  • Общий кеш обеспечивает контролируемое и оптимальное использование ресурсов. Если у вас есть отдельные кэши для арендаторов, кэш может потреблять ресурсы, даже если арендатор не использует ваше приложение в течение нескольких месяцев.
  • Если арендаторы должны добавляться динамически, вам необходимо придумать концепцию управления всеми конфигурациями кэша.

Хорошей альтернативой является использование комбинации обоих:

  • Поместите арендатора в ключ кеша все время
  • Реализовать пул кеша, который может принимать данные каждого арендатора.
  • Разрешить несколько пулов кеша и возможность назначать пул кеша арендатору

Это позволяет:

  • Имейте единый пул кэшей для разработки и (модульного) тестирования даже с несколькими арендаторами. Упрощение настройки разработки.
  • Назначение арендатора большого объема эксклюзивному пулу кэшей
  • Назначьте арендаторов с небольшим объемом к общему пулу кэшей, оптимизируя использование ресурсов.
  • Новые арендаторы начинают работу в общем пуле или, возможно, у вас есть «бесплатный» и «пробный» пул с другими ограничениями ресурсов.
  • Клиенты с небольшим объемом могут приходить и уходить без изменения конфигурации кэша.
person cruftex    schedule 30.04.2016

arrow_upward
0
arrow_downward

Я провел несколько тестов с этим кодом (скала): https://github.com/neoramon/scala-ignite-muiti-tenant Чем больше 100 000 записей, тем более эффективным становится использование кеша арендатором.

Машина с: 4 ядрами, 8 RAM (куча 4GB) SSD.

person Ramon Rosa    schedule 01.05.2016
comment
Можете ли вы рассказать мне некоторые подробности, почему было лучше использовать отдельные кеши? - person Sarah Tammam; 13.12.2020