Hazelcast против Ehcache

Question

Вопрос ясен, как вы видите в заголовке, я был бы признателен, если бы вы услышали ваши идеи по поводу adv./disadv. различия между ними.

UPDATE: Я решил использовать Hazelcast из-за преимуществ, таких как механизм распределенного кэширования / блокировки, а также чрезвычайно простой настройки при адаптации его к вашему приложению.

Answer 1

Мы опробовали оба из них для одной из крупнейших онлайн-платформ объявлений и электронной коммерции. Мы начали с ehcache / terracotta (серверный массив), потому что он хорошо известен, поддерживается Terracotta и имеет большую поддержку сообщества, чем hazelcast.
Когда мы получаем его в производственной среде (распределенной, за пределами кластера одного узла), вещи меняются, наш бэкэнд архитектура стала очень дорогой, поэтому мы решили дать шанс Hazelcast.

Hazelcast очень прост, он делает то, что говорит и работает очень хорошо без каких-либо дополнительных настроек.

Наш слой кеширования находится на вершине Hazelcast более года, и мы очень довольны.

Answer 2

Несмотря на то, что Ehcache был популярен среди систем Java, я считаю его менее гибким, чем другие решения для кэширования.Я играл с Hazelcast, и да, он справился, это было легко запустить и т.д., и это новее, чем Ehcache.Я могу сказать, что Ehcache имеет гораздо больше возможностей, чем Hazelcast, более зрелый и имеет большую поддержку.

Существует также несколько других хороших решений для кэширования со всеми различными свойствами и решениями, такими как старый добрый Memcache, Membase (теперь CouchBase), Redis, AppFabric, и даже несколько решений NoSQL, которые предоставляют хранилища значений ключей с или безупорство.Все они имеют разные характеристики в том смысле, что они реализуют теорему CAP или теорему BASE вместе с транзакциями.

Вам нужно больше заботиться о том, какая из функций обладает желаемым в вашем приложении, опять же, вы должны рассмотреть теорему CAP или теорему BASE для своего приложения.

Этот тест было сделано совсем недавно с Cassandra в облаке Netflix.Они достигли миллионов записей в секунду с около 300 экземплярами.Cassandra - это не кэш-память, но ваша модель данных похожа на кеш, состоящий из пар ключ-значение.Вы также можете использовать Cassandra в качестве кеша распределенной памяти.

Answer 3

Hazelcast был кошмаром для масштабирования, и стабильность по-прежнему остается серьезной проблемой.

Выбор выделенного клиента для компонента сетки:

1. Грязная версия, которая не может пережить потерю узла в любом месте, отрицая точку резервного копирования (суперклиент), или
2. AnНевероятно медленная опция собственного клиента, которая не позволяет распределять нагрузку между узлами обработки в сетке.

Если какой-либо хост мог бы запрашивать записи из этой сетки данных, это был бы приятный дизайн, но вы застряли с этими двумя слабыми вариантами, чтобы получить что-нибудь из этого.

Кроме того, часто возникают проблемы с блокировкой пулов потоков базы данных на отдельных элементах и ​​отсутствием записи в базы данных, что приводит к постоянной потере записей, и нам часто приходится часами снимать все это, чтобы обновить любой изJVM.Раздвоенный мозг также остается проблемой, хотя в 1.9.6 он, похоже, немного успокоился.

Объединение для перехода на Ehcache и улучшение уровня базы данных вместо использования его в качестве лейкопластыря.

Answer 4

Hazelcast был для меня кошмаром. Я смог заставить его «работать» в кластерной среде Websphere. Я использую термин «работать» свободно. Во-первых, вся документация Hazelcast устарела и показывает только примеры использования устаревших вызовов методов. Попытка использовать новый код без комментариев в Javadocs и без примеров в документации очень трудна. Кроме того, код контейнера J2EE просто не работает на этом этапе, потому что он не поддерживает транзакции XA в Websphere. Выдается ошибка, вызывающая код, который явно следует их единственному примеру J2EE (похоже, Milestone 3.0 решает эту проблему). Мне пришлось забыть о присоединении Hazelcast к транзакции J2EE. Похоже, что Hazelcast определенно ориентирован на контейнерную среду не EJB / Non-J2EE. При вызове Hazelcast.getAllInstances () не сохраняется какая-либо информация о состоянии Hazelcast при переключении с одного корпоративного Java-компонента на другой. Это вынуждает меня создавать новый экземпляр Hazelcast просто для запуска вызовов, которые дают мне доступ к моим данным. Это приводит к тому, что многие экземпляры Hazelcast запускаются на одной и той же JVM. Кроме того, получение данных из Hazelcast не быстро. Я попытался получить данные, используя как собственный клиент, так и непосредственно как член кластера. Я сохранил 51 список, каждый из которых содержал только 625 объектов в Hazelcast. Я не мог выполнить запрос непосредственно по списку и не хотел сохранять карту только для того, чтобы получить доступ к этой функции (операции SQL можно выполнять на карте). Для получения каждого списка из 625 объектов потребовалось около половины секунды, потому что Hazelcast сериализует весь список и отправляет его по проводам, а не просто сообщает мне дельту (что изменилось). Другое дело, что мне пришлось переключиться на конфигурацию TCPIP и явно перечислить IP-адреса серверов, которые я хотел бы видеть в кластере. Конфигурация многоадресной рассылки по умолчанию не работала, и из групповых обсуждений в Google другие люди также испытывают эту проблему. Подводить итоги; В конечном итоге я получил 8 машин, соединяющихся в кластере в течение многих часов мучительной программной конфигурации, проб и ошибок (документация не поможет), но когда я это сделал, у меня все еще не было контроля над количеством экземпляров и разделов, создаваемых на каждом из них. JVM из-за недоделанной природы Hazelcast для EJB / J2EE, и это было ОЧЕНЬ МЕДЛЕННО. Я реализовал реальный вариант использования в приложении по страхованию от безработицы, над которым я работаю, и код стал намного быстрее совершать прямые вызовы в базу данных. Было бы здорово, если бы Hazelcast работал как рекламируется, потому что я действительно не хотел использовать отдельный сервис для реализации того, что я пытаюсь сделать. Я широко использовал MongoDB, поэтому могу пропустить все в кэше памяти и просто сериализовать свои объекты в виде документов в отдельном хранилище.

Answer 5

Hazelcast сериализует все, когда есть узел (стандартный-1), поэтому данные, которые вы будете сохранять в Hazelcast, должны реализовывать сериализацию.

http://open.bekk.no/efficient-java-serialization/

Answer 6

Одним из преимуществ Ehcache является то, что он поддерживается компанией (Terracotta), которая проводит обширную тестирование производительности, отработки отказа и платформы в большой лаборатории производительности. Терракота обеспечивает поддержку, компенсацию и т. Д. Для многих компаний такие вещи важны.

Я не использовал Hazelcast, но слышал, что он прост в использовании и работает. Я ничего не слышал о масштабируемости или производительности Hazelcast против Terracotta / Ehcache, но, учитывая объем тестирования масштабируемости и отработки отказа, который делает Terracotta, мне сложно представить, что Hazelcast будет конкурентоспособным в производственном развертывании. Но я предполагаю, что он будет работать нормально для небольших применений.

[Предвзятость: я бывший сотрудник Терракоты.]