Кстати как оказалось, это очень удобно, держать в кэше только горячие данные (настроено вытеснение и протухание), а в cassandra всю историю без реализации какого бы то ни было своего persistence слоя. Держать в RAM все на больших объемах не окупает себя.
Спасибо, за очень продуктивный пост!
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 приятно удивит.
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 приятно удивит.