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

Программный код и данные которыми он оперирует не совсем одно и тоже . Я знаю только одну концепцию, которая работает в описанном Вами режиме - это программирования для BigData - Map:Reduce.

Означает ли что для VoltDB нужно писать хранимки в таком же стиле ?

з.ы. IMHO хранимка это не только "догонка" транзакций "связанными" данными (ключами или справочниками) . Обычно это еще и пакетная обработка всех данных (за год, или день).

Извините, но я не уловил связи... MapReduce - механизм генерализации параллельной обработки больших объемов данных на распределенном НРС кластере. VoltDB - OLTP СУБД. MapReduce разработан под аналитический бэтч-процесс, VoltDB - под большое количество коротких SQL запросов (транзакций) в реальном времени. MapReduce не предполагает логического партицирования данных (файловай система просто разбивает файл на чанки, при этом никакой логической связи между данными в индивидуальном чанке нет), а VoltDB группирует строки таблицы по значению в определенной колонке (т.о все данные в партиции имеют общий аттрибут). В MapReduce код исполняется параллельно на каждом ноде, в VoltDB - на ноде, на котором размещена соответствующая партиция данных (например, запрос SELECT Col1, Col2, Col3 FROM Invoices WHERE CustomerID = XYZ будет исполнен ядром которое обслуживает партицию содержащую инвойсы заказчика XYZ).

essbase.ruVoltDBпропущено...


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

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

Опять-таки, мне кажется это пример аналитического запроса. В контексте OLTP задача звучала бы так:

Клиент: "СУБД, выполни сохраненную процедуру, которая называется МойКод, при этом передай в процедуру аргумент CustomerID=XYZ."

СУБД: "Ага, процедура МойКод ищет иновойсы заказчика XYZ... Я знаю, что все инвойсы этого заказчика сгруппированы вместе и находятся в оперативной памяти, локально приписанной к ядру номер 2 на ноде номер 3. Поручаю дальнейшую работу именно этому ядру. Готова к следующему заданию..."

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


Получается что весь код хранимок выполняется в других процессах и службах ? Т.е. по сути нет совмещения данных и программного кода как это есть в других RDB ? (где можно написать бизнес слой на PL-SQL(TSQL) и получить дополнительный выйгрыш за счет того, что данные "далеко" не пробрасываются ? )

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

essbase.ruЧем мне может помочь в этом VoltDB ?

Я не уверен я понимаю какую проблему Вы пытаетесь решить... Вы не могли бы описать задачу?

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


Опять-таки, мне кажется это пример аналитического запроса. В контексте OLTP задача звучала бы так:

Клиент: "СУБД, выполни сохраненную процедуру, которая называется МойКод, при этом передай в процедуру аргумент CustomerID=XYZ."

СУБД: "Ага, процедура МойКод ищет иновойсы заказчика XYZ... Я знаю, что все инвойсы этого заказчика сгруппированы вместе и находятся в оперативной памяти, локально приписанной к ядру номер 2 на ноде номер 3. Поручаю дальнейшую работу именно этому ядру. Готова к следующему заданию..."

Щасс... готова она. Вы же строго последовательно прогоняете транзакции,

Ну да - именно готова к следующему заданию... Выполнение процедур сериализуется на уровне ядра, а не всей системы. То есть, если в кластере, например, 24 ядра, то это значит, что 24 процедуры могут выполняться одновременно, остальные ждут своей очереди. Система асинхронно "разбрасывает" запросы по очередям ядер - после того как запрос направлен определенному ядру для выполнения, система готова принимать следующее задание от клиента



iv_an_ruтак что к времени работы транзакции запросто прибавляются два времени IPC и связанные с ними противные мьютексы на читателях и писателях.

Я, честно говоря, не понимаю зачем коммуникация между процедурами вообще нужна. В общем случае, приходят одновременно два независимых запроса с двух независимых клиентов и конкурируют за доступ к данным - лок-менеджер умеет таким доступом управлять... Вы можете привести пример двух SQL запросов, потребовавшего от разработчика этих запросов кодирования мютекса?

iv_an_ruЧем дольше я думаю над вашей моделью обработки данных, тем более узкоспециальной она мне кажется.

У Вас есть конкретный пример OLTP задачи, с которой Вы считаете VoltDB не может справиться по причине своей "узкоспециализированности"?

iv_an_ru Но некорректность, IMHO, в мало обоснованном предположении, что выкидывание всех X,Y,Z со всеми их мьютексами не изменит статистики ожиданий на мьютексах в оставшемся коде.

Давайте попробуем сначала... Представьте что у Вас есть ящик с 2 процами, каждый по 4 ядра. На этом ящике всего 128ГБ памяти. Давайте представим, что мы поделили всю эту память между всеми ядрами - каждое ядро имеет свой собственный регион в 16ГБ. Теперь давайте возьмем таблицу инвойсов и разделим ее на несколько частей по имени заказчиков. Предположим, у нас всего 85 заказчиков, т.е, соответственно, таблица инвойсов разделена на 85 частей и каждая часть приписана к какому нибудь ядру; 5 ядер имеют по 11 "кусков" данных, 3 ядра - по 10. На наш ящик начинают приходить запросы - каждый требует доступа к инвойсу определенного заказчика, т.е доступ к только к определенной части данных, которая, соответственно, приписана к определенному ядру. Так как у нас всего 8 ядер, только 8 запросов исполняются одновременно, причем каждое из них работает только со своими собственными данными. Остальные запросы сидят в очередях - каждый в очереди на том ядре, которое имеет часть данных, необходимую запросу. В этом случае, никакого конкурентного доступа просто не существует.

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

iv_an_ruVoltDBУ Вас есть конкретный пример OLTP задачи, с которой Вы считаете VoltDB не может справиться по причине своей "узкоспециализированности"?Я подозреваю, хотя ещё не было времени проверить, что если сделать шаг в сторону от "самой удобной" OLTP, то производительность окажется хорошей, но не выдающейся. Интересно было бы посмотреть, скажем, на SQL-версию BSBM Explore and Update ( http://wifo5-03.informatik.uni-mannheim.de/bizer/berlinsparqlbenchmark/spec/index.html#usecase_explore_and_update ) . Там запросы и довольно правдоподобные, и простые, и составляющие на удивление пакостную смесь --- кто слишком хорошо выигрывает на update части, тот норовит завалиться на explore, и наоборот. Хотя на первый взгляд проблемам взяться неоткуда. "Ничто не предвещало беды в то теплое летнее утро: ни огромная кружка парного молока, только что из под коровы, ни свежесобранные пупырчатые огурцы с грядки..."


VoltDB - СУБД реляционная, не граф-СУБД. Соответственно, наш интерес - не SPARQL, а SQL. Более традиционные тесты для SQL нагрузки основаны на спецификациях TPC (Transaction Processing Counsel), в частности, TPC-C. Вкратце, суть теста сводится к эмулированию широко-используемых бизнес-транзакций (введение заказа, проверки статуса заказа и доставки, проверка наличия в складе и.т.д) и замерению пропускгой способности СУБД для соответствующих запросов. Детальную ТРС-С спецификацию Вы можете найти здесь: http://www.tpc.org/tpcc/spec/tpcc_current.pdf Исходный код для одного из наших тестовых стендов можно найти здесь: https://github.com/apavlo/h-store/tree/master/src/benchmarks/org/voltdb/benchmark/tpcc/

iv_an_ruVoltDB,

...восьмидесятое место voltDB в http://db-engines.com/en/ranking становится вполне объяснимым.

Это ж надо - рейтингов стало больше чем продуктов:) Даже не слышал о такой организации... Кстати, а какой рейтинг у их рейтинга? :)

iv_an_ruVoltDBИсходный код для одного из наших тестовых стендов можно найти здесь: https://github.com/apavlo/h-store/tree/master/src/benchmarks/org/voltdb/benchmark/tpcc/
The TPC-C example runs a modified TPC-C benchmark.Я даже не буду разбираться после этого, что именно там "modified", потому что для сравнения с другими СУБД я должен сделать... что? Для каждой СУБД подкрутить бенчмарку в удобную для неё сторону? Или сделать что-то менее разрушительное? Я в растерянности.

Там дальше в тексте есть детали... В официальном тесте есть бизнес-транзакции, которые представляют заказ посланный на один склад, а выполненный на другом. Мы посчитали, что в век интернета (оригинальная ТРС-С спецификация вышла в 1988 году), сразу посылать заказ на "правильный" склад особого труда не составит (например, в вэб-сервере) и модифицировали эту часть теста таким образом, что заказ выполняется на том складе, на который он поступил. Кстати, в соответствии со ТРС-С спецификацией, это 10% всех транзакций. Но так как тест модифицирован, официальным он быть не может (с чем мы полностью согласны)

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


Там дальше в тексте есть детали... В официальном тесте есть бизнес-транзакции, которые представляют заказ посланный на один склад, а выполненный на другом. Мы посчитали, что в век интернета (оригинальная ТРС-С спецификация вышла в 1988 году), сразу посылать заказ на "правильный" склад особого труда не составит (например, в вэб-сервере) и модифицировали эту часть теста таким образом, что заказ выполняется на том складе, на который он поступил. Кстати, в соответствии со ТРС-С спецификацией, это 10% всех транзакций. Но так как тест модифицирован, официальным он быть не может (с чем мы полностью согласны)

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

Я точных деталей уж и не упомню - все-таки 5 лет прошло с того теста... Но могу сказать, что даже на тот момент мы чувствовали, что некоторые бизнес-транзакции, как их описывала спецификация 20-летней давности, устарели. Некоторые вещи из того, что включено в ТРС-С спецификацию, сегодня лучше делаются за пределами СУБД. В том, что внесение изменение в некоторые транзакции в тест сработало в пользу H-Store архитектуры - так это, по моему мнению, только подтверждает что такая архитектура лучше приспособлена к современным реалиям в бизнес-транзакциям. Да и, по-большому счету, какая разница кто быстрее на определенном "синтетическом" бэнчмарке? Ведь более важный вопрос - может ли система обеспечить требуемую пропускную способность и надежность нагрузки, вызванной конкретными запросами продиктованными конкретным бизнес-процесом и сколько такое решение стоит . Для каких-то задач VoltDB - решение, а для каких-то - нет. Как говорится, на вкус и цвет - карандаши разные... :)

iv_an_ruКстати, у меня по этому продукту вопрос за вопросом так или иначе одним ребром упирается в IPC. Сходу вспоминаются распределённые транзакции, точная настройка партиционирования, тормоза на восстановлении после сбоя, поддержка нескольких маршрутов между двумя машинами кластера, латентности на IPC перед и после "неудобных" транзакций. И тут из стандартной бенчмарки вырезается как раз IPC-шный кусочек. Обидно, понимаешь.

Мне кажется, мы с Вами продолжаем теоретизировать и обсуждать какие-то абсолютно гипотетические проблемы... Разрешите мне повториться и задать Вам тот же самый практический вопрос, который я уже задавал: у Вас есть пример какой-нибудь конкретной OLTP задачи, которая, по Вашему мнению, не вписывается в архитектуру VoltDB?