Предположим, я запустил компьютер Apple II образца 1977 г. Эта весьма передовая для своего времени машина имела процессор с тактовой частотой 1 МГц, 4 Кб ОЗУ и монохромный видеоконтроллер. Она относится к той же эпохе, что Atari, Commodore 64 и TRS-80. Понятно, что эти модели (а равно их операционные системы, дисководы для дискет, клавиатуры и дисплеи) представляют собой вызывающий ностальгию антиквариат, но не компьютеры для бизнеса.
Но еще до появления первого микропроцессора, вызвавшего к жизни недорогие домашние компьютеры вроде Apple II, Эдгар Френк Кодд совершил прорыв в своем знаменитом документе “Реляционная модель для больших банков данных коллективного использования”, который положил начало базам данных из строк и столбцов, получивших название “классической реляционной модели”.
Сегодня классическая реляционная модель, появившаяся до коммерциализации Интернета, является важнейшим элементом главных систем практически каждой корпорации из списка Global 2000. Но задумайтесь над тремя обстоятельствами, которые обнаружились за время существования этой парадигмы строк и столбцов.
1. Крупнейшие в мире базы данных выросли практически с нуля до 100 Тб, а затем и до многих петабайтов.
2. В 1980-е и 1990-е годы в БД доминировали структурированные данные. Но сегодня объём неструктурированных данных растёт почти вдвое быстрее структурированных. Кроме того, мы все чаще используем данные в аналитических целях.
3. Средства компьютерной аналитики, которой не существовало в момент появления баз данных из строк и столбцов, теперь образуют рынок объемом 20 млрд. долл.
Несмотря на трудности, которые создает классическая реляционная модель для масштабирования, производительности и управляемости баз данных с учетом нынешних объемов хранящейся в них информации и характера современных приложений, она сохраняет свое влияние. Остальная технологическая экосистема развивалась быстрыми темпами, а парадигма строк и столбцов остается практически неизменной на протяжении десятилетий. Это все равно, что использовать миллионы накопителей на гибких магнитных дисках в эпоху передаваемых потоками фильмов высокого разрешения или играть в электронный пинг-понг в эhe суперкомпьютеров.
Ограничения баз данных из строк и столбцов
Позвольте мне привести четыре причины, в силу которых строки и столбцы не годятся для современных ИТ точно так же, как Apple II.
Причина № 1. Строки и столбцы нельзя масштабировать под нынешние объемы данных
Поскольку объем данных на предприятии продолжает ежегодно удваиваться, то же происходит с размерами и количеством таблиц. По мере роста таблиц для обработки запросов аналитических приложений приходится просматривать огромное количество строк и столбцов, чтобы найти данные, соответствующие принятым критериям. Если нынешние тенденции сохранятся, то уже в этом десятилетии информационным технологиям придется туго, поскольку таблицы станут слишком велики для поиска, несмотря на рост производительности оборудования. В результате управлять таблицами станет крайне трудно.
Причина № 2. Управление таблицами — большой труд
Сегодня мы смирились с тем, что крупным предприятиям необходимы группы специалистов, управляющих таблицами, — создающих, загружающих, объединяющих их, считывающих в оперативную память, просматривающих, сортирующих, обеспечивающих их хранение и реорганизацию. Есть три обстоятельства, из-за которых поддержание порядка в табличном хозяйстве становится все более трудоемким.
Во-первых, необходимо загружать в таблицы и индексировать большие объемы неструктурированных данных. Во-вторых, по мере роста объема данных растет и число таблиц, которые нужно обслуживать. И в-третьих, ради достижения приемлемой производительности постоянно приходится вручную структурировать и переструктурировать таблицы.
Причина № 3. Строки и столбцы никогда не предназначались для аналитики
Формат строк и столбцов был разработан еще до появления компьютеризированной бизнес-аналитики и хорошо обслуживал транзакции. Информация, хранимая в строках и столбцах, по своей природе не предназначена для анализа и должна индексироваться. Процесс индексирования создает разрыв по времени между вводом данных и тем моментом, когда они становятся доступны для запросов.
Причина № 4. Строки и столбцы представляют собой жесткую статичную структуру
Базы данных, состоящие из строк и столбцов, создаются под определенные приложения, когда зачастую еще неизвестно, как эти приложения будут использоваться. Затем характер использования приложений меняется, и бизнес диктует необходимость взглянуть на данные под иным углом зрения. Тогда приходится вручную оптимизировать всю структуру таблиц, чтобы достичь приемлемой производительности при выполнении запросов. Следующее поколение интеллектуальной аналитики не сможет работать с жесткими, состоящими из строк и столбцов структурами из-за слишком большого объема ручного труда по введению в БД неструктурированной информации или настройки аналитических запросов ad hoc.
Усовершенствование баз данных, состоящих из строк и столбцов
Конечно, нельзя сказать, будто об этих проблемах ничего не известно. Если сотрудникам приходится всю свою трудовую жизнь посвящать управлению таблицами, маловероятно, что они никогда не задумывались о том, есть ли более совершенный способ решения этой задачи. Поскольку руководители информационных служб и бизнес-подразделений тратят миллионы на серверы, ПО и сервисы, можете быть уверены, что они пытались найти способ удовлетворения своих потребностей при меньших затратах.
Действительно, многие производители стремились решить эти проблемы путем частичного усовершенствования состоящих из строк и столбцов баз данных. Выпускалось патентованное оборудование, создавались кластеры для массово-параллельных вычислений, предназначенные для работы с ориентированными на столбцы системами.
Многие модели демонстрируют значительное повышение производительности, но все же ограничены жесткостью классической реляционной модели. Обслуживание таблиц, ручная настройка ради повышения быстродействия, индексирование и процессы загрузки остаются неизменными. Кроме того, расходы на оборудование, программирование для удовлетворения собственных нужд и лицензии на ПО опустошают банковские счета предприятий ради аналитики, в которой они остро нуждаются.
Устраните ограничения, наложенные классической реляционной моделью
Чтобы освободиться от оков жестких статичных строк и столбцов, которые не позволяют нам продвигаться вперед, необходимо отказаться от частичных усовершенствований классической реляционной модели и создать новую. Если данные больше не будут ограничены жесткими, статичными структурами строк и столбцов, компьютеры смогут реструктурировать их с целью динамической оптимизации производительности и с математической точностью адаптировать их к новым запросам.
Кроме того, устраняя ограничения, накладываемые жесткими, статичными структурами, и позволяя компьютерному ПО манипулировать данными в любой структуре, мы сможем лучше анализировать неструктурированные данные и устранить проблемы масштабирования, связанные с устаревшими системами управления данными на основе классической реляционной модели.
Чтобы превратить СУБД из повозки в истребитель, нам необходимо полностью избавиться от ограничений, накладываемых классической реляционной моделью, и разработать более совершенную.