Виды многораздельных хранимых процедур и будут ли они блокировать весь кластер в VoltDB 9? - PullRequest
Новая
       45

Виды многораздельных хранимых процедур и будут ли они блокировать весь кластер в VoltDB 9?

0 голосов
/ 07 января 2020

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

Из H-Store-FAQ :

[...] это позволяет H-Store поддерживать дополнительные оптимизации, такие как спекулятивное выполнение и произвольное мульти транзакции Например, в VoltDB каждая транзакция является либо однораздельной, либо полностью разделенной. То есть любая транзакция, которая должна касаться нескольких разделов, заставит координатор транзакций VoltDB заблокировать все разделы в кластере, даже если транзакции нужно только касаться данных в двух разделах. [...] Вполне вероятно, что VoltDB будет поддерживать эти функции в будущем [...]

Документы СУБД оперативной памяти VoltDB и Как работает VoltDB Транзакции утверждают, что в VoltDB существует хотя бы один сплит многораздельных транзакций: One-Shot-Reads и General-2P C -Transactions.

В классе MpTransactionTaskQueue есть различие, будет ли транзакция перенаправлена ​​на многораздельный сайт (количество 1) или пул сайтов только для чтения (по умолчанию до 20) MPI, и они не могут быть выполнены с чередованием.

Итак, это мои дополнительные вопросы:

  • Всегда ли однократное чтение выполняется на RO-сайтах?
  • RO-сайты выполняются только для чтения и не однофазные многораздельные транзакции в дополнение?
  • Если это хотя бы один фрагмент записи в многораздельных транзакциях, он будет выполняться на RW-сайте, а атомы c зафиксированы с 2P C?
  • В обоих случаях возможно, что мне не нужно трогать все разделы в кластере. Заблокированы ли незадействованные разделы или они могут одновременно выполнять однораздельные транзакции (если в других разделах выполняется несколько операций One-Shot-Reads или одной операции 2P C -Transaction). Если они заблокированы, как? Получают ли они FragmentTaskMessage с пустым или фиктивным фрагментом плана, например?
  • Класс SystemProcedureCatalog определяет «Every-Flag», и он будет проверяться в коде в дополнение к чтению только и однораздельные флаги. Как этот флаг связан с One-Shot-Reads или Run-Everywhere-Pattern ?

1 Ответ

1 голос
/ 08 января 2020

Чтобы упростить задачу для разработчиков, процедуры вызываются одинаково, независимо от их типа. Внутренне существуют различные типы многораздельных процедур, поскольку они обеспечивают некоторую оптимизацию, хотя многое еще предстоит сделать, и некоторые проекты H-Store провели исследования в этих областях.

Транзакции MP по-прежнему в конечном итоге включают отправку задач в быть сделано на всех разделах. Единственное исключение, которое вы заметили, - это специальная транзакция с двумя разделами, которая используется только для перебалансировки данных во время добавления или сокращения elasti c.

Разделы состоят из одного или нескольких сайтов (на отдельных серверах) в зависимости от kfactor. Эти сайты остаются в синхронизации c без 2P C, требуя детерминированных c процедур. Разделы работают через очередь в очереди так быстро, как позволяет время процесса (или локальное время выполнения). Все сайты обрабатывают как чтение, так и запись.

Задачи MP, отправленные в эти очереди разделов, должны ожидать завершения всех ожидающих элементов до sh. Вот почему существует пул из 20 (по умолчанию) потоков для чтения MP. Это позволяет отправлять 20 задач одновременно, так что при следующем считывании MP обычно не нужно ждать 2 сетевых прыжка + максимальное время ожидания очереди + время обработки, прежде чем он сможет даже встать в очередь.

Чтения MP, которые не являются «однократными», будут Java процедурами с несколькими вызовами voltExecute SQL (), такими как процедура, в которой последующие SQL запросы зависят от результатов предыдущих запросов. Когда эти транзакции отправляют задачи в разделы, разделы должны ждать максимального времени ожидания очереди + время обработки + 2 сетевых прыжка, прежде чем они смогут выполнить следующую часть транзакции.

Запись MP также может иметь несколько Вызовы voltExecute SQL (), плюс они должны ждать окончательного сигнала фиксации, так что все это задерживает прогресс на разделах.

Есть, конечно, примеры транзакций MP, которые не должны включать все разделов и может извлечь выгоду из будущих оптимизаций, но это не так просто, как может показаться для базы данных, которая должна поддерживать долговечность диска, k-safety, elasti c add и shrink, многокластерную активно-активную репликацию, и многие другие функции, которые были добавлены в VoltDB на протяжении многих лет с тех пор, как он вырос из проекта H-Store.

Раскрытие информации: я работаю в VoltDB

...