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С запозданием до меня дошло, что если транзакции выполняются строго одна за одной, то на боевой системе нельзя использовать отладчик.

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