По-настоящему гибкие вычисления: объединяем in-memory data grid и облака

В отечественном с вами технологическом мире всё перевёрнуто с ног на голову. Не обращая внимания на то что Солнце поднимается на Востоке, технологические инновации сейчас приходят по большей части с Запада. А Восток, будучи «делом узким», выступает как громадный завод, фабрика по воплощению западной технологической мысли. Эта модель очень условна, потому, что в Азии всё-таки имеется технологически продвинутые страны, но однако «Айфоны» все ещё придумывают в Штатах.

Это я к тому, что и для облачной индустрии «Айфоны» куют в Америках. В том смысле, что идеологические и технологические новшества облачных вычислений создаются, в большинстве случаев, где-то на Западе. И сейчас мы поболтаем об очередном достаточно запутанном, но оттого не меньше занимательном новшестве называющиеся In-Memory Data Grid, либо легко IMDG. Об этом концепте до тех пор пока ещё мало слышно в русскоязычном пространстве Сети, но IMDG уже вовсю обсуждается англофонами как будущее облачных разработок.

Сейчас — потому, что раньше In-Memory Data Grid была через чур дорогим удовольствием. Но на данный момент многие компании меняют архитектуру собственных информационных совокупностей чтобы им также стала дешева стремительная транзакционная обработка данных. IMDG стала дешевее за счет того, что подешевели RAM и потому количество данных, каковые сейчас возможно хранить в оперативной памяти, существенно возрос. Вместе с тем увеличилась и скорость обработки данных. IMDG — это инструмент построения ответов, предназначенных для сверхбыстрой и масштабируемой обработки данных за счёт возможностей RAM и тесной интеграции с остальными вычислительными ресурсами.

По сути, In-Memory Data Grid — это распределённое хранилище объектов. Оно снабжает стремительную сверхвысокую доступность и обработку информации при помощи распределённого хранения данных в оперативной памяти.

Это хранилище похоже по интерфейсу на простую многопоточную хеш-таблицу. Объекты сохраняются по ключам. Но в классических совокупностях значения и ключи ограничены типами «массив строка» и «байт», а в IMDG возможно применять любой объект бизнес-модели в качестве ключа либо значения. Это существенно повышает гибкость ответа, открывая возможность хранить в Data Grid полностью тот же объект, с которым трудится бизнес-логика, без сериализации и десериализации, нужных при с другими разработками. Возможность трудиться конкретно с объектами бизнес-модели — одно из главных отличий IMDG от баз данных In-Memory (IMDB). При с IMDB пользователям нужно осуществлять объектно-реляционное отображение (Object-To-Relational Mapping), которое очень сильно снижает производительность.

Главное отличие IMDG от той же NoSQL — целостность данных. NoSQL в большинстве случаев спроектированы по принципу «целостности в конечном счете» — Eventual Consistency. Операции записи в таких совокупностях происходят достаточно скоро, но скорость операций чтения не радует, а вдруг правильнее, то скорость чтения не превосходит скорости записи. В IMDG совокупностях, предусматривающих двухфазовую фиксацию (two-phase-commit), чтения и скорость записи существенно выше, чем в условно-классических БД, выстроенных по принципу конечной целостности данных.

Но для построения In-Memory архитектуры не хватает только совокупности хранения данных. Информация в IMDG обязана обрабатываться параллельно и с высокой скоростью. Архитектура секционирует её в кластере и отправляет исполняемый код на те серверы, где находятся нужные ему эти. Вычислительный код в этом случае есть частью вычислительных кластеров (Compute Grids), исходя из этого интеграция между Compute Grid и In-Memory Data Grid весьма и крайне важна. Синергетический эффект вероятен только в том случае, если IMDG и Compute Grid являются частью одной и той же совокупности. Так возможно достигнуть надёжности архитектуры и максимальной производительности In-Memory.

Возвратимся, но, с временной почвы в тучи, поскольку сугубо технический частокол прошлых абзацев точно утомил достопочтенную публику, не обращая внимания на то что он был полностью нужен для создания верного понимания разработки. Так вот, самоё логичное использование связка IMDG + Compute GRID находит в анализе рисков, торговых системах, биометрике, электронной коммерции, онлайн-играх, видеохостингах и многом втором. Что неспециализированного у этих областей? Верно, им нужны масштабируемость и производительность. Как раз те параметры, которым соответствуют решения на базе облачных вычислений. Исходя из этого нет ничего необычного в том, что разработка In-Memory Data Grid так нужна тучам.

Одно из базисных преимуществ облачных ответов перед классическими ИТ-совокупностями — понижение цены владения. Частично оно вероятно благодаря свойству облачных совокупностей поставлять вычислительную мощность без необходимости подключения дополнительного «железа». Из этого и синергия, появляющаяся на месте слияния IMDG и туч, а имя ей — эластичность. При помощи IMDG возможно легко масштабировать хранилища и память так, дабы производительность возрастала в прямой зависимости от количества серверов. А эластичное трансформации количества серверов (в противном случае говоря, вычислительной мощности) вероятно благодаря облачным совокупностям.

На практике это в большинстве случаев выглядит следующим образом. Предположим, что маркетинговый отдел вебмагазина решил запустить акцию с громадной скидкой на товары и привлечением дополнительного трафика. Предполагается, что в течение нескольких суток на магазин будет громадная нагрузка, а после этого трафик возвратится к обычной отметке. Эта обстановка совершенна для применения архитектуры, которую ваш покорный слуга достаточно детально обрисовал выше. Вы размещаете CMS на облачном кластере, интегрированном с In-Memory Data Grid, и совокупность подключает и отключает серверы в правильном соответствии с нагрузкой.

Многие специалисты прочат In-Memory Data Grid славу «будущего облачных разработок». Раньше облака и IMDG не трудились в связке, потому, что использовались в различных областях IT. А сейчас, в то время, когда показалась яркая идея совместить их в единой архитектуре, они стали друг друга превосходно дополнять.

Полагаю, что у самый продвинутой части аудитории остался ещё один вопрос — как реализовать концепцию IMDG в собственном ответе, в случае если имеется необходимость выстроить подобную архитектуру у себя на предприятии. Хорошая новость содержится в том, что физического доступа к компьютерам вам не потребуется, достаточно облачных серверов. Уже на данный момент возможно реализовывать на практике IMDG-решения в облаке. Для этого нужен один из фреймворков, коих много — GridGrain, Oracle Coherence, GemFire, JBoss. Кое-какие из них (к примеру, GridGrain) легко запускаются на Amazon EC2. Другие наряду с этим являются ещё и ответами Open Source (к примеру JBoss). Следовательно, настало время переходить от слов к делу, тем более что IMDG фактически не развита в отечественных широтах.

Apache Geode: Beginners guide to an In-Memory Data Grid (IMDG)


Похожие статьи: