Базы данных остались в 20 веке

Дэйв Келлог

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

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

С другой же стороны, с точки зрения файловой системы, большая часть контента «бездомна». Если повезет воспользоваться механизмом поиска для индексирования контента, то Вам удастся найти файлы, содержащие определенные слова и фразы. Или же, при помощи некоторых дополнительных установок, можно индексировать XML теги при их наличии, и занести их в поля для поиска. Но для большей части контента полный набор преимуществ проживания в базах данных – таких как мощные, детальные запросы, согласованность транзакций и возможность немедленного обращения – попросту недоступны.

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

Имеет ли ECM отношение к контенту?

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

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

Несмотря на присутствие слова «контент» в аббревиатуре ECM, на сегодняшний день она на самом деле имеет отношение не к контенту, а к метаданным.

По аналогии, ECM-система немного похожа на базу данных, которая предоставляет отчеты, но не запросы. Вы можете получить тот или иной отчет. Этот отчет сделал Боб, а тот – Салли. Этот - версия 2, тот – версия 3. Этот должен одобрить Джо перед его официальной публикацией. Но у Вас не будет возможности проникнуть на уровень более мелких структур, сформировать Ваши собственные запросы, или изменять отчеты для того, чтобы группировать различные данные разными способами. Так происходит потому, что в хранилище ECM-контент обычно непрозрачен, и система просто записывает информацию о нем.

Несомненно, некоторые системы автоматически позволяют Вам разбивать или «дробить» Ваш контент на более мелкие, но все-таки непрозрачные части. Однако такой подход работает в том случае, если контент имеет абсолютно регулярную структуру (чего практически не встречается), и создают проблему Шалтая-Болтая: можно ли снова собрать уже разбитый на части контент? Чаще всего ответ будет отрицательным, поскольку возникнут потери информации при преобразовании контента из его обычной формы в «расщепленную» и обратно. Кроме того, даже среди тех, кто выбрал дробление, производительность работы с раздробленным на части контентом рано или поздно вынудит большинство пользователей вернуться к работе с контентом, разбитым на более крупные модули. Просто в большинстве систем работать с мелкомодульным контентом слишком медленно и неудобно.

ВОЗВРАЩЕНИЕ К BLOB

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

Я присутствовал на презентации Oracle8 в Нью-Йорке в "Рэдио-сити мюзик-холл" в 1997 году, где Ларри Эллисон предсказывал смерть файлам. Однако файлы упрямо продолжали и продолжают существовать.

Я много читал о WinFS  - попытке решения данной проблемы со стороны Microsoft. Имея и СУБД, и операционную систему, Microsoft использует иной подход. Почему бы не создать более совершенную файловую систему на основе XML, вместо того, чтобы пытаться улучшить СУБД? Ожидание WinFS, изначально разработанной для Cairo, а ныне для Vista, было похоже на ожидание Godot. Почему? Вне сомнений, отчасти задержка объясняется знаменитым скомканным процессом разработки, свойственном Microsoft, а отчасти вызвана давлением руководства относительно того, что WinFS должна быть реализована поверх SQL сервера.  Реляционные базы данных крайне неудобны при моделировании иерархии. Моделирование иерархической файловой системы, в которой каждый файл имеет свою собственную сложную внутреннюю иерархию, является просто неподъемной задачей для реляционных баз данных.

Самой последней попыткой устранения разделения является дополнение реляционных баз данных XML типами. Такой подход возвращает назад к абстрактным типам данных, изначально внедренных в объектно-реляционной СУБД Postgres, изначально продвигаемой компанией Ingres, позже выпускаемой под брэндом Illustra DataBlades, а затем проданной Informix для продвижения как «универсальной» СУБД в середине 90х гг.

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

Несмотря на то, что некоторые потребители фактически использовали абстрактные типы данных, это не остановило поставщиков реляционных СУБД расхваливать их как новейшее решение проблемы неструктурированных данных. Большинство поставщиков реляционных СУБД находятся на середине пути реализации XML в качестве типа, поэтому у вас есть возможность создавать таблицы, называемые DOCUMENTS со строками INTEGER, именуемыми DOC-ID, и XML строки, которые называются DOCUMENT.

КОНТЕНТ ПРЕВЫШЕ ДАННЫХ

Я не верю, что данная последняя попытка устранит огромное разделение, потому что поставщики реляционных СУБД снова начинают с неправильной постановки вопроса. Они (уже в четвертый раз) задают вопрос «Как разместить неструктурированный контент в уже существующих базах данных?» вместо того, чтобы начать с вопроса «Чем контент отличается от данных, и как можно создать хранилище данных, в котором контент имел бы приоритет?».

Я сам отвечу на этот вопрос:

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

●     Во-вторых, необходимо признать, что контент, в особенности XML-контент, является строго иерархическим по структуре. Поэтому технологии должны позволять четко моделировать структуру.

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

●     В-четвертых, вам необходимо будет разработать полнофункциональный поисковый механизм в СУБД, потому что пользователи захотят запускать запросы, в которых сочетаются структурированные и неструктурированные поля (например, возврат к первому параграфу всех документов, написанных Бобом, и содержащим слово «тендинит»). Традиционных двоичных деревьев для создания индексов недостаточно, так же, как и попыток независимого индексирования текста и XML.

●     В-пятых, необходима система, которая учитывала бы те неоднозначные явления, которые не существуют в более простом мире данных, но свойственны контенту, такие как омонимия, морфологическая форма слова («Дэйв» вместо «Дэвид»), синонимы («перелом» вместо «разрушение»), таксономия («фрукт» вместо «яблоко») и язык оригинала («яблоко» вместо «apple»).

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

«Пап, ты хочешь сказать, что раньше у вас были базы контента, которые могли обрабатывать только поля, содержащие числа и короткий текст? Отстой!».

Базы данных остались в 20 веке.

Об авторе

Дэйв Келлог является Президентом и Председателем правления компании MarkLogic, разработчика сервера XML-контента MarkLogicServer. Дейв Келлог имеет 30-летний стаж работы в отрасли разработки программного обеспечения, возглавлял отдел маркетинга в Business Objects и в Versant Object Technology (провайдер систем управления объектными базами данных), прежде занимал должности в техническом и маркетинговом отделах в корпорации Ingres Corporation – производителя реляционной СУБД.

Перевод компании DIRECTUM.