RealWorld HazelCast

Question

Есть ли у кого-нибудь реальный опыт в мире с Hazelcast распределенной сетью данных и исполняемым продуктом? Как это сработало для вас? У этого есть удивительно простой API и функциональность, которая кажется почти хорошей, чтобы быть правдой для такого простого в использовании инструмента. Я сделал несколько очень простых приложений и, похоже, работает так, как было объявлено до сих пор. Итак, здесь я ищу реальную проверку реальности. Спасибо.

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

Answer 7

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