Вряд ли можно поспорить сегодня с аргументом, что скорость и эффективность обработки информации стали ключевыми факторами успеха любого цифрового проекта. При этом традиционные подходы к хранению и обработке данных уже не могут удовлетворить растущие потребности бизнеса и пользователей. Именно в этот момент на сцену выходит Apache Ignite — высокопроизводительная, распределенная платформа для вычислений в памяти. Рассказывает Александр Столяров, ведущий программист компании Comindware.

Александр Столяров, ведущий программист Comindware.
Александр Столяров, ведущий программист Comindware.

Вместо введения

Технология Apache Ignite не просто ускоряет обработку данных, она помогает переосмыслить то, как мы работаем с информацией. От распределенного кэширования до выполнения SQL-запросов непосредственно над кэшированными данными, от вычислений в памяти до поддержки полноценных ACID-транзакций в распределенной среде — Apache Ignite открывает новые горизонты возможностей.

Продукт, над которым я работаю, — это Comindware Business Application Platform — наша основная система. Мы успешно интегрировали Apache Ignite, создавая условия для масштабирования. Это позволило нам решить вопросы  импортозамещения и обновить базу данных, которую мы использовали до этого. Apache Ignite обеспечивает работу на Windows и Linux, что делает ее универсальным решением для баз данных.

И мы рассмотрим основные компоненты Apache Ignite, преимущества и недостатки, а также опыт применения этой технологии на нашем продукте.

Переходим со своей СУБД на Apache Ignite

У нас сегодня для работы системы применяется собственная система обработки данных. И надо сказать, что мы ей довольны, как и множество клиентов, которые используют ее преимущества каждый день. Но в плане дальнейшего технологического развития платформы она постепенно теряет свою актуальность. На смену ей приходит Apache Ignite привнося еще большую возможность для масштабирования.

Тут стоит сказать, что собственная система, которую мы использовали, не имела возможности запустить одно и то же бизнес-приложение в разных масштабах. Это не минус системы, это просто ограничение, которое было изначально. Просто раньше спроса на такие задачи фактически не было, поэтому мы использовали СУБД, которую применяли уже много лет с нужными доработками и улучшениями.

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

Мы выбрали Apache Ignite, чтобы компании могли работать без проблем с производительностью систем. Существующая система, хоть и остаётся рабочей и удовлетворяет всем требованиям, но в перспективе будет заменена на Apache Ignite. Ведь у неё есть предел масштабируемости. Мы можем увеличивать её производительность только за счёт увеличения производительности системы, на которой она функционирует. Мы улучшили железо, увеличили производительность, но улучшать железо можно только до определённого предела. Дальше идти достаточно сложно и не всегда экономически целесообразно. Кроме того не можем запустить нашу систему распределённо, на нескольких машинах, в то время как Apache Ignite поддерживает эту возможность. С Apache Ignite мы можем производить вычисления одновременно на нескольких компьютерах, что не позволяла нам предыдущая реализация хранения данных. Ведь она была создана ещё до того, как распределённые вычисления стали популярны. Распределённые вычисления стали трендом в последние полтора десятка лет. До этого особой потребности у бизнеса в таких системах не было. Задачи решались иным образом, и все ориентировались на классические СУБД с фундаментальной производительностью, которой в целом хватало. 

Почему именно Apache Ignite, а не другие СУБД 

Для тех, кто погружен в мир технологий и стремится к пониманию новых трендов, рассмотрим выбор Apache Ignite в контексте нашей работы с данными. Наша система построена на основе графов, и хранение таких графов в классической СУБД представляет собой сложную задачу с большими накладными расходами производительности.

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

Выбор был сужен несколькими критическими факторами: транзакционность, персистентность, хранение памяти кэшей, а также open source. 

Кэш — это стандартное сопоставление ключа с данными, где ключ является уникальным значением, а по нему хранится определенный набор или атомарные данные. Кэш удобен тем, что всегда за фиксированное и одинаковое количество времени возвращает значение. В отличие от SQL-запроса, который может выполняться долго, кэш всегда быстро возвращает значение по ключу. Эта особенность делает его важным инструментом в современных системах обработки данных.

Apache Ignite уже был известен, его использовали крупные компании, он был хорошо документирован и тестирован. По факту, конкурентов у него не было. Тем более, что он умел работать на дотнет-платформе.

Для каких задач стоит выбирать Apache Ignite? 

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

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

Apache Ignite предоставляет разработчикам гибкие возможности для работы с данными. Они могут хранить данные на диске, в памяти или распределять их по разным узлам. Эта система позволяет задавать алгоритм распределения данных, создавать индексы и поддерживает стандартные SQL-запросы. Таким образом, можно выполнять различные запросы к данным. Выбор между Apache Ignite и другими системами может быть сложным, так как вариантов много, и решение должно основываться на конкретной задаче, стоящей перед разработчиками или компанией.

Если говорить о пяти ключевых преимуществах Apache Ignite, то это:

  1. Многоплатформенность: возможность работы на различных платформах (Linux и Windows).

  2. Транзакционность: поддержка различных транзакционных моделей.

  3. Широкий набор инструментов для конфигурирования: гибкость в настройке под конкретные нужды.

  4. Мониторинг и богатая документация: удобство в использовании и наличие всей необходимой информации.

  5. Open Source: возможность просмотра исходного кода, что часто бывает важным для понимания производительности и выбора методов.

Apache Ignite в реальных проектах

Применяя Apache Ignite мы, прежде всего, используем кэш-систему, которая хорошо зарекомендовала себя во множестве проектов, включая разработки крупных компаний, таких как Сбербанк. 

Apache Ignite предлагает нам ряд особенностей, которые отличают его от других решений для распределенного кэша и вычислений. Важно отметить, что многие кэш-системы не поддерживают транзакционность из-за сложностей в работе с распределенными кэшами. Однако Apache Ignite позволяет нам управлять кэшами и контролировать их хранение: хранить данные в памяти или на диске, а также выбирать метод сериализации данных - компактное упаковывание или шифрование.

Помимо этого, Apache Ignite поддерживает бэкапы, что позволяет снимать снапшоты данных с кластера, сохраняя их на диске. Это дает возможность восстановиться после катастрофических событий или несчастных случаев, обеспечивая дополнительный уровень защиты и надежности.

Если вы планируете использовать Apache Ignite, то рекомендую обратить внимание на несколько ключевых моментов, чтобы обеспечить производительность и надежность системы.

Во-первых, важно точно определить, какие данные будут использоваться в вашей системе. Если это фиксированная структура данных, то кэш-система может не быть оптимальным выбором. В этом случае обычная СУБД может справиться с задачей быстрее. При проектировании системы заранее определите, как данные будут храниться и сериализоваться. Сериализация данных в бинарный вид может улучшить производительность.

Если предвидится использование запросов, подобных тем, что используются в базах данных (например, SELECT с условиями), это может стать проблемой для производительности. Apache Ignite в первую очередь является кэш-системой и работает эффективно при получении значений по ключу. Рассматривайте Apache Ignite с этой стороны, а не как базу данных.

Определитесь с тем, какие данные будут транзакционными и где они будут храниться (в памяти или на диске). Для данных, хранящихся в памяти, электрические сбои могут быть менее критичными, так как при перезапуске системы данные восстановятся в памяти. Однако для данных на диске необходимы механизмы восстановления, например, через бэкапы. Репликация данных на несколько NOD обеспечит надежность и отказоустойчивость системы, так что при выходе из строя одной ноды данные останутся доступными.

Важно продумать архитектурные аспекты заранее, чтобы система эффективно работала с выбранными типами данных и обеспечивала надежность в случае возникновения сбоев.

Будущее Apache Ignite, как технологии

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

В мире мультисервисных систем Apache Ignite мог бы стать связующим звеном между различными сервисами. Сейчас обычно база данных находится на одной машине, а ядро, обрабатывающее данные, на другой. Это создает нагрузку на сеть, так как данные нужно передавать по сети для выполнения вычислений. Если бы можно было выполнить эти операции близко к данным, то передача по сети была бы не нужна.

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

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

Современная индустрия распределенных вычислений часто сталкивается с проблемой разделения данных и вычислений. Данные хранятся на отдельных серверах, а обсчет производится в другом месте. Apache Ignite же может обсчитать и отправить готовые данные, обеспечивая эффективный обмен данными.

Эта система позволяет поднимать инфраструктуру в разных регионах и на разных континентах, где каждый региональный сервис может выполнить необходимые вычисления. Затем они синхронизируются и агрегируют результат для конечного клиента. Система хранения данных в Apache Ignite такова, что можно точно определить, на какой ноде что должно находиться. Это удобно, так как данные, которые нужно обработать, должны находиться в одном месте, на одной ноде.

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

Такое применение технологии может служить основой для дальнейшего исследования и использования в различных областях. 


А у вас был опыт использования Apache Ignite? Поделитесь с нами своим опытом использования различных СУБД в комментариях.

Комментарии (2)


  1. QuickJoey
    05.09.2023 08:57

    Ни одного примера, ни одной технической подробности и сравнения было-стало. В начале статьи "замена СУБД", а потом сразу "только если это кэш система и структура не статична".

    Наша система построена на основе графов, и хранение таких графов в классической СУБД представляет собой сложную задачу...

    Как именно хранили? Метрики? Что стало?


    1. UserName1212
      05.09.2023 08:57

      Если тема интересна, то лучше живьем пообщаться. В среду как раз вебинар будет технический - https://www.meetup.com/ru-RU/moscow-apache-ignite-meetup/events/295775808/