LOD как неизбежное добро
Идея
Проект LOD — Linking Open Data — объединяет желающих сделать свои данные общедоступными. Тимоти Бернерс-Ли предложил для этого очень простые правила:
- Разнообразные вещи и понятия «именуются», и эти имена суть строки синтаксиса URI.
- Где только можно, URI начинаются с http://..., чтобы получить информацию о вещи можно было простым вводом её имени в адресную строку браузера.
- Если клиент запрашивает URI и при этом может принимать данные в виде RDF, надо дать ему эти данные и пусть он сам решит, что дальше с ними делать, в том числе, как их показать пользователю. Если сайт хранит достаточно много данных и если есть техническая возможность, то желательно предоставить возможность выборки этих данных стандартными средствами и в стандартных форматах (например, используя язык и протокол SPARQL)
- Описание одной вещи или понятия не должно быть изолированным и самодостаточным, вместо этого оно может содержать ссылки на связанные понятия, опять же в виде URI, по данным можно «бродить» точно так же, как по страницам Сети.
Сеть Linked Data можно представить себе как тень, которую реальные вещи, взаимосвязанные в реальном мире, отбрасывают в Интернет, и связи между вещами видны как связи между ресурсами в Сети. http://dbpedia.org/resource/Moscow не является столицей http://dbpedia.org/resource/Russia , но связь dbpedia-owl:capital между двумя этими ресурсами описывает реальные город и страну, а схожая связь с http://dbpedia.org/resource/Tsardom_of_Russia напоминает о реальной истории. Программа, которая умеет получать из Сети документы, может таким образом накапливать факты о реальности.
Человеку неудобно читать «сырые» данные в формате RDF, в них могут быть смешаны совершенно разношерстные факты, большая часть которых в текущей момент ему не требуется (а часть и никогда не потребуется, скажем, описание вещи на китайском, если он не знает китайского). Избыточность данных не важна. Важно, что эти данные доступны, и нужная их часть может быть отобрана для дальнейшей обработки. Веб-страницу удобно читать, но её удобно только читать, и только человеку, и только одну страницу в один момент. Если человеку понадобится свести воедино данные, опубликованные на сайте в виде тысячи веб-страниц, то ему понадобится или неразумно много рабочего времени или некая специально для этого написанная нетривиальная программа. В то же время данные из тысячи RDF-документов могут быть обработаны стандартными (и потому очень дешёвыми) программными средствами: в RDF данные не перемешаны со всевозможными «декорациями» и текстами, их не надо выковыривать из смеси с текстами, элементами вёрстки, скриптами и прочим. Более того, в RDF кроме данных о вещи могут содержатся связные «метаданные» об этих данных, таким образом, в формате RDF могут быть представлены знания.
Вводная статья специального выпуска IJWIS даёт хороший обзор истории и текущего состояния Linked Data, равно как и хорошо подобранную библиографию.
Критика любой новой идеи, любого нового проекта, должна рассмотреть два вопроса: "а надо ли это" и "а это ли надо". Поскольку критики произошли от обезьян примерно в то же время, что и авторы, к I веку до н.э. они накопили большой опыт, и Марк Витрувий Поллион успешно его обобщил применительно к архитектуре. Его "формулой" и воспользуемся, благо архитектура ПО называется так вовсе не случайно.
Вспоминая Витрувия — Польза
Общеизвестно, что структура общества определяется технологическим уровнем. Нам со школы разжёвывали, как рабы были рентабельны, пока они нуждались только в дешёвых инструментах, и убытки от износа большого количества инструмента с лихвой перекрывались бесплатностью рабочей силы. С появлением более эффективных и дорогих инструментов рабство стало, мол, менее рентабельным, и стал формироваться феодализм. (Почему-то в школе не приводили в пример секс-индустрию, где инструмент не требуется, и рабство встречается до сих пор.)
«Школьная» версия этой теории на практике не применима: она не позволяет делать каких-либо прогнозов, а хоть и бы позволяла — не каждый день инженеру надо писать план работ по смене общественного строя. Куда интереснее то, что часто нет явной зависимости между научной новизной или техническим совершенством новинки и её влиянием на общество, а само влияние непредсказуемо. Из нескольких одинаково интересных для любого корабела открытий Архимеда правило рычага стало общеупотребительным немедленно, «закон Архимеда» о поведении тела в жидкости не получал практического применения 1700 лет(!), а остойчивость шарового сегмента была фактически переоткрыта заново. Иногда мелочь меняет цивилизацию. Подъёмник в виде корзины на верёвке известен любому дикарю, и тем более любому строителю, но только изобретение надёжного аварийного тормоза сделало лифт популярным и привело к развитию высотного строительства. Прогресс в селекции почтовых голубей сделал возможными международные финансовые кризисы, так как позволил Reuters наладить связь между биржами и это усилило позиции спекулянтов. Никакой корреляции между научной ценностью, прибыльностью для изобретателя и воздействием на общество.
Вопрос: как всё же предсказать успех или забвение новой технологии? В общем случае, кажется, никак. В узкоспециальном случае информационных систем, самые успешные проекты последнего времени показывают несколько неожиданных тенденций: они дают «второе рождение» достаточно старым идеям, они строятся по модели «базара», а не «собора», их качество обеспечивается в большей степени частым обновлением, нежели тщательным «замораживанием» архитектуры, они несут расходы на создание «экосистемы» вместо традиционных затрат на рекламу.
Примеры по пунктам
«Второе рождение» достаточно старым идеям
До WWW уже было множество практических реализаций гипертекстов, а самой идее глобального гипертекста к тому моменту было почти полвека. Масштабируемость Google обеспечивается использованием технологии древней лисповой технологии Map/Reduce, ущербность которой для больших баз данных известна давным-давно — а ведь работает, для данного конкретного случая такие особенности как масштабируемость и плавность деградации перевесили недостаток функциональности. Успех Skype и Linux тоже не определён некими новыми уникальными для этих проектов идеями (хотя и идей хватает).
«Базар», а не «собор»
Так Торвальдс сравнил разработку Linux и FreeBSD. Все детали больших и быстро развивающихся проектов не могут быть определены из одного центра, часто выбор осуществляется «естественным отбором». Как результат, даже лучшие из «соборов» оказываются нишевыми продуктами, а «базары» захватывают рынки. Linux и FreeBSD, WWW и MSN, Wikipedia и Britannica или Encarta — примеров предостаточно. Кстати, если исходная идея стара и достаточно известна, то это оказывается доводом в пользу «базара»: у «кривой обучения» новых участников нет «ступеньки» около нуля, то есть нет нужды в длительном изучении некоей «азбуки» перед тем, как «вступить в игру».
Частое обновление вместо «замораживания»
В обычных проектах архитекторы тщательно урезают самостоятельность программистов, составляя детальные спецификации как на уже разрабатываемую функциональность, так и на её будущие расширения. Это имеет смысл, так как иногда позволяет уменьшить число версий за счёт увеличения числа обновлений в каждой версии. Но когда новая идея настолько ценна, что пользователи не очень привередничают по части качества, версии выдаются так часто, как только позволяет цикл тестирования. Доходит и до крайностей. Очень многими продуктами было очень тяжело пользоваться до версии примерно 3.1415, и тем не менее они были «like sex» («When it's good it's very-very good and even if it's bad it's much better than nothing» — L. Torvalds). Не забывая про такие древности, как «форточки» 3.1 и «колхозные форточки» 3.11 — первые действительно живучие версии Windows, помяну один узкоспециализированный продукт поновее — XML Spy. Первые версии были ужасны. Программа умирала примерно раз в час, «сохраняйтесь чаще» из общего лозунга стало спинномозговым рефлексом. Тем не менее, в промежутках между фатальными ошибками она сберегала мне столько нервных клеток, что отказываться от неё я категорически не хотел, а быстрое обновление устранило детские болезни.
Есть и ещё одна причина частых обновлений для «прорывных» продуктов. Когда новый рынок только открывается, он ещё не сегментирован вдоль и поперёк, и на один продукт «набрасываются» самые разные пользователи. Они тянут разработчиков в разные стороны, требуя очень много принципиально разных довесков и улучшений, каждый для себя. Иногда запросы просто противоречат друг другу. В такой ситуации разработчики вынуждены маневрировать даже в случае закрытого коммерческого продукта, уж не говоря про открытый «базар».
«Экосистема» вместо рекламы
Лучшая реклама — довольный пользователь, нахваливающий продукт друзьям. Лучшая техподдержка — сторонний разработчик, поставляющий продукт совместно со своим кодом. Когда новизна и качество продукта говорят сами за себя, затраты на традиционный маркетинг «сами собой» падают, а затраты на поддержку пользователей «сами собой» растут. В самом деле, сбывать неходовую или заведомо низкокачественную продукцию может только квалифицированный продавец, но чем удачнее работает разработчик, тем легче жить продавцу. Это не значит, что качеством обеспечения продаж можно пренебречь, это значит, что при подходящей форме кривых спроса и предложения можно грамотно экономить на расходах, начиная с урезания дорогой рекламы.
Поскольку у нас в стране хорошо учили теоретическому программированию, но технологии программирования учили плохо, а отраслевой «микроэкономике» не учили вовсе, я вынужден сделать совершенно не лирическое отступление, и объяснить, как это затраты перераспределяются «сами собой», что стоит за этой фигурой речи. Но чтобы отступление не выросло в самостоятельную статью, я без разъяснений использую термин «consumer surplus» и сопутствующие ему.
В пользу инвестиций в «экосистему» играют сразу несколько факторов, усиливающих друг друга. Малое число конкурентов приводит к тому, что общая кривая предложения по рынку оказывается изрядно ступенчатой. Если я хочу купить шурупы и обзваниваю оптовые фирмы, то каждая фирма-продавец предложит мне график цены от объёма, являющийся некоторой ломаной линией. Выбирая для каждого объёма наинизшую по рынку цену, получаем ломаную с куда большим числом вершин, ведь продавцы не сговариваются между собой, начиная с каких именно сумм или физических объёмов они начинают делать те или иные скидки, разных пороговых сумм оказывается много. Продавец уникального продукта находится в существенно ином положении: сколько он попросит, столько товар и стоит. Купит ли покупатель этот товар по этой цене — другой вопрос, но покупатель не купит дешевле. В то же время кривая спроса по всему рынку по-прежнему является гладкой — покупателей-то много, их индивидуальные ломаные при суммировании сглаживаются. Даже если все без исключения индивидуальные графики спроса — ступеньки, вроде «куплю ровно одну копию себе и только не дороже $130», их сумма сгладится, так как кто-то согласен только на $50, а кто-то будет рад выложить и $500. И вот вам результат: гладкий спрос против ступенчатого предложения. Более того, частое обновление приводит к тому, что разработчик ПО не в состоянии качественно стратифицировать рынок, он просто не успевает для каждой версии создать множество вариантов по-разному усечённой функциональности за разную цену. Это редко выпускаемую OS можно продавать в семи разных коробках; прорывной продукт может быть, например, усечённым бесплатным, полным платным, ну и всё, и на этом маркетинговые изыски обрываются. Это приводит к недопустимо большому в других случаях уровню «consumer surplus». Но для покупателя не имеет значения, почему разработчик стал для него «добрым Дедушкой Морозом», и рад ли разработчик этому. Покупатель «избыточно доволен» и это превращает его в «рекламного агента», он хвастается удачным приобретением. Кроме того, он согласен потратить немного своего времени в надежде, что тогда он в будущем получит новые «подарки». Это и есть основа «экосистемы».
В отличие от предыдущих пунктов я даже не буду называть конкретные примеры. Множеству программных продуктов сопутствуют форумы пользователей, почтовые рассылки, всяческие багзилы, плагины сторонних поставщиков и т.п. Полностью обнулить consumer surplus не сможет даже гениальный продавец, но у некоторых продуктов он намного больше среднего по индустрии, и пользователи любят эти продукты.
И вот тут в случае действительно необходимого обществу проекта замыкается положительная обратная связь. Члены «экосистемы» начинают вносить заметный вклад в разработку продукта, и она начинает дрейфовать в сторону «базара». Это увеличивает частоту релизов, что, в свою очередь, не позволяет урезать consumer surplus, а зачастую и приводит к его росту. Экосистема продолжает расти, часто даже после исчезновения исходного разработчика. Вспомните Apache.
Итак, похож ли LOD на полезный проект?
Применим наши критерии к LOD.
Нет, не так. Слишком официозно, и вообще это мои субъективные критерии, которые за уши можно притянуть к чему ни попадя, благо проверяемых численных характеристик они не дают.
Применю-ка я мои критерии к LOD.
LOD даёт «второе рождение» идеям безусловно «достаточно старым». Буш, Минский, Уинстон — это очень серьёзный фундамент, наши учителя учились на их книгах, мы выросли в культуре, пропитанной этими идеями. LOD строится по модели «базара», а не «собора», каждый вносит что-то своё, и даже признанные лидеры проекта могут только вдохновлять, но не администрировать «движение снизу». Качество обеспечивается без высеченной в камне архитектуры, наоборот, проект изначально снабжён «гибкими сочленениями». LOD почти не несёт затрат на рекламу, зато общество инвестирует в «экосистему». Всё это — многократно проверенные практикой признаки того, что затея небесполезна.
Но есть и ещё один признак, важнее всех предыдущих. Наличие прямо сейчас работающих приложений для конечного пользователя, использующих данные из LOD даже если пользователь про это не знает и знать не хочет. Вы же не знаете состав чернил в вашей шариковой ручке. Точно так же вы не знаете, как Amarok узнаёт, кто автор песни, которую вы спиратили из сети, как она называется, и как выглядит обложка альбома. И не узнаете, как система бронирования авиабилетов с первой попытки угадает самую подходящую для вас стыковку. Без шумихи, без воплей «это модно», без давления со стороны государства LOD становится частью «повседневной» технической культуры. А это — надолго.
Вспоминая Витрувия — Прочность
Внешние требования к «толстой» программной системе всегда содержат несколько «типовых» разделов, помимо требований, специфических для предметной области и конкретной задачи. Мне хотелось бы отметить, как меняется доля общих требований в общем объёме требований, по мере охвата системой всё большей предметной области. Она не остаётся постоянной.
Специфические требования к обычной программе растут как снежный ком (каждое новое вводимое понятие требует нового программного кода и для него заказчик должен сформулировать требования), в то время как «типовые» разделы меняются слабо. В случае системы управления базой знаний, рост универсальности, наоборот, вычёркивает специфические требования, одно за другим. Это связано с тем, что заказчик обычного приложения знает, как он намерен его использовать, а заказчик базы знаний — нет.
Скажем, заказчик системы резервирования авиабилетов намерен очень часто продавать билеты пассажирам, и иногда принимать их обратно, и ещё реже менять расписание, и он требует, чтобы система это делала. Расширяя систему модулем бронирования мест в отелях заказчик намерен дополнительно предоставлять клиентам обзоры отелей, выбирать и резервировать номера и т.п., и он опять же требует это в дополнительных разделах документа. Томик внешних требований сначала пухнет, потом начинает размножаться почкованием. В то же время формулировки общих требований, вроде масштабируемости и отказоустойчивости, остаются достаточно краткими и становятся незаметными на фоне остального гроссбуха.
Заказчик очень узкоспециализированной базы знаний тоже хорошо представляет себе все её конкретные приложения. Затруднительно использовать «отдельно стоящий» каталог полиморфонуклеарных лейкоцитов для чего-либо, кроме работы с этими самыми лейкоцитами. По мере расширения предметной области определённость исчезает. Разнообразие данных и лёгкость их связывания дают простор для фантазии. Например, старая «карта» BIO2RDF показывает десятки больших коллекций ресурсов, объединённых общей идеологией и допускающих (а скорее даже поощряющих) совместное использование. Число различных сценариев доступа к этим данным очевидно больше, чем может быть описано в одном документе. А ведь это лишь один узкопрофессиональный закоулок на карте связей LOD. В предельном случае LOD, специфических «отраслевых» требований нет вовсе. Специального внимания требуют некоторые типы данных и некоторые типы запросов над ними, например геометрические объекты и пространственные выборки, но это достаточно низкоуровневые и достаточно хорошо известные проблемы. Его Техническое Величество a.k.a. Главный Архитектор может смело свалить такую мелочь на подчинённых и сконцентрироваться на обеспечении «запаса прочности».
Полнота доступного набора типов данных
На первый взгляд, доступных данных хватает только для достаточно детских задач. В нашем распоряжении только графы с вершинами трёх сортов и дугами разных типов. Тем не менее, никто не заставляет хранить данные строго в том же представлении, в котором они готовятся к вводу и выводу. Внутри хранилища мы видим как минимум стандартные типы SQL, а чаще — все типы XML Schema или ещё более полную коллекцию базовых типов. Кроме того, графы «укладываются» в реляционные СУБД с характерным для индустрии «качеством сервиса». Так что нехватка базовых типов обычно означает недостаточно полное разбиение исходных знаний на отдельные утверждения.
Должен сознаться, что я регулярно ворчу про нехватку в модели RDF встроенной поддержки физических величин. Число 5.12 может быть литералом, а величина 5.12 Ампер на квадратный миллиметр — нет, можно только записать её строкой своего нестандартного формата и использовать исключительно для обмена между своими приложениями. Кошмар. В то же время я прекрасно помню судьбу языка, который должен был, по мнению его авторов, очень понравиться физикам и инженерам как раз хорошей типизацией чисел. Ada. Ну и где та любовь? Так что пусть всё идёт само собой, а запись физических величин при необходимости будет уточнена ровно там, где это всерьёз понадобится. Опыт имеется — «проблема 2000». Много лет назад авторы программ прекрасно понимали, что срок жизни их творений ограничен, и неплохо было бы использовать четыре цифры вместо двух, однако теперь мы знаем, что «двузначное» решение было экономически правильным. Когда компьютеры были большими, а слова в них короткими, цена хранения байта была много больше нынешней. К непосредственно сэкономленным на хранении суммам добавились банковские проценты, набежавшие на них за предшествовавшие Y2K десятилетия, и полная сумма экономии существенно превысила все разовые затраты на связанные с Y2K мероприятия.
Ещё одним поводом для ворчания является слабая поддержка географических и прочих пространственных данных, а также серий данных. Но ведь все предшествовавшие RDF «универсальные» форматы обмена данными обладали ровно тем же самым недостатком, и это никого не останавливало. Простым непрофессиональным приложениям хватит и имеющихся возможностей, а индустриальные системы смогут использовать любой «неродной» формат только для ввода-вывода, в лучшем случае для запросов «рядом» с основными базами данных. Возьмём, к примеру, геоданные. Имеющиеся публичные ресурсы содержат множества географических точек либо как пары свойств «широта» и «долгота» либо как «координаты» в виде пары значений через пробел. И, в общем-то, всё, единичными случаями более сложных структур можно пренебречь. Этого хватает, чтобы, скажем, ограничить поиск пивнушек ближайшим к пользователю городом и показать подходящий фрагмент карты Google или Yahoo c иголками-ссылками. Теперь представим себе, что кто-то выложил для скачивания в формате RDF все имеющиеся индустриальные геоданные по всему миру. Воображение рисует райскую картинку — любой желающий сможет сделать для своего приложения «географический атлас» с только теми деталями, которые ему нужны, не захламляя карты всем остальным. Более близкое знакомство с предметом показывает, что у этого «любого желающего» не найдётся ни подходящего для таких работ датацентра, ни денег на покупку соответствующего софта, ни квалификации, чтобы написать свой собственный софт. Даже для простых работ «сырые» входные данные запросто могут измеряться петабайтами, и даже очень простой и потому очень популярный формат ESRI предусматривает тридцать с лишним типов базовых объектов. Случайным разработчикам тут просто нечего делать. С сериями данных дела обстоят ещё хуже, там иногда лень считать объёмы в байтах, и считают их сразу в футах библиотеки стриммерных лент. Sun StorageTek SL8500, скажем, даёт плотность хранения 1.7 петабайта на 37.5 люймов длины коридора; совсем нетрудно считать, какое здание строить. И тут самое место воткнуть следующий подзаголовок.
Масштабируемость по объёмам обрабатываемых данных
Единственный «общественный строй», обеспечивающий гибкий доступ к петабайтным и ещё большим хранилищам для «простых смертных» — федерация «владельцев недвижимости», связанных дорогими «толстыми» каналами между собой и предоставляющих «высокоуровневые» сервисы для находящихся в Сети «относительно лёгких» клиентов. LOD хорошо сочетается с таким стилем обработки данных благодаря технологиям Federated SPARQL и RDB2RDF. Первая из них позволяет выполнить разные фрагменты запроса на разных машинах, «поближе к данным». Вторая — использовать имеющиеся базы данных как основу виртуального хранилища RDF: SPARQL запрос к якобы хранящимся в хранилище графам RDF транслируется в SQL-запрос к действительно существующим реляционным таблицам.
Нельзя сказать, что SPARQL-доступ является самым производительным. Наоборот, потребовались большие усилия для того, чтобы сократить до небольшого константного множителя разрыв с лидерами индустрии — классическими реляционными СУБД с классическими клиент-серверными соединениями вроде ODBC. Даже для самых вылизанных систем SPARQL-запрос через HTTP обходится дороже SQL-запроса через ODBC, причём дороже и по времени компиляции запроса и по накладным расходам на передачу одной строки ответа. Но это разумная плата за то, что SPARQL-запросы к различным системам намного легче унифицировать, чем SQL — внутренние детали каждого хранилища «маскируются» дополнительным уровнем абстракции в RDB2RDF. При этом «закон Мура» целиком на стороне LOD — выраженная в долларах разница в цене SPARQL- и SQL-запроса падает и будет падать, а цена конкурирующего метода «ручной» унификации хранилищ на уровне схемы СУБД будет только расти с ростом сложности этих схем и числа хранилищ.
Не надо забывать и про хвост распределения — кроме немногочисленных сверхбольших хранилищ есть тысячи баз данных поменьше, десятки миллионов небольших хостов, в десятилетней перспективе — миллиарды «интерактивных» конечных пользователей и ещё лет через десять — десятки, если не сотни миллиардов мелких устройств, и все они в той или иной мере будут источниками данных. Не породит ли идеология LOD узкие места в соединяющей их Сети? Пока предпосылок для этого не видно, сообщество LOD последовательно сталкивается с теми же проблемами, что возникали при росте WWW, только с разницей в пятнадцать лет. Если они были решены тогда, стыдно будет не решить их сейчас, с готовыми рецептами и лучшей инфраструктурой. Вспоминается одиннадцатилетней давности шутка одного из инженеров мэрии Рима: «мы не переживаем по поводу проблемы-2000, ведь мы уже успешно решили проблему-1000 и проблему-0».
Масштабируемость по объёму схемы обрабатываемых данных
С ростом LOD растут разнообразие публикуемых данных, число «перекрёстных» связей, превращающих эти данные в знания, число вариантов, которыми одни и те же знания описываются в разных источниках. Неограниченный рост по любому из этих трёх направлений способен уподобить LOD Вавилонской башне, тем более что число понятий даже одной большой современной онтологии заведомо больше числа известных древнему каменщику (цензурных) слов. SPARQL-процессор может скрыть разницу во внутреннем представлении данных между разными сервисами, но не более того: если сервисы будут использовать разные онтологии, то их клиенты будут вынуждены или становиться «полиглотами» или урезать «круг общения» или общаться через сервисы-«переводчики».
Пока дела идут неплохо. Лень в очередной раз оказывается двигателем прогресса. В большинстве случаев незачем создавать новую онтологию, если кто-то уже сделал то, что надо, или «почти то». В результате удачные онтологии используются всё большим числом сервисов и клиентов, по тем же причинам и точно так же, как в естественном языке удачная научная терминология со временем используется во всё большей доле текстов по данной тематике. При этом «широкая публика» использует простые онтологии, злоупотребляя полнотекстовым поиском и эвристиками на стороне сервиса, а узкопрофессиональные приложения строят сложные запросы со строгим использованием точных понятий.
В LOD онтологии публикуются преимущественно в формате OWL, который хорошо подходит для подобных «расхождений во вкусах». OWL удобно описывает не только стройные иерархии понятий со всё большими «подробностями» от уровня к уровню, но и многочисленные синонимы одного и того же понятия в разных источниках знаний и неполные описания терминов и прочие «проявления беспорядка».
Два предыдущих абзаца могут вселять оптимизм, для чего и были написаны, но не могут служить обоснованием надёжности. Технические решения должны «подпираться» техническими же доводами, а не только психологическими этюдами про лень и прогресс. Архитектор, считая прочность балкона, не должен предполагать, что на него будут в основном ходить курить, а в однокомнатной квартире вряд ли живёт больше двух курильщиков; он должен посчитать, сколько человек может набиться туда битком, прибавить массу снега да ещё на всякий случай помножить суммарный вес на четыре. Приложение содержит занудный подсчёт, результат показывает, что способность человечества «умножать сущности сверх необходимости» уступает и будет уступать его же способности строить мощные серверные.
Многие ресурсы LOD представлены только в виде доступных для загрузки файлов или являются частью обычных веб-страниц, например в случае RDFa+HTML. Очевидно, в этом случае размер схемы является проблемой только лишь клиента — веб серверу совершенно все равно, какие именно байты передавать.
Масштабируемость по числу запросов
Казалось бы, сильно распределённая структура сервисов LOD должна вести себя при росте нагрузки не лучше, но и не хуже сервисов традиционной части Сети. На практике это так только для тех ресурсов LOD, что являются просто статическими файлами или генерируются аналогично традиционным веб-отчётам из баз данных. Если сравнивать SPARQL-сервисы и сложные веб-сервисы, то новые технологии создают существенно новые трудности, потому что SPARQL запросы «разнообразнее» средних запросов к динамическим веб-страницам. Вглядимся в эту разницу получше.
Большинство HTTP-запросов к обычным веб-серверам приводят к выдаче достаточно статичных данных — страниц или графики, идентифицируемых константами, обычно с известным временем последнего обновления и нередко с известной частотой обновления. Динамический контент либо подгружается в виде отдельных небольших ресурсов, либо встраивается в шаблон страницы, но в любом случае он зависит от небольшого числа жёстко заданных параметров. Это позволяет организовать эффективное кэширование и статических и динамических страниц как на стороне клиента, так и на стороне сервера, и протокол HTTP всячески поддерживает это. Решение о кэшировании принимается по результатам всего лишь сравнения одной строки — адреса ресурса — с имеющимися в кэше, плюс сравнения пары отметок времени и проверки пары флагов. Даже в случае кэширования на стороне сервера кэш может быть выполнен на отдельно стоящих машинах, не связанных с первоначальным генератором страниц. Хорошим примером служит Википедия, у которой число squid-машин существенно больше числа серверов вики. Да, страницы Википедии обновляются часто и непредсказуемо, но активность читателей все равно намного превосходит активность писателей и пользователей нетривиальных сервисов.
Кэшировать SPARQL-запросы к публичному сервису обычно очень тяжело, тяжелее, чем SQL-запросы в корпоративной СУБД. В корпорации используется ограниченное количество приложений, и при этом многие работы целиком выполняются на сервере в виде хранимых процедур, так что клиент отправляет по сети не многочисленные сложные SQL-запросы, а ограниченное количество вызовов хранимых процедур. Кроме того, широко используются параметрические запросы, повтор которых не приводит к вызову SQL-компилятора, и кэшированные временные таблицы, позволяющие не повторять некоторые фрагменты вычислений. Открытая всему миру точка веб-доступа к SPARQL получает куда более разнообразные запросы, что приводит к падению частоты «попаданий в кэш» до уровня, когда на обслуживание кэша уходит больше времени, чем он экономит.
Как результат, в пересчёте на один запрос клиента сервисы LOD требуют существенно больше ресурсов, чем традиционные веб-сервисы. С другой стороны, при правильном проектировании представления знаний они могут быть экономнее в пересчёте на строку данных, действительно необходимых пользователю. Ответ сервиса SPARQL не утяжелён версткой и обычно не сопровождается всяческой декоративной графикой. Более того, он может быть существенно короче даже «голого текста», сформированного традиционным сервисом, потому что аккуратно сформулированный SPARQL-запрос может отсечь лишние данные на стороне сервера более тщательно, чем традиционная примитивная фильтрация ответов по значениям некоторых полей.
Можно ожидать, что SPARQL-сервисы LOD будут требовать заметно больших вычислительных ресурсов, чем традиционные веб-ресурсы, но не большего трафика.
«Наивный» подсчёт числа запросов равно осмысленен для обычного гипертекста и для статических ресурсов LOD, но не для SPARQL-сервисов: трудоёмкости разных запросов SPARQL различаются на много порядков (и почти не коррелируют с длиной запроса или ответа). При этом на стороне серверов требуется защита от умышленной или случайной перегрузки в виде черезчур сложных запросов. Возникает техническое противоречие: сервер должен ограничивать сложность запросов, чтобы защитить себя и продолжать выполнять простые запросы, и сервер не должен ограничивать сложность запросов, потому что иногда клиенты задают их не по злому умыслу и не по неграмотности, а потому что им действительно надо получить нетривиальные ответы. Противоречие может быть разрешено многими способами, в том числе разделением на бесплатный сервис с жёсткими ограничениями и платный с ослабленными, созданием отдельного неинтерактивного сервиса, который заносит SPARQL-запросы в журнал, и выполняет их в часы наименьшей загрузки в пакетном режиме, сдачей в аренду виртуальных машин с «персональными» копиями сервиса. Первые два способа хорошо известны и традиционной сети, последний стал практичным только с появлением настолько унифицированного представления данных, как RDF и настолько высокоуровневого языка запросов, как SPARQL: для традиционных систем время обучения работе с подобной виртуальной машиной оказывается недопустимо велико.
Средняя наработка сервисов на отказ
Как раз сейчас мы завершаем тестирование OpenLink Virtuoso Cluster Edition, по его итогам можно будет дать не проектные, а экспериментальные оценки MTBF, времени простоя и стоимости его уменьшения. Как будут готовы — впишу сюда. Ну а конкуренты пусть хвалят себя без моей помощи.
Устойчивость к стрессовым нагрузкам
Многие помнят, как в день удара по WTC и Пентагону все крупнейшие новостные сайты или «лежали» или были вынуждены временно заменить обычный ресурсоёмкий динамический контент простыми статическими страницами. Более частым проявлением проблемы является «слэшдот-эффект»: новостной сайт с большой аудиторией обращает внимание публики на небольшой, но интересный частный ресурс, после чего тот «падает», иногда вгоняя в гроб и соседей по хостингу. Как LOD будет вести себя в подобных ситуациях? Общего ответа нет, как и в случае традиционных сайтов всё будет зависеть от владельцев конкретных сервисов. Избыточная мощность не бывает бесплатной, и владелец сайта должен сам выбирать между удорожанием оборудования/хостинга и риском остаться без сервиса как раз тогда, когда это нужно больше всего.
В идеальном мире устойчивость сообщества LOD обеспечивалась бы не только усилиями владельцев сервисов, но и «благотворительностью» клиентов, точно так же, как воспитанные пользователи BitTorrent поддерживают устойчивость источников данных, «оставаясь на раздаче» и в процессе получения нужных данных и некоторое время после. Проблема в том, что большая часть ресурсов LOD имеет очень малую длину, накладные расходы на «умное» соединение легко могут превышать объём полезных данных, и оно должно использоваться только в исключительных случаях, которые надо ещё суметь вовремя распознать на стороне клиента. Поэтому более вероятна «взаимопомощь» между владельцами сайтов. Если я знаю, что большая популярность моего сайта приводит к слэшдот-эффекту, то вместе с содержащими ссылки ресурсами я могу передать клиенту и самые популярные фрагменты данных, находящихся по этим ссылкам, предотвратив часть запросов к ним. Для представления такого «RDF-ресурса с приложениями» хорошо подходит недавно появившийся формат TriG.
Максимальная длина жизненного цикла данных
Не знаю. Честно. Все стараются продлить жизнь своих систем, все верят в успех и убеждают в этом окружающих, вот только не всем удаётся. W3C делает, что может, как для обычного веба, так и для семантического, и даже небезуспешно (напр., ушли в прошлое «войны браузеров»), но нельзя надёжно утверждать, что предпринимаемые усилия по наведению порядка и обеспечению своместимости будут достаточны всегда.
«Хочу жить вечно. Пока получается».
С другой стороны, важны не столько шансы на вечную жизнь, сколько гарантии, что время жизни «экосистемы» будет больше срока окупаемости вашего личного проекта. С этим как-то проще.
Вспоминая Витрувия — Красота
(длинное продолжение следует, а пока критикуйте начало)
Благотворительность с целью наживы
(умные люди советуют сначала писать вступление и заключение (в случае диссертации — ещё и отзывы на себя), и фаршировать серединку в последнюю очередь; я так не умею)
Занудное приложение. Максимальный размер онтологии «обо всём», какую могли бы создать люди.
Итак, у нас есть три множителя, произведение которых оценивает сверху разнообразие знаний: число различных видов данных, разнообразие связей, разброс в идеологии представления.
Когда первый множитель достигнет максимума, вряд ли он превысит число слов естественного языка, ведь мы мыслим словами. Пусть будет два миллиона.
Разнообразие связей может, конечно, быть и квадратичным от первого множителя, но на практике оно квадратично от числа очень общих групп типов данных. К тому же общий объём знаний разбивается на области связности. ОК 017-94 перечисляет 24 отрасли науки, очень разных по числу специальностей но, по-моему, общих по одному критерию — учёные разных отраслей обладают сравнимыми словарными запасами, но при этом не понимают друг друга. Я бы взял физику как науку с самым развитым аппаратом для формального описания вещей, число различных единиц СИ как оценку разнообразия связей для одного субьекта (физики любят мерять всё подряд), и помножил на 24. Итого, 30*24=720. Кажется, это действительно оценка сверху, лично я не смогу описать даже самый хорошо известный мне субьект — себя самого в целом — настолько разносторонне, даже если начну с физики (рост, вес) и закончу культурологией, но не буду вводить предикаты для составных связей, таких как «длина моей левой руки» или «имя исполнителя главной роли моего любимого фильма».
Третий множитель самый субъективный, я бы взял религию (пожалуй, самую свободную от естественных ограничений и самую зависимую от культурного контекста область человеческой культуры), и оценил число различных религий, описывающих принципиально разные картины мира. Их десяток, ну уж точно не тысячи.
Перемножая, получаем, что даже самой мощной и универсальной системе хранения знаний, какую люди могут хоть как то использовать, достаточно будет работать с онтологией в 14 миллиардов понятий. Нельзя назвать задачу тривиальной, но уже имеющиеся системы имеют расчётную масштабируемость до петаквадов и экспериментально проверенную до десятков гигаквадов, так что такая онтология могла бы использоваться уже сейчас, занимая приемлемую часть хранилища.
В будущем тоже проблем не будет. Для удвоения объёма такой онтологии понадобилось бы, чтобы каждый из 7 миллиардов ныне живущих людей сделал по два достаточно крупных открытия, на что потребуется очевидно больше времени, чем на удвоение наличных вычислительных мощностей.
—-
P.S. Документ представляет мою личную точку зрения, OpenLink Software, W3C, сообщество LOD и другие организации тут не замешаны.
| Иван Николаевич Михайлов | |
| Ivan Mikhailov | |
| Род деятельности: |
программирование |
|---|---|
| Роль участника: | |
| Основной раздел: | |
| Гражданство: | |
| Сайт: | |
| Nickname | |
