Встраивание Information Life Cycle Management (ILM) в СУБД
Как известно, данные и информация имеют свой цикл жизни (рис. 2). Вначале они поступают в систему (в БД) и являются активными, т.е. используются очень часто. Нужно обеспечить быстрый доступ к информации и хранить ее на быстрых дорогих дисках. Затем информация начинает устаревать, переходит в разряд менее активной. Она все еще должна быть под рукой, но ее уже можно переместить на более дешевые и медленные диски.
Рис. 2. Цикл жизни данных и информации
Затем информация переходит в разряд исторической. По закону мы должны хранить ее определенное количество лет (или вечно). После истечения срока хранения информацию надо удалять, чтоб освободить место в БД. Надо иметь возможность легко воссоздавать старые отчеты на базе этой информации. Кроме того, данные исторической информации нельзя менять (кто же хочет иметь непредсказуемую историю?), и надо гарантировать их неизменность. Надо также гарантировать их неудаляемость в течение заданного срока. Не всем пользователям и приложениям разрешается работать с исторической информацией, нужен контроль за тем, кто и как ее использует и т.д. и т.п. Поскольку запросы к историческим данным выполняются редко, а их объем достаточно велик, часто прибегают к сжатию исторических данных. Ну, и в конце своей жизни данные часто переносятся в оффлайновые архивы на лентах.
Поддержание жизненного цикла информации и данных разного типа, как правило, сегодня реализуется на уровне логики приложений. Это сложно, негибко, усложняет приложения и снижает качество управления информацией. В результате важные данные могут быть утеряны (пример - компания Энрон) или занимать большой объем на дорогих дисках.
Часто управление жизненным циклом данных реализуют производители систем хранения. Но, поскольку они работают именно с данными (а не с информацией) и не знают бизнес-логики и бизнес-характеристик информации, то реализуют поддержку именно жизненного цикла данных (DLM), а не информации (ILM)
Поэтому сегодня наметилась тенденция реализации механизма ILM на уровне самой СУБД.
Администраторы или разработчики описывают различные области хранения данных с разными характеристиками (быстрые диски, медленные диски, ленты, флеш-память, CD и т.д.) и правила разделения данных одного типа на группы (например, по мере устаревания, по частоте использования и т.д.). Группы привязываются к областям хранения, и при изменении характеристик данных они автоматически перемещаются в другую группу, а следовательно, и в другую область хранения. При этом меняются характеристики этих данных, данные могут сжиматься, переводиться в режим “только для чтения” и т.д. Система будет следить, чтобы данные группы хранились требуемое время и затем уничтожались.
Разделение данных на группы должно учитывать бизнес-смысл данных (работаем с информацией) и должно быть независимым от оборудования, на котором данные хранятся и обрабатываются; оно должно быть прозрачным для приложений (приложения не знают о том, что эти данные разделены на группы и работают как обычно). Очень удобным средством такого логического разделения данных на группы является механизм секционирования (partitioning). Например, можно группировать данные по диапазону значений, по времени, по частоте использования, по географии размещения, по значению одного или нескольких полей записи. Возможно и смешанное секционирование (по нескольким измерениям). Графический инструментарий позволяет не только описать эти группы, области хранения, политики хранения/уничтожения и т.д. и отслеживать состояние данных. Он также подскажет, сколько денег и места на дисках вы сможете сэкономить, используя тот или иной вид сжатия данных, тот или иной тип устройств хранения. С помощью механизма ILM вы сможете переложить всю ответственность за поддержку жизненного цикла информации на СУБД.
