Спасибо за отличную статью.
Т.к. работаю в Hazelcast, возьмусь прокомментировать пару моментов.
Буду комментировать по ходу чтения статьи.
Развал кластера и Split Brain
Обычно, из-за высокой latency между датацентрами, мы не рекомендуем размазывать кластер Hazelcast на множестно датацентром. есть WAN Replication, но как и у многих конкурентов она входит в платный пакет.
Так же, хочу отметить, что в более новых версиях появился механизм quorum, который позволяет настроить CP vs AP поведение для конкретных структур данных.
По поводу NoClassDefFoundError. У Hazelcast много чего разного лежит в META-INF/services.
Не все uberjar упаковщики правильно приносят это все.
В общем случае, хотелось бы поглядеть на полный stacktrace, но я тут вижу вы как-то это полечили.
Ложные срабатывания политик эвикта данных
Начиная с 3.7, eviction был очень сильно переработан. Об алгоритме можно почитать тут и тут.
Пусть вас не смущает JCache в последнем линке. с 3.7 JCache и IMap используют унифицированный механизм.
Так же в 3.7, появились Custom Eviction Policies — секция Custom Eviction Policy, так что можно реализовать что-то свое если LRU или LFU не подходят (там есть пример).
можно сначала запустить ноду кластера, а затем применить настройки хранения
так делать нельзя. не то, чтобы я запрещаю, просто в этом случае ваш конфиг не применится, а будут использованы defaults.
Вывод: сначала конфигурируем инстанс, затем запускаем.
ваш вывод очень правильный.
Config conf = new Config();
// кастомизации происходят тут
HazelcastInstance hz = Hazelcast.newHazelcastInstance(conf);
В любом случае, все ноды кластера должны иметь одинаковый конфиг.
Долго выполняются команды в момент изменения структуры кластера
Есть крутилки и для этого.
Вот тут можно почитать, что можно (и нужно крутить, для обработки внештатных ситуаций).
Мониторинг кластера
Тут все правильно сказал.
Management Center, кстати, умеет отдавать агрегированную статистику через JMX.
Можно заставить, MC собирать статистику по Hazelcast кластеру и отдавать ее в Zabbix или Prometheus.
Такое логирование можно реализовать с помощью MapListener, что полностью покрывает потребности нашей команды в мониторинге кластера.
Я бы не рекомендовал. Лучше поглядите на Diagnostics — фича, highly inspired by Metrics framework.
Перезапуск нод кластера
Каждое изменение настроек Hazelcast
мне еще предстоит познать «радость» обновления с Hazelcast 3.5.5 до свежей версии 3.8.
Начиная с 3.6, клиенты и ноды начали общаться по стандартному протоколу Hazelcat Open Client Protocol, что позволяет обновлять минорные версии нод и клиентов в разное время.
В 3.8 EE (Enterprise Edition) появилась возможность обновлять минорные версии нод «на горячую», т.е. обновлять 3.8 -> 3.9, 3.9->3.10 и тд.
Исходя из всего выше описанного, обновление на 3.8 очень рекомендовано.
В любом случае, буду рад ответить на любые вопросы, если такие появятся.
ignite — это OSS. коммерческое решение — GrigGain.
если в общем по функциям смотреть, они пишут что у них больше всего. Качество? Не могу комментировать
Нужно вам это или нет — решать вам.
Если что-то конкретное интересует в Hazelcast — пишите, с удовольствием отвечу!
Спасибо
Да пади мучались сидели! надо было выкрикнуть в лицо, за этим я и презжал. Теперь уже хз когда предстоит такая возможность.
Но для начала, дорогой gurinderu, определите для меня что вы вкладываете в понятие «лучше»?
Кол-во коммитов? Покрытие тестами? количество пользователей? активность community? количество багов? "быстрее"?
есть официальная информация у нас и у них
независимая информация GridGain (Ignite там не нашел), Hazelcast
p.s. кстати если вы следили за развитием проекта ignite, то вы могли бы заметить различные организационные (переход из closed source в open source, модель коммерческой поддержки пользователей, и так далее) изменения, которые компания GridGain привнесла в проект.
Многие из этих изменений являются корневыми для Hazelcast многие годы. И уж если компания, которая конкурирует с нами, копирует, это означает, что мы все делаем правильно!
у меня был клиен у которого был обратный случай. отказались от монги из-за лимитов на индексы. и взяли Hazelcast. я соглашусь с 23derevo, все очень голословно звучит.
можно кричать что «караул, разваливается», но без деталей я вам не смогу помочь. а детали как я понял NDA и все такое (кстати, нет проблем подписать ваш NDA и поглдеть что не так и почему «ноды друг друга не видят».
опять же, что значит «RPS 1000»? это количество рейквестов к вашему сервису или Hazelcast? какой размер объктов? сколько нод?
есть желание поговорить предметно — пишите в личку, с удовольствием поговорю.
+1 лучше оставить лог как есть imo
Спасибо dbelob за highlights!
Спасибо, Данияр! держу кулачки за твой доклад!
причем С# клиент работает через Java клиент (через какой-то дикий интероп)
правильной дорогой идете, товарищи © https://hazelcast.org/documentation/#open-binary
https://blog.hazelcast.com/jepsen-analysis-hazelcast-3-8-3/
Спасибо за отличную статью.
Т.к. работаю в Hazelcast, возьмусь прокомментировать пару моментов.
Буду комментировать по ходу чтения статьи.
Обычно, из-за высокой latency между датацентрами, мы не рекомендуем размазывать кластер Hazelcast на множестно датацентром. есть WAN Replication, но как и у многих конкурентов она входит в платный пакет.
Так же, хочу отметить, что в более новых версиях появился механизм quorum, который позволяет настроить CP vs AP поведение для конкретных структур данных.
По поводу
NoClassDefFoundError. У Hazelcast много чего разного лежит вMETA-INF/services.Не все
uberjarупаковщики правильно приносят это все.В общем случае, хотелось бы поглядеть на полный stacktrace, но я тут вижу вы как-то это полечили.
Начиная с 3.7, eviction был очень сильно переработан. Об алгоритме можно почитать тут и тут.
Пусть вас не смущает JCache в последнем линке. с 3.7 JCache и IMap используют унифицированный механизм.
Так же в 3.7, появились Custom Eviction Policies — секция Custom Eviction Policy, так что можно реализовать что-то свое если LRU или LFU не подходят (там есть пример).
так делать нельзя. не то, чтобы я запрещаю, просто в этом случае ваш конфиг не применится, а будут использованы defaults.
ваш вывод очень правильный.
В любом случае, все ноды кластера должны иметь одинаковый конфиг.
Есть крутилки и для этого.
Вот тут можно почитать, что можно (и нужно крутить, для обработки внештатных ситуаций).
Тут все правильно сказал.
Management Center, кстати, умеет отдавать агрегированную статистику через JMX.
Можно заставить, MC собирать статистику по Hazelcast кластеру и отдавать ее в Zabbix или Prometheus.
Я бы не рекомендовал. Лучше поглядите на Diagnostics — фича, highly inspired by Metrics framework.
вот только вчера выкатили 3.9-EA (early access) с новой фичей про добавление конфигураций динамически.
Можно пробовать!
Вот тут сейчас обидно было ©
Начиная с 3.6, клиенты и ноды начали общаться по стандартному протоколу Hazelcat Open Client Protocol, что позволяет обновлять минорные версии нод и клиентов в разное время.
В 3.8 EE (Enterprise Edition) появилась возможность обновлять минорные версии нод «на горячую», т.е. обновлять 3.8 -> 3.9, 3.9->3.10 и тд.
Исходя из всего выше описанного, обновление на 3.8 очень рекомендовано.
В любом случае, буду рад ответить на любые вопросы, если такие появятся.
ignite — это OSS. коммерческое решение — GrigGain.
если в общем по функциям смотреть, они пишут что у них больше всего. Качество? Не могу комментировать
Нужно вам это или нет — решать вам.
Если что-то конкретное интересует в Hazelcast — пишите, с удовольствием отвечу!
Спасибо
Да пади мучались сидели! надо было выкрикнуть в лицо, за этим я и презжал. Теперь уже хз когда предстоит такая возможность.
Но для начала, дорогой gurinderu, определите для меня что вы вкладываете в понятие «лучше»?
Кол-во коммитов? Покрытие тестами? количество пользователей? активность community? количество багов? "быстрее"?
есть официальная информация у нас и у них
независимая информация GridGain (Ignite там не нашел), Hazelcast
Короче, это все гуглится очень хорошо.
Но от себя хочу добавить, не слушайте меня и не слушайте их.
А просто пойдите скачайте оба продукта, по крутите, поиграйтесь, посмотрите что «лучше» для вас.
тут выше писали, что кому-то и монга лучше.
А когда надоест, возвращайся назад ©
p.s. кстати если вы следили за развитием проекта ignite, то вы могли бы заметить различные организационные (переход из closed source в open source, модель коммерческой поддержки пользователей, и так далее) изменения, которые компания GridGain привнесла в проект.
Многие из этих изменений являются корневыми для Hazelcast многие годы. И уж если компания, которая конкурирует с нами, копирует, это означает, что мы все делаем правильно!
Спасибо
вопросов по Hazelcast было столько, что пропустил доклад про Ignite ;( (на самом деле :D )
опять же, что значит «RPS 1000»? это количество рейквестов к вашему сервису или Hazelcast? какой размер объктов? сколько нод?
есть желание поговорить предметно — пишите в личку, с удовольствием поговорю.