Серверы для контента XML

Обработка Больших Данных — это в том числе и манипулирование огромными текстовыми массивами с помощью приложений, выделяющих нужное текстовое подмножество из базы текстовых документов. Так, на авиалиниях стандартную сумку экипажа с полетными документами начинают заменять планшетниками, в которые перед вылетом загружаются документы, относящиеся к рейсу; либо, скажем, требуется снабдить командира армейского подразделения частью общей информации о проводимой войсковой операции. Список такого рода примеров можно продолжать — возникающие задачи очевидны, однако до поры не предпринимались попытки автоматизации их решения. Сегодня область приложения компьютерных технологий существенно расширилась, и данные, с которыми приходится иметь дело, сейчас уже плохо укладываются в неприспособленные для них реляционные таблицы — общеизвестно, что свыше 80% хранимых данных представлено в виде текстовых документов различных форматов (Word, PowerPoint, PDF и др.). Продуктивно работать с неупорядоченными документами трудно: их сложно интегрировать, в них сложно найти нужные сведения, и особенно запутанными оказываются повторное использование существующих данных и передача нужного контента от одного пользователя другому. Оказалось, что ни реляционные СУБД, ни системы корпоративного поиска данных не могут полноценно наладить работу с контентом — требуется новый класс ПО.

Инструментом для работы с текстовыми данными может стать сервер управления контентом XML (XML content server), позволяющий строить приложения для работы с контентом. Изначально серверами контента называли машины, хранящие все многообразие содержимого Интернета, но с распространением неструктурированных данных это понятие распространилось на любые источники данных. Основой хранения служит формат XML, в который при загрузке трансформируются все остальные форматы, а «управление контентом» в названии таких серверов указывает на их способность работать с контентом, что отличает их от баз данных XML (XML database). Сервер не просто хранит документы, но и позволяет создать приложения, обеспечивающие полный цикл работы с контентом, состоящий из четырех этапов:

• подготовка — импорт документов, преобразование, структуризация;
• поддержка запросов — составление индексов и выполнение запросов на языке Xquery;
• формирование требуемого выходного контента — разного рода преобразования, обновление и сборка;
• результат — объединение, форматирование и доставка.

Сегмент рынка XML-серверов еще очень молод, но активно развивается и на данный момент представлен несколькими компаниями, в том числе Inmagic, InfoTrust, MarkLogic, выпускающими коммерческие продукты. В нем, как в любом зарождающемся сегменте, активно действуют производители систем категории Open Source, которых уже около 30(http://www.2000shareware.com/downloads/xml/content/server).

Признанный лидер в этой области — MarkLogic Server. В данном продукте реализована наиболее полная функциональность обработки контента XML:

• автоматическая конвертация контента — загрузка XML-документов в исходной форме, преобразование популярных форматов (Microsoft Office, PDF и HTML) в форматированные XML-документы без привлечения схем DTD и XML, что заметно проще и дешевле, чем дробление документов на части для их загрузки в реляционные базы;
• полнотекстовый поиск и XML-поиск с использованием ключевых слов, их последовательностей, булевых выражений и т. п.;
• инфраструктура для создания пользовательских приложений (Content Processing Framework);
• поддержка стандартов XML и XQuery, API для Java и. Net.

Компания MarkLogic до сентября 2011 года была в тени и вышла из нее под девизом «Заставим данные работать». MarkLogic — весьма примечательная компания, посвятившая весь свой бизнес работе с неструктурированными данными и представляющая собой типичный стартап, созданный не вчерашними выпускниками Стэнфорда или Беркли, а признанными гуру в своей области. В данном случае это Кристофер Линдблад, бывший в свое время главным архитектором в компании Ultraseek, разработавшей Infoseek, одну из некогда популярных поисковых машин, и его коллега, ныне профессор университетов Корнелла и Лос-Анджелеса Пол Педерсен, несколько лет назад занимавший должность вице-президента по корпоративному поиску в Google. Сегодня названия Infoseek/Ultraseek мало что говорят большинству жителей Паутины, но именно с Infoseek и ее конкурентами связаны первые шаги в деле освоения WWW. Замечательным свойством Infoseek был простой, но очень эффективный язык запросов, позволявший использовать не только ключевые слова, но и логические операции, скобки и другие полезные вещи, которых явно не хватает в рассчитанной на массового обывателя поисковой машине Google. За последнее десятилетие Infoseek растворился в процессе продаж и перепродаж, но наследие этой системы живо. К примеру, китайский национальный поисковик Baidu был создан под руководством Робина Ли, вернувшегося на родину после работы в Infoseek и сейчас возглавляющего компанию с оборотом 10 млрд долл.

Сегодня у MarkLogic примерно 240 клиентов, в числе которых Библиотека Конгресса США, федеральные агентства, крупные издательства и организации, имеющие дело с большими объемами текстовых данных: взрывной рост объемов неструктурированных данных оказался большой удачей для этой компании. Ее новый руководитель Кен Бадо, до начала 2011 года управлявший бизнесом Autodesk, намерен обеспечить рост прибыли не менее 45% в год и уверен в способности MarkLogic противостоять по определенным вопросам таким игрокам, как Oracle.

Модель хранения MarkLogic построена на полноценных текстовых документах в формате XML, которые могут быть отформатированы заранее или в процессе загрузки в базу. В реляционных базах использование текстов в качестве единиц хранения невозможно — следует либо каким-то образом распределить документ по полям в строках, либо хранить его неиндексированным в структурах типа BLOB (Binary Large OBject) или CLOB (Character Large OBject). Однако, не будучи реляционной СУБД, MarkLogic остается транзакционной — это качество ей придает репозиторий собственной разработки, обеспечивающий высокую производительность на больших массивах текстовых документов. MarkLogic поддерживает полный набор свойств ACID (Atomicity, Consistency, Isolation, Durability — «атомарность, согласованность, изолированность, долговечность»), обязательных в реляционных СУБД, но неожиданных для документоцентричных баз данных, ориентированных на поиск. Своей возможностью эффективного поиска сервер MarkLogic обязан близкому родству с поисковой машиной Infoseek, от которой MarkLogic унаследовал важнейшую для Big Data способность к масштабированию. MarkLogic может работать на кластерах с практически неограниченным числом узлов, в каждом из которых выполняется один и тот же процесс MarkLogic, но при этом узлы делятся на две категории в зависимости от исполняемой ими роли. Узлы типа D (Data Manager) работают с подмножествами данных, а управляющие узлы типа E (Evaluator) обрабатывают входящие запросы и распределяют их по узлам D. Управление кластером (в основном балансировка нагрузки) осуществляется автоматически — по мере роста объемов необходимо увеличивать число узлов обоих типов. Кластерная файловая система обеспечивает сохранность данных при выходе узлов из строя, причем независимо от их типа.

Очевидно, что главным действием любой системы, обеспечивающей доступ к данным, является индексация, с которой еще в XIV веке началась история библиотек. MarkLogic предполагает несколько простых вариантов индексации.

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

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

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

Структурное индексирование. Если документы имеют структуру, с которой можно работать, используя Xpath, язык запросов к элементам XML, то можно создавать иерархические индексы (родитель — потомок), позволяющие прослеживать элементы в иерархии.

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