Блог

Главная - Вопросы по программированию - Oracle Coherence быстрый пустой полный кластер

Oracle Coherence быстрый пустой полный кластер

#oracle-coherence

#oracle-coherence

Вопрос:

У меня возникли проблемы с кластером кэша для очистки всех хранилищ данных кэша.

Этот кластер содержит 89 хранилищ кэша, и для полной выгрузки данных требуется более 40 минут.

Я использую эту функцию:

 public void deleteAll() {
    try {
        getCache().clear();
    } catch (Exception e) {
        log.error("Error unloading cache",getCache().getCacheName());
    }
}

Метод getCache извлекает NamedCache из CacheFactory.

 public NamedCache getCache() {
    if (cache == null) {
        cache = com.tangosol.net.CacheFactory.getCache(this.idCacheFisica);
    }

    return cache;
}

Кто-нибудь нашел какой-либо другой способ сделать это быстрее?

Заранее благодарю вас,

Комментарии:

1. Вызывается ли eraseAll метод для каждого CacheStore ?

2. Да, цель этого метода — оставить кластер кэша пустым для перезагрузки новых данных.

3. Итак, вы используете CacheStore , но инициализируете кэш вне кластера? Если это действительно то, что вы хотите сделать, я бы посмотрел на реализацию CacheStore s — удаляют ли они строки по одному ключу за раз или выполняют массовое удаление?

4. да, обновление данных происходит из внешнего события. И я не могу найти ни одной ссылки на массовое удаление. Но этого было бы достаточно с помощью метода быстрой очистки кэша. Потому что затем они снова загрузят все данные. Заранее благодарю вас, Ник.

5. Пожалуйста, добавьте несколько примеров кода для одной из CacheStore реализаций

Ответ №1:

Странно, что это займет так много времени, хотя, честно говоря, это необычно для вызова clear .

Вы можете попробовать уничтожить кеш с помощью NamedCache.уничтожить или CacheFactory.destroy(NamedCache).

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

Ответ №2:

Часто вызов «массовой операции», такой как clear(), будет передаваться обратно на резервные карты как массовая операция, но в какой-то момент (где-то внутри серверного кода) станет реализацией на основе итераций, так что каждая удаляемая запись может быть оценена в соответствии с любыми зарегистрированными правилами, триггеры, прослушиватели событий и т. Д., И чтобы резервные копии могли быть точно записаны. Другими словами, чтобы гарантировать «корректность» в распределенной среде, это замедляет работу и заставляет ее выполняться в виде некоторой упорядоченной последовательности подопераций.

Некоторые из причин, по которым это может произойти:

  1. Вы настроили режим чтения, записи и / или последующей записи для кэша;
  2. У вас есть почти все кэши и / или непрерывные запросы (которые подразумевают слушателей);
  3. У вас есть индексы (которые необходимо обновлять по мере исчезновения данных);
  4. и т.д.

Я попрошу несколько предложений о том, как ускорить это.

Обновление (14 июля 2014 г.) — Да, оказывается, что это известная проблема (т. Е. Что Ее можно оптимизировать), но для поддержания как «корректности», так и обратной совместимости оптимизация (которая была бы существенными изменениями) была отложена, и clear() все еще выполняетсяитеративным образом на серверной части.