Инфраструктура Linking Open Data Project: опыт эксплуатации и будущее масштабирование
Это черновик неофициального доклада на ЗОНТ-2009, которому сильно не повезло --- по не зависящим от меня причинам я на ЗОНТ-2009 не попал. Документ представляет мою личную точку зрения, OpenLink Software, W3C, сообщество LOD и другие организации тут не замешаны.
Linked Data Project создаёт общеупотребительные иерархии классов, словари нарицательных и собственых имён, а также помогает владельцам массивов данных объединять их базы знаний в одну связную систему знаний. Во многих случаях участники проекта объединяют уже имеющиеся большие базы, помогая друг другу установить соответствие между идентификаторами одной и той же вещи в разных базах. Если какая-то база знаний заполняется некоторой автоматической процедурой, то эта процедура может начать использовать имена, уже используемые другими участниками, если она пишется вручную, то авторы могут заглядывать в DBpedia, GeoNames, WordNet или Yago как в словарь, одновременно с этим превращая свои даные в "заметки на полях" большой энциклопедии. В выигрыше все --- и авторы небольших баз, и составители больших словарей. Наличие перекрёстных связей между различными базами знаний не только делает эти базы более полезными --- часто сами знания очищаются от ошибок.
Весной 2009 года суммарный объём баз проекта составил 4.5 гигаквада, и сейчас проект находится в почти неуправляемой, но очень увлекательной фазе экспоненциального роста. (Десять дней пролежала статья без движения --- и уже 4.7). Растёт не только объём базы --- одновременно растёт и количество запросов к базе. Это создаёт интересные проблемы для OpenLink, потому как имено мы предоставляем SPARQL-доступ к основным ресурсам проекта. Мы бежим наперегонки с остальными участниками проекта. На ранних этапах проекта мы участвовали в создании, скажем, YAGO. В настоящий момент мы уже не добавляем в проект свои знания, мы только лишь непрерывно совершенствуем OpenLink Virtuoso Universal Server, улучшая его масштабируемость, и плавно наращиваем вычислительные мощности. Если мы задержимся в развитии --- наш веб-сервис издохнет под нагрузкой. Если мы сделаем нечто "эдакое", и получим принципиально лучшую масштабируемость --- поставщики крупных баз данных будут рады открыть доступ к массивам, на порядки большим, чем весь нынешний LOD, и гонка продолжится. Одна только Ordinance Survey, геодезическая служба Её Величества, оценивает доступный объём заний об одних только Англии и Ирландии в один петаквад. И мы планируем предоставить им всю необходимую для этого инфраструктуру, параллельно расширяя возможности языка запросов.
Прежде, чем продолжать хвастаться, хотелось бы объяснить цель этого хвастовства применительно к российским условиям. Очевидно, что Россия в ближайшие годы не будет крупным участником этого "горизонтального" "общеупотребительного" проекта и ему подобных. У нас в прошлом году приключилось знаменательное событие --- появился президент, умеющий браузером пользоваться, всего-то на два президентских срока позже, чем следовало бы. При таком лаге серьёзных денег на отечественный семвеб не будет как минимум ещё три президентских срока. Не будет даже если это прорубает здоровенную дыру в обороноспособности страны, потому что потребные суммы слишом малы по сравнению, скажем, с производством авиатехники. За долю в этих мелких деньгах ни один лоббист не почешется. Также очевидно, что Академия Наук в её нынешнем виде не сможет выступить инициатором вертикальных отраслевых проектов --- нет ни свободных кадров в Академии, ни заказчиков в промышленности. Будут небольшие локальные проекты, на голом или почти голом энтузиазме. Что общего между будущей инфраструктурой этих проектов и большими проектируемыми кластерами LOD? Да самое главное --- общие проблемы с бюджетом, общие законы физики.
Сначала о наболевшем. Нет повести печальнее на свете, чем повесть о запросах и бюджете. OpenLink --- небольшая частная компания, всего 50 человек. При этом базы знаний --- вовсе не основное наше направление. Мы давно и прочно являемся лидером в производстве кроссплатформенных драйверов баз данных, брокеров запросов и прочего RDBMS middleware. Нас уже двадцать лет кормит именно это, а вовсе не семвеб. LOD --- это работа в надежде на светлое будущее, но при этом каждый ящик в серверную --- это деньги, с кровью выдранные из бюджета какого-то другого проекта уже сейчас. Кроме того, все вопросы по этой тематике минуют обычную техподдержку и попадают напрямую к ведущим разработчикам, в довесок к основной работе. Так что мы кровно заинтересованы в том, чтобы ПО не требовало квалифицированого администрирования и работало на "комодах", т.е. на серверах, собраных в домашних условиях из недорогих железяк. В частности, мы используем дешёвые диски, относительно дешёвые планки памяти, не самые быстрые процессоры, и мы до последнего будем избегать межмашинных соединений дороже Gigabit Ethernet. Мне кажется, что такие технические ограничения поддержат многие отечественные бригады, которым абсолютно необходимо, чтобы система стоила мало, обрабатывала много, обслуживалась раз в неделю ленивым студентом и при этом жужжала одна на весь институт, потому как на вторую денег уж точно не будет. Такую вещь мы и пишем. Пока получается.
Общие законы физики гарантируют одинаковые для всех проектов пропорции между производительностью процессоров с одной стороны и скоростью и латентностью межмашинного обмена. Сколько бы не стоила сетевая карта, сигнал по проводнику идёт примерно со скоростью одна ширина кристалла процессора за такт этого процессора. Дюйм за такт, если наглядно. Параметры жёстких дисков тоже достаточно близки, в силу схожести габаритов и материалов. Схожи и основные временные характеристики используемых операционных систем, в том числе задержка потеря времени на переключении нити, если нить вынуждена ждать мьютекс, время входа в мьютекс "без помех", время обмена даными с драйвером сетевой карты и т.п. Любая "тяжёлая" операция, будь то неторопливый системный вызов или посылка байта куда-то на периферию будет стоить в сотни а то и сотни тысяч раз больше, чем шаг интерпретации запроса. Если параллелизм хороший, а обмен между процессами спланирован верно, то тяжёлых операций будет мало, и процесоры не будут простаивать в ожидании --- готовых к работе нитей хватит всем. Если параллелизм плохой --- ляжет кластер любого размера и цены. При этом хорошо распараллелить можно только изначально аккуратный код, известный разработчику сверху донизу. Это как раз наш случай. Виртуоза лучше всех не потому что мы самые умные, а потому что она в продаже с 1995-го года, у нас фора в десять с лишним лет.
"Что верно для бактерии, то верно для слона" --- старая шутка генетиков. У нас импликация в другую сторону. Что работает для LOD --- заработает и на паре ящиков под столом энтузиаста-одиночки.
Рассказ о бочке мёда уместно начать с ложки дёгтя. Наш хостинг LOD не лишен ограничений. Рассмотрим самые важные из них: ограничение на время исполнения запроса, запрет на использование реляционных источников данных, запрет на материализацию видов.
Ограничение на время исполнения запроса.
SPARQL-запросы очевидно более выразительны, чем, скажем, полнотекстовый поиск. Можно легко написать сколь угодно трудоёмкий запрос, особенно по ошибке. Немедленно обнаружилась проблема --- сервис сможет выполнить множество несложных поисков либо ответить на существенно меньшее число более "умных" вопросов. Что полезнее для общества --- непонятно. В итоге мы разрешаем любые запросы, но ограничиваем их по времени исполнения. Более того, мы их ограничиваем дважды. Сначала мы отбрасываем без попытки запуска те запросы, для которых компилятор выдал слишком большую оценку стоимости. Потом мы обрываем выполнение "слишком задумчивых" запросов по реальному времени. Это не исключает некоторой "нечестности" --- оценка компилятора может оказаться несправедливо завышенной, несколько одновременно запущенных сложных запросов одного пользователя могут забить всю память, привести к непрерывной подкачке и тем самым убить все запросы --- и хорошие и плохие, но по крайней мере система имеет хороший воспитательный эффект --- плохие запросы убиваются всегда, отбивая охоту их задавать.
Те, кому действительно надо выполнять сложные запросы могут, разумеется, создать свою базу, загрузить нужное подмножество LOD и своих данных, и делать что угодно. Либо сэкономить время и силы, арендовав точную копию нашей базы на облаке Amazon.
Запрет на использование реляционных источников данных.
Одно из базовых ограничений инфраструктуры LOD --- используется только "чистый" RDF, даже если исходные данные доступны в другом представлении, скажем, в виде реляционных данных. При этом мы умышленно лишаем себя одного из самых важных своих инструментов. Дело в том, что Virtuoso позволяет описать отображение реляционных данных в RDF, и потом транслировать SPARQL-запросы к этому воображаемуму RDF в эффективные SQL-запросы к реальным таблицам. Такие отображения называются RDF Views, и их использование обычно позволяет выиграть в производительности по сравнению со SPARQL-запросами над действительно экспортированными данными. Выигрыш достигается за счёт правильного использования индексов, специфичных для конкретных данных и конкретного приложения. Кроме того, исчезает весь набор проблем, связанных с поддержанием актуальности RDF-копии реляционных данных. Больших, доложу вам, проблем. И тем не менее, мы в случае LOD миримся с этими проблемами и при этом жертвуем потенциальным выигрышем в производительности. Это связано с тем, что время компиляции некоторых запросов растёт как полином от числа RDF-видов. Это не является непреодолимой проблемой для десятков или даже сотен отображений, чего достаточно для корпоративных приложений, но могло бы стать блокирующим препятствием для LOD с его непрерывно растущим разнобразием данных.
Опять-таки, желающие могут использовать любые схемы хранения, это наше частное решение для данного конкретного проекта, а не некий фундаментальный запрет.
Запрет на материализацию видов.
Дело в том, что стоимость обновления нетривиальных видов растёт полиномиально от объёма базы, а с ростом разнообразия данных в базе растёт и число видов, которые могли бы кому-то пригодиться. Если бы мы решили начать использование SPMJV или других похожих трюков, то сейчас все наличные мощности были бы заняты обновлением видов, а не полезной работой. Оракл использует SPMJV, но для корпоративных приложений с постоянной и известной администратору тематикой запросов. Если корпоративный пользователь Virtuoso хочет делать запросы с известной тематикой, то ему лучше использовать RDF Views, чем комбинацию экспорта и SPMJV. Поэтому MJV нет и в обозримом будущем не будет.
Теперь о более приятном --- о том, что наша общедоступная точка доступа делать умеет. Первое, и самое главное --- она работает. Работает себе и работает, как и положено уважающей себя системе индустриального качества. Как пример, весной 2009 года два скромных ящика, каждый с одним quad-core Xeon и 8 гигабайтами, выполняли все "разумные" запросы к lod.openlinksw.com, 4.5 гигаквада.
Во-вторых, система работает быстро. Мы стабильно показываем наилучшие времена в BSBM --- Berlin SPARQL Benchmark.
В-третьих, Virtuoso может с той же скоростью выполнять и более сложные запросы. Наш язык запросов существенно мощнее стандартного SPARQL, он даже мощнее того, что будет предусматривать спецификация SPARQL 2.0, которую сейчас готовит Data Access Working Group W3C. Мы добавили вывод "дополнительных" фактов в соответствии с имеющимися онтологиями и предикатами same-as. Запрашивая свойства одного субъекта, можно заодно получить и свойства всех его синонимов, синонимов его синонимов и т.п. Схожим образом обрабатываются подклассы и частые случаи свойств. Мы добавили BI- (Business Intelligence) расширения к SPARQL, и в результате можем выполнять SPARQL-BI версии запросов TPC-H всего лишь на 30 процентов медленнее, чем оригинальные SQL версии, а их мы выполняем с той же скоростью, что и остальные "серьёзные" поставщики СУБД. Мы добавили транзитивные подзапросы, получив возможность искать пути произвольной длины. Мы добавили "Sponge" --- механизм загрузки из Сети недостающих данных по мере необходимости --- запрос может сам добавить в базу недостающие данные или обновить устаревшие. Мы очень аккуратно встроили SPARQL в SQL, так что SPARQL-запрос может вызывать встроенные функции и хранимые процедуры SQL, и с другой стороны он может быть использован в качестве подзапроса в SQL-запросе или в теле хранимой процедуры. Более того, запрос может быть выполнен не только через SPARQL web service endpoint, но и через ODBC/UDBC/IODBC/JDBC. Мы поддерживаем мощный полнотекстовый поиск в SPARQL.
Что действительно интересует пользователей? Очень популярными оказались запросы типа DESCRIBE. Это полностью разошлось с прогнозами, согласно которым DESCRIBE должен был быть мёртвой функциональностью, никому не нужной как минимум до тех пор, пока в спецификацию не добавлено подробное описание ожидаемого результата. Пришлось внепланово заняться специальной оптимизацией таких запросов. Очевидно, большому количеству приложений надо "рассказать хоть чего-нибудь на заданную тему". Кроме того, очень востребованным оказался ещё один тип запросов, потребовавший расширения не только интерпретатора, но и протокола SPARQL --- "верните хотя бы начало ответа на вопрос, но за ограничнное время". Такие запросы позволяют интерактивным приложениям оперативно получать подсказки для пользователя, эскизы отчётов, а также необходимую для некоторых интерфейсов оценочную статистику "много-мало" (например, чтобы выбрать тип представления по умолчанию или вовремя попросить пользователя расширить или сузить поиск). Квалифицированные пользователи часто используют "низкоуровневый" веб-интерфейс, вводя запросы простой статистики (например, суммы чего-нибудь по странам, отсортированные по значению или по имени страны или по другой статистике) и указывая, что результат должен импортироваться в электронную таблицу.
(Необходимое уточнение. С тех пор поведение агентов существенно изменилось, как показывает анализ активности пользователей в работе Knud Möller, Michael Hausenblas, Richard Cyganiak, Siegfried Handschuh and Gunnar Grimnes. Learning from Linked Open Data Usage: Patterns & Metrics. Web Science Conference 2010)
(Ранее этот текст обитал на http://webofdata.ru/LOD_infrastructure_experience , перенесён оттуда по просьбе редакторов webofdata.ru)
| Иван Николаевич Михайлов | |
| Ivan Mikhailov | |
| Род деятельности: |
программирование |
|---|---|
| Роль участника: | |
| Основной раздел: | |
| Гражданство: | |
| Сайт: | |
| Nickname | |
