The OpenNET Project / Index page

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

Представлена новая открытая СУБД VoltDB

26.05.2010 11:48

Анонсирована новая открытая СУБД нового поколения - VoltDB, ориентированная на обработку транзакций в реальном времени (OLTP) и продемонстрировавшая способность обрабатывать миллионы транзакций в секунду на недорогом кластере, собранном своими силами из обычных серверов. Проектирование и разработка VoltDB велась под руководством Майкла Стоунбрейкера (Mike Stonebraker), одного из основателей проектов Ingres и PostgreSQL. СУБД распространяется в двух вариантах: коммерческом, с обеспечением полноценной поддержки, и свободном "Community Edition". Исходные тексты доступны в рамках лицензии GPL.

Отмечено, что VoltDB опережает по производительности традиционные OLTP СУБД в односерверной конфигурации в 45 раз, но в отличие от высокопроизводительных БД проповедующих подход NoSQL, VoltDB поддерживает выполнение запросов на языке SQL и гарантирует транзакционную целостность данных (ACID, атомарность и изолированность транзакций). По заявлению разработчиков, пре-релиз VoltDB можно рассматривать как стабильный, он уже несколько месяцев используется в компании Getco, бизнес которой связан с электронными финансовыми торгами, и продемонстрировал непревзойденные показатели производительности и масштабируемости. Другим примером внедрения VoltDB являются online-игры студии Eonblast, по данным которой производительности при использовании VoltDB опережает классические решения на базе MySQL с кешированием в Memcached.

Невероятного на первый взгляд роста производительности в VoltDB удалось добиться благодаря использованию совершенно непохожей на традиционные схемы внутренней архитектуры. Типичные современные OLTP СУБД используют те же приемы, что и 30 лет назад и очень трудно масштабируются при увеличении числа CPU или узлов в кластере. Исследование показало, что в таких СУБД более 90% времени тратится на такие операции, как ведение журнала, обеспечение блокировок, фиксацию изменений и управление буферизацией.

Суть архитектуры VoltDB в комбинации хранения всех данных в памяти с концепцией распределенной организации и разбиения БД по разделам (партицирование). СУБД VoltDB оптимизирована для работы на современных серверах, снабженных большим количеством ОЗУ и многоядерными CPU. Для сохранения данных на диск используется концепция снапшотов, отражающих срез данных, актуальных на момент создания снапшота. Работа с данными осуществляется через хранимые процедуры на языке Java, копии которых прикрепляются к каждому из разделов (ODBC/JDBC и прямое выполнение SQL-операторов для всей базы не поддерживается). При выполнении запроса, затрагивающего несколько разделов, в каждом из нужных разделов вызывается хранимая процедура, а затем результаты агрегируются.

Основные элементы архитектуры VoltDB:

  • Все данные постоянно держатся в ОЗУ, что обеспечивает максимальную пропускную способность и исключает необходимость буферизации;
  • VoltDB распределяет данные и их SQL-обработчики по узлам, каждый из который привязан к своему процессорному ядру (на одном сервере запускается столько узлов VoltDB сколько ядер CPU);
  • Каждый однопоточный раздел работает в автономном режиме, что исключает необходимость в блокировках и фиксации операций;
  • Данные автоматически реплицируются внутри кластера, что позволяет добиться высокой доступности и исключает необходимость ведения журнала;
  • Производительность VoltDB увеличивается почти линейно при добавлении дополнительных серверов в кластер.

Результаты измерения производительности:

  • СУБД VoltDB обработала 53 тыс. транзакций в секунду на одном сервере, в то время как другие СУБД на том же оборудовании могли выполнить только 1155 транзакций. При увеличении числа серверов до 12, кластер позволил выполнить 560 тыс транзакций в сек.
  • Тестирование работы online-игры на 12-узловом кластере продемонстрировало производительность в 1.3 млн. транзакций в сек.
  • При сравнении VoltDB с NoSQL-базами, оперирующими данными в виде ключ/значение, производительность VoltDB была на уровне или выше рассматриваемых систем.

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

  • Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);
  • Набор инструментов для мониторинга кластера;
  • Интерфейс для доступа клиентов с использованием формата JSON;
  • Увеличение производительности транзакции для выполнения которых необходимо привлечение данных из нескольких разделов;
  • Расширение поддерживаемого синтаксиса SQL (сейчас поддерживаются только простейшие операции);
  • Возможность автоматической замены сбойного узла на лету;
  • Расширение возможностей по экспорту данных из БД;
  • Поддержка WAN-репликации между территориально разделенными узлами;
  • Возможность подключения новых узлов к кластеру на лету и вывод узлов без остановки кластера.


  1. Главная ссылка к новости (http://www.voltdb.com/voltdb-l...)
Лицензия: CC-BY
Тип: Интересно / К сведению
Короткая ссылка: https://opennet.ru/26732-voltdb
Ключевые слова: voltdb, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (48) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, i (??), 12:36, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    гарантирует транзакционную целостность данных это хорошо...
    Сравнили бы с ораклом, там с увеличением CPU все нормально.
     
  • 1.4, pro100master (ok), 13:08, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    судя по джаве, господа замахнулись на наше, на святое, на оракл :)
     
  • 1.5, tester777 (?), 13:10, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот только я так и не понял как написать клиентское приложение для работы с данной СУБД на языках отличных от Java, т.е. на C/C++? На сайте нет ни слово про это, да и в SVN примеры только на Java
     
     
  • 2.21, mike lee (?), 16:21, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    и для каких задач вы будете использовать такую СУБД на С/С++?
     
     
  • 3.53, tester777 (?), 10:13, 27/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >и для каких задач вы будете использовать такую СУБД на С/С++?

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

     

  • 1.6, letsmac (?), 14:00, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хомячкам на заметку - ORACLE это OLAP база. А тут примитивный OLTP, даже вложенных запросов не поддерживает.
     
     
  • 2.14, n (??), 15:52, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если ты имеешь ввиду Oracle Database Server, то это чистый OLTP.
    OLAP от Oracle - это Oracle OLAP Option (дополнительные функции для сервера БД)

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

     

  • 1.7, Аноним (-), 14:15, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    Ну круто, только это уже почти вчерашний день. Будущее за полностью распределёнными системами. Пример: на такой штуке можно было бы сделать мега-масштабируемый торрент-трекер. Но зачем? Если и так само движется к magnet-ссылкам и DHT.
     
     
  • 2.25, аноним (?), 17:38, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Сделай Банк\Склад\Accounting\GL\ERP\CRM\OLT\e.t.c. на "magnet-ссылках и DHT"
    А если не сделаешь - "Ну круто, только твоя зарплата - это вчерашний день"


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

     
     
  • 3.31, Аноним (-), 18:20, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Ты бы не умничал, а сначала подумал. Идея "засунем всё в одну огромную бд, а потом будем думать, как сделать так, чтобы оно ещё и работала" изначально тупиковая. Только представь себе, что вместо множества банков будет один банк, где все счета всех клиентов будут храниться в ОДНОЙ базе, пусть и распределённой по 100000 внутрикорпоративных серверов. К счастью, такого ужаса никогда не будет, т. к. много независимых банков с этим справляются лучше, чем один большой и всемирный. То же самое с интернетом, подумай, почему он расцвёл, а другие сети по-тихому сдулись.
     
     
  • 4.45, DeadMustdie (??), 21:20, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Только представь себе, что вместо множества банков будет один банк,
    > где все счета всех клиентов будут храниться в ОДНОЙ базе

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

     
  • 2.39, User294 (ok), 19:49, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если и так само движется к magnet-ссылкам и DHT.

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

     

  • 1.8, Lefan (?), 14:17, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ACID - это не только транзакционная целостность.
    Как выполняется "D" без ведения журнала на дисках? Только за счет "автоматической репликации данных внутри кластера" в памяти узлов? Почему-то другие производители, имеющие аналогичную репликацию, считают, что этого не достаточно для Durability и все же реализуют журналирование.
     
     
  • 2.9, Аноним (-), 14:23, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А в чём разница? При наличии бесперебойного питания.
     
     
  • 3.10, QuAzI (??), 14:44, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не бывает идеального железа. И бесперебойники дохнут и блоки питания и рейд-контроллеры.
     
     
  • 4.12, Аноним (-), 15:41, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Так и винты дохнут, и чем тогда журнал тебе поможет? А ещё я могу rm -rf сделать, неужели ACID от этого не защищает?
     
     
  • 5.27, аноним (?), 17:46, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хоть тебе это и больно - но всё же попробуй включить моск.
    Если поучится - подумай почему пишут журнал даже на системах с ECC RAM + BB RAID + UPS ...
     
     
  • 6.41, Sw00p aka Jerom (?), 20:30, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ООМ достаточно ))

    журналу - да

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

     
     
  • 7.52, Taller (?), 02:22, 27/05/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    судя по всему, там на всем кластере кроме БД ничего стоять не должно.
    Хотя ОС - это уже кое-что.
     
  • 4.16, Аноним (-), 15:53, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну там же репликация используется.
     
  • 2.11, Аноним (-), 14:48, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ну вперед, расскажи Майклу как ему надо делать СУБД
     
     
  • 3.13, Lefan (?), 15:42, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно не мне рассказывать как делать СУБД. Я всего лишь указал, что в своем обзоре они не до конца раскрывают значение соответствия своей СУБД ACID принципам. Это все смахивает на маркетинг, который ориентирован на таких, как ты, уважаемый "Аноним". Вам достаточно увидеть имя "Mike Stonebraker", чтоб отключить мозг и идти за великим и могучим.
     
     
  • 4.18, klalafuda (?), 15:55, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    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.

     
     
  • 5.19, Crazy Alex (??), 16:13, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А репликации разделов ни при чем? Учитывая, что разделы на разных нодах в том числе, т.е. чтобы завалить все реплики (ага, в памяти) надо угробить несколько нод.
     
     
  • 6.24, Lefan (?), 17:30, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    классическое Durability подразумевает, что после полной незапланированной перезагрузки системы (включая весь кластер, т.к. питание всего ЦОД-а может тоже накрыться)данные подтвержденной транзакции сохраняться.

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

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

     
     
  • 7.26, Crazy Alex (??), 17:41, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, я считаю, что это слишком жесткое требование в 99,9% случаев реального использования. Веротяноть ухода в даун всего кластера вряд ли больше веротяности ошибки в софте, когда кривые данные будут реплицированы и записаны на диск.
     

  • 1.15, klalafuda (?), 15:53, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Невероятного на первый взгляд роста производительности в 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.

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

     
     
  • 2.29, аноним (?), 17:54, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    klalafuda - там и с вот этим на поверку оказалось не как в рекламе:
    > using ANSI-standard SQL for data access

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


     
     
  • 3.34, Crazy Alex (??), 18:52, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >klalafuda - там и с вот этим на поверку оказалось не как
    >в рекламе:
    >> using ANSI-standard SQL for data access
    >
    >А в реале ЖОСТКИЙ субсет от SQL'я - для реальной работы ...
    >того :(

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

     

  • 1.17, mef (ok), 15:54, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Это хорошая новость, но как мне попробовать эту DB через php?
     
     
  • 2.20, iZEN (ok), 16:19, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вам ещё не ясно? PHP нет места в энтерпрайзе. Этот язык создавался для домашних страничек.
     
     
  • 3.22, mef (ok), 16:35, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А Java создавался для кофемолок.
     
     
  • 4.23, klalafuda (?), 17:24, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/

    Во-первых, не для кофемолок а для пылесосов. Во-вторых, не Java а NetBSD. В-третьих, она на них так до сих пор и не работает.
     
     
  • 5.43, Sw00p aka Jerom (?), 20:35, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >
    >Во-первых, не для кофемолок а для пылесосов. Во-вторых, не Java а NetBSD.
    >В-третьих, она на них так до сих пор и не работает.
    >

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

     
     
  • 6.56, Javanymous (?), 21:42, 27/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Для бытовых приборов, коих гораздо больше чем кофемолок.
     
  • 4.54, mike lee (?), 12:05, 27/05/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    не важно что для чего создавалось. суть в том что сейчас Java в интрепрайзе, а пхп нет.
     
  • 2.59, XoRe (ok), 01:40, 31/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Это хорошая новость, но как мне попробовать эту DB через php?

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

     

  • 1.36, gennady (??), 19:26, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Однако:
    "Все данные постоянно держатся в ОЗУ, что обеспечивает максимальную пропускную способность и исключает необходимость буферизации;"

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

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

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

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


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

     
     
  • 2.40, funky_dennis (?), 19:54, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка СУБД);

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

     
     
  • 3.49, Crazy Alex (??), 21:59, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Возможность изменения схемы БД на лету (сейчас для изменения структуры требуется остановка
    >СУБД);
    >
    >Особенно интересно, куда денутся те данные которые лежат в этих 32Г оперативы,
    >после рестарта...

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

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

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

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

     
     
  • 3.50, Crazy Alex (??), 22:00, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >[оверквотинг удален]
    >>
    >>PR очередного прожекта?
    >
    >отсюда один сегфолт и вся память в течке ))
    >рестартните сервер
    >
    >пс: тупо и ещё раз тупо всё хранить в памяти
    >если бы Л2 или Л1 кеши были бы хотя бы в размер
    >с ОЗУ то они умудрились бы и там хранить всё )
    >

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

     
     
  • 4.55, Sw00p aka Jerom (?), 12:17, 27/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    а память выделенная до сегфолта ???
    http://www.makelinux.net/alp/095.htm

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

     

  • 1.37, funky_dennis (?), 19:47, 26/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Да йомайо - PR PR PR, TimesTen - абсолютно тоже самое, чуваки писали, что увеличили производительной бекендной базы Oracle в 10 раз, поставив перед ней фронтенд - TimesTen, при этом объясняя ускорение за счет прямой адресации страниц в памяти, ну то есть TimesTen 100% ограничен оперативой.

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

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

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

     
     
  • 2.47, DeadMustdie (??), 21:27, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >TimesTen - абсолютно тоже самое

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

     
  • 2.51, Crazy Alex (??), 22:05, 26/05/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а тут уже написано. И даже SQL понимает какой-никакой. В общем, добавили же софта, а не украли - чего ругаться...
     

  • 1.57, Евгений (??), 11:51, 28/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это база не попадает в категорию баз "общего назначения".
    Отсюда её уникальная скорость.
    Да и что понимать под RealTime?

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

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

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

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

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

     
  • 1.58, Alex (??), 22:50, 30/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    In-memory годятся только для систем, где данных не очень много, и отказ всего кластера по питанию не столь вероятен. Обычно либо первое, либо второе - ибо большие распределенные системы обрабатывают огромное количество данных, а мелкие сосредоточены в одном здании.

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

     

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



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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