LINUX.ORG.RU

Вышла новая версия SciDB

 


4

6

Вышла новая версия проекта SciDB - 12.12.

SciDB - проект Майка Стоунбрейкера, отца многих СУБД.

SciDB - версионируемая СУБД для аналитики, работающая с большими многомерными распределёнными массивами.

Доступны два вида синтаксиса:

  • Array Query Language (AQL) — язык очень похожий на SQL, но работающий не с таблицами (таблица = одномерный массив), а с многомерными массивами;
  • Array Functional Language (AFL) — «чистый» в функциональном смысле полностью эквивалентный AQL язык.

Партицирование данных и запросов, линейная алгебра, математическая статистика и машинное обучение из коробки.

В новой версии большое количество исправлений, оптимизаций производительности.

Появилась интеграция с MPICH и ScaLAPACK.

Доступны репозитории для CentOS 6.x, RedHat 6.x, Ubuntu 12.04.

Доступные интерфейсы:

  • Python
  • R
  • iquery (аналог консольного клиента)

В ближайшем будущем планируются:

  • RESTful API
  • JDBC-connector
  • ODBC-connector

SciDB используется:

  • банками
  • страховыми компаниями
  • генетиками
  • астрономами
  • платёжными системами

Из публично доступных примеров: 1000 Genomes Browser

>>> Скачать



Проверено: catap ()
Последнее исправление: catap (всего исправлений: 10)

Ответ на: комментарий от catap

Ну, Hadoop более зрелое решение, по идее, в плане maintance он проще. Но в Hadoop запросы нужно писать на Java. В SciDB же у тебя доступен достаточно простой. синтаксис, и тебе не нужно думать как параллелить запрос.

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

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

В системе можно настроить избыточность по данным, и даже развалившись на части кластер будет считать запросы дальше.

zabivator
() автор топика

многомерные массивы это что в данном случае?

Array Query Language (AQL) — язык очень похожий на SQL, но работающий не с таблицами (таблица = одномерный массив), а с многомерными массивами;

если массивы такие многомерные, то почему не взять MDX?(ну расширить его там командами DDL). В общем ничего не понятно и ссылки на подробности нет.

RedPossum ★★★★★
()

ого, надо пощупать, звучит очень интересно

Reset ★★★★★
()
Ответ на: комментарий от zabivator

Спасибо. Заодно сняли мой не заданный вопрос про ACID :)

Для «Ъ»:

Отказ от поддержки транзакций. Для научных данных не нужны транзакции (WORM - Write Once Read Many), которые сильно усложняют архитектуру СУБД и вносят существенные расходы на их поддержание. ACID - традиционная архитектура, в сетевом окружении <...> невозможно добиться одновременно целостности (Consistency) данных, доступности (Availability) данных и распределенности (Partitioning). В наших условиях, когда мы не можем обойтись без распределенности данных <...>, надо выбирать между целостностью и доступностью. Доступность данных тоже является важным условием для науки, а требование целостности смягчается до условия 'eventual consistency' <...>, что вполне достаточно для научных данных в силу WORM.

X-Pilot ★★★★★
()
Ответ на: комментарий от zabivator

щас меня за этот коммент шапками закидают.

Я понимаю разницу между бесплатным и свободным. SciDB - свободная и бесплатная, kdb - закрытая и платная

zabivator
() автор топика
Ответ на: комментарий от X-Pilot

Статья двулетней свежести. Сейчас там read-write array level lock, но в следующем релизе мы этот вопрос будет решать.

zabivator
() автор топика
Ответ на: комментарий от X-Pilot

И да, с другой стороны, а нафига аналитической СУБД транзакции? Обычно гоняют толстые запросы, что долго работают на больших объёмах данных

zabivator
() автор топика
Ответ на: комментарий от catap

SciDB - это opensource. Платное расширение есть, P4 называется, и не факт, что оно тебе нужно SciDB - это международный научно-исследовательский проект, в то время как P4 занимается интеграцией, внедрением и всякими не нужными ширнармассам плагинами.

zabivator
() автор топика
Ответ на: комментарий от zabivator

И да, с другой стороны, а нафига аналитической СУБД транзакции? Обычно гоняют толстые запросы, что долго работают на больших объёмах данных

Не-не-не, я же ничего не говорю, просто теперь понятно, что оно подходит под свои (!=мои :) ) специфичные нужды.

X-Pilot ★★★★★
()
Ответ на: комментарий от X-Pilot

Аналитики считают. Выгружают в многомерное пространство пользовательские данные, ищут закономерности, считают риски займов, оптимальные цены, автоматически кластеризуют клиентов

zabivator
() автор топика
Ответ на: комментарий от zabivator

ну т.е. прайс у вас как у взрослых 5% от полученных инвестицйи в год или 3% от годового оборота, да?

catap ★★★★★
()
Ответ на: комментарий от Harald

Сомневаюсь, т.к. проводки - это всё-таки OLTP А вот раз в неделю выгружат в SciDB, чтобы потом всякие хитрые отчёты строить - отлично ложится, ИМХО

zabivator
() автор топика

Звучит хорошо, а какие у нее недостатки / слабые места? Ее рационально использовать в повседневной жизни?

zerg6p
()
Ответ на: комментарий от zerg6p

В повседневной жизни рационально использовать холодильник, зубную щётку и контрацепцию. А новость - про продукт для работы.

zabivator
() автор топика
Ответ на: комментарий от zabivator

В повседневной жизни рационально использовать холодильник, зубную щётку и контрацепцию. А новость - про продукт для работы.

Если ты используешь зубную щётку чаще, чем инструмент для работы, ты серьезно болен.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от zabivator

ну вот допустим, записи вида «время/дата, сумма денег, дебетовый счёт, кредитный счёт, тип операции»

Отчёты типичные, на пальцах приблизительно так:

1)суммы всех операций, сгруппированые по счетам, за определённый период времени

2) баланс - суммы всех операций, сгруппированных по счетам с момента начала деятельности (или расчёта предыдущего баланса) по настоящий момент

3) суммы всех операций, сгруппированые по типу, за определённый период времени


Может сабж такое?

Harald ★★★★★
()
Ответ на: комментарий от Harald

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

zabivator
() автор топика
Ответ на: комментарий от zabivator

Сможет. Только писать нужно не онлайн

ну не обязательно онлайн, предположим, записи поступают не 100500 раз в секунду, а 200-300 штук в день. Но такие отчёты нужно генерировать часто, поднимать записи за последние 20-30 лет. Их генерация занимает некоторое время.

Будет ли сабж быстрее реляционных БД на такой задаче?

Harald ★★★★★
()
Ответ на: комментарий от Harald

Да, безусловно будет быстрее Но 200-300 записей в день я бы не стал всё-таки делать :) Либо сделал бы под это дело отдельной массив, который заливал бы в основной раз в сутки и пересоздавал.

zabivator
() автор топика
Ответ на: комментарий от zabivator

При этом запросы можно делать по нескольким массивам сразу - join'ы практически бесплатные, благодаря удобной модели данных.

zabivator
() автор топика
Ответ на: комментарий от zabivator

Выгружают в многомерное пространство пользовательские данные, ищут закономерности, считают риски займов, оптимальные цены, автоматически кластеризуют клиентов

меня все еще терзают смутные сомнения насчет более классического OLAP

RedPossum ★★★★★
()
Ответ на: комментарий от RedPossum

Так это и есть OLAP, только не в гамаке на лыжах, как реляционки, а напрямую. CUBE/ROLLUP - это OLAP? Нафига этим операциям таблицы (одномерные массивы)?

zabivator
() автор топика

эквавалентный

эквивалентный

REST-full API

RESTful API

amix ★★★
()
Ответ на: комментарий от zabivator

Так это и есть OLAP, только не в гамаке на лыжах, как реляционки, а напрямую.

ну так оно и есть напрямую, к примеру у MS, ЕМНИП. И не ораклом единым. Говорю же, посмотрите в сторону MDX.

RedPossum ★★★★★
()

Банально огороженный мануал. Что может быть хуже.

These are available for the Ubuntu 12.04 platform. ScaLAPACK support for RHEL 6.3 and CentOS 6.3. will be coming shortly.

И почему я не удивлен?

anonymous
()
Ответ на: комментарий от anonymous

Под CentOS и RedHat, судя по всему, придётся перепаковать mpich и ScaLAPACK. Нам не страшно, скорей, печально - почти все зависимости под CentOS и RedHat в оффициальных репозиториях во-первых outdated, во-вторых неправильно собраны :( Например, я не видел НИ ОДНОЙ версии правильно собранного в RHEL boost. То CMake.config кривой, то пути левые, то собрано нерабочим :(

zabivator
() автор топика
Ответ на: комментарий от RedPossum

А тут массивы произвольной мерности, линейная алгебра, мат статистика, агрегаты и machine learning из коробки и эффективный. Вам всё ещё нужен MDX? Зачем?

zabivator
() автор топика
Ответ на: комментарий от zabivator

все зависимости под CentOS и RedHat в оффициальных репозиториях во-первых outdated

У Debian Squeeze тоже?

во-вторых неправильно собраны

Парни из RedHat в курсе?

anonymous
()
Ответ на: комментарий от zabivator

ЕМНИП, boost в первую очередь собирается с помощью bjam или подобного, а cmake - для экспериментаторов. Так что не надо про кривые руки maintainer'ов.

L_user
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.