Представлен (http://blog.voltdb.com/introducing-voltdb-3-0/) релиз инновационной открытой СУБД VoltDB 3.0 (http://voltdb.com/), развиваемой под руководством Майкла Стоунбрейкера (Mike Stonebraker), одного из основателей проектов Ingres и PostgreSQL. СУБД VoltDB поддерживает горизонтальное масштабирование и ориентирована на обработку транзакций в реальном времени (OLTP). На недорогом кластере, собранном своими силами из обычных серверов, СУБД способна обрабатывать миллионы транзакций в секунду. СУБД распространяется в двух вариантах: коммерческом, с обеспечением полноценной поддержки, и свободном "Community Edition (http://voltdb.com/community/downloads.php)". Код опубликован (https://github.com/VoltDB/voltdb/) под лицензией AGPLv3.VoltDB позволяет достичь уровня производительности NoSQL-систем, сохранив при этом поддержку выполнения запросов на языке SQL и гарантирированную транзакционную целостность данных (ACID, атомарность и изолированность транзакций). При оценке производительности в односерверной конфигурации СУБД VoltDB опередила (http://voltdb.com/docs/UsingVoltDB/ChapOverview.php) традиционные OLTP СУБД в 45 раз, обработав 53 тыс. транзакций в секунду, в то время как другие СУБД на том же оборудовании могли выполнить только 1155 транзакций. На 12-уловом кластере СУБД VoltDB обеспечила выполнение 560 тыс. транзакций в сек. При этом, VoltDB уже достаточно давно используется в промышленной эксплуатации и позиционируется как полностью стабильный продукт.
Разгадка высокой производительности VoltDB кроется в непохожей на традиционные схемы внутренней архитектуре, комбинирующей хранение данных в памяти с концепцией распределенной организации и разбиением содержимого БД по разделам (партицирование). Производительность VoltDB увеличивается почти линейно при добавлении дополнительных серверов в кластер. Каждый однопоточный раздел работает в автономном режиме, что исключает необходимость в блокировках и фиксации операций. Данные автоматически реплицируются внутри кластера, что позволяет добиться высокой доступности и исключает необходимость ведения журнала. Все данные каждого узла полностью прокэшированы в ОЗУ, что обеспечивает максимальную пропускную способность и исключает необходимость буферизации.
На одном сервере запускается несколько узлов VoltDB, каждый из которых привязывается к отдельному ядру CPU. Для сохранения данных на диск используется концепция снапшотов, отражающих срез данных, актуальных на момент создания снапшота. Работа с данными осуществляется через хранимые процедуры на языке Java, копии которых прикрепляются к каждому из разделов (ODBC/JDBC и прямое выполнение SQL-операторов для всей базы не поддерживается). При выполнении запроса, затрагивающего несколько разделов, в каждом из нужных разделов вызывается хранимая процедура, а затем результаты агрегируются.Среди новшеств, добавленных в VoltDB 3.0:
- Переработана архитектура координации выполнения транзакций, что позволило минимизировать обмен данными между узлами в процессе выполнения запроса. В результате была увеличена пропускная способность и уменьшена задержка выполнения запросов. По сравнению с VoltDB 2.x версия 3.0 позволяет выполнить на том же оборудовании гораздо больше транзакций и существенно снизить задержки для работающих в синхронном режиме клиентов, в которых выполнение продолжается только после завершения каждого запроса (в асинхронном режиме управление передаётся дальше не дожидаясь выполнения запроса, готовность которого оценивается через обработку событий);<center><a href="http://blog.voltdb.com/wp-content/uploads/2013/01/Screen-Sho... src="https://www.opennet.ru/opennews/pics_base/0_1359134189.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
- Для упрощения разработки высокопроизводительных приложений добавлена поддержка шаблона project.xml для размещения данных в кластере и команды compile для автоматической компиляции схемы. Расширены возможности изменения схемы БД на лету, добавлены команды для создания и изменения индексов, применимые для работающего кластера;
<center><a href="http://blog.voltdb.com/wp-content/uploads/2013/01/AppCatalog... src="https://www.opennet.ru/opennews/pics_base/0_1359134873.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
- Расширен поддерживаемый синтаксис SQL, добавлена возможность использования выражения UNION и операторов LIKE/NOT LIKE, подготовлен полный набор строковых и числовых функций. Реализована поддержка определения индексов с использованием функций, работающих на уровне столбцов;
- Реализован интерфейс для доступа к данным с использованием формата JSON. Указанная возможность позволяет гибко управлять и менять схему хранения, которая теперь может задаваться в произвольном виде. Для манипуляции со структурированными JSON-данными, прикреплёнными к столбцу, представлена новая функция field();- Новые средства для импорта и экспорта данных. Добавлены модули для импорта данных из лога Apache и из CSV-файлов. Переработана поддержка экспорта, отмечается, что новая реализация экспортирует данные в 20 раз быстрее прежней. Добавлен JDBC-коннектор для экспорта данных в СУБД PostgreSQL, Oracle и MySQL;
- Новая утилита voltadmin с реализация интерфейса командной строки для централизованного управления всем кластером VoltDB;
- Добавлен переработанный высокопроизводительный драйвер для PHP и новые драйверы для Node.js и Google Go.
URL: http://blog.voltdb.com/introducing-voltdb-3-0/
Новость: https://www.opennet.ru/opennews/art.shtml?num=35927
Какая-то просто сказка а не СУБД...
на java. отсяюда и сказки и росказни про недорого.
хейтер детектед?сам не пробовал, но осудить всегда рад?
> Какая-то просто сказка а не СУБД...Похоже она не реляционная, оттуда и бонусы.
нереляционная
Все данные каждого узла полностью прокэшированы в ОЗУ...
Не слишком ли жирно?
> Все данные каждого узла полностью прокэшированы в ОЗУ...
> Не слишком ли жирно?Время сейчас такое, оперативная память стоит не дорого, вот и оптимизация идет за ее счет. На мой взгляд, и SSD уже не такое дорогое удовольствие, так что теперь ПО теперь можно оптимизировать только за счет железа. Как бы противоречиво это не звучало, ПО надо проектировать с учетом минимальных системных требований, но с максимальной функциональностью под поставленные задачи. Раньше было слабое железо и все старались писать код оптимально, ковырялись в нем часами, только ради того найти оптимальное решение для максимального быстродействия.
> На мой взгляд, и SSD уже не такое
> дорогое удовольствие, так что теперь ПО теперь можно оптимизировать только за
> счет железа.SSD не панацея.
Неоптимальные алгоритмы могут свести на нет любые бонусы от железа.
Например, если для получения ФИО одного юзера, вы делаете select * from users;
>> На мой взгляд, и SSD уже не такое
>> дорогое удовольствие, так что теперь ПО теперь можно оптимизировать только за
>> счет железа.
> SSD не панацея.
> Неоптимальные алгоритмы могут свести на нет любые бонусы от железа.
> Например, если для получения ФИО одного юзера, вы делаете select * from
> users;Так кодируют только м*даки.
>>> На мой взгляд, и SSD уже не такое
>>> дорогое удовольствие, так что теперь ПО теперь можно оптимизировать только за
>>> счет железа.
>> SSD не панацея.
>> Неоптимальные алгоритмы могут свести на нет любые бонусы от железа.
>> Например, если для получения ФИО одного юзера, вы делаете select * from
>> users;
> Так кодируют только м*даки.А закон Амдала и когерентность кэша тоже так-то никто не отменял.
>Так кодируют только м*даки.зато они очень плодовиты, написали уже pulseaudio, systemd...
MapReduce ведь для лохов
Сам то понял, что сказал и при чем тут это?
Сам-то
Учить до посинения.
http://ru.wikipedia.org/wiki/MapReduce
Прочитав "JDBC не поддерживается" крайне удивился: все-таки на Java написано... Взаимоисключающие параграфы?
Посмотрел на сайте - ничего подобного, поддерживается, есть нормальные примеры. Ошибка в новости?
Не поддерживается напрямую для всей БД. Вместо этого агрегация результатов выполнения на узлах.
а в чем подвох? Бесплатная производительность только в сказках у Жуля, нашего, Верна.
Все очень просто ... на одной машинке с 64Гб хватит памяти чтоб сохранить 10000 записей. Хочешь больше, ставь больше машинок.
хочешь сохранить пару миллионов записей, ставь зоопарк?
Вы не поняли части об оперативной памяти.
> Вы не поняли части об оперативной памяти.А вы поняли? Как вы себе представляете ПОЛНОЕ кэширование 1 Тб? А ведь в промышленных реляционных системах это МАЛЕНЬКАЯ база, даже не средняя.
не нужно иметь много мозгов, чтобы показывать большие tps на контенте в оперативной памяти
> не нужно иметь много мозгов, чтобы показывать большие tps на контенте в
> оперативной памятиПокажи мне TPC-D на этой базе. Угумс? С штатными 32 Тб базы. И полной спецификацией, как положено по TPC.
> а в чем подвох? Бесплатная производительность только в сказках у Жуля, нашего,
> Верна."Жюля".
>Все данные каждого узла полностью прокэшированы в ОЗУЧто? Нужна БД на терабайт - накидай терабайт оперативы? Джававыродки такие милашки.
>>Все данные каждого узла полностью прокэшированы в ОЗУ
> Что? Нужна БД на терабайт - накидай терабайт оперативы? Джававыродки такие милашки.Я что-то не припомню, чтобы хоть в каком-нибудь боксе столько памяти видал. Той самой, которая как лопата дерьма стоит. :))))))))))))))))
то ли такой хитрый пиар джавы то ли ответление от имеющегося nosql-направления в самом postgresql.Неожиданно.
Какой к черту пиар джавы? Вы бы себя со стороны слышали. By design гнилая технология, предназначавшаяся для погроммирования кофеварок переучившимися индусскими таксистами. Ни один пиарщик жабу из ее гнойного болота не вытащит.
> Какой к черту пиар джавы? Вы бы себя со стороны слышали. By
> design гнилая технология, предназначавшаяся для погроммирования кофеварок переучившимися
> индусскими таксистами. Ни один пиарщик жабу из ее гнойного болота не
> вытащит.Вы бы себя со стороны видели как слушаете других или проанализировали собственный недостаток чувства юмора. Мне тоже джава не нравится.
Не совсем понятно что будет если пара узлов упадёт.
> Не совсем понятно что будет если пара узлов упадёт.Исходя из фразы данные реплицируются, можно сделать вывод, что кластер выживет.
>> Не совсем понятно что будет если пара узлов упадёт.
> Исходя из фразы данные реплицируются, можно сделать вывод, что кластер выживет.Из этой фразы ничего не следует. Репликация вообще к надежности кластера никакого отношения не имеет, смекаешь?
Об этом стоит прочитать подробней не из новости, а из документации
В целом VoltDB - это "in memory" система (а таковые обычно изначально ориентированы на кластер ради надёжности) с минимально возможным количеством блокировок - даже на одной машине поднимается кластер по числу ядер и между ними делается распределение данных и нагрузки на уровне протокола. Скорость работы и линейность масштабирования достигается за счёт распределения данных между узлами и того самого фирменного сетевого протокола, которым авторы, наверно справедливо, гордятся и который позволяет реализовать ACID в кластере, которого все так боятся, ибо "медленно"..
Какая разница сколько там чего на одной машине запущено !
Упала железяка и нет кластера и нет ваших данных в памяти...
приверно как это http://habrahabr.ru/post/133435/ только на гогнояве
Таак-c.
Явахейтеры увидели в новости слово "java"
Нищеброды увидели в новости предложение "Все данные каждого узла полностью прокэшированы в ОЗУ"
Ваши мнения безусловно интересны.
Но всё же хотелось бы услышать тех, кто видел этот вольт вживую.
>Все данные каждого узла полностью прокэшированы в ОЗУ
>запускается несколько узлов VoltDB, каждый из которых привязывается к отдельному ядру CPUоптимизация такая оптимизация
OpenMP перевернулся в гробу
Ответы на многие вопросы типа "Как вы себе представляете ПОЛНОЕ кэширование 1 Тб?" есть в FAQ, наверно такого рода вопросы постоянно встречаются у людей, не понимающих, что если серьёзные люди взялись за такую задачу, то не просто ради развлечения.What is VoltDB's scaling model?
VoltDB automatically partitions frequently accessed database tables across the available cluster nodes. Both the capacity and performance of the database can be increased by adding nodes to the cluster. Upon changes to cluster size, VoltDB automatically redistributes the partitions to the new configuration when you reload the data. VoltDB also allows tables with infrequently-changing data to be replicated to each node to further optimize performance.
Короче говоря, хотите получить терабайтную базу - ставьте 10-15 машин по 128 гигабайт. И получите пол-миллиона TPC.
frequently accessed database tablesэто здесь ключевое
