Предикат Hazelcast застревает во время тяжелой нагрузки - PullRequest
Новая
       9

Предикат Hazelcast застревает во время тяжелой нагрузки

0 голосов
/ 09 февраля 2019

У меня есть двухузловой кластер Hazelcast размером 6 Гб каждый.У меня есть предикат, который работает на четырех полях, поэтому, например, для целей, давайте рассмотрим класс Employee 

  public class Employee {
  String id,
  String name,
  String surname,
  String timestamp
  .....
  }

Всего в классе около 13 полей или около того.Я выполняю запрос диапазона по метке времени и полностью совпадаю с остальными 3 полями - идентификатор, имя и фамилия.Для сериализации я использую IdentifiedDataSerializable, так как это наиболее эффективная форма сериализации, которую может предложить Hazelcast.У меня есть настройка контейнера сервлета tomcat, поэтому каждый входящий запрос запускает предикат в кластере.Проблема, с которой я сталкиваюсь в настоящее время, заключается в том, что в кластере примерно 100 000 записей, и я провожу тест производительности на контейнере Tomcat, большинство потоков Tomcat застревают, так как запрос предиката никогда не возвращается.Я посмотрел на модель потоков, предоставленную hazelcast - https://docs.hazelcast.org/docs/latest-dev/manual/html-single/index.html#threading-model.Я возился с разными видами потоков, используя свойства в документации, и это улучшило ситуацию, но в основном он работал в темноте.Я добавил индекс для идентификатора поля, но это тоже не улучшает ситуацию.

Я был бы очень признателен, если бы кто-то указал мне верное направление на то, как я мог бы решить эту проблему.Заранее спасибо!

РЕДАКТИРОВАТЬ -

Версия Hazelcast, используемая как для кластера, так и для клиента, составляет 3.9.Кроме того, я использую Hazelcast, как встроенный в приложение весенней загрузки.Не думаю, что это даст какой-то эффект, но хотел, чтобы вы все знали.

1 Ответ

0 голосов
/ 12 февраля 2019

@ Indraneel-Bende, пара предложений:

  1. Механизм запросов Hazelcast оценивает все предикаты и объединяет результаты.Если это предикат AND, то после всех 4 результатов Predicate будут выбраны общие для всех 4 результатов.Таким образом, если какое-либо из этих полей имеет низкую мощность и возвращает слишком много результатов, это замедлит предикат.Поэтому я бы предложил определить индекс только для одного поля с наибольшим количеством элементов или не более 2 полей.
  2. Поскольку не все поля будут проиндексированы, записи, возвращаемые из хранилища индексов, должны быть десериализованы.применять неиндексированные предикаты.Даже с IdentifiedDataSerializable, если у вас слишком много полей, вы будете платить полную стоимость десериализации каждый раз.Вместо этого вы можете реализовать сериализацию Portable.Хотя размер хранимой записи будет больше, таким образом члены Hazelcast могут десериализовать только те поля, которые вы используете в этих предикатах, и это ускорит запросы.
  3. Как описано здесь, https://docs.hazelcast.org/docs/3.9/manual/html-single/index.html#copying-indexes, Индексные результаты копируются, чтобы удостовериться в правильности результатов, особенно новые узлы присоединяются / покидают кластер.Если вы уверены, что членство не изменится, вы можете установить hazelcast.index.copy.behavior на NEVER.Это также ускорит запросы.

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

...