Comments 11
Есть.

Из того, что сразу приходит на ум — один из наших клиентов использует для хранения и обработки данных с IoT-устойств десятки наших узлов в кластере, за которым стоит более сотни узлов Cassandra, другой наш клиент — крупный западный банк — также использует Ignite в связке с Cassandra. Cassandra может очень хорошо и быстро сохранять данные, при этом она замечательно масштабируется и обеспечивает отказоустойчивость. Ignite может очень эффективно обрабатывать данные на потоке в реальном времени, обогащая их и отвечая на поступающие запросы, в том числе обеспечивая ad-hoc аналитику.
Пример компании, которая использует Ignite и Cassandra.

https://www.optioncarriere.be/jobviewx/0310e7c44f1afde7a9e89aa5c7c7e259.html — You will work with the team that builds the core of the One Digital Backbone solution providing new digital channels for ING worldwide. We mainly use the following technologies and frameworks: Java 8, Apache Ignite/GridGain, Spring, Kafka, Cassandra, Jenkins, Maven and Nolio.
Спасибо, за очень продуктивный пост!
1) Но какова ситуация при большой нагрузке на касандру? Уже довольно долго использовали в production данную связку, но, к сожалению, вынуждены отказаться из-за многих граблей, про которые посты в свое время не были написаны( В частности, что если данных приходит очень много (сотни тысяч операций в секунду), то при использовании IgniteDataStreamer нагрузка становится настолько большой, что касандра просто отваливается по timeout (found long running cache future), скорее всего из за резко возрастающего read latency, а кластер ignite умирает (хотя и не признается в этом) — при перезапуске приложения ловится deadlock. Конечно все фишки с сохранением пачками и асинхронной обработкой учтены. Логи, касательно причин и реальных проблем, наверх не приходят (хоть и специально выведены), а расширение кластера игнайта и касандры не помогает.
2) Касательно типов сохраняемых данных в таблицу. Если использовать самописный класс, его действительно необходимо подложить в конфигурацию каждой ноды и перезапустить их все (на большом кластере это изрядно напрягало, ведь на одном кластере крутится очень много сервисов). Но тут возникают сразу две проблемы. 1. При его изменении — со всей накопленной информацией можно проститься (не десериализуется на уровне получения данных из касандры в кэш), либо переходить на использование BinaryObject и сохранять в кассандру не POJO а BLOB (тип класса предварительно указав BinaryObjectImpl), то есть преобразовывать свой класс ручками к данному формату, что позволит как изменять классы, так и отказаться от постоянного подкладывания новых jar на ноды, но удобства просмотря данных уже не будет (кстати тут появляется новая проблема — при переезде на новую версию игнайта BinaryObjectImpl мог измениться и история снова не десериализуется — найдено при переезде с версии 1.8 на версию 2.0 — данная проблема вынуждает держать несколько кластеров разных версий, пока полностью не переведем все сервисы на новый кластер, предварительно реализовав множество утилиток). 2. Если же остаться на самописном классе и сохранять объект как POJO (или BLOB), то тут проблема бывает еще хуже — если 10 сервисов одновременно работают с игнайтом и сохраняют данные в касандру, а на кластере подложено несколько jar со всеми самописными классами, то тут снова все не идеально — клиенты являются локальными нодами игнайта, то есть тоже должны знать обо всех этих классах, получается надо постоянно держать актуальные версии ВСЕХ классов в каждом приложении — это мука и БОЛЬ (решения 2 — свой кластер на каждый сервис или же jar со ВСЕМИ классами работающих приложений, при изменении которого надо перезапускать все сервисы с полученными обновлениями). 3. Peer class loading в данном случае не работает (а очень помог бы).
3) Есть еще несколько небольших замечаний опять же с IgniteDataStreamer, но они не так велики.

Оговорюсь, что данные ситуации были найдены в реальном production на больших объёмах. Использовалась для этого бесплатная версия (возможно именно в этом корень всех зол). Есть вероятность, что в каких-то местах все же конфигурация не была докручена, но тут все упирается в достаточно скудную документацию данной интеграции, которая не предупреждает о возможных проблемах (найти часть из которых можно, ознакомившись внимательно со всей документацией).

Но при всем этом, скорости показываемые ignite действительно впечатляют (особенно при использовании IgniteDataStreamer). И очень надеюсь, что версия 2.1 приятно удивит.
Очень обстоятельный и детальный комментарий! Спасибо за позитивный отзыв о нас.

Учитывая, что система у вас, судя по всему, достаточно сложная и нагруженная, нужно подробнее изучить ситуацию, конфигурацию нашу и Cassandra, после чего думать, как решить ваши проблемы. Напишу вам в ЛС с предложением пообщаться подробнее на эту тему.

И очень надеюсь, что версия 2.1 приятно удивит.

Должен. Там мы добавим наше собственное распределенное дисковое хранилище с возможностью вытеснять часть данных из памяти на диск (а backup-ы данных и вовсе держать только на диске пока жива primary-копия), делать сквозные SQL-запросы как по данным в памяти, так и по данным на диске, научимся lazy run-у с диска и прогревом памяти уже во время работы узлов кластера, начнем добавлять алгоритмы машинного обучения поверх алгебры, которая появилась в 2.0 и т.д.

Дисковое хранилище можно уже пощупать в вышедшем пару дней назад GridGain 8.1. Код передан в Apache и как только сообщество его переварит и интегрирует в себя, хранилище в полном виде появится и в Apache Ignite, это будет как раз в 2.1, в проприетарной версии будет дополнительно функционал по снятию snapshot-ов.
Да, с удовольствием. Спасибо! И да, почитал основательно и как раз надеюсь на новое хранилище.
А есть ли смысл в такой связке? Если данных достаточно мало, чтобы они могли уместиться в RAM, может, проще и быстрее использовать SQL-хранилище с репликацией?
Не наезда ради, а самообразования для.
Кстати как оказалось, это очень удобно, держать в кэше только горячие данные (настроено вытеснение и протухание), а в cassandra всю историю без реализации какого бы то ни было своего persistence слоя. Держать в RAM все на больших объемах не окупает себя.
Данных может быть очень по-разному. Здесь важно понимать, что Apache Ignite, как и Apache Cassandra, — распределенная партиционированная система, поэтому «уместиться в RAM» не значит «уместиться в RAM на одной машине».

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

Соответственно, если есть инсталляция Cassandra, например, на сотни гигабайт, и необходимо добавить скорость вплоть до анализа в реальном времени и возможность работы с произвольными запросами, можно поднять в связке с ней несколько машин с Apache Ignite, с суммарным объемом RAM в несколько сотен гигабайт (сколько — зависит от данных и коэффициента избыточности, которая нужна для HA), после чего обслуживать запросы с кластера Ignite.

Учитывая, что RAM активно дешевеет, а также появляются такие технологии как NVRAM, это может быть во многих сценариях интересным вариантом, который позволяит делать то, что раньше было невозможно.
Артем, подскажите, каким образом обеспечивается, например, atomicity, при работе с Cassandra, допустим, проводка между двумя счетами?

Я правильно понимаю, что в самой Cassandre на какой-то момент времени будет совершена только одна проводка, но результат не будет показываться движком Ignite?
Only those users with full accounts are able to leave comments. Log in, please.