Нефть и песок О стали Компрессор - подбор и ошибки Из истории стандартизации резьб Соперник ксерокса - гектограф Новые технологии производства стали Экспорт проволоки из России Прогрессивная технологическая оснастка Цитадель сварки с полувековой историей Упрочнение пружин Способы обогрева Назначение, структура, характеристики анализаторов Промышленные пылесосы Штампованные гайки из пружинной стали Консервация САУ Стандарты и качество Технология производства Водород Выбор материала для крепежных деталей Токарный резец в миниатюре Производство проволоки Адгезия резины к металлокорду Электролитическое фосфатирование проволоки Восстановление корпусных деталей двигателей Новая бескислотная технология производства проката Синие кристаллы Автоклав Нормирование шумов связи Газосварочный аппарат для тугоплавких припоев
Главная страница / Архитектура отрасли

Что имеем, то храним

По данным IDC, темпы ежегодного увеличения объема данных составляют 80%. Если в 1983 г. каждый житель планеты в среднем создавал одну страницу текста за два месяца, то к 2000 г. только за минуту он генерировал 3,5 страницы, что составляет 470 Мбайт на человека. При этом затраты на ИТ возрастают только на 20% в год. Если добавить к этому высокие темпы снижения стоимости жестких дисков, а также необходимость обеспечения потребителям доступа к данным в любое время, то становится понятно, что без современных решений по хранению данных, позволяющих работать с информацией на всем протяжении ее жизненного цикла, сегодня не обойтись.

Нельзя сказать, что ИТ-индустрия игнорирует проблему создания эффективных хранилищ. Например, весь рынок таких систем аналитики IDC оценивают в 63 млрд долл. Однако, по данным SNIA (Storage Networking Industry Association), за год количество данных в компаниях возрастает на 60-100%, но только 53% из них находятся в том месте, где их надеется найти пользователь, и это притом, что почти половина всех средств на ИТ в ближайшем будущем будет расходоваться на организацию хранения данных. Мало того, согласно наблюдениям ESG (Enterprise Strategy Group), 51% данных – это дубли, и 70% всего дискового пространства корпораций остается неиспользованным.

Какой же должна быть архитектура хранилища, насколько необходима параллельная обработка, как создать адаптивные хранилища, в которых инфраструктура систем хранения зависела бы от данных, а не наоборот? В платежной системе следует оценивать риски непосредственно в момент обслуживания клиента, а телекоммуникационной компании для выявления недобросовестных абонентов требуется в режиме, близком к реальному времени, просматривать миллионы исторических записей. В отличие от централизованного хранилища, с лавиной данных позволяют справляться распределенные хранилища, использующие параллельные способны обработки и виртуальные системы хранения. Однако, по утверждениям аналитиков, более 80% крупных компаний имеют централизованные хранилища, но до 90% их данных не востребованы. Высокая стоимость, сложность и недостаточный уровень использования ресурсов – именно по этим причинам централизованные хранилища уступают место параллельным системам «с распределенным интеллектом». Стоимость подобных систем пока достаточно высока, но сокращение времени обработки и необходимость соблюдения соглашения об уровне сервиса (SLA) всерьез «играют» против цены.

Технологический цикл – сбор данных, их преобразование, хранение и генерация отчетов – не соответствует современным потребностям компаний. Стоимость поддержки централизованного, статичного хранилища составляет в год примерно 20% его первоначальной цены. Возможно, пришло время распределенных конфигураций? С другой стороны, централизованные хранилища данных позволяют решать такие специфические задачи, как анализ в режиме офф-лайн. Правда, они не способны сохранять актуальные данные, что важно при создании уже упомянутых телекоммуникационных и банковских систем.

Вообще говоря, хранилища данных изначально задумывались именно как средства анализа постфактум, не говоря уже о том, что загрузка данных в них (ETL, Extraction, Transformation и Load) – операция весьма трудоемкая.. До появления таких продуктов, как Oracle 9i и 10g (Warehouse Builder 10gR) или IBM DB2 9 Venom, работа хранилищ данных в режиме оперативном режиме была невозможна. Инфраструктуры хранилищ, базирующихся на продуктах таких компаний, как IBM/Informix, Oracle, Microsoft, NCR/Teradata, Sun/Sybase, насчитывающих до тысяч процессоров и дисков, способны хранить десятки и сотни терабайт, но при создании подобных систем приходится состыковывать и конфигурировать разнородное оборудование, проводить тонкую настройку операционных систем и СУБД, разрабатывать схемы, индексы, запросы, процедуры загрузки баз. Решения такого масштаба весьма дорогостоящие, требуют услуг внешних консультантов и долгосрочной поддержки со стороны поставщиков. Поэтому ведущие поставщики решений для хранилищ наряду с продуктами общего назначения разрабатывают специальные версии СУБД или предварительно сконфигурированные комплекты (data warehouse bundle) той или иной степени полноты: IBM Data Warehousing Balanced Configuration Unit и DB2 Integrated Cluster Environment, Oracle Real Application Cluster и Oracle Database Pack, Sun-Sybase iForce Solutions, Unisys Business Intelligence Solutions.

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

Одно из таких решений – параллельные машины от компании Teradata, предусматривающие выполнение отдельного SQL-запроса путем его разбиения на части, одновременную их обработку и выдачу общего результата. Параллельно могут выполняться все действия в рамках запроса или только отдельные из них. При этом значительно сокращается время обработки SQL-предложения, особенно если требуется прочесть и проанализировать большое количество данных. В продуктах от Teradata изначально было распараллелено все, от ввода SQL-предложений до деталей их выполнения. Не зная предварительно, где возникнут «узкие места», разработчики заранее устранили причины заторов. В СУБД Teradata можно без ограничений определять количество путей межузловых соединений, каналов связи с мэйнфреймами, шлюзов и единиц параллелизма. Это обеспечивает гибкость и контроль над производительностью, которая критически важна для современных крупномасштабных систем, предназначенных для поддержки принятия решений.

Главная страница / Архитектура отрасли