The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Представлен первый стабильный релиз СУБД SciDB

24.06.2011 18:55

Объявлено о выходе SciDB 11.06, первого стабильного релиза проекта по созданию свободной СУБД для использования в области обработки научных данных, полученных в результате экспериментов и наблюдений. В качестве примеров областей, в которых может использоваться СУБД, называется хранение и анализ наблюдений в оптической и радио астрономии, сейсмологии, генетике, океанографии, геологии, климатических и экологических наблюдениях. Кроме научного применения SciDB может использоваться для обработки статистики работы различных сенсоров в нефтедобывающей отрасли и медицинских учреждениях, выполнения финансовой аналитики. СУБД спроектирована для анализа огромных массивов данных (тысячи петабайт) и изначально поддерживает кластеризацию, масштабируясь от одного сервера до десятков тысяч узлов. Код SciDB распространяется в рамках лицензии GPLv3.

Примечательно, что инициатором проекта SciDB выступил Майкл Стоунбрейкер, создатель СУБД Ingres, VoltDB и PostgreSQL, а в разработку были вовлечены российские научные учреждения, такие как НИИСИ РАН и ГАИШ МГУ (сотрудники данных организаций давно участвуют в разработке СУБД PostgreSQL). SciDB не похожа на классические СУБД и в ущерб поддержке некоторых привычных возможностей оптимизирована для обработки и анализа "сырых" данных, которые интенсивно читаются, но почти не изменяются. СУБД не рассчитана на обработку транзакций в реальном времени (OLTP), не поддерживает ACID (атомарность, непротиворечивость, изоляция, долговечность) и журналирование, обеспечивая транзакции лишь на минимальном уровне.

Возможности SciDB сосредоточены вокруг сложной аналитики, для которой стандартная реляционная модель оказывается неэффективной - хранилище оптимизировано для единовременной записи мало структурированных данных и их последующего интенсивного чтения. Вместо добавления отдельных строк, применяется подход загрузки сразу больших порций данных. Хранение данных организовано в виде многомерных вложенных массивов, для обработки которых вместо SQL задействованы языки AQL (Array Query Language) и AFL (Array Functional Language).

AQL напоминает SQL, но предназначен для формирования запросов к многомерным массивам вместо множеств, т.е. позволяющий учитывать соседние позиции элементов при помощи оператора REGRID, выполняющего действия сходные с MapReduce. Для обработки данных внутри СУБД подготовлен язык AFL, которые позволяет создавать встраиваемые процедуры. Пример обработки данных подробно описан в данной статье.

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

  1. Главная ссылка к новости (http://www.scidb.org/news/2011...)
  2. OpenNews: Представлена новая открытая СУБД VoltDB
  3. Обзор SciDB
  4. OpenNews: Релиз СУБД Neo4j 1.3, ориентированной на хранение графов
  5. OpenNews: Релиз открытой СУБД Ingres Database 10
  6. OpenNews: Представлена новая NoSQL БД Hibari, созданная для больших хранилищ данных
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/30983-scidb
Ключевые слова: scidb, database, warehouse
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (18) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 21:02, 24/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    почти год назад впервые услышал о данной дб, на конференции о ней рассказывал один из разработчиков(который из ГАИШ МГУ). Рад что его работа была успешной
     
  • 1.2, fdffdg (?), 21:16, 24/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    такую базу можно было написать лет 10 назад
    или она не нужна ?
     
     
  • 2.3, fr0ster (ok), 21:55, 24/06/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "СУБД не рассчитана на обработку транзакций в реальном времени (OLTP), не поддерживает ACID (атомарность, непротиворечивость, изоляция, долговечность) и журналирование, обеспечивая транзакции лишь на минимальном уровне."

    10 лет назад такая база не шибко нужна была. Это сейчас есть что в ней хранить и обрабатывать, а раньше отсев "лишних" для результата данных старались производить по ходу эксперимента.

     
     
  • 3.5, Evgueni (?), 09:18, 25/06/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а раньше отсев "лишних" для результата данных старались производить по ходу эксперимента.

    Сколько раз уже тыкался носом в то, что подобных "лишних" данных не бывает :(

     
     
  • 4.6, fr0ster (ok), 11:18, 25/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >> а раньше отсев "лишних" для результата данных старались производить по ходу эксперимента.
    > Сколько раз уже тыкался носом в то, что подобных "лишних" данных не
    > бывает :(

    Ну кавычки то не зря ставил. А вообще раньше все в ручном режиме, и накопление наблюдательных данных, и первичная обработка. А первичная обработка силами студентов и прочих особо грамотных субъектов. Вот и старались свести к минимуму фактор внесенных ошибок.
    А сейчас все автоматизируют, накапливают большое количество первичных данных. Вот и выходит сейчас такая база особо к месту.

     
  • 2.4, Evgueni (?), 09:16, 25/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Она нужна довольно ограниченному кругу людей, которые привыкли решать свои задачи максимально простыми ориентированными на текущую задачу способами. Хотя попытки использовать СУБД для хранения данных безусловно предпринимались. Здесь следует вспомнить эпик файл с внедрением в научные круги коммерческой СУБД Objectivity.

    Для относительно небольшого объёма данных (скажем десятки гигобайт) PostgreSQL в принципе подходит, но некоторые вещи напрягают (типа передачи данных через текст, хотя безусловно это обходится). Но с большим объёмом наступают разного рода траблы, так что БД SciDB будет востребована. Жаль немного, что SQL не очень туда вписывается.

     
     
  • 3.7, fr0ster (ok), 11:19, 25/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Она нужна довольно ограниченному кругу людей, которые привыкли решать свои задачи максимально

    Думаю уже сейчас таких людей немало, а дальше их будет больше

     
  • 3.10, Ян Злобин (ok), 18:58, 26/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Для относительно небольшого объёма данных (скажем десятки гигобайт)
    > PostgreSQL в принципе подходит, но некоторые вещи напрягают (типа
    > передачи данных через текст, хотя безусловно это обходится).

    А можно подробнее - имеется в виду, что данные приходится в некоторых случаях преобразовывать в SQL-текст?

     
     
  • 4.11, Evgueni (?), 12:49, 27/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А можно подробнее - имеется в виду, что данные приходится в некоторых случаях преобразовывать в SQL-текст?

    SQL -- это текст, соответственно запрос идёт в текстовом виде в том числе и на вставку и результаты вычитываются тоже как текст. Это гарантирует безпроблемную переносимость. Страшно сказать у нас до сих пор работает VAX под VAX/VMS -- с него тоже надо к БД доступаться. В принципе жить можно, но если объём данных относительно большой, то возникают значительные задержки чисто из-за объёма передаваемых данных, а на VAX и сама процедура перевода из числа в строку или обратно занимает значимое время, так как слабенький он.

    Всё это относится не к сырым данным эксперимента (там никакой БД бы не хватило, кроме разве что SciDB), а калибровочные константы и медленный контроль. Размер массивов колеблется от десятков до десятков тысяч значений. При реконструкции экспериментальных данных считывается около сотни различных массивов констант для конкретного интервала времени.

     
     
  • 5.12, Ян Злобин (ok), 13:37, 27/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > SQL -- это текст, соответственно запрос идёт в текстовом виде в том
    > числе и на вставку и результаты вычитываются тоже как текст...

    Это понятно.  Но можно использовать родную библиотеку постгреса libpq, которая работает несколько на другом уровне.  Работает очень хорошо и быстро.  Проверено.  Есть и плюсовая версия.  Это для специализированного софта, на мой взгляд, идеальный вариант.

     
     
  • 6.14, Evgueni (?), 11:57, 28/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    libpq и используется. Она же и портирована на VAX.
     
     
  • 7.16, Ян Злобин (ok), 15:10, 28/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > libpq и используется. Она же и портирована на VAX.

    Там же есть бинарные данные.

     
     
  • 8.17, Evgueni (?), 18:53, 28/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Программный интерфейс не был стабилен ... текст свёрнут, показать
     
  • 5.13, Антоним (?), 18:24, 27/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Что за ерунда. Посмотрите как во многих БД реализованы протоколы передачи данных между СУБД и клиентом.  Полный SQL текст всегда работает только для пользовательского интерфейса, однако для некоторых программных реализаций передача идёт бинарно через prepared queries + список аргументов.

    Передача результата назад это во многих случаях исключительно бинарные форматы данных.

     
     
  • 6.15, Evgueni (?), 12:00, 28/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Передача результата назад это во многих случаях исключительно бинарные форматы данных.

    У PostgreSQL есть возможность передавать данные через бинарный формат. Есть возможность и класть сразу blobы. Но за всё надо платить.


     
     
  • 7.18, Антоним (?), 21:55, 28/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    У PG это почти штатная фича, большинство типов данных передаются в бинарном представлении. Не нужно за это 'платить'
     
     
  • 8.19, Evgueni (?), 11:00, 29/06/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Проблемы были десять лет назад Сейчас вообще проблем нет с PostgreSQL, но сейча... текст свёрнут, показать
     

  • 1.9, тру йода (?), 18:13, 25/06/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А мы пока по старинке hdf5 будем использовать. Вот как у нее насчет петабайтов сказать не могу - опыта нет.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру