Когда транзакции осуществляются круглосуточно семь дней в неделю с использованием любых доступных каналов связи, компаниям приходится собирать, хранить, отслеживать и анализировать гигантские объемы данных — от истории посещения сайтов и журналов событий до записей разговоров по мобильным телефонам. Это обходится недешево не только для бизнеса, но и для окружающей среды. Хранилища данных и разрастающиеся ЦОДы, в которых они функционируют, потребляют огромное количество энергии как для питания легионов серверов, так и для их охлаждения. Сколько же? Целых 61 млрд. кВт·ч общей стоимостью 4,5 млрд. долл. в год.

В ИТ-отрасли разработаны различные способы снижения энергопотребления в ЦОДах, включая более эффективные системы охлаждения, виртуализацию, серверы-“лезвия” и сети хранения. Но в принципе проблема остается нерешенной. По мере роста объема данных традиционные подходы к созданию хранилищ, ориентированные на устройства, ведут лишь к наращиванию парка оборудования. Это может быстро свести к нулю любой выигрыш, полученный за счет совершенствования системы охлаждения или более плотного размещения серверов.

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

Добиться этого можно тремя основными способами: уменьшить объем данных; сократить затраты на развертывание систем; снизить текущие расходы на управление и обслуживание. Давайте рассмотрим каждый из них более подробно.

1. Уменьшение объема данных

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

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

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

Например, в зависимости от особенностей данных некоторые колоночные СУБД могут достигать сжатия от 10:1 (БД объемом 10 Тб превращается в БД размером 1 Тб) до 40:1 и даже больше. При таком коэффициенте компрессии можно уменьшить распределенную серверную среду в 20—50 раз и разместить ее в одном-единственном корпусе, сократив расход энергии, выделение тепла и углекислого газа.

На сегодняшнюю сцену выходят и виртуальные витрины данных, использующие технологии интеграции информации в масштабе предприятия (Enterprise Information Integration, EII) для создания специализированных представлений наборов данных, не нуждающихся в физическом хранении. Оборотной стороной такого подхода является медленное выполнение сложных запросов. Это может стать проблемой, если анализ должен проводиться практически в реальном времени.

ПО с открытым исходным кодом поднимает эффективность использования ресурсов на новый уровень, поскольку оно, как правило, не требует патентованного оборудования или специализированных устройств.

2. Сокращение расходов на развертывание систем

Новые технологии в сочетании с открытым ПО упрощают тестирование и развертывание БД собственными силами. Это резко сокращает объем ресурсов, необходимых для реализации аналитического решения.

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

Новые технологии с открытым исходным кодом позволяют загружать ПО из Интернета. Кроме того, оно спроектировано так, чтобы его можно было легко установить и чтобы один человек мог справиться с настройкой и развертыванием. Снижается и потребность в технической поддержке, а значит, можно решать проблемы посредством селекторных совещаний и не тратиться на более дорогостоящие командировки, к тому же сопряженные с расходом углеродного топлива.

3. Снижение текущих расходов на управление и обслуживание

Поскольку традиционные БД, как правило, предназначены для обработки запросов определенных типов, они не очень подходят для тех случаев, когда потребности в управлении данными постоянно изменяются и важнейшую роль играет анализ в реальном времени. (А действительность такова, что онлайн-выполнение операций является практически нормой в мире, где ключевую роль стал играть Интернет). Приспособление таких решений к обработке запросов в “горячем” режиме требует огромного объема работ по ручной настройке и приводит к колоссальным затратам ИТ-ресурсов.

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

Некоторые новые аналитические СУБД делают работу с базами данных полностью автоматической наподобие поиска в Google. С их помощью пользователи могут с легкостью получать ответы на многие типы вопросов. Подобная гибкость позволяет на 90% сократить работы по текущему обслуживанию и оперативной поддержке БД. Если цель компании — разработать только одно решение, которое могло бы применяться многими, то это оптимизирует нагрузку на персонал, затраты времени и средств. Кроме того, возросшая продуктивность анализа данных означает сокращение потребностей в оборудовании без ущерба с точки зрения производительности.

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