Комментарии 14
Прочитал Heartbeat как Heartblead.
Много думал.
Много думал.
Надо бы переползти чтоли с 3.1, т.к. в 3.2+ сделали нормальный write-behind в MapStore, но также и сломали протокол и чтобы обновить 3.1 до 3.3 надо все ноды остановить, обновить и запустить снова.
вы еще думаете? =)
вообще хазелкаст по разработке похож на wine: в каждой новой версии пофисили старые баги, добавили новые.
а если без шуток: в 3.1 висит баг на утечку ресурсов который пофиксили в 3.2, но в 3.2 добавили новую утечку которую пофиксили только в 3.3 (в 3.2 портировать не собираются фикс). вот сидим думаем добавили ли что в 3.3 =)
постоянная сериализация-десериализация тоже немного напрягает:
1) выбираем формат хранения object
2) делаем put — объект сериализуется в формат data, передается в хранилище, там десериализуется в object
3) делаем get — запрос уходит в хранилище, там он сериализуется в data, на выходе десериализуем обратно в object
вопрос: в чем профит относительно хранения в Data? а хез его знает, так как на практике даже медленней выходит, может для query и подойдет в некоторых случаях.
другой пример: выбор по префиксу, заявляют как хорошую query (формат репозитория binary), на практике все скатывается к
1) запрос ушел на партишены
2) десериализовали ключи и значения, apply на ключи и если проходит, то emit ключ-значение
3) которые для возврата обратно сериализуем в data, а на выходе еще раз десериализуем
для меня непонятно, зачем гонять значение через сериализаторы по 100 раз?
в общем, чем плотнее сталкиваешься с его работой, а соответственно заглядываешь в код, тем меньше хочется его использовать.
вообще хазелкаст по разработке похож на wine: в каждой новой версии пофисили старые баги, добавили новые.
а если без шуток: в 3.1 висит баг на утечку ресурсов который пофиксили в 3.2, но в 3.2 добавили новую утечку которую пофиксили только в 3.3 (в 3.2 портировать не собираются фикс). вот сидим думаем добавили ли что в 3.3 =)
постоянная сериализация-десериализация тоже немного напрягает:
1) выбираем формат хранения object
2) делаем put — объект сериализуется в формат data, передается в хранилище, там десериализуется в object
3) делаем get — запрос уходит в хранилище, там он сериализуется в data, на выходе десериализуем обратно в object
вопрос: в чем профит относительно хранения в Data? а хез его знает, так как на практике даже медленней выходит, может для query и подойдет в некоторых случаях.
другой пример: выбор по префиксу, заявляют как хорошую query (формат репозитория binary), на практике все скатывается к
1) запрос ушел на партишены
2) десериализовали ключи и значения, apply на ключи и если проходит, то emit ключ-значение
3) которые для возврата обратно сериализуем в data, а на выходе еще раз десериализуем
для меня непонятно, зачем гонять значение через сериализаторы по 100 раз?
в общем, чем плотнее сталкиваешься с его работой, а соответственно заглядываешь в код, тем меньше хочется его использовать.
Оно сейчас работает(с кастомным write-behind), есть-пить не просит вот и не торопимся.
Код его, честно говоря, мне тоже не слишком нравится. А какие альтернативы? Вы что-нибудь присматривали?
Код его, честно говоря, мне тоже не слишком нравится. А какие альтернативы? Вы что-нибудь присматривали?
в embedded режиме внутри нескольких серверов.
первоначально там средний объем данных лежал, была попытка использовать их очереди
но с ростом нагрузки перестала устраивать их производительность, в итоге он остался как кластерный кеш сессий и хранилище конфигурации.
Все остальное переделалось под p2p взаимодействие
первоначально там средний объем данных лежал, была попытка использовать их очереди
но с ростом нагрузки перестала устраивать их производительность, в итоге он остался как кластерный кеш сессий и хранилище конфигурации.
Все остальное переделалось под p2p взаимодействие
когда я пришел на проект, то это уже было сделано, сейчас приводим к более вменяемому виду.
одна nosql уже имеется (hbase), поэтому затягивать еще и couch как-то не хочется.
отдельно стоит отметить, что для couch еще нужно отдельно запускать процессы, что дополнительно усложняет инфраструктуру.
в общем как уже говорилось, сейчас осталось:
1) конфигурация кластера (где какие сервисы доступны)
2) хранение сесии, так как запрос может в процессе жизни пройтись по многим серверам, то имеем apache shiro и кеширование в hazelcast
пока справляется после написания N-го количества сериализаторов (до этого на некоторых структурах скатывался до java сериализатора, а так как кеширование класлоадера в hazelcast не было, то получали contention на класлоадере).
hazelcast.org/docs/latest/manual/html/customserialization.html
с текущей нагрузкой справляется, дальше пока думаем куда двигаться.
одна nosql уже имеется (hbase), поэтому затягивать еще и couch как-то не хочется.
отдельно стоит отметить, что для couch еще нужно отдельно запускать процессы, что дополнительно усложняет инфраструктуру.
в общем как уже говорилось, сейчас осталось:
1) конфигурация кластера (где какие сервисы доступны)
2) хранение сесии, так как запрос может в процессе жизни пройтись по многим серверам, то имеем apache shiro и кеширование в hazelcast
пока справляется после написания N-го количества сериализаторов (до этого на некоторых структурах скатывался до java сериализатора, а так как кеширование класлоадера в hazelcast не было, то получали contention на класлоадере).
hazelcast.org/docs/latest/manual/html/customserialization.html
с текущей нагрузкой справляется, дальше пока думаем куда двигаться.
так потиху все к тому и идет… но нужны тесты, как себя поведет система когда мы в нее еще и сессии в hbase начнем впихивать.
с конфигурацией чуть сложнее, так как помимо всего мы используем discovery из hazelcast для прослушки, когда удаленный сервер добавляется или удаляется, с hbase такое сложно будет сделать, тут уже надо использовать zookeeper.
в общем процесс идет, пускай и не сильно быстро, но движется =)
«устраняем косяки по мере их появления», так как большую систему сложно вот так взять и переписать
с конфигурацией чуть сложнее, так как помимо всего мы используем discovery из hazelcast для прослушки, когда удаленный сервер добавляется или удаляется, с hbase такое сложно будет сделать, тут уже надо использовать zookeeper.
в общем процесс идет, пускай и не сильно быстро, но движется =)
«устраняем косяки по мере их появления», так как большую систему сложно вот так взять и переписать
Работая в проекте с oracle coherence, завидую людям, использующим Hazelcast )
Единственное что не нашел в Hazelcast это UDP протокол между узлами кластера для уменьшения latency операций
Единственное что не нашел в Hazelcast это UDP протокол между узлами кластера для уменьшения latency операций
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Hazelcast 3.3 — что нового?