Журнал о системах электронного документооборота (СЭД)
Управление контентом

In-Memory. База данных в оперативной памяти

  5 комментариев Добавить в закладки

По следам статьи о больших данных, хотелось бы поговорить о конкретных технологиях, применяемых при реализации решений в этой области. Речь пойдет о In-Memory технологиях, а именно In-Memory Data Base (IMDB) и In-Memory Data Grid (IMDG). Если говорить русским языком, то это базы данных использующие оперативную память компьютера в качестве основного хранилища.

Немного предыстории

Почему In-Memory решения стали такими популярными? Дело в том, что стоимость оперативной памяти неуклонно падает, что позволяет хранить весь набор операционных данных непосредственно в памяти, увеличивая тем самым скорость их обработки более чем в 1000 раз. Так же важен тот факт, что современные серверные операционные системы, такие как Windows Server 2012, способны использовать до 4ТБ RAM. А объединив эти сервера в кластеры, можно получить хранилища данных с внушительным объемом и не менее внушительной скоростью доступа.

Чем отличается IMDB и IMDG?

IMDB по своей архитектуре ближе к традиционным реляционным базам данных, в свою очередь IMDG – это распределенное хранилище объектов, схожее с многопоточной хэш-таблицей. Главное преимущество IMDG заключается в возможности работать с объектами из бизнес-модели напрямую. Если в классической РСУБД нам позволено хранить строго типизированные данные, то в IMDG можно хранить любой вид данных, например класс из .NET описывающий покупателя. Данный подход позволяет существенно сократить временные затраты на сериализацию и десериализацию данных на стороне клиента. Ещё одним важным моментом IMDG архитектуры является то, что если используется кластер из нескольких IMDG узлов, то данные следует обрабатывать на том же сервере (узле) где они расположены, что практически исключает их перемещение внутри кластера, тем самым снижается вычислительная нагрузка на сеть и повышается безопасность.

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

Среди крупных игроков на этом рынке можно выделить SAP с реляционной IMDB HANA, Oracle с IMDB TimesTen, а так же IMDB от MemSQL и IMDG от GridGain.

Слабые стороны

У IMDB/IMDG как и у любой другой технологии есть свои слабые стороны, в первую очередь это стоимость. Несмотря на то, что цены на RAM стремительно падают, они по прежнему намного выше, чем у своих твердотельных аналогов. К тому же из-за особенности устройства оперативной памяти, в случае обесточивания все данные моментально исчезают, что требует от компаний вложений в дорогостоящие инфраструктурные решения, обеспечивающие бесперебойное питание и схемы регулярной репликации данных на твердые носители.

Слабые стороны накладывают свои ограничения на потенциальные сферы применения подобных решений, как правило, это второстепенные системы решающие конкретные задачи и берущие данные из основных хранилищ на твердых носителях. Однако зачастую преимущества в виде сверх высокой скорости обработки данных берут верх и In-Memory технологии находят свое применение в таких чувствительных к надежности областях как обработка online транзакций (OLTP).

Области применения

Основными областями применения In-Memory решений являются:

1. Анализ данных рынка, Реакция на события (CEP), Торговля.

2. Авторизация, Online транзакции (OLTP).

3. Real-Time аналитика – интерактивное представление данных, витрины данных.

4. Электронная коммерция (Electronic Data Interchange, e-trade, e-cash, e-marketing), персонализация, Real-Time обслуживание.

В качестве интересного примера внедрения можно привести компанию Pirelli. С помощью In-Memory технологий они анализировали данные с датчиков шин, для достижения наилучшего сцепления с дорогой.

ECM?

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

Ещё материалы автора
Похожие записи
Комментарии (5)
Ришат Мухаметшин 01 августа 2014 г. 00:29  

А что SSD? Он быстрый, от питания не зависит, дешевеет, превосходит по объёмам оперативную память на порядки. Почему его обошли стороной, отмели идею ускорять постоянное хранилище данных?

Артём Обухов 01 августа 2014 г. 12:26  
А что SSD? Он быстрый, от питания не зависит, дешевеет, превосходит по объёмам оперативную память на порядки. Почему его обошли стороной, отмели идею ускорять постоянное хранилище данных?

SSD  дороже чем HDD, при этом уступает по скорости оперативной памяти. Так же SSD недолюбливают из-за ненадежности и скромных размеров. Едва ли можно найти SSD диск ёмкостью больше чем на 1-2ТБ.

Да и в основном In-Memory используют там где важно добиться максимальной скорости обработки данных, а схема работы оперативная память -> процессор, всегда будет быстрее чем любой другой вариант с SDD/HDD, в виду архитектурных особенностей современных вычислительных машин.

 

 

Андрей Подкин 01 августа 2014 г. 23:07  
А что SSD?
Это внешняя технология для СУБД. Точно так же можно найти два HDD, отличающиещееся в скорости на порядок.
Андрей Подкин 01 августа 2014 г. 23:12  
Артем, а кому вообще интересны РСУБД в памяти? Трем с половиной человекам? Это же не показатель. То ли дело NoSQL, например, MongoDB. Вот там совсем другое дело.
Артём Обухов 02 августа 2014 г. 14:56  
Артем, а кому вообще интересны РСУБД в памяти? Трем с половиной человекам? Это же не показатель. То ли дело NoSQL, например, MongoDB. Вот там совсем другое дело.

Дело в том что NoSQL активно применяется в In-Memory в частности в In-Memory Data Grid, о которых я рассказал. В одной из следующих публикаций попробую рассказать и о NoSQL и о MongoDB.

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

 

 

Сейчас обсуждают
Вадим Майшев 16 января 2017 г. 11:27  

Не особо авторы/журналисты утруждают себя использовать правильные термины: тут и "стоимость ЭЦП" - ЭЦП уж 5 лет по закону нет, да и ЭЦП "не продается" (УЦ продают сертификаты).

Никто еще не видел в природе живьем простую электронную подпись, а будто бы только она "устраняет ограничения на использование документов, выдаваемых органами и организациями в электронной форме" :-)

А проблема в том, что граждане вынуждены оформлять дорогостоящую электронно-цифровую подпись, чтобы обжаловать постановления в электронном виде.

Кто решил, что она дорогостоящая? В сравнении с чем? В государстве нет ничего бесплатного! Давно были у нотариуса/врача/... или оплачивали пошлины за "услуги" государства, живущего на деньги налогоплательщиков? И никто (пока) не запрещает использовать неэлектронные варианты взаимодействия!

Александр Валеев 16 января 2017 г. 08:22  
«Большинство услуг и сервисов на портале требуют только простой электронной подписи, однако некоторые услуги, действительно, нужно подписывать квалифицированной электронной подписью. На сегодняшний день это необходимая технология, и она продолжит действовать», — заявил замглавы Минкомсвязи России Алексей Козырев. На сайте Минкомсвязи приведен весь список госуслуг, для которых нужна ЭЦП (XLSX,  187,5 КБ).

Многие опубликовали новость о госуслугах. Но о том, понадобится ли еще КЭП, только здесь. Спасибо

Больше комментариев