2012/02/08 10:22:03

In-Memory Computing
Вычисление в оперативной памяти

In-Memory Computing - высокопроизводительные распределенные системы, предназначенные для хранения и обработки данных в оперативной памяти в реальном времени. Обеспечивают производительность на порядки быстрее, чем системы, основанные на дисках. Технологии вычислений в оперативной памяти (in-memory computing) ускоряют обработку больших объемов данных, поэтому по мере роста такого явления как Big Data приобретают все большую популярность среди предприятий.

Каталог BI-решений и проектов доступен на TAdviser.ru

FAQ по in-memory СУБД

Системы управления базами данных in-memory (in-memory СУБД, англ. - in-memory database systems, IMDS) это растущий сегмент мирового рынка СУБД. Создание in-memory СУБД стало ответом на появление новых задач, которые стоят перед приложениями, новых системных требований и операционного окружения.

Что такое in-memory СУБД?

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

Если целью является отказ от процессов ввода/вывода, почему не добиться ее с помощью кэширования?

Кэширование это процесс, в рамках которого традиционные СУБД хранят часто используемые записи в памяти для быстрого доступа к ним. Однако, кэширование ускоряет только процесс поиска необходимой информации, а не ее обработки. Следовательно, выигрыш в производительности существенно меньший. Кроме того, управление кэш-памятью само по себе является ресурсоемким процессом, который задействует значительные объемы памяти и вычислительные мощности процессора.

Можно ли получить эффект, аналогичный in-memory СУБД, создав диск в памяти (RAM диск) и развернув традиционную СУБД на нем?

В качестве временного решения размещение всей базы данных на диске RAM может ускорить запись и чтение базы. Тем не менее, у такого подхода есть ряд недостатков. В частности, база данных все еще будет привязана к дисковому накопителю, и процессы в базе данных, такие как кэширование и ввод/вывод данных, будут осуществляться, даже если они избыточны. Кроме того, к базе данных, размещенной на диске, адресуется множество запросов, они требуют времени и ресурсов процессора, и этого никак не избежать в случае с традиционной СУБД, даже если она размещена на RAM. Напротив, in-memory СУБД используют единый дата-трансферт, что упрощает обработку данных. Удаление лишних копий данных снижает нагрузку на память, а также повышает надежность процесса и минимизирует требования к ЦПУ.

Есть ли данные, характеризующие количественную разницу производительности между тремя подходами, описанными выше?

Согласно опубликованным тестам McObject, в ходе которых сравнивалась производительность одного и того же приложения, перенесение традиционной СУБД в RAM позволило добиться ускорения чтения в 4 раза и обновления базы в 3 раза по сравнению с традиционной СУБД на жестком диске. In-memory СУБД показала еще более существенные результаты в сравнение с СУБД на RAM диске: чтение базы данных было в 4 раза быстрее, а запись в базу данных оказалась быстрее в 420 (!) раз.

Производительность in-memory СУБД eXtremeDB по сравнению с СУБД db.linux на RAM диске

McObject, 2009

Что еще отличает in-memory СУБД от традиционной?

In-memory СУБД не несет на себе никакой нагрузки от операций ввода/вывода данных. Изначально архитектура таких баз данных более рациональна, а процессы загрузки памяти и циклы процессора оптимизированы.

Для каких приложений актуально использование in-memory СУБД?

In-memory СУБД обычно используются для приложений, которые требуют сверхбыстрого доступа к данным, хранилищам и манипуляций с ними, а также в системах, которые не имеют диска, но, тем не менее, должны управлять значительным количеством данных.

Насколько масштабируемы in-memory СУБД? Если приложение управляет терабайтом данных – много ли это для in-memory СУБД?

Согласно отчету McObject, in-memory СУБД отлично масштабируются за размеры, превышающие терабайт. Так, в ходе проведенных тестов 64-битная in-memory СУБД установленная на 160-ядерном сервере SGI Altix 4700 под управлением SUSE Linux Enterprise Server версии 9 от Novell достигла 1,17 терабайт и 15,54 млдр строк без видимых ограничений для дальнейшего масштабирования. Причем производительность в данном тесте практически не менялась по мере того, как СУБД достигла сотен гигабайт, а затем и терабайта, что свидетельствует о практически линейной масштабируемости.

Разве это не правда, что in-memory СУБД не подходит для использования в сетях из нескольких и более компьютеров?

In-memory СУБД может быть как «встроенной СУБД», так и «клиент-серверной». Клиент-серверные СУБД по сути своей являются многопользовательскими, так что in-memory СУБД также могут быть разделены на несколько потоков/процессов/пользователей.

In-memory вычисления: факты

Новый отчет компании Aberdeen Research обращает внимание не только на несколько интересных фактов о Больших данных, трудностях в обработке и анализе растущего объема данных, но и на то, каким образом вычисления в памяти могут играть ключевую роль в ускорении сбора, совместного использования информации на предприятии и управления ею. По крайней мере, на тех предприятиях, которые могут себе это позволить.

Каждый год объем бизнес-данных растет на 36%.
Главная проблема при обработке больших данных заключается в том, как получить результат быстрее (данные из декабрьского отчета 2011 г.).
Из 196 клиентов Aberdeen, обсуждавших Большие данные, 33 используют вычисления в памяти. Причина, по которой большинство отказывается от этой технологии, заключается, скорее всего, в ее дороговизне.
Получение информации по запросу занимает 42 с вместо 75 мин, затрачиваемых при использовании обычных технологий.
При вычислениях в памяти обрабатывается 1200 Тб/ч, по сравнению с 3,2 Тб при использовании обычных технологий. Налицо повышение эффективности в 375 раз.
Вычисления в памяти, проще говоря, делают быстрыми обработку и анализ информации, и это хорошо для пользователей и ИТ-организаций, имеющих дело с увеличивающимися объемами информации, используемой при принятии бизнес-решений.

Источники данных в зависимости от размера компании

TechTarget, декабрь 2011

По данным компании TechTarget, in-memory СУБД наиболее часто используют компании среднего размера (23%) по сравнению с небольшими (18%) и крупными компаниями (15%).

Проблемы применения in-memory вычислений

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

Хотя производители не оглашают цены на приложения для вычислений в памяти и в отчете также не приводятся цены, вполне достаточно взглянуть на статистику из отчета: предприятие, использующее вычисления в памяти, потратило около 850 000 долл. за последние 12 мес.

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

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

Продукты

Создание in-memory СУБД началось в 1993 году в Bell Labs. Система была прототипирована как Dali Main-Memory Storage Manager. Эти исследования положили начало созданию первой коммерческой in-memory СУБД - Datablitz.

В последующие годы in-memory СУБД привлекли внимание крупнейших игроков рынка баз данных. TimesTen, компания-стартап, основанная Мари-Энн Неймат (Marie-Anne Neimat) в 1996 году как ответвление от Hewlett-Packard, была приобретена Oracle в 2005 году. Сегодня Oracle продает этот продукт в том числе как in-memory СУБД. В 2008 году IBM купила SolidDB in 2008, также ведет работу в области in-memory СУБД и Microsoft.

VoltDB, основанная одним из пионеров рынка СУБД Майклом Стоунбрейкером (Michael Stonebraker), анонсировала выход in-memory СУБД в мае 2010 года, на данный момент компания предлагает как свободную, так и проприетарную версию этой системы. SAP выпустила in-memory СУБД, SAP HANA, в июне 2011 года.

Перечень доступных на рынке in-memory СУБД:

Российские реалии

Российским заказчикам доступно множество решений in-memory. Среди наиболее используемых − решения Oracle, IBM Cognos TM1, SAP HANA, Microsoft PowerPivot, QlikView и Pentaho Business Analytics. Такие платформы хорошо использовать при необходимости анализа данных в режиме реального времени с учетом того, что в процессе анализа данные могут быть изменены в любой момент. Также такие решения хорошо подходят в случаях, когда нет возможности создания многомерного хранилища данных и нужно проводить анализ данных учетной системы без ее модификации. Системы предлагают различные способы горизонтального масштабирования, как с использованием средств самой платформы, так и с применением дополнительного ПО.

В частности, функцию работы с виртуальными кубами в Pentaho Business Analytics можно масштабировать с использованием промышленного решения JBoss Data Grid, которое предназначено для создания распределенных in-memory хранилищ информации.

При таком подходе можно создавать in-memory кубы объемом 1 Тб и выше. С точки зрения ценовой доступности, эти решения вполне позволительны для SMB компаний. В частности, для SMB рынка у IBM есть комплексное решение Cognos Express (TM1 является ее частью), а у Pentaho есть бесплатная версия и специальные ценовые предложения для небольших компаний.

Строго говоря, технологии in-memory делятся на два класса. Это решения data discovery и именно in-memory, или, как правильнее, «in-memory системы управления базами данных (СУБД)». Пример решения data discovery - Qlikview. Данные в этой системе представлены в удобной форме, а использование технологии in-memory позволяет работать с визуальной составляющей быстро. Но к ней нельзя подключить другие инструменты: данные из файлов Microsoft Excel, систем Cognos или Oracle BI.

In-memory СУБД – это когда данные изначально хранятся в оперативной памяти, и доступ к ним практически не занимает времени. Например, главному бухгалтеру компании нужно посмотреть отчет за позапрошлый год в динамике по дням: если запустить этот процесс на классической СУБД, на него уйдет минимум 10 минут (при правильной настройке системы). Если информация хранится в оперативной памяти, результат появится мгновенно. Пример такого решения - SAP HANA. Эта система, являясь СУБД, предоставляет доступ к памяти любому BI-инструменту: можно загрузить данные из таблиц Excel, систем Cognos, Oracle BI и других.

Стоимость таких решений складывается из множества факторов, начиная от сроков внедрения проекта и заканчивая стоимостью самой технологии. Некоторые решения действительно стоят дорого, но быстро окупаются за счет повышения эффективности и оперативности работы. Такие продукты востребованы в любой компании, где важно получать аналитические отчеты оперативно. Например, в случае, если аналитику нужно сформировать отчет, состоящий из 30 Excel файлов, ему потребуется минимум 3 дня для того, чтобы свести его вручную. При наличии необходимых ИТ-систем, ему достаточно лишь указать на эти 30 файлов, после чего система сама сформирует единый отчет, с которым можно будет работать.

Владимир Иткин, директор по развитию партнерской сети Qlik (QlikTech) Россия, рассказал TAdviser, что отличие QlikView – в ориентации на простоту и удобство в построении отчетов. При таком подходе существенно сокращается цикл внедрения, и многие наши партнеры могут работать в режиме экстремального программирования. Это итерационный подход, где длительность одного цикла обычно не более недели. Таким образом, бизнес пользователь уже с первых дней проекта начинает видеть результат и принимает участие в создании решения.

«Через 5-6 таких итераций на выходе получается не просто BI-решение, а актуальный и «живой» инструмент аналитика. Из последних проектов в таком режиме можно назвать «Геотэк Холдинг» и аптечную сеть А5», - пояснил топ-менеджер. По его словам, около 77% всех проектов, от совместного создания ТЗ до запуска в промышленную эксплуатацию внедряются менее чем за 3 месяца. Треть клиентов внедряют QlikView самостоятельно.

Например, КРОК реализовал проект по объединению баз маркетинговой информации в единое информационное пространство в фармацевтической компании «Никомед». Раньше для поиска и анализа информации использовались различные оболочки работы с маркетинговыми данными, которые зачастую были неудобными и не интуитивно понятными. После внедрения решения работа с хранилищем данных стала обеспечиваться аналитической системой Qlikview, благодаря которой работа с разрозненной информацией стало быстрой и удобной.

В «М.Видео», например, была внедрена система SAP HANA с технологией in-memory computing. Система хранения и анализа данных, которая была у заказчика раньше, уже не справлялась с таким объемом информации – данные в более чем 2,5 млрд строк загружались около 3 часов. После внедрения SAP HANA система загружает эти данные менее чем за 30 минут.

В пример можно привести и проект «Терн (Tern Group)» для «Сургутнефтегаз». Главной задачей проекта было сокращение временных затрат на подготовку отчетов, начиная от обработки данных и заканчивая визуализацией полученных результатов. Время подготовки отчетов сократилось в результате сотни раз, и уже сейчас пользователи могут работать со своими аналитическими запросами практически в режиме онлайн.