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

[danilissimus]

>VoltDB опережает по производительности традиционные OLTP СУБД в односерверной конфигурации в 45 раз
>опережает
>Java
tell me moar.

[valergrad]

Я тоже немного не понял. В 45 раз быстрее за счет того, что все хранится в оперативной памяти? А что будет, если вдруг свет вырубят? Ну, и непонятно как быть с по-настоящему большими БД, которые в оперативку не влезут.

[noRerih]

Это вот такое, видимо, кино imdb. Сам с таким не сталкивался.

[PASSTor]

Если вырубят свет, то

Для сохранения данных на диск используется концепция снапшотов, отражающих срез данных, актуальных на момент создания снапшота

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

А по-настоящему большие БД влазят в память благодаря партицированию.

Суть архитектуры VoltDB в комбинации хранения всех данных в памяти с концепцией распределённой организации и разбиения БД по разделам (партицирование)

[mikeborozdin]

А по-настоящему большие БД влазят в память благодаря партицированию.

Суть архитектуры VoltDB в комбинации хранения всех данных в памяти с концепцией распределённой организации и разбиения БД по разделам (партицирование)

Поясни? Каким образом partitioning гаррантирует сохранность данных?

[PASSTor]

В комментарии на который я отвечал было 2 вопроса: один касался сохранности, второй размеров БД. Само по себе партицирование не гарантирует сохранность данных, а увеличивает пропускную способность.
Тем не менее, есть механизм, позволяющий увеличить сохранность, учитывая кластерную структуру, как уже написали здесь.

[shai_hulud]

троллефобия это болезнь

[noRerih]

что такое «moar»?

[Dreammaker]

«исчо»
tell me moar
аффар, пеши исчо :)

[CLR]

интернет мем, на всяких чанах особенно популярен — lurkmore.ru/Moar

[Xpeh]

thedailywtf.com/Articles/Announcing-APDB-The-Worlds-Fastest-Database.aspx для желающих истошно расхохотаться.

[Overberk]

это все конечно хорошо и красиво, но что если у меня база в несколько террабайт, где я им столько памяти нарисую. или мне предлагается сделать кластер на 100500 серверов?

[proc]

>Не понимаю я, почему в штыки воспринимаете так это всё. Какие-то поверхностные суждения без вникания в технологию.

Наверное потому что статья поверхностная.

[Zorkus]

Причем тут шаред хостинг, у меня выделенный Oracle RAC. А теперь что мне даст ваша СУБД? У меня нет и близко памяти 4 терабайта держать в них. Даже каких то жалких 400 гигов памяти не хватит держать.

[Terion]

я думаю, раз такие пироги, эта база достаточно умна, чтобы закидывать в память не все данные, если ее не хватает. проанализировать и понять, что чаще всего нужно — я думаю, разработчики это сделали.

это во-первых, а во-вторых — у вас много баз весом в террабайт?
даже у какой-нибудь популярной онлайн-игры база вряд-ли будет весить больше 20—30Гб.
а учитывая то, какой кластер нужен будет для обеспечения игры такого масштаба — то это сущие мелочи. 32Гб на узел — нынче таким никого не испугаешь.

и в третьих — в 90% (если не больше) случаев базы сайтов занимают до 100мб. ну до 200мб.
при этом для сайта с такой базой уже нужен какой-нить VPS, а это, как правило, минимум 512мб памяти (у Воли у самого дешевого сразу гиг, например).

Так что не нужно столь драматизировать и пытаться использовать вещи для того, для чего они не предназначены

[pred8or]

Там где есть многотерабайтные базы данных, распределённая обработка их особенно актуальна.

Когда несколько дней назад начала распространяться информация про VoltDB, сразу же пошёл смотреть, что за зверь. Слишком быстро выяснилось, что в очередной раз надежда не оправдалась.

[PASSTor]

А что именно не оправдало надежд? Я тоже хочу поиграться в ближайшее время.

[mikeborozdin]

Базы данных только для сайтов используются?

[Terion]

базы данных делаются универсальные, для всего сразу?

[FractalizeR]

32Гб? У меня скоро дома столько будет стоять :) Что за объем для сервера? :)

[DIegoR]

А чем вы сейчас пользуетесь?

[DIegoR]

Я почитал описание, ограничения на память в ноде там нет. Если у вас несколько терабайт — то 12 нод по 256Гб даст вам уже 3 терабайта. Главное, чтобы ваши таблицы можно было partitioning.

[PASSTor]

Данная БД скорее должна использоваться как оперативная, а уже срезы, аналитика и история могут перекочёвывать в более традиционные хранилища. Вы же не делаете запросы по всем своим террабайтам данных? А если делаете то у вас скорее кластер, что для Вольта, по идее, родная среда…

[PASSTor]

И кстати, судя по описанию, на одной машине поднимется несколько нод Вольта (по одной на процессорное ядро)

[shai_hulud]

>поддерживает выполнение запросов на языке SQL
>Работа с данными осуществляется через хранимые процедуры на языке Java, копии которых прикрепляются к каждому из разделов (ODBC/JDBC и прямое выполнение SQL-операторов для всей базы не поддерживается)

вот тут можно немного пояснений?

[Aoli]

VoltDB automatically partitions database tables across the available cluster nodes. Both the capacity and performance of the database can be increased by adding nodes to the cluster. VoltDB automatically redistributes the partitions to the new configuration when you reload the data.

VoltDB distributes the rows across the partitions using a hash partitioning scheme. The user identifies, for each partitioned table, which column is used as input to the internal hashing function. Note that not all tables have to partitioned; you can choose to replicate smaller lookup (read-intensive) tables.

Официальная дока

[TravisBickle]

Вещь в себе. Нету SQL-клиентов кроме как для erlang'а. Доки по протоколу тоже не ощущаю.

[TravisBickle]

У вас есть желание писать клиент путем reverse enginering'а и потом юзать? У меня ни малейшего. Хотя бы потому что исходный код может меняться, и следить за изменениями не представляется возможным. Для решения таких проблем придумали спецификации (другими словами соглашения).

[GamePad64]

Будущее за открытым совтом. Больше баз данных, красивых и разных!

[Danilka]

С шахматами и поэтессами.

[sylvio]

Какие-то сомнительные цифры с точностью до одной транзакции.
На каком сервере тестировалось? Какая структура БД? Какие запросы?

[Aoli]

> VoltDB обработала 53 тысячи транзакций в секунду на одном сервере, в то время как другие СУБД на том же оборудовании могли выполнить только 1155 транзакций.

Интересно, а если измерять производительность, скажем, сутки.
Как сильно будет тормозить механизм снапшотов?

[hell]

По первому впечатлению от документации — мощная штука. Но, не то, чтобы на любителя. В смысле — любитель с ней (IMHO) не справится.

Аппаратные требования — 2 и больше ядер (от 8 для оптимальной производительности)
Память — от 4 Гб

Каждой таблице сопоставляются процедуры, содержащие SQL и дополнительные обсчеты этого SQL. Фактически — каждой таблице соответствует класс Java, отвечающий за все манипуляции с таблицей.

Производительность достигается за счет партиционирования таблиц, отказа от постоянного журналирования и хранения транзакции в ОЗУ.
Крайне специфическое применение (во всяком случае — на текущий момент)

In other words, VoltDB's target audience is what have traditionally been known
as Online Transaction Processing (OLTP) applications

Есть шанс, что через пару-тройку версий их этой штуки может поллуиться нечто более, чем юзабельное (Может быть, уже получилось — но тут надо пробовать.)

[akzhan]

Ну вообще-то большая часть приложений (тех же сайтов) как раз рассчитаны на OLTP.

[hell]

Судя по документации, имеются в виду высоконагруженные (в самом полном смысле слова «высоко») проекты типа on-line бронирования, продаж или аукционов. Причем — (опять же суда по моим ощущениям — возможно, когда я документацию перечитаю более внимательно, эти ощущения изменятся) не проекты целиком, но именно их транзакционная часть. То есть что-то вроде поддержки только корзины интернет-магазина из расчета 50 килопокупок в секунду.

[el777]

Нагруженные сайты как раз в большинстве своем живут на грамотном кешировании на всех возможных уровнях.
Самая первая задача при такой оптимизации звучит так: «разгрузить базу».

[PASSTor]

это не везде возможно

[el777]

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

[vlsergey]

1) Иметь серьёзную базу данных с гарантией атомарности хорошо, но для enterprise нужен кластер. Что в этом случае с производительностью — не ясно.

2) Само понятие транзакции означает, что по её завершении обязана быть произведена запись на жёсткий диск либо результатов, либо transaction log. Если этого не делать (или делать не каждую транзакцию), то скорость разумеется возрастает, но надёжность сильно падает — БД уже нельзя назвать транзакционной.

[saterenko]

2) «Данные автоматически реплицируются внутри кластера, что позволяет добиться высокой доступности и исключает необходимость ведения журнала» — нет необходимости постоянно сбрасывать логи на диск, если упадёт одна нода, данные будут доступны на другой/других.

[vlsergey]

Если упадут ВСЕ ноды и сразу? Или если нода только одна и она упадёт?

[lovchy]

VoltDB achieves durability through intra-cluster and inter-cluster replication. Data is synchronously committed to multiple execution sites within the cluster to provide durability against node failures. Transactions are asynchronously committed between clusters to provide durability against full-cluster failures (e.g., catastrophic data center events).

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

[emendz]

Ключевое слово «asynchronously». Т.е. есть ненулевая вероятность, что СУБД отрапортовала об успешной транзакциии, но на диске ее не будет.

[lovchy]

Asynchronously в этом контексте означает, что писаться транзакции будут независимо друг от друга. Система все равно количество нод знать будет, все они будут писаться по простой мат. формуле — это же очевидно. Ну ей богу, ну неужели вы думаете, что они там _настолько_ дибилы?

[lair]

Да нет, не дибилы.

Просто надо отдавать себе отчет, что чудес — не бывает. Любое архитектурное решение — всегда компромис, выигрыш в чем-то за счет чего-то другого. Здесь, очевидно, выигрыш в производительности за счет надежности.

[bolk]

Причём тут дебилы? Теорему Брюера ещё никто не отменял.

[Alexander_Smirnov]

Тогда получается, что эта БД на одной машине не в состоянии обеспечить ACID? точнее именно последний пункт — Durability, говорящий о том что если транзакция закоммичена, то сбой ей уже не страшен. Получается ACID начинается с 2 машин в кластере…

[googol]

blog.mongodb.org/post/381927266/what-about-durability

[saterenko]

Странное какое-то сравнение с «другими СУБД», которые выдали 1155 транзакций в секунду, все СУБД одинаково 1155??? Напомнило рекламу порошка «круче других в 100500 раз».

А так решение интересное.

[lovchy]

Доставляет. Наконец кто-то собрал все _хорошие_ идеи, разбросанные по сотням постоянно появляющихся DBMS, и сделал не просто что-то новое, а что-то новое изначально не мертво-рожденное.

Если команда не сдуется, рынок ждет передел.

[bolk]

Если гарантируется «D» (из ACID), то данные полюбому скидываются на диск при записи. Этот момент как они оптимизировали? Что-то нечисто тут со сравнением с другими СУБД.

[Alexander_Smirnov]

Этот момент уже обсуждается выше. Но на мой взгляд ваша фраза показательна, именно благодаря тому, что у людей получилось посмотреть на проблему немного по другому — у них получилось интересное решение.

[alexbozhko]

Результаты TPC тестов есть?

tpc.org

[TDz]

Она ещё в пелёнках эта VoltDB — да, новая СУБД на рынке OLTP, ей понадобятся годы чтобы убедить людей не смотреть в сторону того же MySQL Cluster. То что она обгоняет обычные СУБД которые вообще не предназначены для OLTP это ни о чём не говорит как и цифра в 53к tps, тот же nbd выдавал в тестах уже миллион транзакций в секунду на одной машине, для баз полностью в памяти нет в этом никакой фантастики. А отложенные синки на диск это фрукт в себе, я думаю через полгодика можно будет думать о VoltDB, а пока о ней нужно только читать :)

[mas]

> VoltDB обработала 53 тысячи транзакций в секунду на одном сервере, в то время как другие СУБД на том же оборудовании могли выполнить только 1155 транзакций

Kdb меряли?

[romx]

> ориентированная на обработку транзакций в реальном времени (OLTP)

Вообще-то OLTP вовсе не означает «обработку транзакций в реальном времени».

[insa]

Я так понимаю, что ребята решили пожертвовать Partition-tolerance в обмен на производительность. Непонятно, что будет если одна из нод кластера решит прилечь. Во всех FAQ этот вопрос игнорируется.

Так же интересно посмотреть как происходит JOIN для данных расположенных на разных нодах.

И непонятно что у них с лицензией. На сайте пишут GPL v3, в исходниках встречаются GPL, MIT и BSD.

[Zubchick]

ни GPL ни MIT ни BSD не мешают выпустить конечный продут под GPL3

[yul]

без ссылок на сами тесты «в 45 раз быстрее» и т.п. сложно воспринимать адекватно.

[just_vladimir]

Где бенчмарки? иначе цифры выглядят голословными

[ainu]

А если смонтировать кусок оперативки в качестве диска и в него установить MySQL, то скорость тоже станет в 45 раз быстрее.
А если поступиь как википедия, и поставить зеркала баз на десятке серверов, с одним мастер-сервером, то вот и кластер получится.

[Scala]

Если бы большинство комментаторов прочитали хотя бы статью на википедии про Стойнбрейкера, думаю было бы куда меньше подколов и сомнений.

[ikatkov]

погуглил «Стойнбрейкер» ничего не нашёл, можно ссылку или анг. написание?

[aleksandrit]

en.wikipedia.org/wiki/Michael_Stonebraker

[diky13]

Я так понял, что вы уже погоняли данную базу.
Интересно сравнение с другими бесплатными базами.
Мы сейчас используем Nexus, интересно было бы сравнить.
Реально о производительности можно говорить только при сравнении на действующих проектах.
Если есть инфа, то просьба поделится.
Заявленные характеристики удивили.

[super_p]

Еще одна MongoDB