Эта группа создана для обсуждения различных аспектов VoltDB - реализации исследовательского проекта H-Store, разработанного совместными усилиями группы ведущих ученых - во главе с доктором Майклом Стоунбрейкером - на базе Массачусетского Технологического Института, Йельского Университета и Университета Брауна. С точки зрения решаемых задач, VoltDB представляет собой распределенную OLTP СУБД, базирующуюся на shared-nothing архитектуре и разработанную для систем сбора, хранения и обработки данных в условиях реального времени и требующих экстремальной транзакционной нагрузки с полной ACID поддержкой.

VoltDB находится в разработке с 2009 года и является продуктом, который в настоящее время (по состоянию на начало 2014 года) используется более чем в 200-х производственных системах, разработанных и внедренных различными пользователями в Соединенных Штатах, Великобритании, Японии, Австралии, Польше и других странах.

Начиная с 2010 года, на sql.ru было создано несколько групп, затрагивающими тему VoltDB - все разными людьми, в разное время и на разные темы. Настоящая группа создана с целью объединения и систематизации наиболее интересных из предыдущих дискуссий, вопросов и комментариев, а также создания форума для обсуждений новых тем, связанных с архитектурой, функциональностью, разработкой и эксплуатацией Систем Управления Баз Данных VoltDB и их приложений-клиентов.

VoltDB Community Edition доступна в открытом доступе в соответствии с условиями лицензии AGPL: http://voltdb.com/download

Документация: http://voltdb.com/download/documentation/

Исходный код: https://github.com/VoltDB/voltdb

AGPL лицензия: https://github.com/VoltDB/voltdb/blob/master/LICENSE

Просто ссылка на предыдущие дискуссии:

http://www.sql.ru/forum/762473-2/voltdb-neskolko-millionov-tranzakciy-v-sekundu

http://www.sql.ru/forum/762124/predstavlena-novaya-otkrytaya-subd-voltdb

Вопрос который был недавно был получен в одной из предыдущих групп ( http://www.sql.ru/forum/762473-8/voltdb-neskolko-millionov-tranzakciy-v-sekundu)

]VoltDB,

1. Можно ли узнать технические детали о протоколах обеспечения транзакционности?

В работе 2007 года пишется:

H-Store Transaction and Schema CharacteristicsWe use single-sited, sterile, two-phase, and strong two-phase
properties in the H-Store algorithms, which follow.


В частности, интересует, как определяется тип транзакции и как это влияет на допустимые операции в рамках этой транзакции.

Было бы здорово увидеть схему процесса обмена сообщениями для каждого типа транзакций.

И услышать, каким образом достигается, что все транзакции в системе становятся очень короткими.

2. Как в VoltDB решаются проблемы изоляции транзакций?

3. Каким образом гарантируется, что на всех узлах HA-системы лежат одни и те же данные? В случае систем долговременного хранения это реазличного рода checksum, но этого также бывает недостаточно и о том, что данные в mirror-блоке битые мы можем узнать только когда вылетел primary блок. Традиционно с этим борются резервным копированием и созданием standby. Как с этим у VoltDB?

4. Какие ограничения целостности поддерживает система и какими механизмами гарантируется их соблюдение?

5. Какие механизмы секционирования возможны и насколько они совместимы друг с другом?

6. Как происходит увеличение размера кластера в 2 раза? Если это возможно вообще.

7. Возможна ли репликация средствами БД в пределах нескольких ДЦ по WAN?

8. В k-safety какое максимально возможное k и какова политика размещения копий?

P.S. Я заранее извиняюсь, вопросов множество, понимаю, что на всё ответить нельзя, но если получится - будет очень здорово.

VoltDBВопрос который был недавно был получен в одной из предыдущих групп ( http://www.sql.ru/forum/762473-8/voltdb-neskolko-millionov-tranzakciy-v-sekundu)

]VoltDB,

1. Можно ли узнать технические детали о протоколах обеспечения транзакционности?

В работе 2007 года пишется:

H-Store Transaction and Schema CharacteristicsWe use single-sited, sterile, two-phase, and strong two-phase
properties in the H-Store algorithms, which follow.


В частности, интересует, как определяется тип транзакции и как это влияет на допустимые операции в рамках этой транзакции.

Было бы здорово увидеть схему процесса обмена сообщениями для каждого типа транзакций.

И услышать, каким образом достигается, что все транзакции в системе становятся очень короткими.

2. Как в VoltDB решаются проблемы изоляции транзакций?

3. Каким образом гарантируется, что на всех узлах HA-системы лежат одни и те же данные? В случае систем долговременного хранения это реазличного рода checksum, но этого также бывает недостаточно и о том, что данные в mirror-блоке битые мы можем узнать только когда вылетел primary блок. Традиционно с этим борются резервным копированием и созданием standby. Как с этим у VoltDB?

4. Какие ограничения целостности поддерживает система и какими механизмами гарантируется их соблюдение?

5. Какие механизмы секционирования возможны и насколько они совместимы друг с другом?

6. Как происходит увеличение размера кластера в 2 раза? Если это возможно вообще.

7. Возможна ли репликация средствами БД в пределах нескольких ДЦ по WAN?

8. В k-safety какое максимально возможное k и какова политика размещения копий?

P.S. Я заранее извиняюсь, вопросов множество, понимаю, что на всё ответить нельзя, но если получится - будет очень здорово.

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

К тезису о том, что существующая архитектура традиционных реляционных СУБД устарела.

Наиболее рапрстраненная на сегодняшний день архитектура реляционных СУБД корнями уходит в разработанную в 70-е и начале 80-х годах архитектуру System R. Как и любая другая архитектура, System R пыталась найти компромис между техническими требованиями к системе и ее стоимостью. Основными проблемами которые System R должна была решить на то время являлись дорогая, но маленькая оперативная память, малопроизводительные процессоры и ненадежные медленные хранилища с низкой пропускной способностью. Для того чтобы решить задачи присущие типичной СУБД на системе, лимитированными такими технологическими факторами, да еще и при условии необходимости минимизиции стоимости такой системы, System R архитектура предложила такие решения, как:

буфер памяти (с соотватствующим менеджером) для оптимизации storage IO,

одновременное использование ресурсов для более эффективного использования процессора (и, соответственно, менеджемент конкурентного доступа к ресурсу путем блокировок и защелок),

усложненный механизи обеспечения надежности (undo/redo и транзакционный лог).

Предложенная архитектура на тот момент времени и с учетом технологических и бизнесс реалий, являлясь оптимальной и была адаптирована в той или иной форме многими разработчиками широко адаптированых СУБД т.к Oracle, SQL Server и DB2. Дальнейшая разработка и усовершенствование базовой современной СУБД архитектуры заняла много лет и огромное количество человеческих и финансовых ресурсов. Этот поистине титанический труд, занявший у СУБД производителей три последующих десятилетия и потребовавший миллиардных инвестиций. Результат - современая кодовая база крупнейших производителей СУБД составляет миллионы линий компьютерного кода.

Многие пользователи традиционных СУБД отмечают отсутствие фундаментальных инноваций в архитектуре со стороны производителей. Причина очень проста. Крупные корпорации-лидеры в разработке СУБД слишком велики и нединамичны. К них слишком много багажа для того чтобы иметь возможность позволить себе коренные изменения в кодовую базу. Многие согласятся, что писать код системы с чистой страницы (то что , кстати, делают многие молодые компании, не обремененные багажем) гораздо более эффективнее чем адаптировать миллионы линий существующего кода к новой архитектуре, отвечающей современным требованиям. Кроме того, ведь такая адаптация, по сути еще означала бы необходимость обновлять существающие системы у заказчиков или поддерживать две линии систем, новую архитектуру и старую. А это ведь все недешево...

В чем заключаются “узкие места” существующей архитектуры?

В 2008 году группа исследователей из MIT, Yale и HP Labs (кстати, под руководством академиков, которые активно участвовали в разработке System R архитектуры в 70-80-ые годы) разобрали типичную CУБД на части и померяли, а откуда, собственно, происходят издержки в продуктивности. Результат получился достаточно интересным:

- около 35% времени исполняется код связанный с менеджированием buffer pool

- около 30% это код связанный с локировками и задвижками для менеджирования конкурентного доступа к ресурсам

- около 30% это код связанный с undo/redo и транзакционным логом

... И только около 5% времени исполняется код, связанный непосредственно с "полезной" работой. Мне кажется, коэффициент полезного действия - так себе, не очень... Можно бы и получше, если с учетом современных реалий в технологиях...

Более детальную информацию о проведенных исследования можно найти здесь:

Stonebraker et al "OLTP Through the Looking Glass, and What We Found There"

http://nms.csail.mit.edu/~stavros/pubs/OLTP_sigmod08.pdf

Так же, производная предыдущей работы: "The End of an Architectural Era (It’s Time for a Complete Rewrite)":

http://nms.csail.mit.edu/~stavros/pubs/hstore.pdf

, а также, множество последующих работ непосредственно на тему дальнейших разработок проекта H-Store:

http://hstore.cs.brown.edu

О тенденции разделения универсальных СУБД на специализированные


Как результат такой тенденции, и существует специализированная OLAP Vertica, разработанная для эффективных аналитических нагрузок и бэтч-загрузок, а также, специализированная OLTP VoltDB, разработанная для эффективной поддержки транзакционной нагрузки в режиме реального времени. Дело в том, что идеальные архитектуры OLTP и OLAP имеют очень разные задачи.

Классическая OLAP нагрузка подразумевает большое количество аггрегатных запросов (SUM, AVG, COUNT итд) и, как результат, требует сканнированния большой части таблицы, что, в свою очередь, подразумевает большое количество чтений с диска. Причем, большинству аналитических запросов полная строка данных и не нужна. Колоночное хранилище, позволяет запросу читать отдельные колонки данных. Кроме того, данные, читаемые по-колоночно, отлично компрессируются. По этим причинам, колоночное хранилище прекрасно подходит для оптимизации решения OLAP задач.

OLTP, в свою очередь, отличается большим количеством точечных запросов, находящих в таблице запись (строку) данных, обязательно включающую каждую колонку. Соответственно, колоночное хранилище уступает построчному для оптимизации OLTP нагрузки.

Таким образом, возникает противоречие: если система должна быть гибридной OLTP/OLAP, оптимизировать ее нужно было бы методами хранения данных, противоречащими друг другу. Но если разделить OLTP и OLAP, тогда каждая из-задач может быть оптимизирована отдельно и без последствий для другой задачи: OLTP с построчным хранилищем и OLAP с колоночным. Своего рода, случай когда 1+1>2

Ответ на группу вопросов, касающихся защиты данных во время плановых или аварийных остановок кластера:

В зависимости от требований к надежности системы, существует несколько видов и, соответственно, уровней защиты от потери данных в аварийных ситуациях. Более сложные DR схемы, обычно применяемые в критических и особо важных системах обычно реплицируют данные во вторичный дата центр - это покрывает риск, связанный с "отрубили электричество" в дата центре (как и от любых других катастроф, приводящих к полной неработоспособности или потере инфраструктуры, т.к. природные бедствия итд). Конфигурация такой репликации может быть или синхронной, или асинхронной - в зависимости от требований к надежности приложения и допустимого общего замедления системы, вызванного достижением такой надежности. Этот уровень предохраняет данные при авариях на уровне дата центра.

Следующий, более низкий уровень защиты - это "reverse caching", те периодические снэпшоты (своего рода incremental backup) базы на локальные диски каждого нода в кластере. Обычно, с периодичностью до часа, во многих системах - каждые 10 -15 минут. Идея в том, что если "отрубили электричество", то обычно у системы есть хоть какое-то гарантированной время для продолжения работы на резервном питании с UPS-батарей и, соответственно, перейти в аварийный режим и сохранить данные из памяти на диск. Этот уровень защиты предохраняет от аварии на уровне кластера.

Для защиты от аварий на уровне одного или нескольких нодов, обычно применяется K-safety кластера: транзакция не коммитнется до тех пор, пока копия изменения не гарантирована на другом ноде в кластере, то если любой нод падает, данные могут быть восстановлены из других нодов (концептуально и функционально напаминает Redundant. Array of Inexpensive Drives, но имплементация другая, те сравнение с RAID 5 в было бы не совсем корректно). Такая защита, конечно, предполагает дополнительную задержку, но при скоростях передачи данных на современных сетях и с учетом, что копия создается только в памяти другого нода (а не на диске), такой подход выглядит как вполне разумный компромисс между высокой надежностью и высокой производительностью системы. K-safety может быть сконфигурирована с К>1, те можно создавать дополнительные копии, и таким образов выживать потерю более чем одного нода. Чем больше К, тем надежнее (но медленнее) система. Фейловер полностью автоматический, равно как и восстановление и обновление данных в случае возврата остановленного нода, и никоем образом не отражается на работоспособность подключенных клиентов.

[quot iv_an_ru]Раз обсуждение переползло сюда, сдублирую вопрос недельной давности.

iv_an_ruпропущено...
Интересно было бы сравнить и "в другую сторону": не односерверный VoltDB с другой односерверной СУБД, а VoltDB "стоящий на трёх китах" с традиционной кластерной СУБД...

Основные тесты VoltDB базировались именно на мульт-узловых системах, включая вариации ТСР.


iv_an_ru... в которой разрешили отложенную запись (и сделали классический скриптик для NUT: нода при пропадании сетевого питания или связи с любой нодой немедленно начинает чекпойнт, на время проблемы делает чекпойнты частыми, в результате при battery low система укладывается весьма быстро.)

Да, интересно было-бы попробовать. Мы такой эксперимент не делали

iv_an_ruКстати, что за транзакции были такие толстые, что "СУБД VoltDB обработала 53 тыс. транзакций в секунду на одном сервере" пишется с гордостью? Сама-то голая цифра "не о чём", году в 2000-м Orri Erling на одном комодном ящике показывал 4 процесса, каждый из которых проводил ~10000 TPC-C-подобных транзакций и реплицировал их на 3 других процесса, итого ящик успевал окучить примерно 4 * (10000 + 30000) = 160000 транзакций и между прочим честно слить их на диски безо всяких батареек.

Мне кажется, цифра в 53 тыс. транзакций быля взята из результатов тестов, проведенных на одной из самых первых версий (наверное, где-то в 2009-2010 годах). С тех пор, как говорится, много воды утекло :) У нас есть документация по тому эксперименту. Если не ошибаюсь, это была вариация ТРС-С, и также сравнение с MySQL и другой широко распрастраненной СУБД. Если кого-нибудь интересует, пожалуйста, сообщите - с удовольствием поделюсь.

xifos...Это общие подходы, а технические детали как узнать?...

Очень многие вопросы покрыты в документации здесь: http://voltdb.com/dev-center/documentation/

Если что-то не покрыто или нужно копнуть глубже, мы постараемся ответить на зтом форуме (пожалуйста заметьте, что ответы могут занять какое-то время т.к вопросов много). Ну а самый лучший вариант, конечно, это загрузить open source версию и попробовать...

Об издержках менеджера локировок в традиционной СУБД архитектуре

Традиционная client-server модель не запрещает нескольким клиентам одновременно посылать запросы, которые могут конкурировать за доступ к данным. Это диктует необходимость сложного и дорогого (в смысле использования CPU циклов) механизма для управления доступом к данным между конкурирующими клиентами (inter-process overhead). Например. в МССКЛ, лок-менеджер должен уметь управлять одновременно громадным количеством Shared, Intended, Exclusive локами на уровне экстента, страницы, таблицы и строки для того, что бы гарантировать ACID - ведь это сложно-то как! [1] И цена у такого менеджера, выраженная в CPU циклах и занятых байтах памяти, соответственно, очень высокая. Да и разработка такого мэнеджера дело долгое и сложное. Например, у МС разработка уже 15 лет продолжается [2]. А вот если всю логику убрать на сервер в сохраненную процедуру, да еще и наложить ограничения на client-server модель и сериализировать для клиентов доступ к такой процедуре, тогда управление доступом становится достаточно тривиальным. Кроме того, такой подход, как показывает широкая практика использования хранимок в существующих СУБД, имеет и дополнительные преимущества уменьшения раунд-трипов в сети, возможности компиляции хранимки, удобства обслуживания кода и.т.д


[1] Кстати, разработан такой менеджер без учета специфики приложения, т.е пытается покрыть одновременно и OLTP и OLAP нагрузку, т.о еще более усложняя механизм. Действительно, как часто OLTP система делает, к примеру, сканирование большого участка или всей таблицы? Или, другой пример, нужна ли поддержка эксклюзивного по-строчного лока в полностью аналитической системе, в которой большинство времени данные вообще никак не модифицируются, а когда модифицируются, то без особого ущерба можно было бы и всю таблицу локировать? Я, ни в коем случае, не предлагаю начать разрабатывать свой лок-менеджер для каждого приложения. Просто, еще один довод в пользу идеи разделения гибридов на специализированные OLTP и OLAP системы - многие вещи, связанные с управлением конкурентным доступом, станут гораздо проще и эффективнее. А если бы иметь какой-нибудь domain specific language высокого уровня, который бы позволял легко и удобно программировать конкретную локировку оптимальную для конкретного приложения... :)

[2] Я, для примера, внедрение по-строчной локировки в версии 7.0 за точку отсчета взял

iv_an_ruVoltDBОсновные тесты VoltDB базировались именно на мульт-узловых системах, включая вариации ТСР.Бывает TCP и TCP. Например, некоторые мамки идут с 4 10GbE на борту, и в кластере очень удобно поставить 4 свича с полной пропускной способностью в матрице у каждого свича, прицепить каждый ящик ко всем свичам и при наличии поддержки в ядре СУБД получить "инфинибанд для бедных" --- 40 гигабит с любого на любой ящик. Латентность, конечно, никуда не девается, но на OLAP задачах удавалось получать порядка 70% от производительности того же кластера с недорогими мелланоксовскими картами. VoltDB сможет заюзать все 4 карты, распараллеливая потоки?

Извините, это была опечатка :) Имелось ввиду, не ТСР, а ТРС (Transaction Processing Council)

[quot iv_an_ru]VoltDB...VoltDB сможет заюзать все 4 карты, распараллеливая потоки?

Я легко могу себе представить, как большой аналитической системе может понадобиться 40Гбт пропускная способность (например, параллельное сканирование супер-большой таблицы, неколлоцированный JOIN или распределенный пересегментация данных в Вертик-кластере[1]), но, мне кажется, в OLTP системах (запросы-то, в основном, точечные и транзакции - сравнительно короткие) такая необходимость может возникнуть гораздо реже, я бы даже рискнул сказать, что почти никогда. Но даже, давайте представим себе, что такая необходимость существует и нам нужно агрегировать 4 интерфейса. Я не сетевой инженер, и могу ошибаться в этом вопросе, но мне кажется, мы бы попытались применить какую нибудь из известных моделей агрегирования, в простейшем случае NIC bonding. Мне кажется, в общем случае, это не VoltDB должен агрегацией заниматься, а или операционная система (в простом варианте) или агрегатор в сетевом интерфейсе (в более сложных случаях). Опять-таки, я себя в этом вопросе не считаю специалистом.

[1] - Я сталкивался с мулти-петабайтной Вертикой, в которой 2х10Гбт интерфейс на каждом ноде был просто необходимостью именно по этим причинам

iv_an_ruVoltDBА если бы иметь какой-нибудь domain specific language высокого уровня, который бы позволял легко и удобно программировать конкретную локировку оптимальную для конкретного приложения... :)Virtuoso/PL ? ;)

Да это я так, задумался... На самом деле, пользователей, наверное не так много, т.е такая игра вряд-ли стоила бы свеч. С Virtuoso/PL, к сожалению, не знаком

redoxifos Отказались от механизма redo/undo, а что взамен? Как сделать бекап 100 машин кластера? Ведь нам нужна согласованная копия. Да, можно остановить весь кластер, но не забываем, у нас OLTP, а значит длительный простой невозможен.


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

Спасибо за комментарий! Это Вы даже так глубоко в недра кода заглянули? :) Очень были бы признательны за мнение - что, в общем, о системе думаете?

iv_an_ruVoltDBпропущено...


Да это я так, задумался... На самом деле, пользователей, наверное не так много, т.е такая игра вряд-ли стоила бы свеч. С Virtuoso/PL, к сожалению, не знакомТам есть милые фенечки вроде вставки только в один из индексов или вставки только на одной из нод кластера, или insert select, у которого select ограничен одной нодой, и т.п. В сочетании с возможностью запустить из транзакции пул асинхронных задач, возможностью включать-выключать лог и автокоммит, и --- главное --- возможностью комбинировать упомянутые возможности как попало, получаем разнообразные возможности выстрелить себе не только в ногу, но и в голову.

LOL :) Нужно запомнить...

iv_an_ru...зато OLAP на таблицах по 0.5 триллиона записей не вызывает паники :)

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

iv_an_ru...Там есть милые фенечки вроде вставки только в один из индексов или вставки только на одной из нод кластера, или insert select, у которого select ограничен одной нодой, и т.п.

Серьезная щтука... Это-ж сколько всяких разностей клиентскому приложению про базу и кластер знать нужно!

iv_an_ruVoltDBЯ легко могу себе представить, как большой аналитической системе может понадобиться 40Гбт пропускная способность... в OLTP системах такая необходимость может возникнуть гораздо реже, я бы даже рискнул сказать, что почти никогда.В OLTP большой трафик любит вылезать при восстановлениях после аварий, особенно если кроме накатки местных логов выполняется чтение больших подписок publisher/subscriber replication.

Может быть... Hаверное все зависит от требований системы. Лично я бы при высоких требованиях к надежности, второй кластер в запасном дата центре поставил, и в него бы или реплицировал с основного, или сразу писал-бы с приложения в два места, если топология позволяет. А вместо супер-широкого сетевого интерфейса, на ноду локальные диски побыстрее поставил - снэпшоты ведь на них читать-писать нужно. Опять таки, это лично мое мнение - Ваша система может иметь очень другие требования. Как говориться, "There is more than one way to skin a cat" :)

iv_an_ruVoltDBпропущено...


Серьезная щтука... Это-ж сколько всяких разностей клиентскому приложению про базу и кластер знать нужно!А нисколько. Обычно немногочисленные грамотные люди пишут серверную часть и RDF Views, а остальные потом пишут SPARQL-запросы, не особо задумываясь о последствиях о планах выполнения, индексах и т.п. Для защиты от дурака пользователя с гуманитарным складом ума обычно используется механизм anytime query , когда по истечении лимита на время исполнения клиент получает частичный ответ на запрос.

Понял... Спасибо за инфу!

Разница между партиционированием и шардированием

Хотя партиционирование данных в VoltDB функционально сходно с техникой шардинга, применяемой другими СУБД, существуют несколько критических архитектурных отличий. Фундаментально, и шардинг, и партиционирование подразумевают разбивку таблицы на горизонтальные “срезы”, т.е строки данных в таблице группируются в соответствии со значением в определенной колонке текущей строки. Например, таблица заказчиков может быть шардирована (или партиционирована) по названию заказчика таким образом, что все заказчики, чье имя начинается на букву “А” находятся в одной группе, начинающиеся на букву “Б” - в другой и.т.д.

Первое различие между шардингом и партиционированем данных в VoltDB заключается в том, в каком компоненте системной архитектуры принимается решение о принадлежности текущей строки к тому или иному шарду (или, соответственно, партиции). В шардинге, как правило, такое решение принимается не СУБД, а каким-нибудь другим компонентом, например специальным сервером-раутером или приложением-клиентом. То есть, для принятия такого решения, соответствующий компонент архитектуры должен проанализировать данные текущей строки и затем, зная детали конфигурации СУБД и кластера, определить к какому шарду такая строка принадлежит. В случае с VoltDB, непосредственно такое решение принимается непосредственно СУБД. С точки зрения любого клиента сервиса СУБД (будь-то раутер или любой другой компонент, отличный от СУБД) данные партиционируются автоматически. Таким образом, приложение-клиент не знает никаких специальных деталей о СУБД и конфигурации подлежащего кластера и, соответственно, любые изменения в СУБД или кластере (например, добавление дополнительных нод) остаются изолированными и не требуют никаких изменений за пределами СУБД. [1]

Второе важное отличие заключается в том, что обычно шардинг подразумевает размещение одного шарда таблицы на каждом ноде в кластере (таким образом, сколько нодов - столько шардов таблицы). В нашем предыдущем примере с таблицей заказчиков, все заказчики, чье имя начинается на букву “А” находились бы в на одном ноде кластера, начинающиеся на букву “Б” - на другом и.т.д. В VoltDB каждый нод в кластере может иметь больше одной партиции (в этом случае партиция называться “site”). Например, каждый нод в кластере может иметь столько партиций (сайтов), сколько ядер процессора(ов) такой нод имеет в своем распоряжении. Таким образом, в отличии от традиционного шардинга, такая архитектура партиционирования VoltDB позволяет не только параллелизм доступа к данным, расположеным на всех нодах в кластере, но и более гранулярный параллелизм доступа к данным каждым ядром, имеющимя в распоряжении нода. Как результат такого увеличения паралелизма обработки данных, общая пропускная способность системы увеличивается.


[1] Еще одной из техник распределения данных на сервере является федерирование. Как и при применении шардинга, в федерированных СУБД решение о принадлежности данных к тому или иному серверу принимается при загрузке компонентом за архитектурной границей СУБД. Но в отличии от шардинга, клиентский запрос обслуживается оптимизатором внутри самой СУБД: сначала строится и исполняется план запроса, а затем результат консолидируется и возвращается клиенту.

iv_an_ruVoltDB,

Да, речь именно про партиционирование. В одной базе про гидрологические буйки две таблицы (event_id integer not null primary key, event_start datetime, tag1 double precision, tag2 double precision,... tag15 double precision) должны быть партиционированы по полю event_start двумя разными способами. В подсистеме моделирования цунами они могут быть партиционированы по нескольким битам после 9-го бита секунд, так что на каждую машину будут падать данные за последовательные 512 секунд, так что короткий срочный запрос по последнему десятку минут будет выполнен без существенных задержек на IPC по кластеру, силами одной машины, максимум двумя зеркальными группами машин, а большие выборки ретроспективных данных равномерно загрузят весь кластер. В подсистеме анализа течений похожие таблицы должны быть партиционированы по первым битам дней, потому что там "свежие данные" --- это последняя пара приливов и отливов.

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

alter index RDF_QUAD on RDF_QUAD partition cluster ELASTIC_1 (S int (0hexffff00))
create distinct no primary key ref column index RDF_QUAD_SP on RDF_QUAD (S, P) partition cluster ELASTIC_1 (S int (0hexffff00))
create distinct no primary key ref column index RDF_QUAD_GS on RDF_QUAD (G, S) partition cluster ELASTIC_1 (S int (0hexffff00))

в одном случае и

alter index RDF_QUAD on RDF_QUAD partition cluster ELASTIC_1 (S int (0hexffff0000))
create distinct no primary key ref column index RDF_QUAD_SP on RDF_QUAD (S, P) partition cluster ELASTIC_1 (S int (0hexffff0000))
create distinct no primary key ref column index RDF_QUAD_GS on RDF_QUAD (G, S) partition cluster ELASTIC_1 (S int (0hexffff0000))

в другом. Загрузчики работали на всех узлах в параллель, Узлы в кластере неплохие --- 16 ядер 256 гигов ОЗУ на каждом, а вот соединение так себе, эзернетом.

Разумеется, можно завести специальную целочисленную колонку и партиционировать по ней. Но тогда во-первых оптимизатор не поймёт, какие данные колоцируются друг с другом, а какие надо собирать через IPC. Во-вторых, для EAV это уполторазит объём некоторых индексов. В третьих, тупая пакетная загрузка без трансформаций и пакетная загрузка с шахматами и куртизанками --- две разные по производительности вещи.

Да-да - я знаю, что еще не до конца ответил на Ваш предыдущий вопрос. Вы понимаете, многие ответы требуют, так сказать, "введения в VoltDB", т.е иначе мне пришлось бы каждый ответ начинать с базовых концепций о партиционировании, single-site vs multi-site запросов итд.Кроме того, каждый ответ был-бы очень длинным

По поводу Вашего приложения - с Вами можно связаться напрямую?

iv_an_ruVoltDB,

По поводу Virtuoso? Разумеется. Но если у вас линукс, то Virtuoso Open Source с довольно большой вероятностью у вас уже крутится как часть KDE, разве что удобнее скачать версию поновее и поднять отдельно от "внутрисистемного" экземпляра.

по поводу базы с гидрологическими буйками.

iv_an_ruVoltDBпропущено...


по поводу базы с гидрологическими буйками.Это не наше приложение, это пользователи, и мы никогда не раскрываем имён пользователей (хотя иногда аж зудит похвастаться :) Некоторых, правда, можно нагуглить по фразе "Virtuoso SPARQL Query Editor" --- если кто-то выставляет СУБД голым интерфейсом в Сеть, то тут тайны уже точно нет.

Понял - тайны меня не интересуют :) Судя по Вашему описанию (бэтчевый загрузчик?), система, похоже, аналитическая, а не рил-тайм?

iv_an_ruVoltDB,

Удивила цитата из доки, https://voltdb.com/docs/tutorial/Part3.php#PartitionTables :
PARTITION TABLE Customer ON COLUMN CustomerID;

Это, конечно, не смертельная проблема для чистого OLTP в памяти, но даже немудрячая смешанная нагрузка BSBM explore and update показывает, насколько производительность приложения может зависеть от того, какие именно биты используются для партиционирования и насколько длинные последовательности значений размещаются на каждом из узлов. Стоунбрейкер, разумеется, про это знает. Можно прояснить, там запрятано некое хитрое автоконфигурирование и/или функция посложнее обычного round robin-а "по модулю"? Или никакой хитрой магии, просто производительность OLAP умышленно принесена в жертву ради удобства администрирования? Или я не дочитал до того места, где описывается точная настройка партиционирования?

Я по указанной ссылке PARTITION TABLE Customer ON COLUMN CustomerID; не нашел...

Новая версия VoltDB 4.0

Интерактивный вэбкаст с демонстрацией новой функциональности и Q&A сессией состоится в среду 29-го января, 2014 в 23:00 МСК.

Зарегистрироваться можно здесь: https://voltdb.webex.com/mw0401l/mywebex/default.do?nomenu=true&siteurl=voltdb&service=6&rnd=0.699249563374278&main_url=https://voltdb.webex.com/ec0701l/eventcenter/event/eventAction.do?theAction=detail&confViewID=1004752450&&&&siteurl=voltdb&utm_source=hs_email&utm_medium=email&utm_content=11602540&_hsenc=p2ANqtz-_BBBU6bkwv5zrx3pyQac0xUVHSsDS57ypeaNTqOPKj2jTt3wq-i905po16L1UN3p9arR-3akTqffRoQtJtsWH60BWSXw&_hsmi=11602540

iv_an_ruVoltDB,

Упс, PARTITION TABLE towns ON COLUMN state_num . Первая, стало быть, была из другого тьюториала.

Пожалуйста заметьте, что разница между PARTITION TABLE Customer ON COLUMN CustomerID и PARTITION TABLE towns ON COLUMN state_num критична. Ведь, судя по всему, значения в колонке CustomerID были бы уникальны. Такого рода партицирование привело бы к созданию отдельной партиции для каждой строчке в таблице т.е группировка записей по какому-либо общему атрибуту не была бы достигнута. А в примере с партицированием по state_num, все города, находящиеся в определенном штате будут сгруппированы вместе в единой партиции и "приписаны" к определенному ядру. Сколько уникальных штатов - столько и партиций. Причем каждая партиция имела бы записи для многих городов, но все города в одной партиции находились бы я в одном штате. Таким образом, все запросы, содержащие WHERE state_num = ? будут локализированы.

iv_an_ruVoltDB,

ok, http://voltdb.com/docs/UsingVoltDB/ChapAppDesign.php содержит как раз PARTITION TABLE Customer ON COLUMN CustomerID, но ON COLUMN CustomerID и ON COLUMN state_num к вопросу о локальности последовательностей относится только косвенно. Партиционирование по штату вопросов не вызывает, если выборка или группировка по штату действительно часто встречаются. В остальном она может быть любой, поскольку вряд ли кто-то фильтрует наподобие ...WHERE state_num BETWEEN 10 and 20. Партиционирование по CustomerID уже чуточку интереснее, если покупатели "одноразовые" и нумеруются в порядке создания --- тогда разное партиционирование начинает влиять на запросы с диапазонами дат. Ну а если для значений колонки диапазоны "от...до" имеют явный смысл, тогда и влияние такое же явное.

Безусловно, запросы с BETWEEN могут встречаться, но я думаю, важно отметить что, в общем случае основную нагрузку OLTP системы все-таки составляют точечные запросы. Пример в документации на который Вы указываете, иллюстрирует процесс принятия решения о партиционировании системы продажи авиационных билетов, которая бы разрабатывалась, в первую очередь, для поиска авиарейса(ов) по пункту отлета и прибытия и проверке наличия свободных мест на авиарейсе. Это не означает, что такая система поддерживала бы только такие запросы - другие запросы тоже вполне функциональны, но, как Вы можете видеть из описания самого примера, в соответствии с тех-заданием в Таблице 3.1 на http://voltdb.com/docs/UsingVoltDB/ChapAppDesign.php, частота таких запросов относительно невелика (до 1000 запроов/сек, в то время как первоочередные запросы требуют от 1 до 10 тысяч запросов/сек). Соответственно, система оптимизируется с учетом запросов, которые будут исполняются более часто.

iv_an_ruVoltDB,

С этими примерами всё понятно, тем не менее исходный-то вопрос остаётся неотвеченым. Можно прояснить, там (1) запрятано некое хитрое автоконфигурирование и/или функция посложнее обычного round robin-а "по модулю"? Или (2) никакой хитрой магии, просто производительность OLAP умышленно принесена в жертву ради удобства администрирования? Или (3) я не дочитал до того места, где описывается точная настройка партиционирования?

Да, действительно - давайте вернемся к исходному вопросу о возможности локализации последовательностей, или, в общем случае, возможности партиционирования данных, базирующегося на различного рода неочевидных (по-крайней мере, для оптимизатора) взаимозвязях. Таких, как в Вашем примере о подсистеме моделирования цунами, где партиционирование могло бы быть произведено по нескольким битам после 9-го бита секунд таким образом, что данные за каждые последовательные 512 секунд могли бы храниться в отдельной партиции с целью оптимизации призводительности OLAP. Нет, автоматическая поддержка такого специального партицирования в VoltDB не реализована. Хотя мы не думаем об отсутствии такой поддержки как об “умышленно принесенной жертве” :). Как Вы правильно заметили, такая функциональность может быть эмулирована путем добавления в таблицу дополнительной колонки, содержащей модифицированные значения для такого партиционирования. В отношении “обычного round robin-а "по модулю", хотя наш алгоритм и немного сложнее (т.к необходимо учитывать К-factor кластера), но никакой хитрой магии нет.

Кстати, разрешите воспользоваться случаем и показать как работает К-safety.

На рисунке ниже показаны 3 нода, каждый с 4 сайтами (каждое ядро имеет свой сайт), то-есть, всего 12 сайтов. Так как кластер сконфигурирован с К-factor=1, в кластере только 6 партиций. Каждая из шести партиций имеет копию на другом ноде; таким образом, если по какой-либо причине один из нодов в кластере потерян, база остается функциональной.




essbase.ruМожно пж посмотреть на мои вопросы ?

Интерсно узнать архитектуру исполнения кода пользовательских процедур (хранимок )
В частности
1) Код выполнятся на случайной ноде или на всех

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

essbase.ru2) Можно ли || код.

Если Вы имеете ввиду sqlcmd, то да

essbase.ru 3) Есть ди интерфейсы обмена данными между хранимками ?

Хранимые процедуры пишутся в JAVA, соответственно, все JAVA IPC методы доступны

essbase.ru 4) Как насчет Джобов ? Тригеров ?

Нет, не поддержаны

essbase.ru 5) Как решатеся проблема замирания кода из-за работы Java GC ?

Я думаю, производительность Java приложений в большей степени зависит от индивидульного стиля разработки такого приложения, чем от GC.

essbase.ru 6) Есть ли огрничения по внешнему взаимодествию в коде хранимок

Теоритически - нет. На практики, так как в VoltDB процедура является “контейнером” для транзакции, и соответственно, время, в течении которого такая транзакция остается открытой должно сводиться к минимуму, мы не рекомендуем включать в процедуры код, который может существенно увеличить время исполнения.

essbase.ru-- у Вас свой движок JVM или испльзуется что-то "стандартное"

Стандартный

essbase.ru-- можно ли дергать Web Сервисы из кода ?

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

essbase.ru 7) Есть ли понятие "табличные" функции ?

Нет. Но у разработчика есть доступ к таблице из Java, так что...

iv_an_ruС запозданием до меня дошло, что если транзакции выполняются строго одна за одной, то на боевой системе нельзя использовать отладчик.

Не то что бы нельзя... Но Вы абсолютно правы что "боевая" система не совсем подхлдящее место для отладки кода.