какие существуют api сервисы dataspace
Почему Dataspace?
DataSpace является ведущим оператором коммерческих центров обработки данных в России, обеспечивающим гарантированный уровень услуг и высочайший уровень надежности и безопасности для развертывания критически важной IT-инфраструктуры российских и международных компаний.
Приоритетами DataSpace являются комплексное управление и эксплуатация ЦОД, предоставление услуг колокации премиум-класса, а также обеспечение свободного выбора поставщиков телеком и IT-услуг для обеспечения максимальной непрерывности IT и бизнес-процессов.
DataSpace является ведущим оператором коммерческих центров обработки данных в России, обеспечивающим гарантированный уровень услуг и высочайший уровень надежности и безопасности для развертывания критически важной IT-инфраструктуры российских и международных компаний.
Приоритетами DataSpace являются комплексное управление и эксплуатация ЦОД, предоставление услуг колокации премиум-класса, а также обеспечение свободного выбора поставщиков телеком и IT-услуг для обеспечения максимальной непрерывности IT и бизнес-процессов.
DataSpace является 100% дочерней компанией фонда Russia Partners, дочернего предприятия фонда частных прямых инвестиций Siguler Guff & Company. В состав участников фонда входят глобальные международные инвесторы, крупнейшими из которых являются Европейский банк реконструкции и развития и Международная финансовая корпорация Всемирного банка. Успешное прохождение тщательнейшей финансовой и юридической экспертизы является подтверждением высокой финансовой стабильности нашей компании и жизнеспособности нашей коммерческой модели.
ЦОД DataSpace стал первым объектом, получившим сертификат соответствия стандарту Tier III Gold от Uptime Institute. Это означает, что наш центр обработки данных был спроектирован, а затем построен и испытан с учётом требований параллельного обслуживания инженерной инфраструктуры и эксплуатационной устойчивости объекта. Это очень важная особенность, так как она означает отсутствие простоя оборудования. Соответствие данным требованиям означает, что мы можем, в любой момент времени, изолировать любой элемент критической инженерной инфраструктуры центра обработки данных для его испытаний, технического обслуживания или замены без остановки и отключения оборудования наших клиентов.
В результате успешного прохождения программы сертификации со стороны Uptime Institute мы готовы нести ответственность за убытки наших клиентов на сумму до 10 млн. долларов США. Данные гарантии финансируются в рамках страхового покрытия, предоставленного ведущими международными страховыми компаниями. Столь высокая сумма страхового покрытия была предложена ими после всестороннего аудита нашего объекта, правил и процедур его эксплуатации, а также близкого знакомства со строгими требованиями сертификации на соответствие стандарту Tier III.
DataSpace – самый безопасный и защищённый коммерческий центр обработки данных в Москве. Уровень физической безопасности нашего объекта гораздо выше, чем у любого другого оператора. Мы предлагаем выделенные машинные залы, обеспечивающие высокий уровень защиты размещаемого в них оборудования. Благодаря этому, ваше оборудование будет защищено не только от несанкционированного доступа, но и от любых аварий, пожаров или происшествий на оборудовании других клиентов. Вам будет предоставлена возможность контроля и управления доступом в ваш собственный, выделенный центр обработки данных, надёжно защищённый всеми мерами безопасности, имеющимися на нашем объекте.
По сравнению с другими операторами, DataSpace вкладывает гораздо более серьёзные средства в подбор, обучение и профессиональное развитие нашей команды специалистов, отвечающих за эксплуатацию центра обработки данных. В сочетании с возможностью параллельного технического обслуживания оборудования это сделало нас оператором центров обработки данных с абсолютно безаварийной историей эксплуатации. Помимо того, что наши инженеры регулярно проходят обучение на территории заводов-изготовителей оборудования, мы также постоянно поддерживаем запас компонентов и запасных частей зачастую более крупный, чем на складах самих поставщиков оборудования в Москве.
Platform V Dataspace
Инструмент даёт слой доступа к данным на основе модели данных клиента
Отказоустойчивая и распределенная система для хранения и обработки данных в режиме онлайн, которая хранит данные в оперативной памяти и имеет всю функциональность СУБД
Возможности
Независимость от СУБД, автоматическое формирование и накат DDL-скриптов, поддержка PostgreSQL SE, Oracle, а также встроенной H2 для тестирования на локальном компьютере
Независимость от языка программирования за счёт предоставления Cloud Native протокола для взаимодействия — GraphQL, JSON-RPC 2.0
Поддержка горизонтального масштабирования в контейнерной среде (k8s, OSE)
Поддержка идемпотентности, обеспечивающая защиту от «двойного списания»
Поддержка паттерна физического разделения потоков (CQRS)
Автоматически генерируемые функциональные и unit-тесты, позволяющие протестировать приложение до развёртывания на стендах
Обширный набор метрик для мониторинга производительности
Автоматический DevOps, позволяющий устанавливать новые версии приложений без недоступности
Технологии
Преимущества
Оптимизация Time-2-Market
Широкая функциональность
Стандартизация и снижение рисков
Схема работы
Примеры использования
Разработчик описывает модель данных и с помощью инструмента DataSpace генерирует сервисы для сохранения и поиска данных в БД. Взаимодействие с сервисами происходит через Cloud Native API без требований к использованию конкретного языка программирования или с помощью типизированного Java SDK.
Platform V DataSpace позволяет разработчикам значительно сократить время на разработку бэкенда приложений за счёт решения типовых задач по работе с БД в распределённой среде и обеспечению нужного уровня надежности, а также нивелирует необходимость погружаться в детали работы с БД
Platform V Dataspace
Инструмент даёт слой доступа к данным на основе модели данных клиента
Отказоустойчивая и распределенная система для хранения и обработки данных в режиме онлайн, которая хранит данные в оперативной памяти и имеет всю функциональность СУБД
Возможности
Независимость от СУБД, автоматическое формирование и накат DDL-скриптов, поддержка PostgreSQL SE, Oracle, а также встроенной H2 для тестирования на локальном компьютере
Независимость от языка программирования за счёт предоставления Cloud Native протокола для взаимодействия — GraphQL, JSON-RPC 2.0
Поддержка горизонтального масштабирования в контейнерной среде (k8s, OSE)
Поддержка идемпотентности, обеспечивающая защиту от «двойного списания»
Поддержка паттерна физического разделения потоков (CQRS)
Автоматически генерируемые функциональные и unit-тесты, позволяющие протестировать приложение до развёртывания на стендах
Обширный набор метрик для мониторинга производительности
Автоматический DevOps, позволяющий устанавливать новые версии приложений без недоступности
Технологии
Преимущества
Оптимизация Time-2-Market
Широкая функциональность
Стандартизация и снижение рисков
Схема работы
Примеры использования
Разработчик описывает модель данных и с помощью инструмента DataSpace генерирует сервисы для сохранения и поиска данных в БД. Взаимодействие с сервисами происходит через Cloud Native API без требований к использованию конкретного языка программирования или с помощью типизированного Java SDK.
Platform V DataSpace позволяет разработчикам значительно сократить время на разработку бэкенда приложений за счёт решения типовых задач по работе с БД в распределённой среде и обеспечению нужного уровня надежности, а также нивелирует необходимость погружаться в детали работы с БД
Какие существуют api сервисы dataspace
Оригинал: Michael Franklin, Alon Halevy, David Maier. From Databases to Dataspaces: A New Abstraction for Information Management, SIGMOD Record, Vol. 34, No. 4, Dec. 2005
Аннотация
1. Введение
К сожалению, в современных сценариях управления данными редки случаи, когда все данные могут находиться под управлением традиционной реляционной СУБД или какой-либо другой модели данных или системы. Вместо этого разработчики часто сталкиваются с набором слабо связанных источников данных и поэтому вынуждаются каждый раз решать повторяющиеся низкоуровневые задачи управления данными в разнородных коллекциях. В число этих задач входят обеспечение возможностей поиска и запрашивания данных; соблюдение правил, ограничений целостности, соглашений об именовании и т.д.; отслеживание происхождения данных; обеспечение доступности, восстановления и контроля доступа; управляемое развитие данных и метаданных.
В этой статье мы вводим понятие пространства данных как новую абстракцию управления данными в таких сценариях. В качестве ключевой программы работ в области управления данными мы предлагаем проектирование и разработку платформ поддержки пространств данных (DataSpace Support Platforms, DSSP). Коротко говоря, DSSP обеспечивает набор взаимосвязанных услуг и гарантирует разработчикам возможность концентрироваться на специфических проблемах их приложений, а не на повторяющихся задачах, возникающих при потребности согласованной и эффективной работы со взаимосвязанными, но раздельно управляемыми данными. Свое обсуждение пространств данных и DSSP мы начнем с определения их места в контексте существующих систем.
Рис. 1. Пространство решений управления данными
1.1 Архитектуры управления данными
Измерение «Semantic Integration» («семантическая интеграция») является мерой того, насколько близко могут быть сопоставлены схемы различных источников данных. Другими словами, насколько хорошо соответствуют типы, имена, единицы измерения, смысл и т.д. данных в источниках. На дальнем конце («low») информация о схемах вообще отсутствует. В промежутке между «high» и «low» размещаются различные решения и подходы интеграции данных, основанные на полуструктурированных данных и контролируемых словарях. Это измерение показывает уровень, на котором могут быть обеспечены семантически развитые средства запрашивания данных и манипулирования данными над группой источников данных, причем более высокий уровень интеграции обеспечивает более развитые функциональные возможности.
Как показывает рисунок, традиционные СУБД представляют только одну точку (хотя и очень важную) в пространстве решений управления данными. СУБД требуют, чтобы все данные находились под единым административным управлением и соответствовали единой схеме. В ответ на удовлетворение этих ограничений СУБД могут обеспечить развитые средства манипулирования данными и обработки запросов с понятной и строгой семантикой, а также строгие транзакционные гарантии обновлений, параллельного доступа и долговременного хранения (так называемые свойства «ACID»). Важной точкой на рис. 1 являются «системы интеграции данных». На самом деле, системы интеграции данных и обмена данными традиционно предназначаются для поддержки многих других осмысленных служб в системах пространств данных. Особенность состоит в том, что в системах интеграции данных требуется семантическая интеграция до того, как могут быть обеспечены какие-либо прочие услуги. Поэтому, хотя и отсутствует единая схема, которой соответствуют все данные, система должна знать точные взаимосвязи между элементами, используемыми в каждой схеме. В результате для создания системы интеграции данных требуется существенная предварительная работа.
Пространства данных не являются подходом к интеграции данных; скорее, это подход сосуществования данных. Цель поддержки пространства данных состоит в обеспечении базового набора функций надо всеми источниками данных, а не в их интеграции. Например, DSSP может обеспечить надо всеми своими источниками данных поиск по ключевым словам, аналогично тому, что обеспечивают существующие поисковые системы в десктопах. При потребности в более сложных операциях, таких как запросы в реляционном стиле, анализ данных (data mining) или мониторинг каких-либо источников, можно приложить дополнительные усилия к более тесной интеграции этих источников в инкрементной манере «оплаты текущих счетов» («pay-as-you-go»).
Аналогичная гибкость имеется и в измерении административной близости рис. 1. Если желательно наличие административной автономии, то DSSP не сможет гарантировать согласованность, устойчивость результатов операций обновления и т.д. Для удовлетворения потребности в более строгих гарантиях нужны дополнительные усилия для достижения соглашений между владельцами источников данных и открытия некоторых интерфейсов (например, для протоколов фиксации транзакций).
1.2 План работ в области пространств данных
Оставшаяся часть статьи организована следующим образом. В разд. 2 потребность в системах пространств данных обосновывается с помощью двух примеров. В разд. 3 описываются логические компоненты пространства данных и первая попытка представления архитектуры DSSP. В разд. 4 очерчивается несколько исследовательских проблем, критичных для построения DSSP, и в разд. 5 обсуждается несколько перспектив плана работ. В разд. 6 содержится заключение.
2. Примеры
Управление персональной информацией: Цель управления персональной информацией (Personal Information Management, PIM) состоит в обеспечении простого доступа и манипулирования всей информацией на персональном компьютере с возможными расширениями к мобильным устройствам, персональной информации в Web и даже всей информации, накопленной в течение жизни человека.
Поисковые средства, доступные на десктопах в настоящее время, представляют важный первый шаг для PIM, но они ограничиваются запросам на основе ключевых слов. Наши десктопы обычно содержат некоторые структурированные данные (например, электронные таблицы), и между различными элементами десктопа имеются важные ассоциации. Поэтому на следующем шаге развития PIM пользователю должно быть позволено производить поиск в десктопе более осмысленным образом. Например, «найти список студентов, которые прослушали мой курс по базам данных в прошлой четверти» или «вычислить общий баланс моих банковских счетов». Нам также хотелось бы искать по ассоциациям, например, «найти сообщение электронной почты, которое Джон послал мне в тот день, когда я вернулся в Гавайев» или «выбрать все пробные файлы, имеющие отношение к моей статье на конференцию SIGMOD в этом году». Наконец, нам хотелось бы запрашивать данные об источниках, например, «найти все статьи, в которых я приношу благодарность на предоставление данного гранта» или «найти все электронные таблицы, включающие столбец дисперсии».
В этом примере задействованы следующие принципы пространств данных: (1) средство PIM должно иметь возможность доступа ко всей информации на десктопе, а не к какому-нибудь явно выбранному подмножеству; (2) хотя при управлении персональными данными часто используются данные, интегрированные из нескольких источников, мы не можем считать, что пользователи захотят тратить время на интеграцию. Вместо этого, большую часть времени система будет вынуждена обеспечивать наилучшие из возможных результаты, а более тесная интеграция будет производиться только в тех случаях, когда выгода от нее явно перевесит расходы по времени.
Управление научными данными: Рассмотрим научную исследовательскую группу, работающую в области наблюдений за окружающей средой и предсказаний ее поведения. Они могут осуществлять мониторинг прибрежной экосистемы с использованием метеостанций, сенсоров, установленных на береговых стойках и буях, и удаленных устройств получения изображений. Кроме того, они могут использовать атмосферные и гидродинамические модели, имитирующие прошлые, текущие и будущие условия. Для вычислений могут потребоваться данные и модельные результаты от других групп, обеспечивающих прогнозы речных стоков и океанических циркуляций. Наблюдения и моделирование обеспечивают входные данные для программ, генерирующих широкий диапазон продуктов данных для использования данной группой и другими группами: диаграммы сравнения наблюдавшихся и модельных данных, изображения распределений поверхностной температуры, анимации поступления соленой воды в устья рек.
Такая группа легко накопит миллионы продуктов данных в течение всего лишь нескольких лет. Хотя может оказаться, что для каждого файла кто-то в группе знает, где он находится и что означает, ни один человек не сможет знать ни все хранилище целиком, ни то, что означает каждый файл. Людям, обращающимся к этим данным, в особенности, тем, которые не входят в состав данной группы, понадобится сводный реестр основных атрибутов файлов, таких как период времени, к которому относится данный файл, географический район, высота или глубина, физические параметры (уровень солености, температура, скорость ветра), вид продукта данных (график, диаграмма из изолиний, анимация), предсказание это или ретроспективный прогноз и т.д. Когда интересующие продукты данных обнаруживаются, наиболее важным становится понимание их происхождения, чтобы можно было анализировать и сравнивать продукты: Какая использовалась версия кода? Какая сетка конечных элементов? Каким был временной шаг симуляции? Какой атмосферический набор данных использовался на входе?
Вскоре таким группам потребуется объединяться с другими группами для создания научных пространств данных регионального или национального масштаба. Им потребуется как можно проще импортировать свои данные в стандартных научных форматах и с глубиной детализации (часть файла или несколько файлов), не обязательно соответствующей разделению, использовавшемуся при хранении данных. Пользователи федеративных пространств данных могут захотеть увидеть коллекции данных, принадлежащих разным группам федерации, например, все наблюдения и продукты данных, относящиеся к скорости воды, или все данные за последние два месяца, относящиеся к данному отрезку береговой линии. Для быстрого поиска в таких коллекциях могут понадобиться локальные копии или дополнительные индексы.
Этот сценарий иллюстрирует несколько требований пространства данных: (1) каталог пространства данных; (2) поддержку анализа происхождения данных и (3) создание коллекций и индексов сверх тех, которые поставляются любым участвующим в пространстве источником данных.
3. Пространства данных
3.1 Логические компоненты пространств данных
Рис. 2. Пример пространства данных и компоненты системы пространства данных
Участниками пространства данных являются индивидуальные источники данных: они могут быть реляционными базами данных, репозиториями XML, текстовыми базами данных, Web-сервисами и пакетами программного обеспечения. Они могут храниться или быть потоками данных (локально управляемыми системами потоков данных), или даже сенсорными установками.
Пространство данных должно уметь моделировать любой вид связи между двумя (или несколькими) участниками. В более традиционном варианте мы должны уметь моделировать ситуации, когда один участник является представлением или репликой другого участника, или отображать одна на другую схемы двух участников. Однако нам хотелось бы моделировать намного более широкий набор связей, например, что источник A был вручную произведен из источников B и C, или что источники E и F создавались независимо, но отражают одну и ту же физическую систему (например, ДНК мыши). Связи могут быть даже менее конкретными, например, два набора данных образованы из одного источника данных в одно и то же время.
Пространства данных могут вкладываться одно в другое (например, пространство данных факультета Computer Science вкладывается в пространство данных университета), и они могут перекрываться (например, пространство данных факультета Computer Science может разделять некоторых участников с факультетом Electrical Engineering). Поэтому в пространстве данных должны содержаться правила разграничения доступа. Вообще говоря, в некоторых случаях границы между пространствами данных могут быть плавающими, но мы ожидаем, что в большинстве случаев эти границы будут определяться естественным образом.
3.2 Сервисы пространства данных
Двумя основными службами, которые будут поддерживаться в DSSP, являются поиск и запрашивание данных. В то время как СУБД отличаются улучшенной поддержкой запросов, поиск является основным механизмом работы конечных пользователей с большими коллекциями незнакомых данных. Поиск менее требователен, чем запрашивание данных, поскольку он основан на сходстве, предоставлении конечным пользователям ранжированных результатов и поддержке интерактивного совершенствования, так что пользователи могут исследовать набор данных и инкрементно улучшать свои результаты. DSSP должны позволять пользователям задавать поисковый запрос и итерационно его совершенствовать, если это уместно, до вида запроса в стиле базы данных. Ключевой принцип пространств данных состоит в том, что поиск должен быть применим ко всему содержимому пространства данных, независимо от форматов данных.
Универсальные возможности поиска и запросов должны распространяться не только на данные, но и на метаданные. У пользователей должны иметься возможности нахождения требуемых источников данных и получения информации об их сложности, корректности и актуальности. В действительности, DSSP должны быть также осведомлены о наличии брешей в своем покрытии прикладной области. DSSP будут также поддерживать и обновления данных. Очевидно, что эффекты обновлений будут определяться уровнем изменчивости соответствующих источников данных. Одной из основных исследовательских проблем пространств данных является разработка и обеспечение гарантированной семантики обновлений в разнородной среде с высоким уровнем автономности компонентов.
Другие ключевые сервисы DSSP включают мониторинг, обнаружение событий и поддержку сложных потоков работ. Например, мы можем захотеть произвести вычисление при поступлении новой части данных и распространить результаты этого вычисления в набор приемных источников данных. Аналогично, в DSSP должны поддерживаться различные формы анализа данных.
Не каждый участник пространства данных будет обязательно обеспечивать интерфейсы, требуемые для поддержки всех функций DSSP. Поэтому появится потребность в различных расширениях источников данных. Источник не обязательно будет хранить свои собственные метаданные, поэтому для таких источников нам потребуется независимый репозиторий метаданных. Может потребоваться облечение информации во внешнюю форму на основе источника или его контекста. Например, для списка агенств скорой помощи из Вашингтона может потребоваться явная пометка «Вашингтон», чтобы его можно было объединить с аналогичными списками из Орегона и Калифорнии. Или для научного набора данных может потребоваться наложенная схема. Элементы данных в источнике могут обогащаться аннотациями, рейтингами, ссылками на элементы в других источниках. Для источников, в которых отсутствует собственная служба нотификации, может потребоваться поддержка соответствующего мониторинга.
3.3 Системы пространств данных
Каталог и просмотр: Каталог содержит информацию обо всех участниках пространства данных и о связях между ними. У каталога должна иметься возможность поддерживать разнообразные источники и сохранять информацию об их структуре и возможностях на разных уровнях. В частности, для каждого участника каталог должен включать схему источника, статистические данные, скорость изменения, точность, возможности ответов на запросы, информацию о владельце и данные о политике доступа и поддержке конфиденциальности. Связи могут сохраняться в виде преобразований запросов, графов зависимости, а иногда даже в виде текстовых описаний.
При наличии возможности каталог должен содержать базовый реестр элементов данных в каждом участнике: идентификатор, тип, дата создания и т.д. Тогда в нем можно поддерживать базовую возможность просмотра объединенного реестра всех участников. Хотя интерфейс просмотра не является очень масштабируемым, его можно, по крайней мере, использовать для ответов на вопросы пользователей о наличии или отсутствии элемента данных или определения того, какие участники хранят документы данного типа. Возможности этого интерфейса могут быть расширены с помощью запуска над участниками простых скриптов. Например, вычисление и сохранение для всех элементов данных значения свертки по алгоритму хэширования MD5 может помочь обнаружить дубликаты, хранимые разными участниками.
Поверх каталога DSSP должны поддерживать среду управления моделями, позволяющую создавать новые связи и манипулировать существующими связями (например, объединять или инвертировать отображения, сливать схемы и создавать единые представления нескольких источников).
Поиск и запрашивание: Этот компонент должен обеспечивать следующие возможности:
(1) Запрашивание всего, что угодно: У пользователей должна иметься возможность запроса любого элемента данных, независимо от его формата и модели данных. Сначала DSSP должны поддерживать для каждого участника запросы по ключевым словам. По мере того, как мы получим больше информации об участнике, мы должны постепенно начать поддерживать более сложные запросы. Система должна поддерживать плавное переключение между запросами по ключевым словам, просмотром и структурированными запросами. В частности, при выдаче ответов на запрос по ключевым словам (или на структурированный запрос) должны предлагаться дополнительные интерфейсы запросов, позволяющие пользователю усовершенствовать свой запрос.
(2) Стуктурированные запросы: Запросы в стиле баз данных должны поддерживаться на основе общих интерфейсов (т.е. схем-посредников), обеспечивающих доступ к нескольким источникам, или же они могут адресоваться к конкретному источнику данных (с использованием его собственной схемы) с намерением получения ответов и от других источников (как в системах управления одноранговыми данными Peer-Data Management System). Запросы могут формулироваться на разнообразных языках (и на основе разных моделей данных), и они должны, по возможности, наилучшим образом переформулироваться на другие модели данных и схемы, обеспечивая точные и приближенные семантические отображения.
(3) Запросы к метаданным: В системе должен поддерживаться широкий спектр запросов к метаданным. Должны обеспечиваться возможности (a) получения данных об источнике ответа или о том, как этот ответ был выведен или вычислен; (b) обеспечения временных меток на элементах данных, которые участвовали в вычислении ответа; (c) указания того, какие другие элементы данных в пространстве данных могут зависеть от заданного элемента данных, и поддержки гипотетических запросов (т.е. Что бы изменилось, если бы я удалил элемент данных X?); (d) запрашивания источников и уровня недостоверности ответа.
DSSP должны также поддерживать запросы на установление местоположения данных, ответами на которые являются источники данных, а не конкретные элементы данных. Например, система должна быть в состоянии отвечать на запросы Где я могу найти данные про IBM? или В каких источниках имеется атрибут «salary»?. Аналогично, при наличии XML-документа должна иметься возможность запросить XML-документы с похожей структурой и соответствующие XML-преобразования. Наконец, при наличии фрагмента схемы или описания Web-сервиса должно быть возможно найти в пространстве данных похожие фрагменты.
Локальное хранение и индексирование: В DSSP будет иметься компонент хранения и индексирования для достижения следующих целей: (1) для создания запрашиваемых ассоциаций между объектами данных от разных участников; (2) для совершенствования доступа к источникам с ограниченными собственными средствами доступа; (3) для обеспечения возможности выполнения некоторых запросов без доступа к реальному источнику данных и (4) для поддержки высокого уровня доступности и восстановления.
Средства индексирования должны обладать высоким уровнем адаптивности к неоднородным средам. В качестве входных данных должно приниматься любое элементарное значение, встречающееся в пространстве данных, и должны выдаваться координаты всех объектов данных, в которых имеется такое значение, и роли каждого его вхождения (например, строка в текстовом файле, элемент пути к файлу, значение в базе данных, элемент схемы или тэг в XML-файле). Важными аспектами индекса является то, что, во-первых, он определяет информацию для всех участников, когда некоторые значения входят в несколько источников данных (в некотором смысле, это обобщает идею индексов соединения). По-видимому, для этой цели для некоторого множества значений будут строиться специальные индексы. Во-вторых, индекс должен справляться с разнообразием ссылок на объекты реального мира, например, с различными способами указания компании или человека.
Нам может захотеться кэшировать некоторые фрагменты пространства данных (вертикальные или горизонтальные), чтобы (1) строить на них дополнительные индексы для поддержки более эффективного доступа; (2) повысить уровень доступности данных, хранимых в ненадежных участниках и (3) уменьшить нагрузку запросами участников, которые не могут обрабатывать непредусмотренные внешние запросы.
Компонент раскрытия: Назначение этого компонента состоит в обнаружении участников в пространстве данных, создании связей между ними и оказании помощи администраторам при совершенствовании и усилении этих связей.
Обнаружение участников может происходить в нескольких формах, например, в форме обхода справочной структуры, начиная от корня, или форме поиска координат всех баз данных в корпоративной сети. Компонент должен выполнять начальную классификацию участников на основе их типов и контента.
После раскрытия участников система должна обеспечить среду для полуавтоматического создания связей между участниками и совершенствования и поддержки существующих связей. Этот процесс включает нахождение пар участников, которые, вероятно, должны быть связаны один с другим, и затем предложение связей (например, отображений схем, реплик, связей по включению), которые потом проверяются и уточняются человеком. Наконец, важно то, что компонент раскрытия осуществляет мониторинг содержимого пространства данных, чтобы можно было со временем предложить новые связи.
Компонент расширения источников: У некоторых участников могут отсутствовать существенные функции управления данными. Например, участник может являться всего лишь ведомственным репозиторием документов, единственной службой в котором может являться еженедельное резервное копирование. У DSSP должны иметься средства наполнения такого участника дополнительными возможностями, такими как схема, каталог, поиск по ключевым словами и мониторинг обновлений. Заметим, что может оказаться необходимо обеспечивать эти расширения «по месту», поскольку могут иметься существующие приложения или потоки данных, рассчитанные на имеющиеся форматы или справочные структуры.
Этот компонент также поддерживает информацию с «добавленной стоимостью», сохраняемую DSSP, но не присутствующую в исходных участниках. Такая информация может включать «лексические переходы» между словарями, таблицы трансляции закодированных значений, классификаторы и рейтинги документов, а также аннотации или ссылки, привязанные к наборам данных или контенту документов. Должна иметься возможность распространения такой информации на несколько участников. Например, в базе данных десктопа значительные усилия затрачиваются на построение связей между элементами разных приложений (например, сохранение связей между презентациями, статьями и программами, относящимися к одному и тому же проекту).
Хотя мы полагаем, что DSSP с полным набором служб должны содержать все эти компоненты, мы обращаем внимание, что многие из них могли бы использоваться независимо для достижения некоторого компромисса между расходами и получаемыми преимуществами. Например, возможно, что большой университет вначале сможет себе позволить только сервис каталога и просмотра для пространства данных масштаба кампуса, но и это было бы продвижением вперед от существующей непрозрачности ресурсов. Потом могли бы быть добавлены возможности поиска по ключевым словам в масштабах кампуса или избранных подпространств данных. Важно, что DSSP допускает инкрементное инвестирование, а не представляет собой только монолитное решение. Наконец, хотя мы и не описывали это подробно, мы ожидаем, что DSSP будет включать компонент администрирования и некоторый модуль, поддерживающий «мягкое» восстановление.
4. Исследовательские проблемы
4.1 Модели данных и запросы в DSSP
Ниже уровня модели мультимножества слов в иерархии может располагаться модель полуструктурированных данных, основанная на помеченных графах. Если участник поддерживает некоторую структуру, мы должны иметь возможность формулировки простых путевых запросов или запросов по включению, а может быть, и более сложных запросов, основанных на модели полуструктурированных данных. Задача состоит в том, что если у участника имеется способ естественной интерпретации путевого запросов, то обработчик запросов должен пытаться следовать такой интерпретации.
В иерархии будут присутствовать и другие модели данных: реляционная модель, XML со схемой, RDF, OWL (Web Ontology Language). При наличии некоторой среды ключевая проблема состоит в нахождении методов интерпретации запросов на различных языках на участниках, поддерживающих некоторые модели. Более точно, проблема состоит в переформулировании запроса, представленного на сложном языке, для источника, который поддерживает более слабую модель данных, и наоборот, переформулировании запроса, представленного на простом языке, для источника, который поддерживает более выразительные модель данных и язык запросов (например, запрос по ключевым словам к реляционной базе данных).
Более широкое представление запрашивания: Для адекватного удовлетворения потребностей сценариев приложений и пользователей пространства данных, в DSSP требуется поддержка более широкого подхода к запросам. Благодаря WWW и наступающей революции в области доступа людей к информации, люди воспринимают поиск как одну из основных активностей. Пользователи компьютеров осознают, что существенная часть их поддерживаемых компьютером активностей может быть разделена на две части: поиск релевантной информации и работа с обнаруженной информацией. Может существовать много разновидностей поиска, некоторые из которых напоминают запросы к базам данных (нахождение билетов для совершения путешествия, оперативная проверка банковского баланса), а другие находятся ближе к поиску по ключевым словам (нахождение нужных документов на предприятии или поиск рецептов для изготовления вафель).
Поэтому ключевой проблемой является обеспечение интуитивных средств поиска и запрашивания всего, что угодно. На самом деле, с точки зрения пользователя различие между поиском и запрашиванием должно исчезнуть. Пользователи должны начинать с простейших способов поиска, а затем, по мере потребности, направляться к более специальным интерфейсам поиска и запросов. На основе имеющегося запроса система должна обеспечивать для пользователя полезные советы относительно других тем, которые могут быть ему интересны, и возможностей соответствующего поиска. Нужно также разработать интуитивную визуализацию результатов, направляющую пользователей в правильном направлении.
4.2 Раскрытие пространства данных
4.3 Повторное использование человеческого труда
4.4 Хранение и индексирование пространств данных
Сложно будет поддерживать индекс в актуальном состоянии, особенно для участников, не имеющих механизмов извещения об обновлениях. Кроме того, несколько интересных проблем автоматической настройки следуют из потребности решать, какие части пространства данных следует кэшировать в локальном хранилище, и какие индексы следует создавать и поддерживать.
4.5 Гарантии корректности
4.6 Теоретические основы
5. Перспективы
5.1 Связь с другими областями
Естественно, большую часть данных в пространстве данных будет составлять неструктурированный текст. Поэтому важную роль при построении DSSP будут играть методы информационного поиска (Information Retrieval). Важно то, что в сложном пространстве данных пользователи часто не знают, что именно они ищут, и как интерпретировать результаты. Поэтому важно, чтобы они могли эффективно визуализировать результаты поиска и запросов для улучшения направленности своих исследований пространства данных. Здесь пригодятся современные методы из области визуализации информации (Information Visualization).
5.2 Обучение пространствам данных
5.3 Промышленные перспективы
Например, начинает набирать силу корпоративная интеграция информации (Enterprise Information Integration). Компании, специализирующиеся в этой области, производят системы для обработки запросов к нескольким источникам данных внутри организации. Имеется несколько примеров продуктов, которые создают индексы над несколькими источниками данных для достижения целей, которые мы упоминали выше (например, Master Data Management, компонент продукта NetWeaver компании SAP). Имеются проекты, направленные на раскрытие источников данных предприятия, и только немногие компании изучают различные аспекты управления корпоративными метаданными. Интересно, что средства поиска персональных компьютеров также распространяются на корпоративный уровень, поступая совсем из другого сектора индустрии.
6. Заключение
Пространства данных можно считать «зонтиком» для большей части исследований, которые уже активно ведутся в сообществе баз данных; на самом деле, в этом и состояла одна из исходных целей. Однако мы также попытались очертить несколько новых исследовательских возможностей, которые происходят из более целостного представления возникающих проблем «данных повсюду». Исследовательское сообщество баз данных однозначно решило заняться решением этих проблем, и мы предвидем непрерывный прогресс в расширении области применения технологии управления данными.