Как стать автором
Обновить

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

Он очень платный. Прямо очень.
hazelcast сырой, лучше смотреть на JBoss Infinispan либо GridGain
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канирование массива происходит последовательно».
Спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации