Эта глава предоставляет информацию о протоколе, используемом для связи между узлами данных и узлами API в кластере NDB, чтобы выполнить различные операции, такие как запись и чтение данных и обработка записей транзакции.
Узлы данных и API NDB Cluster общаются друг с другом сообщениями друг
другу. Отправка сообщения от одного узла и его прием другим узлом упоминается
как сигнал, протокол
NDB
это ряд правил, управляющий форматом этих
сообщений и способ, которым они передаются.
Сообщение NDB
, как правило,
запрос или
ответ. Запрос указывает, что узел API хочет
выполнить операцию, включающую данные о группе (такие как поиск, вставка,
обновление или удаление) или транзакции. Запрос при необходимости
сопровождается информацией об индексе или ключом. Ответ, посланный узлом
данных на этот запрос, указывает, сопровождается ли запрос одним или
более сообщениями данных.
Типы запросов. Запрос представляется как сообщение
REQ
. Запросы могут быть разделены на тех,
которые обрабатывают данные и тех, которые обращаются с транзакциями:
Запрос данных. Операции по запросу данных имеют три основных типа:
Primary key lookup operations выполняются через обмен сообщениями
TCKEY
.
Unique key lookup operations
выполняются через обмен сообщениями TCINDX
.
Table or index scan operations
выполняются через обмен сообщениями SCANTAB
.
Сообщения запроса данных часто сопровождаются сообщениями
KEYINFO
или
ATTRINFO
.
Запросы транзакций. Они могут быть разделены на две категории:
Commits and rollbacks
, которые представляются сообщениями запроса
TC_COMMIT
и
TCROLLBACK
.
Transaction record requests
состоят из получения и освобождения записи транзакции и обработаны с помощью,
соответственно, сообщения запроса TCSEIZE
и
TCRELEASE
.
Типы ответа. Ответ указывает на успех или на неудачу запроса, в котором это посылают в ответ:
Ответ, указывающий на успех, представляется как сообщение
CONF
(confirmation) и часто сопровождается
данными, которые упакованы как одно или больше сообщений
TRANSID_AI
.
Ответ, указывающий на неудачу, представляется как сообщение
REF
(refusal).
Для получения дополнительной информации об этих типах сообщений и их отношениях друг к другу посмотрите раздел 3.2.
Эта секция описывает типы сообщений протокола
NDB
, их функции и структуру.
Соглашения о присвоении имен. Названия сообщения построены согласно простому образцу, который должен быть очевиден из обсуждения запроса и типов ответа в предыдущей секции. Их показывают в следующей таблице:
Таблица 3.1. Сообщения протокола NDB с названиями сообщений REQ, CONF и REF
Тип операции | Запрос (REQ ) |
Ответ: Success (CONF ) |
Ответ: Failure (REF )
|
---|---|---|---|
Primary Key Lookup
(TCKEY ) |
TCKEYREQ |
TCKEYCONF |
TCKEYREF |
Unique Key Lookup
(TCINDX ) |
TCINDXREQ |
TCINDXCONF |
TCINDXREF |
Table or Index Scan
(SCANTAB ) |
SCANTABREQ |
SCANTABCONF |
SCANTABREF |
Result Retrieval
(SCAN_NEXT ) |
SCAN_NEXTREQ |
SCANTABCONF |
SCANTABREF |
Transaction Record Acquisition
(TCSEIZE ) |
TCSEIZEREQ |
TCSEIZECONF |
TCSEIZEREF |
Transaction Record Release
(TCRELEASE ) |
TCRELEASEREQ |
TCRELEASECONF |
TCRELEASEREF |
CONF
и REF
это сокращения от confirmed и
refused.
Три дополнительных типа сообщений используются в некоторых случаях коммуникации междоузлия. Эти типы сообщений перечисляются здесь:
KEYINFO
содержит информацию о ключе, используемом в
TCKEYREQ
или
TCINDXREQ
. Это используется, когда ключевые
данные не соответствуют в рамках сообщения запроса.
Сообщение ATTRINFO
содержит неключевые значения атрибута, которые не переданы в сообщении
TCKEYREQ
,
TCINDXREQ
или
SCANTABREQ
. Это используется для:
Поставка значений атрибута для вставок и обновлений.
Обозначение, какие признаки должны быть прочитаны для операций чтения.
Определение дополнительных значений для операции удаления.
Сообение TRANSID_AI
содержит данные, возвращенные из операции чтения, другими словами, это набор
результатов (или его часть).
В этой секции мы обсуждаем последовательность передачи сообщений, которая происходит между узлом данных и узлом API для каждой из следующих операций:
Primary key lookup
Unique key lookup
Table scan or index scan
Explicit commit of a transaction
Rollback of a transaction
Transaction record handling (acquisition and release)
Primary key lookup. Операция, используя поиск первичного ключа, выполняется, как показано в следующей диаграмме:
Рис. 3.1. Обмен сообщениями в поиске первичного ключа
* и + используются здесь в значениях "ноль или больше" и "один или больше", соответственно.
Шаги, составляющие этот процесс, перечислены и объяснены более подробно здесь:
Узел API посылает сообщение
TCKEYREQ
узлу данных.
Если необходимая информация о ключе, который будет использоваться, слишком
большая, чтобы содержаться в TCKEYREQ
,
сообщение может сопровождаться любым количеством сообщений
KEYINFO
, несущих остающуюся ключевую информацию.
Если дополнительные признаки используются для операции и превышают
пространство, доступное в TCKEYREQ
,
или если данные нужно послать в узел данных как часть операции записи, то их
посылают с TCKEYREQ
как любое количество
сообщений ATTRINFO
.
Узел данных посылает сообщение в ответ на запрос, согласно тому, имела ли операция успех или нет.
Если операция была успешна, узел данных посылает сообщение
TCKEYCONF
узлу API. Если запрос был для операции
чтения, то TCKEYCONF
сопровождается сообщением
TRANSID_AI
, которое содержит фактические данные
о результате. Если есть больше данных, чем может содержаться в одном
TRANSID_AI
, можно послать больше, чем
одно такое сообщение.
Если операция потерпела неудачу, то узел данных посылает сообщение
TCKEYREF
узлу API, и более сигналов не
происходит, пока узел API не обращается с новым запросом.
Unique key lookup. Это выполняется способом, подобным выполненному в поиске первичного ключа:
C запросом обращается узел API, используя сообщение
TCINDXREQ
, которое может сопровождаться нолем
или больше сообщений KEYINFO
, а также нолем
или больше сообщений ATTRINFO
.
Узел данных возвращает ответ, в зависимости от того, имела ли операция успех:
Если операция имела успех, сообщение
TCINDXCONF
. Для успешной операции чтения это
сообщение может сопровождаться одним или больше сообщений
TRANSID_AI
, несущих данные.
Если операция потерпела неудачу, узел данных возвращает
сообщение TCINDXREF
.
Обмен сообщениями, вовлеченными в поиск уникального ключа, проиллюстрирован в следующей диаграмме:
Рис. 3.2. Обмен сообщениями при Unique Key Lookup
Table scans and index scans. Они подобны во многих отношениях поискам первичного и уникального ключей, как показано здесь:
Рис. 3.3. Обмен сообщениями при Table Scan Or Index Scan Operation.
С запросом обращается узел API, используя сообщение
SCAN_TABREQ
, наряду с нолем или больше сообщений
ATTRINFO
. KEYINFO
сообщения также используются с просмотрами индекса,
если границы используются.
Узел данных возвращает ответ, согласно тому, имела ли операция успех:
Если операция имела успех, сообщение
SCAN_TABCONF
. Для успешной операции чтения это
сообщение может сопровождаться одним или больше сообщений
TRANSID_AI
, несущих данные о результате. Однако,
в отличие от случая с поисками на основе первичного или уникального ключа,
часто необходимо передать многократные ответы узла данных.
Запросы после первого сообщены узлом API, используя
SCAN_NEXTREQ
, который говорит узлу данных
посылать следующий набор результатов (если есть больше результатов).
Это показывают здесь:
Рис. 3.4. Получение многократных наборов данных результатов после операции чтения таблицы или просмотра индекса
Если операция потерпела неудачу, узел данных возвращает сообщение
SCAN_TABREF
.
SCAN_TABREF
также используется, чтобы
сигнализировать к узлу API, что все данные послали.
Committing and rolling back transactions.
Процесс выполнения явной передачи следует за тем же самым общим образцом,
как показано ранее. Узел API посылает сообщение
TC_COMMITREQ
узлу данных, который отвечает
TC_COMMITCONF
(при успехе) или
TC_COMMITREF
(если передача неудачна).
Это показывают на следующей диаграмме:
Рис. 3.5. Обмен сообщениями при Explicit Commit Operation
Некоторые операции выполняют COMMIT
автоматически, таким образом, это не требуется для каждой транзакции.
Отмена транзакции также следует этому образцу. В этом случае, однако,
узел API посылает сообщение TCROLLBACKTREQ
узлу данных. TCROLLACKCONF
или
TCROLLBACKREF
послано в ответ,
как показано здесь:
Рис. 3.6. Обмен сообщениями при отмене транзакции
Handling of transaction records. Получение записи транзакции
достигается, когда узел API передает сообщение
TCSEIZEREQ
узлу данных и получает в ответ
TCSEIZECONF
или
TCSEIZEREF
, в зависимости от того, был ли запрос
успешен. Это изображено здесь:
Освобождение записи транзакции также обработано, используя образец ответа
запроса. В этом случае запрос узла API содержит сообщение
TCRELEASEREQ
и ответ узла данных использует TCRELEASECONF
(указание, что запись была освобождена) или
TCRELEASEREF
(указание, что попытка не имела
успеха). Эта серия событий проиллюстрирована в следующей диаграмме: