astronet2009

Идеи для гранта РФФИ на 2009-2011 гг.

Почему PostgreSQL ?

• Лицензия BSD, либеральная
• Многоплатформенность - Unix, Windows, MacOSX, …
• Большое устойчивое сообщество, не принадлежит никакой компании - защищенность инвестиций
• Долгая история, возникла в Беркли как научный проект, оказал большое влияние на развитие СУБД (http://www.sai.msu.su/~megera/postgres/talks/what_is_postgresql.html)
• Производные БД - лидеры инноваций - либеральная лицензия, модульность, богатый набор возможностей
  • PostgreSQL Plus Cloud Edition - поддержка расширяемости через Cloud Computing (Amazon веб-сервисы, http://www.enterprisedb.com/community/blades/elastra.do)
  • GreenPlum (http://www.greenplum.com/) - параллельное исполнение запросов, поддержка технологии MapReduce
  • AsterData (http://www.asterdata.com/) - паралелльное исполнение запросов, поддержка технологии MapReduce
  • Yahoo Everest - PostgreSQL с вертикальных хранилищем (см. ниже)
  • TelegraphCQ (http://telegraph.cs.berkeley.edu/telegraphcq/) - потоковая СУБД, его коммерческая версия - StreamBase
• Расширяемость - возможность создания новых типов данных, новых запросов, эффективных (индексная поддержка) предметными специалистами, а не разработчиками ядра СУБД. Неполный список расширений:
  • Blastgres (http://sourceforge.net/projects/blastgres) - расширение для эффективной работы с биологическими последовательностями PostGIS (www.postgis.org) - поддержка геоданных
  • Owlgres (http://pellet.owldl.com/owlgres) - семантическое расширение PostgreSQL

Семантические технологии интернет

Историческое:

• 80-e - email (@address, text, SMTP) - ТЕКСТ
• 90-e - web (URI, HTML, HTTP) - ТЕКСТ Дальше веб развивается в двух направлениях
• начало 21 века - семантический веб - (RDF, RDFs, OWL) - ДАННЫЕ
• начало 21 века - веб-сервисы - (UDDI, WSDL,SOAP) - ПРОГРАММЫ Нас ждет счастливое будущее, когда два направления соединятся - веб-сервисы объединятся с семантическим вебом, программы с данными.

WebServices (ПРОГРАММЫ)  --->       FUTURE_WEB (ПРОГРАММЫ+ДАННЫЕ)   
(UDDI,WSDL,SOAP)                                                                 
  ^                                                                       ^
   |                                                                        |
   |                                                                        |
Web   (ТЕКСТ)       ---->        SemWeb  (ДАННЫЕ)
(http,html,text)                      (RDF,RDFs,OWL)

Из http://www.ibm.com/developerworks/ru/library/wa-semweb/index.html?S_TACT=105AGX99&S_CMP=GR01

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

К семантическим технологиям Web относятся следующие:

• Глобальная схема имен (URI);
• Стандартный синтаксис описания данных (RDF);
• Стандартные способы описания свойств данных (схема RDF);
• Стандартные способы описания связей между объектами данных (онтология, определяемая с помощью OWL - онтологического языка Web (Web Ontology Language)).

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

Такой контент-анализ требует формальных и подробных спецификаций моделей доменов, которые определяют используемые термины и их связи. Подобные формальные модели доменов иногда называются онтологиями. Они определяют модели данных в терминах классов, подклассов и свойств.

Онтологический язык Web (Web Ontology Language), рекомендуемый консорциумом W3C, помогает в выражении онтологий. Рабочий онтологический язык (Ontology Working Language, сокр. OWL) добавляет больше словарных возможностей для описания свойств и классов, чем RDF или схема RDF. В частности, он позволяет описывать связи между классами (например, неперекрываемость), мощность множества (например, "ровно один"), равенство, более богатую типологию свойств и их характеристики (например, симметрия).

Хороший пример - FOAF (friend of a friend, http://www.foaf-project.org/original-intro). Семантическое описание людей и связей между ними, создается социальная сеть.

Для SOA семантические технологии дают возможность автоматического обнаружения ресурсов, составление сценариев на уровне веб-сервисов.

Веб как универсальная платформа

Современное видение Веба - это универсальная платформа для обмена информацией, данными и знанием. Общий подход к архитектуре веба - это дальнейшее развитие архитектуры распределенных вычислений и модульного программирование в сторону Абстрагировании от конкретного устройства программных компонент, протоколов связи между ними и формата данных, которыми они обмениваются. CORBA провалилась из-за амбиций вендоров ПО, Java/RMI, COM/DCOM - не интероперабельны. C развитием Веба, появились Веб-службы (сервисы), которые предложили архитектуру , основанную на слабой связности (loose coupling) между компонентами. Это означает, что компонентам системы не обязательно знать как устроены, взаимодействующие с ними подсистемы, и нет необходимости разрабатывать новые форматы данных и создавать специальное ПО для взаимодействия с ними. Другими словам, все компоненты системы представляют друг для друга "черные ящики". Для Веб-служб важно только то, что используется протокол передачи данных HTTP, которые передаются в формате XML, содержащий сериализованные объекты и способ адресации - URI (Unified Resource Identifier). Учитывая, что практически все вендоры приняли и используют спецификации W3C (w3c.org), Веб-сервисы имеют все шансы стать новой технологией распределенных информационных систем.

Для реализации SOA (методология построения систем и их интеграции) в настоящее время существуют два подхода (реализации), которые ориентированы на сервисы и рассматривают веб как платформу.

• WS - ориентируется на слабо-связанные сервисы, объединяет приложения и базы данных, ориентируется на бизнес процессы, более строгий top-down подход, любой запрос предполагает запуск веб-сервиса, имя вызываемой функции явно описан в wsdl - файл, в котором опубликованы веб-сервисы на языке WSDL (web service definition language). wsdl файлы могут быть скачаны приложением, которое может использовать его для автоматических запросов в веб-сервису - там уже описан апи, аргументы и его типы и точка входа (адрес ws) Запросы и результаты сериализованы в SOAP сообщение. Веб-сервисы могут использоваться как лего-кубики для поддержки сложных бизнес процессов (хореография веб-сервисов, BPEL - business process execution language). Описания сервисов регистрируются в реестрах, которые могут использоваться для поиска. Universal Description, Discovery and Integration (UDDI) стандарт специфицирует каким образом сервисы должны описываться, находиться и взаимодействовать (текущая практика включает значительное участие человека, который осуществляет семантическую экспертизу ресурса ).
• Web 2.0/REST - ориентируется на http протокол (stateless), текстовый формат и ресурсы. 4 метода - GET,PUT,POST,DELETE. Запрос предполагает доступ к ресурсу (не удаленное исполнение сервисов как в SOA !). Более легкий подход, так как его можно реализовать в самом простом случае как статические документы. Web 2.0 объединяет людей, облегчая коллаборацию, способствуя созданию документов людьми (тэги вместо ключевых слов, например). С web2.0 связывают развитие веба после кризиса 2001 года (сдувания мыльного пузыря). Это down-top подход. К web2.0 еще относят много разных технологий - Cloud Computing, http://en.wikipedia.org/wiki/Cloud_computing), WOA (Web Oriented), SaaS/PaaS( softwareplatform as a service, http:/en.wikipedia.org/wiki/Software_as_a_Service), IaaS (infrastructure as a service - выдача компьютерной инфраструктуры как сервис - хостинг-виртуализация), Utility Computing (предоставление компьютерных ресурсов по счетчику, как вода, электричество, http://en.wikipedia.org/wiki/Utility_computing).

WS - более труден для реализации, так как требует сервер приложений (tomcat, например), который разбирает XML-запрос (требование протокола SOAP) и исполнение соотв. кода (веб-сервиса), REST сильно проще, ресурс указывается в URI. REST-сервис можно реализовать например как статический XML-файл. REST - менее нагрузочен, не нужны куча спецификаций (SOAP, WSDL, UDDI,..), http протокол масштабируется стандартными средствами (вплоть до аппаратрных), мониторится. Однако, REST - stateless, потому для надежного обмена сообщениями, поддержки транзакций необходимы как раз сложные спецификации SOA.

Резюме старое как мир - все хорошо там, где оно максимально полезно и проще в реализации.

Astronet - сочетание двух архитектур - www.astronet.ru - портал с поддержкой REST/GET, но не web2.0, vo.astronet.ru - SOA

В науке SOA + специфические рекомендации

• астрономия - VO (Virtual Observatory)
• физика высоких энергий - GRID
• биология - биоинформатика, международные банки данных
• есть свои спецификации и в науках о земле, медицине

Организация хранения и доступа к очень большим научных данных на современном этапе

Что такое очень большие базы данных ? Следует различать базы данных как хранилища метаданных, которые содержат очень большое количество записей с активным доступом и базы данных, ориентированных на архивное хранение очень больших бинарных объектов.

• На сегодня официально анонсирована самая большая в мире база данных с активным доступом - Yahoo Everest, которая на май 2008 года имело хранилище размером более 2 Pb, несколько триллионов записей, с ежедневным поступлением около 24 млрд событий и более 1/2 миллиарда пользователей в месяц. Ожидается в 2009 году рост базы данных до 5Pb. Интересно отметить, что Yahoo Everest - это свободная СУБД PostgreSQL с распределенным вертикально-ориентированным хранилищем и поддержкой кластеризации. Из планируемых научных экспериментов выделяются
• Большой Адронный Коллайдер (LHC, http://lhc.web.cern.ch/lhc/), который ежегодно будет производить около 15 Pb данных, распределенное хранилище будет состоять из примерно 200 центров данных по всему миру
• большого телескопа для обзора неба (LSST, http://www.lsst.org), с диаметром зеркала 8.4 метра и матрицей размером 3.2 Гп (гига-пикселей). Ожидается наполнение БД в 49 миллиардов объектов (256 атрибутов), 2.8 триллиона источников (56 атрибутов). К 2025 году ожидается накопить 14 Pb данных !

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

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

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

Для организации процесса обработки данных (pipeline), который может быть очень трудоемким, поисковых задач требуется доступ к GRID центрам, что также требует определенных соглашений (см. проект GRIST, http://grist.caltech.edu).

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

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

Кроме того, помимо необходимости разработки новых программных компонентов, существует большое количество старых программ и систем, которые обслуживают существующие информационные ресурсы и требуется найти способ их интеграции. Очевидно, что это возможно только при абстрагировании от конкретного устройства компонент, протоколов связи между ними и формата данных, которыми они обмениваются. В противном случае, затраты на подключение новых компонентов к системе требует больших финансовых и временных затрат ( большинство существующих распределенных информационных систем связаны именно таким способом ). Такая архитектура получила название сервисно-ориентированной архитектуры (SOA) и развивается по спецификациям W3C (http://www.w3.org/2002/ws/) и OASIS (http://www.oasis-open.org/).

Использование SOA в науках, развитие которых связано с ростом данных, идет по одному сценарию - общие спецификации W3C дополняются специфическими рекомендациями, что позволяет использовать общепринятые технологии. Так, в астрономии, еще в конце 90-х крупные центры астрономических данных (CDS (Франция), CaDC (Канада), STScI (США), и т.д.) предложили начать разработку стандартов для доступа к астрономическим данным. Основная цель - оптимизировать доступ, обработку и анализ данных с целью получения максимальной научной отдачи. В 2002-м году был образован Международный Альянс Виртуальной Обсерватории (IVOA, International Virtual Observatory Alliance, http://ivoa.net), объединивший национальные международные ВО проекты. Главная миссия IVOA - разработка, утверждение и распространение стандартов для всех типов астрономических данных и средств их обработки и анализа. Основным результатом для общественности является появление десятков архивов, предоставляющих доступ к данным через стандартные интерфейсы, например центр астрономических данных в Страсбурге (http://cdsweb.u-strasbg.fr/), Национальная Американская Виртуальная Обсерватория (http://www.us-vo.org/projects/dataserv.cfm). В России недавно появился пилотный проект Российской Виртуальной Обсерватории vo.astronet.ru, нацеленный на предоставление доступа к данным для России и стран СНГ, а также на исследование технологий сервисно-ориентированной архитектуры.

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

В рамках Виртуальной Обсерватории организована сеть реестров ресурсов, которая используется для поиска данных как исследователем, так и программными агентами. Доля человеческого участия постепенно будет уменьшаться с развитием технологий семантического Веба (w3c.org/sw). Уже сейчас идет работа по созданию онтологии астрономических объектов, обозначений астрономических величин (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/IvoaSemantics).

Помимо гигантских архивов данных важным источником научной информации являются публикации в электронных архивах и электронных журналах, в которых зачастую публикаются экспериментальные данные, которые еще не вошли в каталог. Обычно, процесс публикации данных в виде структурированных каталогах занимает 3-5 лет. Поэтому, возможность поиска по всему информационному пространству является важной задачей. Семантические технологии должны сильно помочь в такой интеграции.

Какие хранилища используются для хранения научных данных ? В чем специфика научных БД ?

• файловые системы
• СУБД + кластерные решения

Проблемы развития баз данных

Что изменилось ?

• Много данных - порог петабайтных БД преодолен, сотни террабайт архивы становятся привычным. Yahoo (2008) анонсировала Yahoo Everest >2Pb online (PostgreSQL+vertical storage) хранилище - ComputerWorld - May 22, 2008,http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=18&articleId=9087918&intsrc=hm_topic - "Size matters: Yahoo claims 2-petabyte database is world's biggest, busiest” (Computerworld)
  • Largest table: "multiple trillions of rows”
  • "The 2 Pb database requires fewer than 1,000 PC servers”
  • Количество данных растут быстрее (http://www.b-eye-network.com/view/7188) чем закон Мура (http://en.wikipedia.org/wiki/Moore_Law)
• Данные стали разными, новые запросы - многомерные данные, запросы не ограничиваются операциями сравнения, например, найти 10 самых похожих изображений.
• Много запросов, другие требования к производительности и расширяемости - новые технологии (AJAX), динамические документы, увеличилось кол-во запросов, требование выполнение десятые доли секунды
• Клиенты стали другими - раньше были операторы, сейчас в основном это бездушные клиенты, большей частью через http, большой уровень конкурентности
• "Железо" стало дешевым - нужны новые алгоритмы, ориентированные на использование памяти и большого количество дешевых компьютеров.

Что делается ?

• Добавляются новые расширения на основе встроенных средств расширяемости. Например, PostgreSQL имеет GiST, GIN, с помощью которых сильно улучшена работа со множествами, реализован полнотекстовый поиск.
• Создаются специализированные СУБД, ориентированные на специфические типы данных, специфические условия. Например, в связи с появлением дешевых сенсоров возникла необходимость в работе с потоками данных, когда сами данные не важны, а интересны только агрегаты, такие как средняя температура, и т.д. Традиционные СУБД имеют большие накладные нагрузки (транзакционность, хранение на диске,..). Пример потоковых данных - StreamBase (http://www.streambase.com/) Другой пример - встроенные (embedded) СУБД (sqlite, tinyDB) используются в специализированных приборах. Появились XML базы данных для хранения слабо-структурированных данных (http://en.wikipedia.org/wiki/XML_database). Документо-ориентированные БД ( http://en.wikipedia.org/wiki/Document-oriented_database) работают не с таблицами с фиксированными полями, а с записями, которые содержат произвольное количество пар (ключ,значение). Хмм, чем они лучше XML DB ?
• СУБД используют в кластерах для масштабирования. Современная тенденция - это использование полностью независимых дешевых компьютеров. Промежуточный слой (middleware) между приложением и кластером отвечает за маршрутизацию запросов и результатов. Такая схема позволяет легко масштабировать и следить за сохранностью данных. Пример Sequoia(http://community.continuent.com/community/sequoia),uni/cluster для PostgreSQL, MySQL (http://www.continuent.com/). \ Другой подход - это использование технологии Cloud Computing для масштабирование как по хранилищу, так и по числу процессоров, например PostgreSQL Plus компании EnterpriseDB.
• Специализированные сервера с использование сопроцессоров (FPGA), например XtreemeData http://www.xtremedatainc.com/, модифицированный PostgreSQL, интегрированный в FPGA, для аналитических систем (OLAP)(прокачивает данные 1Tb/min)
• Модифицируется ядро СУБД для поддержки параллелизма (AsterData, GreenPlum), что позволяет один запрос выполнять на нескольких компьютерах. Приложение - аналитические базы данных (OLAP).
• СУБД упрощаются до поддержки типа данных (ключ,значение), результаты передаются приложению, где и происходит окончательные вычисления. Язык SQL здесь не нужен. Примеры - Google BigTable (http://labs.google.com/papers/bigtable.html), Amazon SimpleDB (http://www.amazon.com/SimpleDB-AWS-Service-Pricing/b?ie=UTF8&node=342335011), HyperTable (http://hypertable.org/). Намеренная простота таких БД компенсируется великолепной масштабированностью как по дисковому хранилищу, так и по процессорам.

Тем не менее, как считает видный участник DB-сообщества Майкл Стоунбрейкер, все это являются полумерами и требуется кардинальные изменения в технологии СУБД, а именно - изменение принципа хранения данных. Он считает, что эра обычных больших СУБД общего назначения прошла (http://www.databasecolumn.com/2007/09/one-size-fits-all.html) и требуется совершенно новые подходы для создания современной БД, которая с самого начала будет ориентирована на распределенность, параллельное исполнение запросов, компрессию, ориентацию на хранение по атрибутам, высокую доступность, линейное масштабирование с использование кластеров независимых серверов.

Традиционные СУБД хранят данные в виде записей, которые содержать все атрибуты (колонки). При чтении с диска поднимается вся запись, даже если запрашивается только один атрибут. Подобных накладных расходов можно избежать при хранении атрибутов отдельно - атрибутно-ориентированное (column-oriented) хранение. Их-за одинаковой природы данных они очень хорошо сжимаются, следовательно занимают меньше места на диске и требуют меньшее количество операций ввода-вывода, которые очень медленны и "убивают" всю производительность. Несмотря на то, что соединения нескольких таблиц для такого хранения представляется очень сложным, оказывается, что можно использовать алгоритмы поиска по сжатым данным и откладывать материализацию записей как можно дальше, что приводит к лучшей производительности, чем при традиционном хранении. Пример - Vertica (http://www.vertica.com/), распределенная ( GRID), аналитическая БД с вертикальным хранилищем - коммерциализия C-store (http://db.lcs.mit.edu/projects/cstore/)

Проблемы хранения очень больших научных баз данных

Специфика научных баз данных

• Сверхбольшие БД - сотни петабайт в ближайшие 10 лет
• Научные данные часто хранятся в двух видах - метаданные в БД и данные где-то в файловой системе, требуется поддерживать их непротиворечивость. Современные БД не приспособлены для эффективной работы с терабайтами бинарных данных
• Научные данные, особенно "сырые" данные, практически не меняются
• OLAP запросы преобладают над OLTP
• Очень много разных требований в разных науках - трехмерные объекты, временные ряды, треки элементарных частиц и т.д
• Версионность данных - важно для науки, иначе нет воспроизводимости результатов.
• Распределенность - данные хранятся в разных научных центрах для локализации трафика, по физическим причинам, резервирование данных, масштабирование нагрузок

Сообщества научное и разработчики СУБД решили взаимодействовать для создания новой SciDB (http://confluence.slac.stanford.edu/display/XLDB/SciDB) для XLDB (http://en.wikipedia.org/wiki/XLDB). Несколько совещаний:

• 1st Workshop on Extremely Large Databases, SLAC, Oct. 2007, http://www-conf.slac.stanford.edu/xldb07/
• SciDB Meeting, Asilomar, Apr. 2008, http://silicondetector.org/display/XLDB/xldb2

Были выработаны основные требования к будущей базе данных для Большой Науки:

• открытая модель развития гарантирует независимость от вендора и защиту инвестиций, а также способствует привлечению разработчиков.
• отказ от строгого соблюдения ACID, хранилище оптимизированое в основном на чтение, загрузка данных только большими порциями (bulk load), многомерные массивы как основная структура данных
• масштабируемость на сотни петабайт, при этом SciDB должна работать как на ноутбуке, так и на кластере в тысячи серверов. Минимизация административных затрат на поддержание работоспособности кластера.
• интерфейсы к научным приложениям, таким как R, MATLAB, IDL, к языкам программирования (C++, Python)
• Поддержка версионности данных, отслеживание источников данных, поддержка данных с ошибками

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

• Почему эта проблематика важна для нашей группы ? В ближайшие нескольких лет
  • вводится 2.5-метровый автоматический телескоп (около Кисловодска), ожидается большой поток наблюдательных данных
  • Космический обзор неба "Лира" с МКС, совместно с РКА Энергия - ожидается 300-400 терабайт данных
  • Группа давно занимается разработкой PostgreSQL и сделала немало важных проектов - системы расширяемости GiST и GIN, полнотекстовый поиск, эффективная работа с массивами, хранение и работа с очень большими астрономическими каталогами (данные со сферическими атрибутами)
  • В рамках проекта "Астронет" реализован узел Виртуальной Обсерватории (vo.astronet.ru), который предоставляет интерактивный и программный доступ к терабайтным астрономическим БД

Методы и подходы: Развитие СУБД PostgreSQL

Майк Стоунбрейкер в своем блоге про базы данных для Большой науки http://www.databasecolumn.com/2007/11/databases-for-big-science.html привел причины, по которым попытка использования PostgreSQL в начале 90-х годов (проект Sequoia 2000, http://meteora.ucsd.edu/s2k/s2k_home.html) для геофизических данных провалилась, из чего он сделал далеко идущий вывод, что никакие существующие СУБД (даже PostgreSQL !) не могут предложить ничего для Большой науки и призвал сообщество написать новую СУБД (SciDB) с нуля. Следует отметить, что с тех пор многое изменилось в PostgreSQL и, кстати, усилиями нашей группы были сильно улучшен инфраструктура расширяемости, введена поддержка массивов, иерархических данных. Кроме того, был разработан алгоритм индексации очень больших данных со сферическими атрибутами (астрономические координаты, географические координаты), который активно используется в БД с миллиардами объектов. Таким образом, не отрицая необходимость разработки новой БД для Большой науки, на что потребуется немалое количество лет, мы придерживаемся точки зрения, что необходимо проанализировать современный PostgreSQL для выявления возможных препятствий (bottleneck) в алгоритмах и структурах, изучить опыт сторонних компаний, которые добавили атрибутно-ориентированное хранилище (Yahoo Everest), параллельное исполнение запросов (Greenplum, AsterData). Мы планируем продолжать наши работы по системе расширяемости PostgreSQL, на основе которой будут реализованы новые расширения, тестирование и апробация которых предполагается на сайте Астронет, на котором есть возможность тестирования как очень больших базах астрономических данных, так и на коллекции полнотекстовых документов. Результаты работ будут доложена на ежегодных конференциях разработчиков PostgreSQL и после дополнительного тестирования часть из них войдет в будущую версию PostgreSQL, тем самым станут доступными большому количеству пользователей. Учитывая такие факторы, как его использование в науке, доступность PostgreSQL, богатый набор возможностей, а также совместимость с коммерческими вариантами (которые на данный момент являются лидерами в области параллельных и кластерных решений), мы верим в его применимость как универсальное хранилище для научных баз данных. В частности, мы планируем уже в рамках этого проекта начать работы по созданию свербольшого хранилища для космического проекта совместно с РКК Энергия.

Расширяемость и масштабируемость СУБД PostgreSQL и развитие архитектуры "Астронет"

• Протестировать все структуры в PostgreSQL и алгоритмы для использования в XLDB (петабайтные БД).
• Сравнение производительности вертикально-ориентированных БД с возможными реализациями на основе PostgreSQL:
  • index-only scan - все колонки проиндексированы, запрещен последовательный доступ к данным
  • декомпозиция таблицы на множество таблиц вида(PK, NPK). Вертикальные БД интересны для хранения "сырых" данных, где доступ к архивам осуществляется только по первичному ключу,а сами данные сериализованы в один бинарный атрибут.
• Исследование возможности применимости параллельных и распределенных БД для хранения очень больших научных БД на основе PostgreSQL - PostgreSQL Plus, Greenplum.
• Улучшение производительности при работе с большим количеством атрибутов переменной длины. Сейчас существует очень заметный оверхед, особенно заметный при массивной загрузки данных (100% cpu при загрузке SDSS каталога ~ 300 млн. записей с несколько сотнями колонок).
• IOT (Index Organized Tables) - индексно-организованная таблица (таблица с индексной организацией) . Индекс-таблица - это индекс, построенный по первичному ключу, который вместо ссылки на запись в таблице, содержит саму запись в листьях дерева. Другими словами, в IOT таблицах данные сгруппированы по первичному ключу. Экономия IO,так как не требуется доступ к таблице, ,возможно, места на диске. IOT будут полезны для схем 'star' и 'snowflake' (звезда и снежинка), в которых часто используются соединения по первичным ключам.
• Алгоритмы оптимальной кластеризации бинарных сигнатур на диске для эффективного создания GiST индексов. Массивы представляются сигнатурами, текущий вариант - квадратичный алгоритм Гуттмана (из Rtree) с использованием расстояния Хемминга (количество несовпадающих битов в сигнатурах). Недостаток - малое количество возможных уникальных расстояний (n+1), где n - это длина сигнатуры, как следствие - плохая селективность индекса.
• Быстрое обновление GIN-индексов. Типичный пример - появление нового документа приводит к обновлению полнотекстового индекса. Количество вставок в поисковое дерево равно количеству уникальных слов в документе, что может вызывать замедление работу поискового сервиса. Предлагается отложенное обновление обратного индекса, когда вставка в поисковое дерево не производится, а новые ключи укладываются в структуру на диске (позволяющая относительно быстрый поиск) - баланс между скоростью вставки и поиском. Собственно обновление индекса происходит во время служебной процедуры сбора статистики. Большой выигрыш ожидается для массивного обновления таблиц.
• Частичный поиск (partial match) в GIN-индексе. Существующая реализация поддерживает только полное совпадение ключей. Алгоритм поиска с поддержкой неполного совпадения ключей позволит реализовать префиксный поиск, например в полнотекстовом поиске, или поиск по подстроке.
• Реализация композитных GIN-индексов - индекс по нескольким атрибутам. Стандартный Btree-index поддерживает композитные индексы, но его производительность сильно зависит от того, по какому ключу идет поиск (индекс по (a,b) эффективно используется для запросов с ограничениями по 'a' и 'b', по 'a', но не по 'b'. Задача состоит не только в реализации поддержки таких индексов, но и чтобы композитный индекс одинаково эффективно использовался во всех случаях. (PGCon-2008, Canada, Ottawa, http://www.pgcon.org/2008/schedule/events/58.en.html)
• GIN для скалярных типов данных, построение GIN индекса по нескольким атрибутам. Текущая реализация поддерживает только массивы (разных типов), что ограничивает использование композитных индексов. Например, композитный GIN-индекс по (timestamp, tsvector) был бы очень эффективен как для полнотекстового поиска с ограничением по дате, так и по каждому атрибуту.
• UTF-8 для pg_trgm - поддержка UTF-8 для триграмного поиска (используется для поиска с ошибками)
• Быстрая приближенная статистика на основе индекса (GiST, GIN) - быстрая, потому что используется только индекс без доступа к таблице, приближенная - не учитывается информация о видимости записей (для данной транзакции), которая как раз и содержится именно в таблице. PostgreSQL - многоверсионная СУБД, поэтому необходимо иметь такую информацию. Для большого класса задач, в которых записи меняются редко, такая статистика может быть достаточна. Выигрыш в скорости идет на несколько порядков.
• Эффективная работа с RDF (тройки данных "объект - предикат - субъект") в PostgreSQL (в поддержку semantic web) - тип данных, методы доступа с индексной поддержкой, функциональный интерфейс, реализующий подмножество семантического языка запросов SPARQL (http://www.w3.org/TR/rdf-sparql-query/). Предполагается создать экспериментальный прототип в виде расширения PostgreSQL (contrib/pg_rdf), с тем, чтобы после цикла тестирования предложить в ядро PostgreSQL (см. также Owlgres, http://clarkparsia.com/weblog/2008/03/23/owlgres-scalable-db/, готовый пользователь)
• Алгебра поискового запроса с поддержкой логических операций (AND, OR, NOT, NEAR) и группировок (скобки). Здесь NEAR - это усиленная логическая операция AND с ограничением по расстоянию между операндами. Требуется составить непротиворечивый набор правил для преобразование поискового запроса в дерево запросов, в котором операнды (лексемы) находятся в листьях, а в вершинах - операторы. Такие деревья позволяет эффективно планировать и выполнять поисковые запросы.
• Реализация поиска по фразам в PostgreSQL на основе алгебры с поддержкой ограничения расстояния между операндами.
• Fallback search - переписывание оригинального запроса, если поиск не дал результатов с учетом встречаемости слов в поисковом индексе
• Predictive search (autocompletion) - поиск по префиксу для подсказки пользователю возможных вариантов дополнения запроса. Например, пользователь вводит 'Сверхн', и поиск предлагает 'Сверхновые звезды'. Может использоваться также как навигационный элемент, если индексировать контент. Задача состоит в очень быстром поиске по префиксу и правильных алгоритмах релевации найденных результатов.
• Тип данных для временных интервалов - поддержка интервальной алгебры Аллена (http://en.wikipedia.org/wiki/Allen%27s_Interval_Algebra). Можно использовать для БД по событиям, со сложной временной структурой (цикл жизни конференции, предполагается использовать на астронете), эффективной работы с темпоральными данными, например, наблюдения солнечной активности.
• Расширение GiST API - добавление операций навигации по поисковому дереву (по индексу). Существующий программный интерфейс к GiST (http://www.sai.msu.su/~megera/postgres/talks/gist_tutorial.html) не позволяет разработчику новых методов доступа (access methods) возможность навигации по поисковому дереву, например подняться/спуститься на один уровень, что ограничивает возможность реализации некоторых новых поисковых алгоритмов.
• Поиск ближайших соседей (KNN) - используя навигацию по дереву можно эффективно находить K-ближайших соседей. Для этого, сначала производим поиск по дереву (GiST индекс), потом поднимаемся вверх по дереву, подсчитывая количество точек в узлах. Как только их стало K точек, задача решена. Этот метод замечателен тем, что не требует задания радиуса поиска (можно постепенно увеличивать радиус поиска пока не найдется K-точек. Требует априори знания начального радиуса и неопределенного кол-ва поисков).Это очень востребованный алгоритм для поиска закономерностей во многомерном пространстве, например, поиск похожих изображений.
• Расширение инфраструктуры полнотекстового поиска (http://www.postgresql.org/docs/8.3/static/textsearch.html) в PostgreSQL для обеспечения более гибких настроек пользовательского поиска. Существующая реализация предполагает использование стека словарей, которые пытаются привести входное слово к некоторой "стандартной", с точки зрения текущего словаря, форме. Предполагается улучшить интерфейс конфигурации и поведения как словарей, так и самого стека.
• Полнотекстовый поиск по данных архива научных публикаций arxiv.org. Предполагается создать зеркало в PostgreSQL и разработать свой словарь, учитывающий специфику номенклатуры астрономических объектов, сложившихся синонимов, для поиска "свежих" наблюдательных данных, которые еще не попали в каталоги. Трудность состоит в том, что один и тот же объект в разных проектах обозначается по разному и требуется специальная служба резолвинга имен, специальный метол индексирования, чтобы достичь полноты поиска. Кроме того, будет реализована возможность извещения (используя RSS каналы) о новых статьях, удовлетворяющие поисковому запросу. Это позволит мониторить архив по своей тематике, например, RSS-поток http://vo.astronet.ru/arxiv/rss.php?query=sn, будет включать все новые статьи, которые содержат информацию про Сверхновые звезды. В дальнейшем это зеркала будет использоваться для семантических исследований (на основе онтологии астрономии, разраб. в IVOA, http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/IvoaSemantics).
• Реализация поисковых интерфейсов с подсказкой фраз на основе журнала запросов, материалов проекта "Астронет" как новый элемент навигации по сайту
• Создание хранилища для событий со сложной временной структурой - конференции, семинары, юбилеи и т.д.
• Дальнейшее наполнение астрономического глоссария проекта Астронет
• Подготовка экспериментальной онтологии астрономии на основе астрономического глоссария проекта Астронет - разметка в тексте с использованием микроформатов, экспериментальный интерфейс для поиска. Используем RDF для описания свойств ресурсов (объектов), а онтологию (OWL или другой способ) для описания связей между ресурсами (объектами). Эта работа позволит уже сейчас использовать технологии семантического веба, предоставить тестовое наполнение для работ по семантическому расширению PostgreSQL.
• Визуализация астрономических архивов - задачи эффективного склеивания и масштабирования астрономических изображений. На примере DSS2 (Цифровой обзор неба, получен по соглашению с Космическим институтом Хаббла,space telescope, 1 терабайт изображений в разных фильтрах).
• Универсальное хранилище астрономических каталогов в PostgreSQL - проблема - нужен унифицированный доступ к астрономическим каталогам. Несмотря на то, что каждый каталог является строго структурированным,коллекция таких каталогов представляет собой слабо-структурированые данные. Разрабатывать интерфейсы к каждому каталогу - занятие плохо масштабирующееся. Предлагается разработать метакаталог, которые хранит описание всех каталогов, и методы для эффективной работы с этим метакаталогам. Доступ предполагается как с использование стандартного SQL, так и через WS (web services). Поддержка основных астрономических запросов () с использованием разработанного ранее быстрого алгоритма поиска по очень большим каталогам со сферическими атрибутами (Koposov S., Bartunov O.S., "Q3C, Quad Tree Cube - The new sky-indexing concept for huge astronomical catalogues and its realization for main astronomical queries (cone search and XMatch) in open source database PostgreSQL", in Astronomical Data Analysis Software and Systems XV ASP Conference Series, 2005 C. Gabriel, C. Arviset, D. Ponz and E. Solano, eds.)
• Веб-сервисы для доступа к хранилищу очень больших каталогов
• PLASTIC (http://plastic.sourceforge.net/) интерфейс к хранилищу, который позволит использовать привычные инструменты VO с хранилищем
• Наполнение хранилища (принцип аутентичности, нужности. все взяты из оригинальных мест, многие по спец. соглашению):
  • Denis - 3 издание инфракрасного каталога галактик (43000 объектов), ESO
  • USNO-A2.0 - каталог астрометрических стандартов (United States Naval Observatory очное положение > 500 млн объектов), United States Naval Observatory
  • 2MASS (The Two Micron All Sky Survey) - инфракрасный обзор неба, (положения и фотометрия для > 470 млн точечных источников и > 1.5 млн протяженных источников) The University of Massachusetts
  • USNO-B1.0 - астрометрический каталог (положения >1млрд объектов),
  • GSC 1.2 (The Guide Star Catalog) - каталог Космического телескопа Хаббла, > 19 млн объектов ярче 16 величины, содержит позицию и фотометрию
  • GSC II (версия 2.3.2) - каталог всего неба, положения, фотометрия и собственное движение ~ 1 млрд объектов. Space Telescope Science Institute
  • The Tycho-2 - опорный астрометрический каталог, ~ 2.5 млн звезд по всему небу, точное положение, фотометрия и собственные движения звезд. На основе данных проекта ESA (спутник Hipparcos )
  • Nomad -объединенный астрометрический каталог, 1.1 млрд объектов, The U.S. Naval Observatory
  • SDSS DR5 - The Sloan Digital Sky Survey версия 5, содержит более массу инфы (позиция, фотометрия, спектры, параметры изображений) по > 100 млн объектам
  • 2XMM - Каталог рентгеновских источников ( ~ 250,000) , по данным космической обсерватории ESA-XMM Newton Observatory
  • SDSS DR6 - The Sloan Digital Sky Survey версия 6, ~ 300 млн источников
  • DSS2 (см. выше)

неструктурированные заметки

Типы данных

• Структурированные данные в каталогах
• Данные в электронных публикациях ( еще не попали в каталоги)
• Слабоструктурированные данные - текстовые документы

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

Разнородные и слабо-структурированные данные, особенно в старых архивах, требуют семантических методов работы, которые способны (как верится) автоматизировать большую часть работы (рутинной) исследователя. Пример из астрономии - найти изображения галактики до взрыва Сверхновой 1972e. Типичные действия астронома - из каталога Сверхновых звезд извлечь координаты Сверхновой 1972e и найти все снимки области неба с центром, имеющий эти координаты, в избранных обзорах неба. Это рутинная задача требует много времени и вполне могла быть автоматизирована, если только компьютер смог: 1. Узнать, что данные о Сверхновых находятся в каталоге Сверхновых звезд 2. Найти адрес ресурса, который содержит каталог Сверхновых звезд, желательно его актуальную и аутентичную версию 3. Обратиться к ресурсу, сформулировав запрос согласно его API 4. Понять какие колонки в результирующей строке являются координатами 5. Найти адрес ресурса, который содержит информацию об обзорах 6. Обратиться к ресурсу, задав координаты центра поля, сформулировав запрос согласно его API 7. Полученные адреса изображений передать астроному

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

В качестве иллюстрации приведем пример из астрономии - на основе анализа астрономических каталогов центра данных в Страсбурге было выявлено, что информация о собственных движениях звезд содержится в колонках таблиц, которые имеют больше 300 различных наименований ! Никакое определеление точных положений звезд, что является одной их самых востребованных задач астрономии, без ручной работы исследователя в настоящее время невозможен. Необходим способ объяснить компьютеру, что есть что, а для этого необходимо также уметь описать данные, научить программы понимать эти описания и принимать решения насколько подходят эти данные (в данном случае, являются ли эти данные собственными движениями звезд) для решения задачи или нет.

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

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

За последние 10 лет наблюдается существенный прогресс в понимании того, что требуется от нового поколения интернета, который рассматривается как универсальная среда для обмена информацией, данными и знанием. Новые Веб получил название Семантического Веба. На самом деле, это очень сложная задача и вызов (challenge) для науки, решение которой требует интеграции всех областей науки.