Анонсирована (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...
Новость: https://www.opennet.ru/opennews/art.shtml?num=26732
гарантирует транзакционную целостность данных это хорошо...
Сравнили бы с ораклом, там с увеличением CPU все нормально.
судя по джаве, господа замахнулись на наше, на святое, на оракл :)
Вот только я так и не понял как написать клиентское приложение для работы с данной СУБД на языках отличных от Java, т.е. на C/C++? На сайте нет ни слово про это, да и в SVN примеры только на Java
и для каких задач вы будете использовать такую СУБД на С/С++?
>и для каких задач вы будете использовать такую СУБД на С/С++?Для начала хочеться посмотреть как оно работает, а с Java на знаком...
Хомячкам на заметку - ORACLE это OLAP база. А тут примитивный OLTP, даже вложенных запросов не поддерживает.
Если ты имеешь ввиду Oracle Database Server, то это чистый OLTP.
OLAP от Oracle - это Oracle OLAP Option (дополнительные функции для сервера БД)
Ну круто, только это уже почти вчерашний день. Будущее за полностью распределёнными системами. Пример: на такой штуке можно было бы сделать мега-масштабируемый торрент-трекер. Но зачем? Если и так само движется к magnet-ссылкам и DHT.
Сделай Банк\Склад\Accounting\GL\ERP\CRM\OLT\e.t.c. на "magnet-ссылках и DHT"
А если не сделаешь - "Ну круто, только твоя зарплата - это вчерашний день"
PS: Раньше неспособности видеть дальше своего носа стеснялись, а сейчас это типо круто да?
Ты бы не умничал, а сначала подумал. Идея "засунем всё в одну огромную бд, а потом будем думать, как сделать так, чтобы оно ещё и работала" изначально тупиковая. Только представь себе, что вместо множества банков будет один банк, где все счета всех клиентов будут храниться в ОДНОЙ базе, пусть и распределённой по 100000 внутрикорпоративных серверов. К счастью, такого ужаса никогда не будет, т. к. много независимых банков с этим справляются лучше, чем один большой и всемирный. То же самое с интернетом, подумай, почему он расцвёл, а другие сети по-тихому сдулись.
> Только представь себе, что вместо множества банков будет один банк,
> где все счета всех клиентов будут храниться в ОДНОЙ базеНе самое маловероятное событие, кстати.
Зато никаких проблем со взыскиванием долгов и отслеживанием транзакций.
Мечта большого брата, в сущности...
> Если и так само движется к magnet-ссылкам и DHT.Ну собссно DHT это по сути этакая гигантская база в стиле key-value из миллионов участников. С достаточно нехилой масштабируемостью, так что за несколько итераций ищется в невъ...нном числе записей + изрядной репликацией так что вылет 1 ноды вообще никто не замечает и это попросту вообще совершенно штатная ситуация.
ACID - это не только транзакционная целостность.
Как выполняется "D" без ведения журнала на дисках? Только за счет "автоматической репликации данных внутри кластера" в памяти узлов? Почему-то другие производители, имеющие аналогичную репликацию, считают, что этого не достаточно для Durability и все же реализуют журналирование.
А в чём разница? При наличии бесперебойного питания.
Не бывает идеального железа. И бесперебойники дохнут и блоки питания и рейд-контроллеры.
Так и винты дохнут, и чем тогда журнал тебе поможет? А ещё я могу rm -rf сделать, неужели ACID от этого не защищает?
Хоть тебе это и больно - но всё же попробуй включить моск.
Если поучится - подумай почему пишут журнал даже на системах с ECC RAM + BB RAID + UPS ...
ООМ достаточно ))журналу - да
пс: все данные хранит в ОЗУ - блин это что на одном сервере кроме бд ничего стоять не должно ???
судя по всему, там на всем кластере кроме БД ничего стоять не должно.
Хотя ОС - это уже кое-что.
Ну там же репликация используется.
ну вперед, расскажи Майклу как ему надо делать СУБД
Конечно не мне рассказывать как делать СУБД. Я всего лишь указал, что в своем обзоре они не до конца раскрывают значение соответствия своей СУБД ACID принципам. Это все смахивает на маркетинг, который ориентирован на таких, как ты, уважаемый "Аноним". Вам достаточно увидеть имя "Mike Stonebraker", чтоб отключить мозг и идти за великим и могучим.
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.
А репликации разделов ни при чем? Учитывая, что разделы на разных нодах в том числе, т.е. чтобы завалить все реплики (ага, в памяти) надо угробить несколько нод.
классическое Durability подразумевает, что после полной незапланированной перезагрузки системы (включая весь кластер, т.к. питание всего ЦОД-а может тоже накрыться)данные подтвержденной транзакции сохраняться.FYI:
MySQL Cluster тоже имеет автоматическую синхронную репликацию между нодами, но для выполнения условия "D" они вынуждены использовать журнальные логи.
C Mnesia аналогичная ситуация.
Или вы считаете, что Эриксон и создатели MySQL Cluster-а чего-то недопонимают в построение DBMS?P.S. только не надо сейчас разводить флейм по поводу того, что можно разные узлы кластера посадить на разные UPS-ы и т.д.
Нет, я считаю, что это слишком жесткое требование в 99,9% случаев реального использования. Веротяноть ухода в даун всего кластера вряд ли больше веротяности ошибки в софте, когда кривые данные будут реплицированы и записаны на диск.
> Невероятного на первый взгляд роста производительности в 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.
Т.е. основная 'уникальность новой архитектуры' я так понимаю состоит в том, что все данные тупо запихали в память :-? Ну-ну. Очень здорово. Особенно для средних баз в пару-тройку терабайт.
klalafuda - там и с вот этим на поверку оказалось не как в рекламе:
> using ANSI-standard SQL for data accessА в реале ЖОСТКИЙ субсет от SQL'я - для реальной работы ... того :(
>klalafuda - там и с вот этим на поверку оказалось не как
>в рекламе:
>> using ANSI-standard SQL for data access
>
>А в реале ЖОСТКИЙ субсет от SQL'я - для реальной работы ...
>того :(Ну, во-первых - в планах есть расширение понимаемого подмножества. Во-вторых - скажите спасибо, что не NoSQL. В-третьих - как раз для OLP много и не нужно - примитивные запросы/вставки в основном.
Это хорошая новость, но как мне попробовать эту DB через php?
Вам ещё не ясно? PHP нет места в энтерпрайзе. Этот язык создавался для домашних страничек.
А Java создавался для кофемолок.
Во-первых, не для кофемолок а для пылесосов. Во-вторых, не Java а NetBSD. В-третьих, она на них так до сих пор и не работает.
>
>Во-первых, не для кофемолок а для пылесосов. Во-вторых, не Java а NetBSD.
>В-третьих, она на них так до сих пор и не работает.
>историю прочти - для кофеварок
Для бытовых приборов, коих гораздо больше чем кофемолок.
не важно что для чего создавалось. суть в том что сейчас Java в интрепрайзе, а пхп нет.
>Это хорошая новость, но как мне попробовать эту DB через php?Написать драйвер для этой ДБ.
В процессе написания напробуетесь)
Однако:
"Все данные постоянно держатся в ОЗУ, что обеспечивает максимальную пропускную способность и исключает необходимость буферизации;"Т.е. размер базы ограничен размером ОЗУ, отсюда и "рост производительности". Соотношение как раз как между диском и RAM. И то только на операциях чтения, а когда пойдет массированная запись она так же сдохнет уперевшись в механику систем хранения и ограничений скорости шин периферии и обмена с дисками. Особенно в распред.вычислениях, где затраты на синхронизацию и управление весьма кусаются.
"Планы на будущее:
Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);"
В InterBase (ныне FireBird) это было еще лет 10 назад...
PR очередного прожекта?
Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);Особенно интересно, куда денутся те данные которые лежат в этих 32Г оперативы, после рестарта...
>Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка
>СУБД);
>
>Особенно интересно, куда денутся те данные которые лежат в этих 32Г оперативы,
>после рестарта...На диск, куда ж еще. Где большая часть и так находится (ибо снапшотами сброшена).
>[оверквотинг удален]
>
>"Планы на будущее:
>
>Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка
>СУБД);"
>
>В InterBase (ныне FireBird) это было еще лет 10 назад...
>
>
>PR очередного прожекта?отсюда один сегфолт и вся память в течке ))
рестартните серверпс: тупо и ещё раз тупо всё хранить в памяти
если бы Л2 или Л1 кеши были бы хотя бы в размер с ОЗУ то они умудрились бы и там хранить всё )
>[оверквотинг удален]
>>
>>PR очередного прожекта?
>
>отсюда один сегфолт и вся память в течке ))
>рестартните сервер
>
>пс: тупо и ещё раз тупо всё хранить в памяти
>если бы Л2 или Л1 кеши были бы хотя бы в размер
>с ОЗУ то они умудрились бы и там хранить всё )
>при сегфолте умерший процесс отдает память операционной системе ;-)
Ну и оно на джаве, насколько я понимаю - там скорее эксепшн
а память выделенная до сегфолта ???
http://www.makelinux.net/alp/095.htmпс: хотя там в какойто степени нечего бояться - gc поможет
Да йомайо - PR PR PR, TimesTen - абсолютно тоже самое, чуваки писали, что увеличили производительной бекендной базы Oracle в 10 раз, поставив перед ней фронтенд - TimesTen, при этом объясняя ускорение за счет прямой адресации страниц в памяти, ну то есть TimesTen 100% ограничен оперативой.Ну вот у меня пару сотен гигов данных (по современным меркам - вообще семечки) и два сервера, как мне помогут их поделки?
Я и сам могу написать БД, которая будет работать только с оперативой, периодически делая срач в лог для D из ACID.
Короче, это реклама ораклу, не более.
>TimesTen - абсолютно тоже самоеДа, весьма похоже. Только Oracle в плане позиционирования своего детища пограмотнее
будет и поэтому TimesTen в основном рассматривается как прослойка между "реальной"
СУБД и приложением - своего рода ускоритель.
Ну а тут уже написано. И даже SQL понимает какой-никакой. В общем, добавили же софта, а не украли - чего ругаться...
Это база не попадает в категорию баз "общего назначения".
Отсюда её уникальная скорость.
Да и что понимать под RealTime?Судя по примерам применения:
Онлайн игры, обрабатывать нужно быстро, но данные не столь критичны. Откат до ближайшего снапшота вполне приемлем.
Онлайн торги: возможно полностью аналогично предыдущему. Данных приходит много, накопление статистики, но сами данные не столь критичны, если будут пропущены.
Т.е. эта штука - решение для весьма узкой ниши.
Вот тока не пойму как они обогнали по производительности MemCache?
In-memory годятся только для систем, где данных не очень много, и отказ всего кластера по питанию не столь вероятен. Обычно либо первое, либо второе - ибо большие распределенные системы обрабатывают огромное количество данных, а мелкие сосредоточены в одном здании.Короче говоря вещь интересная, будем посмотреть, но какой-то disk backend ей определенно нужен.