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

Никогда не слышал о такой. Интересно!

я уже года 3 к ним присматриваюсь ;)

Я восполняю этот пробел :)

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

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

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

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

Я уже скачал ;) Жди тестов и впечатлений в общем.

Это мы всегда ценим :)

Это что-то вроде kdb?

чем оно лучше традиционных реляционных БД с SQL?

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

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

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

Вот тут много подробностей: http://www.sai.msu.su/~megera/wiki/SciDB

Я просто покажу картинку: https://dl.dropbox.com/u/84803444/SciDB-vs-Relation.png

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

Ну, kdb платное (очень платное), в то время как SciDB - opensource.

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

Для «Ъ»:

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

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

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

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

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

в рекламном буклете.

Цен на p4 я все еще не знаю ;)

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

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

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

т.е. что-то узкоспециализированное для расчётов?

С другой стороны, интересно как ее используют банки, страховщики и ПС... :-/

Любая СУБД специализировано, а узко или нет - зависит от ваших задач.

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

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

бухгалтерские проводки в сабже хранить можно/удобно? :)

Не знаю :)

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

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

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

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

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

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

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

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

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

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


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

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

Чем?

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

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

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

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

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

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

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

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

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

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

REST-full API

RESTful API

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

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

Допустим, посмотрим. Что я должен в MDX увидеть?

Что я должен в MDX увидеть?

MDX это язык запросов для кубов.

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

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

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

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

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

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

У Debian Squeeze тоже?

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

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

У Debian Squeeze тоже?

Не проверял. boost в ubuntu собран правильно

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

Да. https://bugzilla.redhat.com/buglist.cgi?quicksearch=boost cmake

Ясно, спасибо.

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