Вопрос ясен, как вы видите в названии, я был бы рад услышать ваши идеи о adv./disadv. различия между ними.
UPDATE: Я решил использовать Hazelcast из-за преимуществ, таких как распределенный механизм кеширования/блокировки, а также чрезвычайно простая конфигурация, адаптируя его к вашему приложению.
Мы попробовали оба из них для одной из крупнейших онлайн-объявлений и платформы для электронной коммерции. Мы начали с ehcache/terracotta (массив серверов), потому что это хорошо известно, поддерживается Terracotta и имеет большую поддержку сообщества, чем hazelcast.
Когда мы получим его в производственной среде (распределенной, помимо одного кластера node), все изменилось, наша бэкэнд-архитектура стала очень дорогостоящей, поэтому мы решили дать шанс на каникулу.
Hazelcast мертв просто, он делает то, что он говорит, и отлично работает без каких-либо накладных расходов.
Наш кеширующий слой находится на вершине орешника более года, мы очень этому довольны.
Несмотря на то, что Ehcache был популярен среди систем Java, я нахожу его менее гибким, чем другие решения для кеширования. Я играл с Hazelcast и да, он выполнял эту работу, было легко запустить и т.д., И это новее, чем Ehcache. Я могу сказать, что Ehcache имеет гораздо больше возможностей, чем Hazelcast, более зрелый и имеет большую поддержку.
Существует также несколько других хороших решений для кеширования со всеми различными свойствами и решениями, такими как старые старые Memcache, Membase (теперь CouchBase), Redis, AppFabric и даже несколько решений NoSQL, которые предоставляют хранилища ключей с сохранением или без сохранения. Все они имеют разные характеристики в том смысле, что они реализуют теорему CAP или теорему BASE вместе с транзакциями.
Вам нужно больше заботиться о том, какой из функций вы хотите в своем приложении, опять же, вы должны рассмотреть теорему CAP или теорему BASE для вашего приложения.
Этот тест был выполнен совсем недавно с Cassandra в облаке Netflix. Они достигли миллионов записей в секунду с примерно 300 экземплярами. Cassandra - это не кеш памяти, но ваша модель данных похожа на кеш, состоящий из пар ключей. Вы также можете использовать Cassandra в качестве кеша распределенной памяти.
Hazelcast был кошмаром в масштабе, и стабильность по-прежнему остается серьезной проблемой.
Выбор выделенного клиента для grid-компонентов -
Если какой-либо хост может запросить записи из этой сетки данных, это будет сладкий дизайн, но вы застряли в этих двух тусклых вариантах, чтобы получить что-то из этого.
Также часто возникают проблемы с пулами потоков базы данных, которые блокируются для отдельных членов и не записывают ничего в базы данных, что приводит к потере постоянных записей, и нам часто приходится часами останавливать все это, чтобы обновить любую из JVM. Сплит-мозг также по-прежнему остается проблемой, хотя в 1.9.6 он, похоже, немного успокоился.
Ралли для перехода на Ehcache и улучшения уровня базы данных вместо использования в качестве полосы помощи.
Hazelcast сериализует все, когда есть node (стандартный), поэтому данные, которые вы сохраните в Hazelcast, должны реализовывать сериализацию.
Hazelcast был для меня кошмаром. Я смог заставить его "работать" в кластерной среде Websphere. Я использую термин "работа" свободно. Во-первых, вся документация Hazelcast устарела и показывает только примеры с использованием устаревших вызовов методов. Попытка использовать новый код без комментариев в Javadocs, и никаких примеров в документации очень сложно. Кроме того, код контейнера J2EE просто не работает на этом этапе, поскольку он не поддерживает транзакции XA в Websphere. Ошибка вызывает код вызова, который явно следует за их единственным примером J2EE (он выглядит так, как Milestone 3.0 решает эту проблему). Я должен был забыть о присоединении к Hazelcast к транзакции J2EE. Кажется, что Hazelcast определенно ориентирован на контейнерную среду с не EJB/Non-J2EE. Выполнение вызовов Hazelcast.getAllInstances() не позволяет сохранить информацию о состоянии Hazelcast при переключении с одного предприятия java bean на другое. Это заставляет меня создать новый экземпляр Hazelcast для запуска вызовов, которые дают мне доступ к моим данным. Это заставляет многих экземпляров Hazelcast запускаться на одной JVM. Кроме того, получение данных из Hazelcast происходит не быстро. Я попытался получить данные, используя как собственный клиент, так и непосредственно в качестве члена кластера. Я сохранил 51 список, каждый из которых содержит только 625 объектов в Hazelcast. Я не мог выполнить запрос непосредственно в списке и не хотел хранить карту, чтобы получить доступ к этой функции (операции SQL могут выполняться на карте). Потребовалось около полутора секунд, чтобы получить список из 625 объектов, потому что Hazelcast Сериализует весь список и отправляет его по проводу, а не просто дает мне дельту (что изменилось). Другое дело, мне пришлось переключиться на конфигурацию TCPIP и явно указать IP-адреса серверов, которые я хотел бы быть в кластере. Конфигурация Multicast по умолчанию не работала и из групповых обсуждений в google, другие люди тоже испытывают эту проблему. Подводить итоги; В конце концов, я получил 8 машин, сообщающихся в кластере, через многочасовую мучительную программную конфигурацию, пробную версию и ошибку (документация будет мало помогать), но когда я это сделал, я все еще не контролировал количество экземпляров и разделов, создаваемых на каждом JVM из-за половины законченного характера Hazelcast для EJB/J2EE, и это было ОЧЕНЬ МЕДЛЕННО. Я применил реальный прецедент в приложении страхования от безработицы, над которым я работаю, и код был намного быстрее, делая прямые звонки в базу данных. Было бы здорово, если бы Hazelcast работал как рекламируемый, потому что я действительно не хотел использовать отдельный сервис для реализации того, что я пытаюсь сделать. Я использовал MongoDB широко, поэтому я могу пропустить все в кеше памяти и просто сериализовать свои объекты как документы в отдельном репозитории.
Одно из преимуществ Ehcache заключается в том, что он поддерживается компанией (Terracotta), которая обеспечивает обширную производительность, отказоустойчивость и тестирование платформы в большой лаборатории производительности. Терракота обеспечивает поддержку, возмещение и т.д. Для многих компаний важна такая вещь.
Я не использовал Hazelcast, но я слышал, что он прост в использовании и работает. Я ничего не слышал о масштабируемости или производительности Hazelcast vs Terracotta/Ehcache, но учитывая объем масштабируемости и отказоустойчивости, которые испытывает Terracotta, мне трудно представить, что Hazelcast будет конкурентоспособным в производственном развертывании. Но я полагаю, что это будет отлично работать для небольших целей.
[Смелость: я бывший сотрудник Терракотты.]
Но Ehcache не поддерживает jdk11. Любые предложения на то же самое?