`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Горячие данные, холодные данные

+66
голосов

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

Никаких стандартов и даже точных определений на используемые в статье основные термины не существует. Неопределённость (или, наоборот, избыточная определённость) усугубляется обилием оснований для её существования. И, всё же, мы попытаемся разобраться. Потому что в области классификации оперативных данных есть совокупность феноменов, обладающих одновременно и общностью, и принципиальными различиями, и на основании понимания этих феноменов строится логика принятия решений при формировании высокоуровневых архитектур информационных систем. И, как убедительно доказано практикой, если ошибки сделаны на самых высоких уровнях — целей и архитектурном, — исправить эти ошибки очень дорого и крайне сложно, если вообще возможно.

Температура данных

Раз уж в названии статьи данные названы «горячими» и «холодными», не делая отступлений сразу перейдём к попытке определения фундаментального понятия, на котором будет строиться весь дальнейший материал. «Температура данных». Крайне упрощенное толкование этого понятия, как и все крайне упрощенное, выглядит незатейливо — «температура» данных (в дальнейшем — Td) является индикатором частоты обращения к данным в информационной системе, поэтому чем выше частота обращений — тем выше «температура». Естественно, понятие «частота», использующееся в фактически инженерном смысле, подразумевает количество событий (обращений всех типов) к данным за какой-то фиксированный интервал времени. Это банальное и на первый взгляд ненужное уточнение на деле приведено для важной иллюстрации — так как сама частота обращений к данным оценивается на некотором фундаментальном временном интервале, который в общем случае никем не определён, то и температура данных фундаментально зависит от этого эталонного временного интервала, и оцененные как «горячие» (с высокой частотой обращений) данные одной системы неизбежно окажутся «холодными» в другой, в зависимости от назначения систем. Для иллюстрации — в бортовой система управления высокоманевренного статически неустойчивого самолета «горячие» данные могут характеризоваться стабильной частотой доступа порядка десятков и даже сотен килогерц (тысяч раз в секунду), «горячие» данные вебсайтов с высоким рейтингом Alexa — единицами-десятками килогерц, и, наконец, «горячие» данные в интранет-системе предприятия средней руки — это уже, даже при самых экстремальных оценках, — единицы герц. То есть, соотношение нижней и верхней оценки «горячести» данных для известных распространенных информационных систем можно смело оценивать на уровне шести порядков. Что означает пока одно — никакой универсальной цифровой оценки «температуры» данных и быть не может. Но это далеко не все. Самое неприятное с определением «температуры» данных начинается в нюансах. Дело в том, что частота обращений к данным — очевидно недостаточный показатель. И в процедуре доведения его до разумной достаточности наблюдается некоторый разброс мнений. Так, специалисты IBM считают, что кроме частоты обращений в формировании понятия Td участвуют «изменчивость» (volatile) данных и важность операций с этими данными для конечного пользователя системы (в частности, такая точка зрения высказана в документации СУБД DB2). С «изменчивостью» вроде как все понятно без дополнений, и... не совсем понятно. Потому что «изменчивость» — всего лишь косвенное уточнение частоты обращения к данным, выделяющее в общем количестве обращений за единицу времени количество изменений (обновлений). Ну а важность для пользователя — вообще не оцениваемая ни в каких единицах характеристика. Но как раз без нее упрощенная картина получается действительно бессодержательной — важные для пользователя данные бесспорно для этого пользователя обладают очевидно высокой «температурой». Более приземленные и прагматичные специалисты в области систем хранения данных (СХД) вводят и более прагматичные составляющие Td — явно разбивают количество обращений к данным на операции чтения и записи, некоторым образом нормируют оценку «температуры» учетом продолжительности целесообразности хранения данных и, наконец, вводят очевидно нужную поправку на специфику конкретной технологии (технологий), используемых при построении СХД.

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

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

Это определение, выстроенное на коротком анализе и, надеюсь, внятной цепочке рассуждений, обладает рядом важных особенностей, которые не заметить нельзя. Во-первых, оно косвенно учитывает не только важность данных для пользователя в конкретный момент времени (в определении — «этих данных на этом временном фрагменте»). Во-вторых, оно вводит неявное нормирование оценки, так как подразумевает общее количество обращений к данным за все время их хранения и сконцентрированную на каком-то временном фрагменте часть этого количества обращений. Ну и, наконец, главное. И самое очевидное. К сожалению, в общем случае мы не можем говорить о «температуре» данных в будущем времени. «Температура» данных практически всегда — оценка прошедшего времени. В общем случае мы можем оценить «температуру» данных исключительно постфактум. Что, собственно, и наблюдается в реализациях программных подсистем, прямо или косвенно связанных с упрощенной тактической оценкой Td. Например, менее года назад ядро Linux семейства популярных серверных ОС приобрело способность тактически упрощенно оценивать Td на уровне абстракции файловых систем (VFS, Virtual File System, в текущей реализации оценка Td пока ограничивается конкретной файловой системой Btrfs разработки Oracle) на основании статистической информации VFS об использовании объектов файловой системы. То есть, реальному «измерителю температуры данных» нужны накопленные метаданные. И время для их накопления. Опять же, такие очевидные и даже банальные замечания категорически нельзя игнорировать, потому что мы не вправе в общем случае оперировать понятием Td как неким критерием для «построения оптимальных для работы с горячими данными систем». В общем случае мы вправе говорить только о задании некоторого предельного значения, помогающего сформировать архитектуру информационной системы и о грамотно спроектированных системах с такой архитектурой и производительностью, которые позволяют использовать непрерывно изменяющуюся тактическую упрощенную оценку Td для улучшения параметров работы системы, а также, возможно, для ее масштабирования. К этому уточнению мы ещё вернемся, потому что в нём, не выходя за границы попытки понимания расхожего термина, мы незаметно добрались до фактически определения целого класса архитектур (tiered и automated tiered storage).

Правило «пяти минут»

Автором правила «пяти минут» является лауреат премии Тьюринга за достижения в области баз данных Джеймс Николас Грей (более известный как Джим Грей, к слову, Microsoft назвала именем Грея один из своих исследовательских центров и с 2007 года награждает премией Джима Грея отличившихся заслугами в области баз и обработки данных специалистов).

В изначальной формулировке (1987 года) правило «пяти минут» на основании временного интервала между обращениями к блоку данных фиксированного размера (1KB) определяет целесообразность хранения этого блока или в основной памяти, или в быстрой долговременной, опять же, в 1987 году — на HDD. В названии правила содержится сама рекомендация — если блок данных требуется чаще чем один раз в 5 минут, его целесообразно хранить в RAM, в противном случае — на HDD.

Логика правила строится на простом алгебраическом выражении, причём с сегодняшней точки зрения и по современным критериям сформулированном в какой-то степени по принципу «от обратного». В 1987 году быстрые дисковые накопители со всем сопутствующим им оборудованием (контроллерами, стойками, подсистемами питания) были очень дороги и требовали ощутимых эксплуатационных затрат. И первоначальная формулировка правила преследовала цель рационального использования быстрой оперативной памяти для экономии на стоимости долговременных накопителей за счёт кеширования. Сама формула, которая и есть правило Грея, крайне проста (оригинальная нотация отличается от приведенной, но без нарушения правильности результата):

Горячие данные, холодные данные

где:

CachePagesPerMB — количество блоков данных фиксированного размера, помещающихся в 1MB кэш-памяти (т.е. косвенно — размер блока);

PriceCachePerMB — стоимость мегабайта кэш-памяти;

PricePerHDD — стоимость одного дискового накопителя;

AccPerSecPerHDD — количество обращений к одному дисковому накопителю в секунду,

HotDataAccInt — временной интервал между обращениями к блоку данных, определяющий целесообразность хранения данных или в RAM, или на HDD.

Формула Грея, в отличие от «закона Мура», является не чисто эмпирической — она «выведена» математически из двух эмпирических оценок: стоимости хранения блока данных в RAM и стоимости заданного количества операций ввода-вывода в единицу времени для традиционных HDD. Это очень важный нюанс, мы к нему в скором времени вернемся.

Забавно, что формальный результат применения формулы Грея для актуальных в 1987 году значений давал вовсе не пять минут (порядка 300 секунд), а около 100 секунд. Но сам автор увеличил оценку примерно в три раза для учета скорых возможных изменений, в первую очередь, в ценах.

Через 10 лет правило «пяти минут» подверглось первой ревизии — увеличился размер блока данных (до 4KB), для которого правило выполняется. Еще через 10 лет цены на оперативную память упали с $5000 за гигабайт до $15, появились доступные долговременные накопители, использующие флэш-память, существенно снизилась стоимость HDD (в 1987 году дисковый накопитель стоил порядка $15000) и улучшились их показатели (например, с 12-15 операций чтения-записи в секунду до более чем 100 для дешевых SATA-дисков и 200 — для SCSI). И очередная ревизия (2007 года) правила выявила его «работоспособность» теперь для блоков памяти размером 64KB и менее.

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

Иерархическое «правило N минут»

Естественно, эмпирическая формула Грея никоим образом не ограничивает возможность построения гипотез для оценки новых накопителей и систем на их основе. В первую очередь, для оценки SSD (и, в общем случае, любых накопителей с любыми интерфейсами на основе флэш-памяти, занимающей по показателям стоимости и быстродействия промежуточное положение между DRAM и HDD). Но, учитывая специфику работы флэш-накопителей, в первую очередь асимметричность характеристик из-за страничного характера процедур чтения и записи и блочного — процедур стирания (необходимых для последующей записи), и вытекающую из этого сложность одновременного повышения производительности на операциях и чтения, и записи, от «пяти минут» в случае с SSD рационально отказаться. Появятся у флэш-памяти коммерческие конкуренты на основе других технологий и с другими показателями — для них тоже совершенно законно будет применить процедуру «повторного использования» формулы Грея. Потому что, возвращаясь к правилу «пяти минут», формула Грея — не совсем эмпирическая.

Итак, не вдаваясь в ненужные нюансы, уточним только один реально важный для оценки по формуле Грея факт — привлекательная в смысле соотношения «цена-емкость-общее быстродействие» флэш-память (NAND-типа) не совсем и «память с произвольным доступом», и память с атомарной операцией записи. То есть, это совсем не RAM. И в случае SSD (или вообще NAND флэш-памяти) из сугубо инженерных соображений мы не вправе «играть» в формуле Грея размером блока данных. Потому что оптимальный размер блока данных в формуле Грея нам подсказан самим принципом работы флэш-памяти — это размер страницы из документации на используемую флэш-память. Потому что это фундаментальная характеристика флэш-накопителя, и все прочие характеристики будут косвенными, за возможность их использования придется отвечать статистическим характером получающихся оценок из-за необходимости учета работы сложного и очень «хитрого» алгоритмически контроллера SSD, выполняющего невидимое кеширование данных и реализующего изменяющиеся стратегии управления операциями с ними. Соответственно, вместо правила «неизменных пяти минут для увеличивающегося со временем размера блока данных» (а именно так и можно более точно охарактеризовать правило Грея) в случае флэш-памяти мы можем и должны сформулировать нечто новое. А именно, — в поисках «неизменных N минут» для горячих данных хранящихся в SSD, — мы должны говорить об увеличении порядка в нормирующей единице измерения емкости флэш-памяти (в формуле Грея — PriceCachePerMB), то есть, вместо оценочной стоимости за мегабайт мы с развитием технологий начинаем говорить о стоимости десяти мегабайт, потом — ста, затем — гигабайта, etc. При таком подходе (который автор статьи не выдумал сам) сравнительная оценка SSD-HDD по формуле Грея для непродолжительного периода развития SSD и типового размера страницы флэш-памяти 4KB дает интересную цифру — порядка 20000 секунд, то есть около шести часов. И есть основания предполагать, что эта оценка останется неизменной по крайней мере в обозримой перспективе развития флэш-накопителей. Что означает — во флэш-памяти (SSD, например) и экономически, и для достижения оптимального быстродействия всей информационной системы в целом, оправдано хранение данных, к которым обращаются чаще чем один раз в шесть часов.

Но у нас ведь ещё есть и правило «пяти минут», определяющее экономическую оправданность и получение хороших характеристик для кеширования самых «горячих» данных в RAM. И теперь, на основании двух правил мы можем сформулировать нечто новое, а именно:

самые «горячие» данные, обращение к которым происходит чаще чем раз в пять минут, целесообразно кешировать в RAM, «тёплые» данные, обращение к которым происходит реже чем раз в пять минут, но чаще чем раз в шесть часов — во флэш-памяти (SSD), прочие «холодные» данные хранятся на традиционных HDD.

Собственно говоря, без лишней деталировки, только на основании минимально необходимого для логики рассуждений, мы пришли к тому «ага», озарению, которое практически полностью определяет целый класс систем хранения данных, методов управления данными в них, и, наконец, множество смутнопонятных и ни о чём не говорящих аббревиатур.

Синергетика

Давайте теперь соберем в одно целое все, о чем говорилось ранее. Во-первых, мы знаем, что «температура» данных, особенно в упрощенной «тактической» формулировке — нечто, что можно оценить только постфактум. Из чего мы уже знаем и логическое продолжение этого утверждения — упреждающие оценки «температуры» данных могут быть только продуктом прогнозирования, гипотезами.

Во-вторых, мы знаем, что есть действующие не совсем эмпирические правила, определяющие диапазоны «температуры» данных и стратегии выгодного размещения данных разной «температуры» в технологических разных накопителях.

Логика нам подсказывает, что раз уж нам известно первое — постфактум-оценка «температуры» данных и формирование гипотез или прогнозов о будущих значениях Td, и раз известно второе (а ему посвящено множество работ, не только эта статья), и, наконец, раз уж в реальности «температура» данных может изменяться и изменяется, то из всего этого напрашивается очевидный вывод — в системе с иерархией кэш-памятей и обычными HDD можно автоматически так управлять данными, чтобы блоки с предсказанной «температурой» находились в оптимальном для их «температуры» месте в иерархии. В таком случае вся система будет и экономически эффективной, и достаточно реактивной (то есть, обеспечивающей приемлемое среднее время отклика), и, наконец, даже живучей. Потому что фундаментальные критерии, полученные с помощью простой арифметической формулы Грея, обладают доказанной «работоспособностью» в широчайшем диапазоне изменения используемых для расчета значений.

Если вы добрались до этого места, можете себя поздравить. Мы только что фактически открыли «Automated Tiered Storage». И еще кучу всякого сопутствующего. Пользуясь только арифметикой, потому что на таком высоком архитектурном уровне, который обозначается невнятным «Automated Tiered Storage» ничего больше и не надо.

Дьявол, как всегда, затаился в деталях

Человек хоть немного образованный, услышав слово «прогноз», должен насторожиться. Если же речь идет о высокоуровневом описании класса достаточно непростых систем, и в основании принципиальной функциональности всего класса лежит некоторая прогностическая оценка, настороженность можно смело менять на тревогу. А если заинтересоваться как обстоит дело с формированием прогнозов «температуры» данных, то тревога может уступить место отчаянию. Потому что здесь уже «хоть немного образованным» делать совершенно нечего. Закупить и развернуть иерархию накопителей разных типов, соединить их в нечто целое, получить постфактум-оценку «температуры» данных — это задачки простые, требующие разве что финансов и времени. Но кому нужна система, которая реагирует на то, что уже было? Стало быть, качество прогноза «температуры» данных в иерархических системах их хранения — собственно и есть качество этих систем. А вот качество прогноза — штука крайне непростая. Самое простое подтверждение — стоит вбить в строку поиска «hot data identification», чтобы убедиться, какие силы сконцентрированы в теоретической составляющей выявления «температуры» данных и прогнозирования ее изменений.

К слову, прогнозирование практически всегда подразумевает «недостаточность информации», и крайне редко — ее избыточность. Для прогнозистов не бывает много исходных данных. И потому лучше не говорить о «совершенных алгоритмах прогноза», не учитывающих специфику конкретной прикладной области. Самый простой пример — цепочка высокоуровневой обратной связи, замыкающая систему управления хранением данных в иерархическом хранилище ИТ-инфраструктуры большой социальной сети. Мониторинг социальной сети может выявлять информацию о трендах — хорошо известный эффект, когда яркое (или «ярко раскрашенное» какими-то социальными механизмами) событие вызывает взрыв активности в социальной сети. Также очевидно, что этот взрыв имеет некоторую продолжительность. И со временем активность затухает. Что означает — информация о выявленном высокоуровневом тренде может и должна использоваться в низкоуровневом управлении данными — какие-то файлы автоматически будут «переброшены» в RAM-кэши, какие-то — в SSD-кэши, что-то уйдёт на HDD, чтобы освободить им место. И в итоге высокоуровневая оценка социального явления на самом низком уровне обеспечит сохранение реактивности всей системе в целом, пользователи не заметят всплеска, странички-картинки будут загружаться так же, как загружались, без заметных «торможений».

Все это — повод задуматься, насколько хорошо можно автоматизировать механизмы управления данными в иерархических кэшированных системах хранения данных. И о том, что любые универсальные механизмы автоматизации могут оказаться в конкретном случае далеко не лучшими. Здесь следует заметить, что косвенно о том же говорят даже люди, от которых при учете их должности и места работы услышать подобное несколько неожиданно. Например, совсем свежее высказывание вице-президента Citrix Уландера о состоянии дел в области виртуализации и cloud-компьютинга — «Я не думаю, что мы даже сдвинулись в направлении идеала, где все будет на 100% абстрагировано и автоматизировано».

В качестве итога — живучесть

Автор не претендовал ни на обзор существующих иерархических систем хранения данных, ни даже на исчерпывающее толкование термина «Automated Tiered Storage» и его разнообразных коммерческих аналогов. Даже не потому что это невыполнимые в объемах статьи задачи. Терминология меняется, коммерческих аббревиатур, обозначающих одну и ту же суть выдумывается море, поэтому гоняться за эфемерными «толкованиями всего» смысла нет. Главное, с чем хотелось разобраться — с основой здравой инженерной идеи построения иерархической системы кэширования данных, позволяющей формировать живучие архитектуры ИТ-систем. Живучесть вообще очень важная характеристика, каждый инженер знает, что все им спроектированное уже морально устарело когда начало проектироваться, и ни один инженер не хочет построить что-то, что физически устареет за год или несколько лет. Правильно организованная иерархия кэширования в системах хранения данных — хороший пример инженерного решения, позволяющего в какой-то мере разрешить эту дилемму. Изменятся технологические основы низкоуровневых накопителей, цены, увеличатся требования — если архитектура системы изначально приспособлена к реакции на все это, и ее приспособленность доказана временем, — система будет работать долго и хорошо. Вот так, в выстроенной на основе простой арифметической формулы архитектуре очевидно собрались и все классические проверенные принципы, например «разделяй и властвуй» и «используй то, что нужно, в тех объёмах, которые рациональны», и основы для модернизаций (например, прогностических алгоритмов или масштабов, их изменение вообще сугубо технологический вопрос), и, наконец, главное в инженерии — ценовая эффективность.

+66
голосов

Напечатать Отправить другу

Читайте также

Что-то народ о термодинамике информационных систем в КО начал рассуждать . Так и о квантовой информатике начнем всерьез говорить. И это, похоже, правильно.

Ищем смыслы, не хочется перепродавать цифромусор :)

Вы хотели сказать цифроентропию?

Скорее, реакция на "термодинамику" в поиске "быстро на вчера" за "столько денег нет и не будет" :-)
Для внутреннего осознания принципа разумной достаточности подобные материалы чрезвычайно важны.
Потому как на научной основе (и даже с применением арифметики!) показывают, что счастье есть, и за него стоит бороться... применяя собственные мозги.
Или остаться потребителем "блекбоксов" с "партнамбером".

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT