hazelcast против ehcache
вопрос ясен, как вы видите в названии, я был бы признателен, чтобы услышать ваши идеи о adv./disadv. разница между ними.
обновление: Я решил использовать Hazelcast из-за таких преимуществ, как механизм распределенного кэширования/блокировки, а также чрезвычайно простая конфигурация при адаптации к вашему приложению.
6 ответов
мы попробовали оба из них для одного из крупнейших интернет-рекламы и электронной коммерции платформы. Мы начали с ehcache / terracotta (Server array), потому что он хорошо известен, поддерживается Terracotta и имеет большую поддержку сообщества, чем hazelcast.
когда мы получаем его в производственной среде (распределенной,за пределами одного кластера узлов), все изменилось, наша архитектура бэкэнда стала очень дорогой, поэтому мы решили дать Hazelcast шанс.
Hazelcast мертв просто, он делает то, что говорит и работает очень хорошо без каких-либо накладных расходов конфигурации.
Наш кэширующий слой находится на вершине hazelcast уже более года, мы им очень довольны.
хотя Ehcache был популярен среди Java-систем, я нахожу его менее гибким, чем другие решения для кэширования. Я играл с Hazelcast, и да, он сделал эту работу, было легко запустить и т. д., И это новее, чем Ehcache. Я могу сказать, что Ehcache имеет гораздо больше возможностей, чем Hazelcast, является более зрелым и имеет большой поддержки.
есть несколько других хороших решений кэша, а также, со всеми различными свойствами и решениями, такими как старый добрый Memcache, Membase (теперь CouchBase), Redis, AppFabric, даже несколько решений NoSQL, которые предоставляют хранилища ключевых значений с сохранением или без него. Все они имеют разные характеристики в том смысле, что они реализуют теорему CAP или базовую теорему вместе с транзакциями.
вы должны больше заботиться о том, какой из них имеет функциональность, которую вы хотите в своем приложении, опять же, вы должны рассмотреть теорему CAP или базовую теорему для своего приложения.
этой тест было сделано совсем недавно с Кассандра на "облаке" от Netflix. Они добрались до миллиона записей в секунду около 300 экземпляров. Cassandra не является кэшем памяти, но ваша модель данных похожа на кэш, который состоит из пар ключевых значений. Вы также можете использовать Кассандра как распределенной кэш-памяти.
Hazelcast был кошмаром для масштабирования, и стабильность по-прежнему является серьезной проблемой.
выделенный клиент для выбора компонентов сетки -
- грязная версия, которая не может пережить потерю узла в любом месте, отрицая точку резервного копирования (superclient) или
- невероятно медленный собственный клиентский параметр, который не допускает балансировки нагрузки на узлы обработки в сетке.
Если любой хост может запросить записи из эта сетка данных это был бы сладкий дизайн, но вы застряли с этими двумя тусклыми вариант, чтобы получить что-нибудь из него.
также несколько проблем с пулами потоков базы данных, блокирующихся на отдельных членах и ничего не пишущих в базы данных, что приводит к потере постоянных записей, является частой проблемой, и нам часто приходится снимать все это в течение нескольких часов, чтобы обновить любой из JVM. Разделенный мозг также по-прежнему является проблемой, хотя в 1.9.6 он, похоже, успокоился маленький.
объединение для перехода на Ehcache и улучшение уровня базы данных вместо использования этого в качестве пластыря.
Hazelcast был кошмаром для меня. Я смог заставить его "работать" в кластерной среде Websphere. Я использую термин "работа" свободно. Во-первых, вся документация Hazelcast устарела и показывает только примеры использования устаревших вызовов методов. Попытка использовать новый код без комментариев в Javadocs и без примеров в документации очень сложна. Кроме того, код контейнера J2EE просто не работает на этом этапе, поскольку он не поддерживает транзакции XA в В WebSphere. Возникает ошибка вызова кода, который следует за их единственным примером J2EE явно (похоже, что Milestone 3.0 решает эту проблему). Мне пришлось забыть о присоединении Hazelcast к транзакции J2EE. Кажется, что Hazelcast определенно ориентирован на среду контейнера non 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, поэтому я могу пропустить весь кэш памяти и просто сериализовать свои объекты как документы в отдельном репозитории.
Hazelcast сериализует все, когда есть узел (стандартный), поэтому данные, которые вы сохраните в Hazelcast, должны реализовать сериализацию.
одним из преимуществ Ehcache является то, что он поддерживается компанией (Terracotta), которая выполняет обширную производительность, отработку отказа и тестирование платформы в большой лаборатории производительности. Terracotta предоставляет поддержку, компенсацию и т. д. Для многих компаний это важно.
Я не использовал Hazelcast, но я слышал, что он прост в использовании и что он работает. Я ничего не слышал о масштабируемости или производительности Hazelcast vs Terracotta/Ehcache, но учитывая объем масштабируемости и отказоустойчивости, который делает Terracotta, мне трудно представить, что Hazelcast будет конкурентоспособным в производственном развертывании. Но я предполагаю, что он отлично подойдет для небольших целей.
[Bias: я бывший сотрудник Terracotta.]