URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 67352
[ Назад ]

Исходное сообщение
"Представлена новая открытая СУБД VoltDB"

Отправлено opennews , 26-Май-10 12:31 
Анонсирована (http://www.voltdb.com/voltdb-launches-next-generation-open-s... новая открытая СУБД нового поколения - VoltDB (http://community.voltdb.com/), ориентированная на обработку транзакций в реальном времени (OLTP (http://ru.wikipedia.org/wiki/OLTP)) и продемонстрировавшая способность обрабатывать миллионы транзакций в секунду на недорогом кластере, собранном своими силами из обычных серверов. Проектирование и разработка VoltDB велось под руководством Майкла Стоунбрейкера (Mike Stonebraker), одного из основателей проектов Ingres и PostgreSQL. СУБД распространяется в двух вариантах: коммерческом, с обеспечением полноценной поддержки, и свободном "Community Edition". Исходные тексты доступны в рамках лицензии GPL.

Отмечено, что VoltDB опережает по производительности традиционные OLTP СУБД в односерверной конфигурации в 45 раз, но в отличие от высокопроизводительных БД проповедующих подход NoSQL,  VoltDB поддерживает выполнение запросов на языке SQL и гарантирует...

URL: http://www.voltdb.com/voltdb-launches-next-generation-open-s...
Новость: http://www.opennet.me/opennews/art.shtml?num=26732


Содержание

Сообщения в этом обсуждении
"Представлена новая открытая СУБД VoltDB"
Отправлено i , 26-Май-10 12:36 
гарантирует транзакционную целостность данных это хорошо...
Сравнили бы с ораклом, там с увеличением CPU все нормально.

"Представлена новая открытая СУБД VoltDB"
Отправлено pro100master , 26-Май-10 13:08 
судя по джаве, господа замахнулись на наше, на святое, на оракл :)

"Представлена новая открытая СУБД VoltDB"
Отправлено tester777 , 26-Май-10 13:10 
Вот только я так и не понял как написать клиентское приложение для работы с данной СУБД на языках отличных от Java, т.е. на C/C++? На сайте нет ни слово про это, да и в SVN примеры только на Java

"Представлена новая открытая СУБД VoltDB"
Отправлено mike lee , 26-Май-10 16:21 
и для каких задач вы будете использовать такую СУБД на С/С++?

"Представлена новая открытая СУБД VoltDB"
Отправлено tester777 , 27-Май-10 10:13 
>и для каких задач вы будете использовать такую СУБД на С/С++?

Для начала хочеться посмотреть как оно работает, а с Java на знаком...


"Представлена новая открытая СУБД VoltDB"
Отправлено letsmac , 26-Май-10 14:00 
Хомячкам на заметку - ORACLE это OLAP база. А тут примитивный OLTP, даже вложенных запросов не поддерживает.

"Представлена новая открытая СУБД VoltDB"
Отправлено n , 26-Май-10 15:52 
Если ты имеешь ввиду Oracle Database Server, то это чистый OLTP.
OLAP от Oracle - это Oracle OLAP Option (дополнительные функции для сервера БД)

http://ru.wikipedia.org/wiki/OLAP


"Представлена новая открытая СУБД VoltDB"
Отправлено Аноним , 26-Май-10 14:15 
Ну круто, только это уже почти вчерашний день. Будущее за полностью распределёнными системами. Пример: на такой штуке можно было бы сделать мега-масштабируемый торрент-трекер. Но зачем? Если и так само движется к magnet-ссылкам и DHT.

"Представлена новая открытая СУБД VoltDB"
Отправлено аноним , 26-Май-10 17:38 
Сделай Банк\Склад\Accounting\GL\ERP\CRM\OLT\e.t.c. на "magnet-ссылках и DHT"
А если не сделаешь - "Ну круто, только твоя зарплата - это вчерашний день"


PS: Раньше неспособности видеть дальше своего носа стеснялись, а сейчас это типо круто да?


"Представлена новая открытая СУБД VoltDB"
Отправлено Аноним , 26-Май-10 18:20 
Ты бы не умничал, а сначала подумал. Идея "засунем всё в одну огромную бд, а потом будем думать, как сделать так, чтобы оно ещё и работала" изначально тупиковая. Только представь себе, что вместо множества банков будет один банк, где все счета всех клиентов будут храниться в ОДНОЙ базе, пусть и распределённой по 100000 внутрикорпоративных серверов. К счастью, такого ужаса никогда не будет, т. к. много независимых банков с этим справляются лучше, чем один большой и всемирный. То же самое с интернетом, подумай, почему он расцвёл, а другие сети по-тихому сдулись.

"Представлена новая открытая СУБД VoltDB"
Отправлено DeadMustdie , 26-Май-10 21:20 
> Только представь себе, что вместо множества банков будет один банк,
> где все счета всех клиентов будут храниться в ОДНОЙ базе

Не самое маловероятное событие, кстати.
Зато никаких проблем со взыскиванием долгов и отслеживанием транзакций.
Мечта большого брата, в сущности...


"Представлена новая открытая СУБД VoltDB"
Отправлено User294 , 26-Май-10 19:49 
> Если и так само движется к magnet-ссылкам и DHT.

Ну собссно DHT это по сути этакая гигантская база в стиле key-value из миллионов участников. С достаточно нехилой масштабируемостью, так что за несколько итераций ищется в невъ...нном числе записей + изрядной репликацией так что вылет 1 ноды вообще никто не замечает и это попросту вообще совершенно штатная ситуация.


"Представлена новая открытая СУБД VoltDB"
Отправлено Lefan , 26-Май-10 14:17 
ACID - это не только транзакционная целостность.
Как выполняется "D" без ведения журнала на дисках? Только за счет "автоматической репликации данных внутри кластера" в памяти узлов? Почему-то другие производители, имеющие аналогичную репликацию, считают, что этого не достаточно для Durability и все же реализуют журналирование.

"Представлена новая открытая СУБД VoltDB"
Отправлено Аноним , 26-Май-10 14:23 
А в чём разница? При наличии бесперебойного питания.

"Представлена новая открытая СУБД VoltDB"
Отправлено QuAzI , 26-Май-10 14:44 
Не бывает идеального железа. И бесперебойники дохнут и блоки питания и рейд-контроллеры.

"Представлена новая открытая СУБД VoltDB"
Отправлено Аноним , 26-Май-10 15:41 
Так и винты дохнут, и чем тогда журнал тебе поможет? А ещё я могу rm -rf сделать, неужели ACID от этого не защищает?

"Представлена новая открытая СУБД VoltDB"
Отправлено аноним , 26-Май-10 17:46 
Хоть тебе это и больно - но всё же попробуй включить моск.
Если поучится - подумай почему пишут журнал даже на системах с ECC RAM + BB RAID + UPS ...

"Представлена новая открытая СУБД VoltDB"
Отправлено Sw00p aka Jerom , 26-Май-10 20:30 
ООМ достаточно ))

журналу - да

пс: все данные хранит в ОЗУ - блин это что на одном сервере кроме бд ничего стоять не должно ???


"Представлена новая открытая СУБД VoltDB"
Отправлено Taller , 27-Май-10 02:22 
судя по всему, там на всем кластере кроме БД ничего стоять не должно.
Хотя ОС - это уже кое-что.

"Представлена новая открытая СУБД VoltDB"
Отправлено Аноним , 26-Май-10 15:53 
Ну там же репликация используется.

"Представлена новая открытая СУБД VoltDB"
Отправлено Аноним , 26-Май-10 14:48 
ну вперед, расскажи Майклу как ему надо делать СУБД

"Представлена новая открытая СУБД VoltDB"
Отправлено Lefan , 26-Май-10 15:42 
Конечно не мне рассказывать как делать СУБД. Я всего лишь указал, что в своем обзоре они не до конца раскрывают значение соответствия своей СУБД ACID принципам. Это все смахивает на маркетинг, который ориентирован на таких, как ты, уважаемый "Аноним". Вам достаточно увидеть имя "Mike Stonebraker", чтоб отключить мозг и идти за великим и могучим.

"Представлена новая открытая СУБД VoltDB"
Отправлено klalafuda , 26-Май-10 15:55 
1.3 How is ACID-compliance achieved?

Durability: VoltDB provides both replication of partitions (known as K-safety) and periodic database snapshots to ensure the availability of the data.

Т.е. снапшотами снапшотами и ещё раз снапшотами. Ну а все, что попало между ними - bad karma.


"Представлена новая открытая СУБД VoltDB"
Отправлено Crazy Alex , 26-Май-10 16:13 
А репликации разделов ни при чем? Учитывая, что разделы на разных нодах в том числе, т.е. чтобы завалить все реплики (ага, в памяти) надо угробить несколько нод.

"Представлена новая открытая СУБД VoltDB"
Отправлено Lefan , 26-Май-10 17:30 
классическое Durability подразумевает, что после полной незапланированной перезагрузки системы (включая весь кластер, т.к. питание всего ЦОД-а может тоже накрыться)данные подтвержденной транзакции сохраняться.

FYI:
MySQL Cluster тоже имеет автоматическую синхронную репликацию между нодами, но для выполнения условия "D" они вынуждены использовать журнальные логи.
C Mnesia аналогичная ситуация.
Или вы считаете, что Эриксон и создатели MySQL Cluster-а чего-то недопонимают в построение DBMS?

P.S. только не надо сейчас разводить флейм по поводу того, что можно разные узлы кластера посадить на разные UPS-ы и т.д.


"Представлена новая открытая СУБД VoltDB"
Отправлено Crazy Alex , 26-Май-10 17:41 
Нет, я считаю, что это слишком жесткое требование в 99,9% случаев реального использования. Веротяноть ухода в даун всего кластера вряд ли больше веротяности ошибки в софте, когда кривые данные будут реплицированы и записаны на диск.

"Представлена новая открытая СУБД VoltDB"
Отправлено klalafuda , 26-Май-10 15:53 
> Невероятного на первый взгляд роста производительности в VoltDB удалось добиться благодаря использованию совершенно непохожей на традиционные схемы внутренней архитектуры.

Ээээ...

1.2. What is the architecture of VoltDB?

VoltDB is an in-memory database distributed on a scalable cluster of shared-nothing servers. Transactions are defined as Java stored procedures, using ANSI-standard SQL for data access and using parallel single-threaded processing to ensure transactional consistency while avoiding the overhead of locking, latching, and resource management seen in traditional database systems.

Т.е. основная 'уникальность новой архитектуры' я так понимаю состоит в том, что все данные тупо запихали в память :-? Ну-ну. Очень здорово. Особенно для средних баз в пару-тройку терабайт.


"Представлена новая открытая СУБД VoltDB"
Отправлено аноним , 26-Май-10 17:54 
klalafuda - там и с вот этим на поверку оказалось не как в рекламе:
> using ANSI-standard SQL for data access

А в реале ЖОСТКИЙ субсет от SQL'я - для реальной работы ... того :(



"Представлена новая открытая СУБД VoltDB"
Отправлено Crazy Alex , 26-Май-10 18:52 
>klalafuda - там и с вот этим на поверку оказалось не как
>в рекламе:
>> using ANSI-standard SQL for data access
>
>А в реале ЖОСТКИЙ субсет от SQL'я - для реальной работы ...
>того :(

Ну, во-первых - в планах есть расширение понимаемого подмножества. Во-вторых - скажите спасибо, что не NoSQL. В-третьих - как раз для OLP много и не нужно - примитивные запросы/вставки в основном.


"Представлена новая открытая СУБД VoltDB"
Отправлено mef , 26-Май-10 15:54 
Это хорошая новость, но как мне попробовать эту DB через php?

"Представлена новая открытая СУБД VoltDB"
Отправлено iZEN , 26-Май-10 16:19 
Вам ещё не ясно? PHP нет места в энтерпрайзе. Этот язык создавался для домашних страничек.

"Представлена новая открытая СУБД VoltDB"
Отправлено mef , 26-Май-10 16:35 
А Java создавался для кофемолок.

"Представлена новая открытая СУБД VoltDB"
Отправлено klalafuda , 26-Май-10 17:24 

Во-первых, не для кофемолок а для пылесосов. Во-вторых, не Java а NetBSD. В-третьих, она на них так до сих пор и не работает.

"Представлена новая открытая СУБД VoltDB"
Отправлено Sw00p aka Jerom , 26-Май-10 20:35 
>
>Во-первых, не для кофемолок а для пылесосов. Во-вторых, не Java а NetBSD.
>В-третьих, она на них так до сих пор и не работает.
>

историю прочти - для кофеварок


"Представлена новая открытая СУБД VoltDB"
Отправлено Javanymous , 27-Май-10 21:42 
Для бытовых приборов, коих гораздо больше чем кофемолок.

"Представлена новая открытая СУБД VoltDB"
Отправлено mike lee , 27-Май-10 12:05 
не важно что для чего создавалось. суть в том что сейчас Java в интрепрайзе, а пхп нет.

"Представлена новая открытая СУБД VoltDB"
Отправлено XoRe , 31-Май-10 01:40 
>Это хорошая новость, но как мне попробовать эту DB через php?

Написать драйвер для этой ДБ.
В процессе написания напробуетесь)


"Представлена новая открытая СУБД VoltDB"
Отправлено gennady , 26-Май-10 19:26 
Однако:
"Все данные постоянно держатся в ОЗУ, что обеспечивает максимальную пропускную способность и исключает необходимость буферизации;"

Т.е. размер базы ограничен размером ОЗУ, отсюда и "рост производительности". Соотношение как раз как между диском и RAM. И то только на операциях чтения, а когда пойдет массированная запись она так же сдохнет уперевшись в механику систем хранения и ограничений скорости шин периферии и обмена с дисками. Особенно в распред.вычислениях, где затраты на синхронизацию и управление весьма кусаются.

"Планы на будущее:

Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);"

В InterBase (ныне FireBird) это было еще лет 10 назад...


PR очередного прожекта?


"Представлена новая открытая СУБД VoltDB"
Отправлено funky_dennis , 26-Май-10 19:54 
Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);

Особенно интересно, куда денутся те данные которые лежат в этих 32Г оперативы, после рестарта...


"Представлена новая открытая СУБД VoltDB"
Отправлено Crazy Alex , 26-Май-10 21:59 
>Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка
>СУБД);
>
>Особенно интересно, куда денутся те данные которые лежат в этих 32Г оперативы,
>после рестарта...

На диск, куда ж еще. Где большая часть и так находится (ибо снапшотами сброшена).


"Представлена новая открытая СУБД VoltDB"
Отправлено Sw00p aka Jerom , 26-Май-10 20:38 
>[оверквотинг удален]
>
>"Планы на будущее:
>
>Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка
>СУБД);"
>
>В InterBase (ныне FireBird) это было еще лет 10 назад...
>
>
>PR очередного прожекта?

отсюда один сегфолт и вся память в течке ))
рестартните сервер

пс: тупо и ещё раз тупо всё хранить в памяти
если бы Л2 или Л1 кеши были бы хотя бы в размер с ОЗУ то они умудрились бы и там хранить всё )


"Представлена новая открытая СУБД VoltDB"
Отправлено Crazy Alex , 26-Май-10 22:00 
>[оверквотинг удален]
>>
>>PR очередного прожекта?
>
>отсюда один сегфолт и вся память в течке ))
>рестартните сервер
>
>пс: тупо и ещё раз тупо всё хранить в памяти
>если бы Л2 или Л1 кеши были бы хотя бы в размер
>с ОЗУ то они умудрились бы и там хранить всё )
>

при сегфолте умерший процесс отдает память операционной системе ;-)
Ну и оно на джаве, насколько я понимаю - там скорее эксепшн


"Представлена новая открытая СУБД VoltDB"
Отправлено Sw00p aka Jerom , 27-Май-10 12:17 
а память выделенная до сегфолта ???
http://www.makelinux.net/alp/095.htm

пс: хотя там в какойто степени нечего бояться - gc поможет


"Представлена новая открытая СУБД VoltDB"
Отправлено funky_dennis , 26-Май-10 19:47 
Да йомайо - PR PR PR, TimesTen - абсолютно тоже самое, чуваки писали, что увеличили производительной бекендной базы Oracle в 10 раз, поставив перед ней фронтенд - TimesTen, при этом объясняя ускорение за счет прямой адресации страниц в памяти, ну то есть TimesTen 100% ограничен оперативой.

Ну вот у меня пару сотен гигов данных (по современным меркам - вообще семечки) и два сервера, как мне помогут их поделки?

Я и сам могу написать БД, которая будет работать только с оперативой, периодически делая срач в лог для D из ACID.

Короче, это реклама ораклу, не более.


"Представлена новая открытая СУБД VoltDB"
Отправлено DeadMustdie , 26-Май-10 21:27 
>TimesTen - абсолютно тоже самое

Да, весьма похоже. Только Oracle в плане позиционирования своего детища пограмотнее
будет и поэтому TimesTen в основном рассматривается как прослойка между "реальной"
СУБД и приложением - своего рода ускоритель.


"Представлена новая открытая СУБД VoltDB"
Отправлено Crazy Alex , 26-Май-10 22:05 
Ну а тут уже написано. И даже SQL понимает какой-никакой. В общем, добавили же софта, а не украли - чего ругаться...

"Представлена новая открытая СУБД VoltDB"
Отправлено Евгений , 28-Май-10 11:51 
Это база не попадает в категорию баз "общего назначения".
Отсюда её уникальная скорость.
Да и что понимать под RealTime?

Судя по примерам применения:

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

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

Т.е. эта штука - решение для весьма узкой ниши.

Вот тока не пойму как они обогнали по производительности MemCache?


"Представлена новая открытая СУБД VoltDB"
Отправлено Alex , 30-Май-10 22:50 
In-memory годятся только для систем, где данных не очень много, и отказ всего кластера по питанию не столь вероятен. Обычно либо первое, либо второе - ибо большие распределенные системы обрабатывают огромное количество данных, а мелкие сосредоточены в одном здании.

Короче говоря вещь интересная, будем посмотреть, но какой-то disk backend ей определенно нужен.