Pull to refresh

Comments 20

hazelcast сырой

Кому лучше? Используем Hazelcast уже года 4, проблем нет.
А вы используете что-нибудь, кроме функциональности распределенной хеш-мапы? Просто когда у нас было тестирование разных гридов, hazelcast выглядел не очень стабильно, причем и сами представители компании говорили, что они пока не production-ready.
Ну как-бы распределенная Map это и есть ядро :) Все остальное построено на ее основе.
Используем локи, очереди, удаленные вызовы.
Использую coherence на проекте. Лицензии стоят как золотой унитаз и по ядрам CPU. Бесплатно можно в dev использовать…
Декомпилировал, чтобы понять как и что в ReadWriteBackingMap и сокетах для extended клиента. Без декомпилятора с ним жизнь вообще не возможна при advanced usage.
Если использовать его протокол TCMP(на основе UDP) тут начинается веселье редкостное. И в статье на этот счет явная дезинформация:
У вас нет ограничения на размер отдельной пары ключ-значение.

При десятко мегабайтных значениях этой пары кластер может просто начать «разваливаться». Это особенность протокола. Также находил переполнение буфера в extended протоколе и много других забавных вещей. Очень много узнал от эксперта по этому решению Алексея Рагозина и из личного опыта работы с coherence.
А также нужен тюнинг GC и прочие радости, чтобы кластер oracle coherence работал как ожидается
Хранить много данных и считать по ним быстро нужно далеко не каждой организации. В сельскую библиотеку такая система не нужна. Такая система нужна тем, кому нужна скорость и кто готов за нее платить. Я видел использование Coherence только в банках.
И потом, если бы такую цену не платили то Coherence стоила бы меньше.

По поводу размера. Ограничения на размер нет. Просто нужно понимать, как система себя будет вести в каждом конкретном случае.
Как говорил gricom в комментарии выше есть open source аналоги, если только это не банк и не гос. проект для министерства, где надо заплатить как можно больше за лицензии. Главное преимущество у coherence на сегодня — это его TCMP на основе UDP, который обеспечивает low latency по сравнению с TCP протоколами других решений на обычной ethernet сети. Но это же является сомнительным решением. Так как best practices — это выделенная сеть только для coherence с приличным размером jumbo frame, нельзя использовать виртуализованные решения.

Если в течении достаточно короткого времени(и количества отправленных пакетов) не приходит heartbeat от любого из storage node кластеров, то все узлы кластера теряют этот узел и восстанавливают из бэкапа его данные в другом процессе. А теперь возвращаемся к
По поводу размера. Ограничения на размер нет. Просто нужно понимать, как система себя будет вести в каждом конкретном случае.


По своему TCMP протоколу узлы обмениваются не только данными, но и heartbeat. И если объем данных достаточно большой… Такое наблюдал, когда пересылали value размером 30MB. Кластер просто «разваливается», т.к. узлы теряют друг друга. Восстанавливают первичные партиции из бэкап партиций. В время востановления кластер не доступен для клиентов — пауза в обслуживании. Часто при восстановлении бывает ситуация, что объема свободного java heap не достаточно для восстановления. Увеличиваются паузы при GC сборках в storage node, и новые узлы не успевают послать heartbeat. Дальше работает принцип домино… В итоге у вас очень дорогое и «отказоустойчивое» решение не доступно в течении длительного времени до полного перезапуска кластера.

Практический совет на размер данных от гуру: средний размер объектов десятки — сотня килобайт при работе кластера по TCMP протоколу. А также много полезных решений для coherence есть на сайте open-source проекта gridkit

Когда coherence появился — не было особых альтернатив. Сейчас доступны hazelcast, JBoss Infinispan.
У того же hazelcast, на мой взгляд, кое что творчески «заимствовано» из coherence(сериализация). API интерфейсы ближе к стандартным java. Так например интерфейсы локов это реализации java.util.concurrent.locks, распределенный Executor — интерфейс java.util.concurrent.ExecutorService.
Да и за деньги лицензий на Coherence, я бы рекомендовал лучше купить infiniband и использовать какое-либо из аналогичных open-source решений. А если вам невозможно отказаться от Coherence по политическим соображениям, не завязывайтесь в коде на его интерфейсы и делайти слой абстракции для cache решения. Чтобы в случае надобности его можно было бы заменить на альтернативное решение.

Лично для меня Coherence — боль на проекте, при том что у нас куплены лицензии, официальный саппорт и по нему доступна экспертиза в организации.
Кстати, у нас Coherence бегает как на железе, так и на виртуалках. Я слышал, что он не любит виртуалки, но по-моему это всё из-за рассинхронизации времени, так что если синхронизировать время по ntp, то всё должно быть ОК. По крайней мере у нас в продакшене проблем из-за этого не было.

Что касается боли — опять же не приходилось особо её испытывать. Да, нашли одну хитрую багу в conditional index, отрепортили в Оракл, сделали свою имплементацию индекса и поехали дальше, до сих пор работает. Наоборот, было очень интересно разбираться, как и что работает, потому что там всё достаточно логично.
Саппорт — ужасный. У нас был телефонный разговор с двумя людьми, которых представили как архитекторов Coherence, но у нас было ощущение, что мы позвонили в Apple, потому что самым популярным ответом на наши вопросы типа «а как правильно сделать вот такую штуку» был «you don't need it».

Вот чего сильно не хватало в Coherence — это распределенной очереди, которая есть в Hazelcast.
Какой протокол используется в кластере? У вас много сообщений soft timeout в логах?
Собирается кластер по мультикасту, wka не используем. Знаю, что советуют использовать TCP и wka, но т.к. всё работает без проблем, то ничего не меняем:)
Софт таймаутов нет совсем.
Везет вам, у нас WKA, выделенная 10G ethernet и свитч отдельный.
Вчера разрешал инцидент с кластером из 30 storage узлов coherence(на 6 физических узлах с 512Gb RAM) и числом партиций > 1000. Так вот при перезагрузке только одного процесса он не мог присоединиться к кластеру. Вообще какая-то вероятностная ерунда
У нас всё скромнее, 9 стораджей (3 физических сервера) плюс еще 3 железных хоста, на которых запущен еще 21 узел (не стораджи)
Еще есть пара десятков кластеров на виртуалках (6 стораджей + 12 не стораджей)
Эту субботу я провел на работе, присматривая за prod кластером и расследуя performance issue, которое, к счастью, оказалось не в coherence. Иначе бы я там ночевал
Трудозатраты на «допиливание» coherence, я лучше бы потратил на изучение исходных кодов hazelcast и тюнинг решений на его основе. По крайней мере его можно использовать как с покупкой поддержки так и без лицензий(apache2 лицензия на community edition) на любых проектах
Кстати, все, кто используют кохеренс на все деньги интенсивно, действительно живут в обнимку с декомпилятором, только это запрещено лицензией:) Так что когда им сабмиттишь баги, надо говорить, что «судя по поведению системы, вот тут-то вы делаете вот то-то. Если это так, то это баг».
Хотя встречал на их форуме, что Рагозин отправлял инженерам оракла копипасту кода, и никто ничего не говорил против.
никто ничего не говорил против

Странно что oracle до сих пор не доплачивает Алексею Рагозину за багфикс, open source расширения для coherence и популяризацию технологии))) Год назад я работал с ним в одном проекте, а сейчас пользуюсь его наработками. Особо нравится возможность запускать несколько нод coherence в одной jvm одновременно и тестировать несколько версий extended клиента в одной jvm сразу.

Когда кластер не работает так как ожидается, надо перерыть десятки-сотни лог файлов на всех узлах кластера. Чтобы избежать эту боль при работе с ним и упростить жизнь поддержке SL3,4 интегрировал Elasticsearch/Logstash/Kibana в наш проект.

Многие лицензии на коммерческое ПО запрещают декомпиляцию. Но это же не повод усложнять себе жизнь, да еще и за столько денег и с такой чудесной поддержкой. Благо хоть обфускацию не применили…
Статья читается тяжело, на вопрос из заголовка отвечает пара абзацев, остальное — немного о другом. Смахивает на авто-перевод.

Если ноды хранения и ноды вычисления разделены, то пересылка данных по сети все-таки есть? Или они всегда на одной физической машине? Но в таком случае зачем из разделять на два процесса?

Почему нужна была еще_одна_сериализация?

Сканирование массива также происходит последовательно. Из этого следует не очевидный вывод: наиболее используемые поля должны находиться ближе к началу байтового массива.

Что за сканирование?
Это не автоперевод. Цель была дать общее определение терминов в начальной статье. Все детали работы и реализации в одну статью не поместятся.

Ноды хранения держат данные. Ваша цель сделать так, чтобы они не упали по OOM. Поэтому базовые вычисления разумно выполнять на этих нодах, а вот аналитику по базовым вычислениям выполнять на вычислительных нодах. Вы можете разнести по разным машинам если хотите. Главное, что вы не передаете все данные какие есть для вычислений на клиенте. У вас есть возможность делать промежуточные вычисления.

По поводу сканирования. Предположим у вас есть класс

public class Person implements PortableObject {
    private String firstName;
    private String lastName;
....................

    public void readExternal(PofReader pofReader) throws IOException {
        firstName = pofReader.readString(0);
        lastName = pofReader.readString(1);
    }

    public void writeExternal(PofWriter pofWriter) throws IOException {
        pofWriter.writeString(0, firstName);
        pofWriter.writeString(1, lastName);
    }
}


В этом случае сначала будет записан firstName, а за ним будет идти lastName.
Теперь у вас есть данные в кеше и есть задача выбрать только lastName. Вы пишете ValueExtractor. Так вот когда экстрактор будет работать, он просканирует массив с начала, найдет lastName и вернет его.

Именно эта мысль была заключена во фразе «cканирование массива происходит последовательно».
Sign up to leave a comment.

Articles