Смайлы Вкл.

Ответ 1

Мы использовали его в производстве с версии 1.8+, используя в основном распределенную функцию блокировки. Он отлично работает, мы нашли пару обходных путей/ошибок, но они были исправлены относительно быстро.

С блокировками 1.8M в день мы не обнаружили проблем до сих пор.

Я рекомендую начать использовать версию 1.9.4.4.

Ответ 2

Есть еще некоторые проблемы, связанные с его развитием,
http://code.google.com/p/hazelcast/issues/list
Как правило, вы можете либо позволить использовать собственный алгоритм многоадресной рассылки, либо указать свой собственный ip. Мы пробовали его в локальной сети, и он работает очень хорошо. Производительность была неплохой, но инструмент мониторинга не работал очень хорошо, так как он не обновлялся большую часть времени. Если вы можете жить с текущими проблемами, то все это нужно для этого. Я бы использовал его с осторожностью, но это отличный рабочий инструмент IMHO.

Обновление: Мы используем Hazelcast в течение нескольких месяцев, и он работает очень хорошо. Настройки относительно просты в настройке и с новыми обновлениями, достаточно полны, чтобы настраивать даже небольшие вещи, такие как количество потоков, разрешенных в операциях чтения/записи.

Ответ 3

Мы используем Hazelcast (1.9.4.6 сейчас) в производстве, интегрированном со сложной транзакционной услугой. Он был добавлен, чтобы облегчить непосредственные проблемы с пропускной способностью базы данных. Мы обнаружили, что нам часто приходится останавливать его, снижая все транзакционные услуги в течение как минимум часа. Мы работаем с клиентами в режиме суперклиента, потому что это единственный вариант, который даже отдаленно удовлетворяет нашим требованиям к производительности (примерно в 4 раза быстрее, чем у локальных клиентов). К сожалению, остановка суперклиента node вызывает проблемы с разделом мозга и заставляет сетку потерять записи, вынуждая полное прекращение обслуживания. Мы пытаемся заставить этот продукт работать для нас почти полный год, и даже заплатили за то, чтобы 2 представителя лебединого фонаря вылетели, чтобы помочь. Они не смогли создать решение, но смогли сообщить нам, что мы, вероятно, ошибались. По их мнению, он должен работать лучше, но это было в значительной степени потерянное путешествие.

На данный момент мы находимся на крючке с более чем 6 цифрами в год в рамках лицензионных сборов, и в настоящее время мы используем в 5 раз больше ресурсов, чтобы поддерживать сеть и удовлетворять наши потребности в производительности, чем мы будем использовать с кластеризованным и оптимизированным стек базы данных. Для нас это было абсолютно неправильным решением.

Этот продукт убивает нас. Используйте это с осторожностью, экономно и только для простых сервисов.

Ответ 4

Если моя собственная компания и проекты считают реальным миром, вот мой опыт. Я хотел бы приблизиться к устранению внешнего (дискового) хранилища в пользу безграничной и постоянной "ОЗУ". Для начинающих, которые устраняют CRUD-сантехнику, которая иногда составляет до 90% от так называемого "среднего уровня". Есть и другие преимущества. Поскольку оперативная память - это ваша "база данных", вам не нужны сложные кэши или репликация сеанса HTTP (что, в свою очередь, устраняет уродливую липкую технику сеанса).

Я считаю, что RAM - это будущее, и у Hazelcast есть все, что может быть в памяти: запросы, транзакции и т.д. Поэтому я написал абстрактную мини-фреймворк: для загрузки данных из постоянного хранилища (я могу подключить все, что может хранить BLOB - самым быстрым оказался MySQL). Слишком долго объяснять, почему мне не понравилась встроенная поддержка настойчивости Hazelcast. Это довольно общий и рудиментарный. Они должны удалить его. Это не наука о ракетах, чтобы реализовать свои собственные распределенные и оптимизированные записи и записи. Принял меня на неделю.

Все было в порядке, пока я не начал тестирование производительности. Запросы медленные - после всех оптимизаций, которые я сделал: индексы, переносимая сериализация, явные компараторы и т.д. Простой запрос "больше чем" в индексированном поле занимает 30 секунд на наборе 60 тыс. Записей 1К (записи в карты). Я считаю, что команда Hazelcast сделала все, что могла. Насколько я ненавижу это говорить, коллекции Java по-прежнему медленны по сравнению с супер-оптимизированными нормальными базами данных на С++. Есть некоторые проекты Java с открытым исходным кодом, которые обращаются к этому. Однако в это время настойчивость запроса неприемлема. Он должен быть мгновенным в одном локальном экземпляре. В конце концов, это технология памяти.

Я переключился на Mongo для базы данных, однако оставил Hazelcast для совместного использования данных во время выполнения, а именно сеансов. Как только они улучшат производительность запросов, я вернусь.

Ответ 5

Если у вас есть альтернативы каре, возможно, сначала посмотрите на них. У нас есть это в режиме производства, и он по-прежнему довольно глючит, просто проверьте открытые проблемы. Тем не менее, интеграция с Spring, Hibernate и т.д. Неплоха, и настройка очень проста:)

Ответ 6

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

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

Кроме того, мы используем распределенную карту для целей кэширования, которые являются общими для всех узлов. Поскольку масштабирование node в Hazelcast настолько простое и использует все его ядро ​​процессора, оно дает дополнительное преимущество перед redis или любой другой базой кэширования.

Ответ 7

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