Нужен был способ дать машине память, чтобы она могла, в терминологии Тьюринга, быстро зарывать данные и так же быстро их выкапывать.
Нил Стивенсон, «Криптономикон»
Фото модуля памяти на магнитных сердечниках в мейнфрейме IBM 1401, использованное в качестве фона на этом изображении, напоминает нам о временах, когда компьютеры были большими, а память — дорогой. Сегодня, как мы узнаем из поста ниже, все поменялось...
IMDG, гриды, In-Memory Data Grids — как только не называют системы, которые оказались темой поста. И хотя название совершенно правдиво, да и гриды, как инструмент, всё более популярны, многие до сих пор путают их то с системами распределённых кэшей, то с NoSQL-базами данных, а то и вовсе полагают, что «если разместить MySQL на RAM-диске, то получится почти IMDG».
Ещё не так давно решение накапливать информацию, а уже после её обрабатывать, казалось логичным, а появившиеся языки запросов к хранилищам информации выглядели отличным решением: каждая стадия процесса работы с информацией была выделенной и достаточно хорошо контролируемой. Но времена меняются, и сегодня всё чаще бизнес заявляет о желании обрабатывать информацию не «вчерашнюю», а текущую, в буквальном смысле иметь «обработку в онлайне», причём по отношению к информации достаточно больших объёмов. И здесь, хотим мы этого или нет, мы вынуждены искать новые инструменты.
Рост числа пользователей онлайн-сервисов, массовое распространение социальных сетей, появление и развитие интернета вещей, развитие услуг в секторах банкинга и телекома — всё это повлияло на IT-индустрию вполне предсказуемым образом: число транзакций резко выросло, хотя требования ко времени выполнения каждой из них только ужесточились, а никаких чудесных решений, работающих «из коробки», долгое время не появлялось. Другими словами, требование времени звучало как «делай как хочешь, но делай быстрее, иначе бизнесу несдобровать!»
Сначала выдержать рост числа запросов к веб-приложениям успешно помогали облака: идея масштабирования вычислительных мощностей в облаке потребовала, конечно, поддержки и учёта в коде приложений, но, по крайней мере, стало понятно, что приложение не упрётся в возможности железа по процессору и памяти. А вот с хранением обрабатываемой информации дело оказалось более сложным, потому что привычные варианты такого хранилища (например, классическая SQL-СУБД), в свою очередь, постепенно оказывались узким местом всей системы. Приложение, все вычислительные ноды которого (сколько бы автомасштабирование ни подняло таких нод) ждут ответа от SQL-сервера, представляет, прямо скажем, душераздирающее зрелище!
Конечно, хороший архитектор и в такой, патовой, ситуации постарается построить работающую систему (отсюда получим кэши на каждом потоке данных, обвязки для их инвалидации, NoSQL-сервера в добавок или на замену их SQL-предшественников, переписывание логики приложения с учётом перечисленного; как ни крути, есть чем заняться всей команде!), но, согласитесь, хотелось бы, конечно, решение «самую чуточку попроще».
Здесь-то на сцену и вышли IMDG-решения, соединившие в себе и кэширование, и NoSQL-подходы, и распределённый подход (чаще даже распределённый через WAN, а не только по локалке) к построению системы. По сути своей, это кластерные хранилища данных, причём модель данных может быть объектной или с хранением по ключам (key-value). Эти хранилища обладают парой откровенно «волшебных» свойств: способностью надёжно хранить данные в совершенной ненадёжной среде — в ОЗУ — и умением обрабатывать данные прямо в памяти, без предварительного сохранения их на диск и дальнейшего вычитывания заново.
Модель хранения данных гридов построена по принципу «ничего общего» (shared nothing) и предполагает распределение данных между множеством физически разнесённых серверов. Все серверы, входящие в IMDG, равнозначны, и все данные хранятся в их оперативной памяти. При этом конструкция грида является отказоустойчивой с возможностью автоматического обнаружения вышедших из строя серверов, и при необходимости (скажем, для изменения объёмов оперативной памяти грида) серверы могут подключаться или отключаться без нарушения работы инфраструктуры грида.
Уже описанных свойств должно хватить, чтобы привлечь к идее IMDG внимание архитекторов крупных систем. По сути, мы получаем распределённое хранение данных, обрабатываемых распределённым же образом — и всё это по цене расширения ОЗУ, удельная стоимость которого, к нашему большому счастью, в последнее время всё больше снижается. Идеологически грид-решения не имеют ограничений на объём ОЗУ кластера, так что проблемы роста объёма данных сверх неких граничных для технологии хранения объёмов с ними в значительной мере менее остры.
Выбор подходящего под конкретный проект грид-решения — задача не из простых. Отчасти потому, что гриды сами по себе довольно сложны и интересны в устройстве, и их, как пресловутую кошку, «нужно уметь готовить» (это непосредственно означает, что как запуск кластера, так и интеграция его в свой проект потребует времени), отчасти потому, что в своём эволюционном развитии IMDG-продукты стараются перенимать друг у друга полезные функции, и нужно внимательно выбирать, где реализация функциональности интереснее и больше подходит нуждам проекта.
Тему In-Memory Data Grids мы обсудили с несколькими крайне интересными собеседниками. Интересными, помимо прочего, тем, что за плечами каждого из них стоят опыт и понимание того, как хорошо работающая система должна быть спроектирована и реализована. Итак, представляю:
Андрей Ершов (Dino Systems)
— Интересный технологический вопрос: выбор грид-решения на стадии проектирования системы. Что бы Вы посоветовали: сразу закладываться на широкий спектр фич, предлагаемых каким-то решением, либо идти по пути постепенного усложнения — запуститься на чём-то, что попроще, и, по мере роста проекта, исследовать возможность использования более функциональных решений?
Принципы работы всех IMDG похожи, но API может отличаться. Есть даже JSR-107, который унифицирует работу с IMDG, вне зависимости от вендора. В этом случае вы можете абсолютно безболезненно перейти от одного решения к другому. Но здесь есть несколько «но».
Во-первых, этот JSR описывает только базовые вещи, вроде «положить в кэш»/«прочитать из кэша», entry processors и continuous query. Зачастую такой функциональности может оказаться недостаточно, и тогда приходится использовать вендор-специфичные функции.
Во-вторых, обязательно нужно проводить функциональные и нагрузочные тесты с используемым решением, потому что разные IMDG имеют различные параметры, у некоторых дефолтные значения выставлены так, чтобы обеспечить максимальную производительность системы, но многие failure-кейсы могут обрабатываться некорректно.
Опять же, переход на другое решение может подразумевать необходимость разбираться в настройках системы другого вендора.
Моя рекомендация — сразу выбрать вендора, но сначала использовать community версию, а потом заплатить за enterprise версию с техподдержкой и дополнительными фичами.
Скажу честно, выбор вендора — дело непростое, особенно, если вы первый раз имеете дело с IMDG и не до конца знаете сценарии использования IMDG в вашей системе. Хорошим подходом в данном случае будет создание PoC вашей системы с каждым из IMDG-решений.
— Так уж повелось, что чуть ли не каждое IMDG-решение позиционирует себя как самое лучшее для пользователей (если не для всех, то для многих). Можно ли в такой теме однозначно говорить о лучшем/худшем?
У меня есть большой опыт работы только с GridGain (Ignite), также я имею представление о фичах Coherence и Hazelcast. Могу сказать, что все три решения предоставляют большую функциональность и имеют много общего. Если нужен key-value store с возможностью реагировать на изменения в grid, то можно смело брать любое решение. Но если вы планируете делать сложные запросы к данным, вам нужна поддержка транзакционности (с настраиваемым уровнем изоляции), сохранение данных на диск, репликация данных между дата-центрами, корректная работа в случае сетевой сегментации, сложное распределение данных по нодам, то имеет смысл изучить документацию каждого решения и выбрать подходящее для своей задачи.
— Если бы Вам в руки попала волшебная палочка, способная создать одну, но очень хорошую систему хранения данных — какую систему Вы бы заказали ей сделать?
Конечно, я как программист хочу, чтобы система была всегда доступна, вне зависимости от падения серверов и сетевых проблем, при этом чтобы она работала наиболее ожидаемым способом.
Вообще, когда речь заходит об ожиданиях о работе БД или IMDG, то говорят про consistency и freshness. Если система имеет дело с транзакциями, то ещё добавляется уровень изоляции транзакций (рекомендую к изучению доклад про CRDT на codefreeze; вот видео этого доклада — прим. автора). Чем выше уровень consistency и isolation, тем более предсказуемо ведёт себя система и тем проще её программировать. Самая лучшая гарантия — strict serializability (strong-1SR): это сочетание уровня изоляции транзакций serializability и уровня consistency — linearizability. Система, которая предоставляет strict serializability, и есть мечта.
Возможна ли такая система? Нас, конечно, будут интересовать распределённые системы. Тут мы вспомним CAP-теорему и скажем, что в случае CP (CA) такая система возможна и даже существует — Google Spanner. Однако, только Google может позволить себе такую систему — из-за очень высоких требований к инфраструктуре. И то приходится мириться с задержками на репликацию данных между континентами.
Хотелось бы иметь систему, которая гарантирует strict consistency в случае AP, то есть когда возможны сетевые проблемы, а также в случае, если нужно быстрое время отклика. Таких систем нет и быть не может, что показано, например, в PhD Peter Bailis.
Возвращаясь к теме выбора IMDG: задумайтесь, какие гарантии даёт то или иное решение, не нарушают ли рекламные обещания производителя теоретические ограничения распределённых систем? Можно ли положиться на IMDG, если у вас сгорел порт на свитче, или происходит длительная сборка мусора в JVM, или трактор разорвал кабель между вашими DC?
Владимир Озеров (GridGain)
— У GridGain есть бесплатная и платные версии. Скажите, с технической точки зрения, разница между ними только в наличии техподдержки и нескольких функциях (таких, как WAN-репликация), а в остальном опенсорсный Apache Ignite и «платный» GridGain одинаковы? Или же мы имеем здесь дело с моделью «Fedora vs. RHEL», когда на бесплатном варианте проходят «боевую обкатку» фичи, которые в дальнейшем в более стабильном виде войдут в платную поставку?
Существует три версии продукта. GridGain Professional — это кодовая база Apache Ignite плюс поддержка и оперативное внесение правок и улучшений (хотфиксы). Это критически важный для бизнеса момент, так как в open source вам никто ничего не должен, и не с кого спросить.
Кроме Professional, мы предлагаем GridGain Enterprise и GridGain Ultimate — это продукты на основе GridGain Professional с расширенной функциональностью, таким как WAN-репликация, security, rolling upgrades, snapshots и т.д.
Хотфиксы сразу же попадают в master Apache Ignite, но релизятся раньше в рамках GridGain Professional. Поэтому платные пользователи получают их сразу, а бесплатные — либо ждут очередной релиз Apache Ignite, либо собирают его сами из мастера, на свой страх и риск.
Обкатку на бесплатных пользователях мы не практикуем :-)
— Судя по всему, Apache Ignite (или, если угодно, GridGain) позиционирует себя как более широкую по функциональности версию других систем IMDG. Это и правда причина для гордости или просто маркетинговый подход, чтобы выглядеть выгоднее на фоне других?
Упрощённо, наша стратегия состоит из трёх пунктов. Первое — работаем на любой платформе и с любыми фреймворками. В нашем арсенале богатая поддержка языков Java, C# и C++, десятки интеграций — от Spring/Hibernate до Hadoop/Spark, и мы продолжаем усиливать это направление. Второе — SQL как ключевой способ доступа к данным. Это другая весовая категория по сравнению с любым key-value API. Мы активно развиваем собственный SQL-движок и JDBC/ODBC драйверы к нему. Третье — это persistence. Мы научились работать как с памятью, так и с диском. Теперь Apache Ignite — это распределённая, горизонтально масштабируемая СУБД, которая может хранить больше данных, чем позволяет ваша оперативная память.
Отсюда видно, что мы действительно ушли далеко вперед от классического термина «IMDG». Тем не менее, Apache Ignite по-прежнему остается быстрым и удобным гридом, одно другому не мешает. Ну а кто «шире» или «уже» — решать пользователям :-)
— Проекты, которые требуют использования IMDG, практически всегда нестандартны, и решения, как архитектурные, так и технические, будут вырабатываться конкретно для проекта. На Ваш взгляд, должна ли компания, использующая в своих проектах Ignite/GridGain, обладать компетенциями на уровне технологического понимания устройства выбранного грид-решения? Необходим в штате компании специально выделенный IMDG DBA-специалист?
Очень правильный вопрос. Мы действительно сталкиваемся с дефицитом навыков применения и администрирования нашей системы, так как она слишком сильно отличается от классических СУБД, к которым все привыкли. Сейчас это во многом ложится на плечи наших solution architects. Но мы ведём многоплановую работу в данном направлении. Наш фокус — документация, тренинги и выстраивание партнерских отношений с компаниями-интеграторами. Всё это способствует распространению знаний и опыта. Думаю, в перспективе нескольких лет такие навыки станут достаточно массовыми.
Виктор Гамов (Confluent; ранее Hazelcast)
— Так уж повелось, что чуть ли не каждое IMDG-решение позиционирует себя как самое лучшее для пользователей (если не для всех, то для многих). Можно ли в такой теме однозначно говорить о лучшем/худшем?
Я бы говорил о use case, а не о понятии «лучший/худший». Нужно отталкиваться от моментов, связанных с внутренней архитектурой проекта. IMDG-решения развиваются каждое в своём направлении, и сравнивать их без ответа на вопрос «лучший для своего» — неверно.
Гриды, в отличие от решений для распределённых кэшей, умеет проводить вычисления непосредственно на своих нодах — это нишевая функциональность, но очень удобный для определённого рода задач. Однако порой IMDG используют только как кэш, и здесь, конечно, сложно проводить сравнения разных решений, поскольку задача не является целевой для гридов. Позже, кстати, разработчики чаще всего, разобравшись с гридом, начинают использовать и другие функции выбранной ими ранее IMDG.
В любом случае, о гридах нужно говорить с позиции разработчика, и исходить нужно, во-первых, из задачи, которую этот разработчик решает, а во-вторых, из его предыдущего опыта и используемого в проекте стека.
— На рынке много «чисто IMDG»-решений и практически лишь одно (Ignite/GridGain), которое себя позиционирует как нечто большее. Правильно ли говорить в такой ситуации, что для всех решений найдётся своя ниша, или можно сказать, что кто-то технологически ушёл вперед, а кто-то ещё не освоил дополнительные функции?
Я напомню фразу времен бурного роста Microsoft: «Давайте сконцентрируемся на всем!»
Думаю, наличие большого числа функций в изначально довольно нишевом продукте — это, во многом, вопрос маркетинга. Каждая IMDG чем-то интересна, и каждая находится в некоторой точке своего развития, так что темпы добавления функций везде разные.
IMDG сильны в трёх моментах: хранение данных, вычисления над этими данными и распределённые коммуникации. Остальные фичи добавляются тогда, когда в нём возникает потребность. Думаю, GridGain реализуют некоторые интересные функции, в том числе и с учётом пожеланий заказчиков (например, в рамках своего сотрудничества со СберТехом), в то время как другие IMDG-решения не видят непосредственной необходимости распылять силы на расширение функциональности своего продукта.
С другой стороны, бенефиты от такой узкой системы, как IMDG, получают, в первую очередь, разработчики, а не конечные пользователи. И уже разработчики решают, как они воспользуются возможностями, предлагаемыми IMDG, и как им изменить логику работы приложения, чтобы использовать эти возможности. (Ссылка на доклад Виктора на английском языке — прим. автора).
— Долгое время концепция IMDG казалась оторванной от реальности: хранить все данные целиком в памяти было дорого и как-то нерационально, да и приложения работали через интерфейсы, оптимизированные под выборку и обработку аккуратно отобранной части данных. Сегодня IMDG всё чаще используют как некую «серебряную пулю». Можно ли ожидать, что эта технология будет на рынке достаточно долго, что это не очередное модное направление, которое однажды сменится другим?
Думаю, да. На мой взгляд, стоимость памяти будет падать, стоимость серверов также снижается, скорость связи по сети растёт — если ваша задача требует надёжного хранения больших объёмов данных с быстрым к ним доступом, использование IMDG будет ещё долгое время отличным выбором. Такого рода задачи будут всегда, поэтому гриды как инструмент будут востребованы.
Здесь я могу заметить, что IMDG прекрасно встраивается в схему потоковой обработки данных. Если у нас есть поток информации, и мы хотим делать по нему статистику в реальном времени, то с IMDG данные будут обрабатываться сразу (не сохраняясь, скажем, на дисках — прямо в памяти, но при этом с гарантией сохранности информации, даже при выходе из строя ноды в кластере) и сразу же могут использоваться далее — скажем, выводиться на некий дашборд. При этом, заметьте, нет необходимости сначала загружать данные в некую базу данных (на диск), потом обрабатывать их, перекладывая на диске же, и затем считывать с диска «наружу» — мы всё время держим их в памяти, существенно экономя на перемещении ненужных нам в долговременном хранении данных «туда и обратно».
Будет ли IMDG «серебряной пулей»? Вряд ли: это, как я уже говорил, нишевое решение, но востребованы гриды точно будут.
Обсуждать эту темe можно долго: спорить, соглашаться, холиварить и даже иногда бить в щи… И если первые три варианта можно реализовать в комментах, то за четвертым (хотя и первые три тоже можно будет практиковать) надо куда-то да ехать. Куда? Можно на Java-конференцию Joker 2017 (3-4 ноября, СПб) или на DevOps-конференцию DevOops 2017 (20 октября, СПб), — тут будет, с кем поговорить о хранилищах.
