Снапшот-таблица
Содержание раздела
Снапшот-таблица — логическая сущность с версионированием данных, но без истории данных.
Снапшот-таблицы поддерживают параллельную запись данных и могут размещаться в нескольких датасорсах. Они сочетают высокую производительность и надежность и предназначены для сценариев, где история данных избыточна (например, при работе в OLTP-режиме).
Снапшот-таблицы доступны только для ADP.
Возможности
Снапшот-таблицы предоставляют следующие возможности:
- параллельная неблокирующая запись данных;
- более высокая производительность по сравнению с обычными логическими таблицами;
- синхронная репликация данных в несколько датасорсов;
- восстановление механизмом auto-failover при сбоях датасорсов;
- гибкое управление уровнем консистентности данных при чтении.
Параллельная запись в снапшот-таблицу может потребовать больше подключений к СУБД, чем последовательная.
Действия с таблицами
Снапшот-таблицы можно создавать, изменять и удалять.
Для таблицы с включенным отслеживанием удаления записей можно настроить retention-правила для периодического удаления информации об удаленных записях.
При создании снапшот-таблицы система создает и далее поддерживает связанный набор физических таблиц.
Действия с данными таблиц
Данные снапшот-таблицы можно загружать, обновлять, запрашивать (читать) и выгружать.
Работать с данными снапшот-таблиц можно так же, как с данными обычных логических таблиц:
- обновлять и читать — напрямую, без участия внешних таблиц;
- загружать и выгружать — с использованием внешних таблиц.
Все изменения данных снапшот-таблиц выполняются в операциях записи, но вне механизма дельт.
Опция set.delete.tracking.enable
В отличие от обычных логических таблиц, снапшот-таблицы не хранят историю данных, но могут хранить информацию об удалении записей.
В зависимости от опции set.delete.tracking.enable, заданной при создании таблицы, она хранит:
- [set.delete.tracking.enable=false] только текущие записи;
- [set.delete.tracking.enable=true] текущие записи и информацию об удалении записей.
Сравнение характеристик снапшот-таблиц в зависимости от значения опции см. ниже.
| Характеристика | Таблица c set.delete.tracking.enable=false | Таблица с set.delete.tracking.enable=true |
|---|---|---|
| Содержимое | Текущие записи | Текущие записи и информация об удалении записей |
| Обновление записи (доступно для таблиц с set.on.conflict.do=update) | Новая запись перезаписывает текущую с обновлением начальной версии (sys_from) | Новая запись перезаписывает текущую с обновлением начальной версии (sys_from) |
| Удаление записи | Запись удаляется бесследно | Запись помечается как удаленная (sys_op=1) и остается доступна для чтения с FOR SYSTEM_TIME RAW или FOR SYSTEM_TIME FINISHED IN/CN/TS. Удаление доступно, только если таблица также имеет опцию set.on.conflict.do=update |
| Повторное добавление удаленной записи | Добавляется новая запись | Добавляется новая запись, а информация о предыдущем удалении удаляется |
| Чтение добавленных и обновленных записей | SELECT ... FOR SYSTEM_TIME STARTED IN/CN/TS | SELECT ... FOR SYSTEM_TIME STARTED IN/CN/TS |
| Чтение информации об удаленных записях* | Недоступно | SELECT ... FOR SYSTEM_TIME FINISHED IN/CN/TS |
* При удалении запись снапшот-таблицы гарантированно сохраняет только первичный ключ — остальные поля могут быть обнулены. Такая запись не является исторической и не отражает состояние объекта перед удалением.
Уровни консистентности при чтении данных
Снапшот-таблицы позволяют гибко регулировать необходимый уровень консистентности данных при чтении из них. Доступные уровни консистентности и меры по их обеспечению см. в таблице ниже.
| Уровень консистентности | Как добиться этого уровня консистентности |
|---|---|
| Casual | Действует по умолчанию, дополнительные меры не требуются |
| Linearizability | Используйте любой из способов:
|
SELECT-запросы без DATASOURCE_TYPE к снапшот-таблице с set.strict.consistency.enable=true выполняются в первом по алфавиту включенном датасорсе таблицы. Это гарантирует строгую консистентность (Linearizability), но вызывает ошибку, если выбранный датасорс содержит данные не всех сущностей запроса.
Сравнение с обычными логическими и прокси-таблицами
В таблице ниже представлено сравнение снапшот-таблиц с обычными логическими таблицами и прокси-таблицами. Плюс означает, что свойство поддерживается или применимо к таблице, минус — что свойство не поддерживается или не применимо.
| Свойство | Снапшот-таблица | Обычная лог. таблица | Прокси-таблица |
|---|---|---|---|
| Параллельная запись данных | + | – | + |
| Версионирование данных | + Отслеживание удалений можно выключить | + | – |
| История данных | – | + | – |
| Запись данных в операциях записи | + | + | – |
| Запись данных в дельте | – | + | – |
| Синхронная репликация данных в несколько датасорсов | + | + | – |
| Восстановление механизмом auto-failover при сбое датасорсов | + | + | – |
| Уровень консистентности данных при чтении | От Casual до Linearizability (в зависимости от настроек таблицы и параметров запроса) | Linearizability | Неприменимо, так как всегда 1 реплика |
Особенности записи данных
Двухфазная запись
Операция записи в снапшот-таблицу исполняется как двухфазный коммит:
- фаза 1 — параллельная подготовка изменений в датасорсах таблицы;
- фаза 2 — одновременная фиксация подготовленных изменений в датасорсах таблицы.
Операция записи переходит к фазе 2 только после успешного завершения фазы 1 во всех датасорсах, минимально необходимых для записи. Ошибки в фазе 1 приводят к автоматической отмене операции, в фазе 2 — к переповторам до успешного завершения.
Число переповторов в фазе 2 определяется параметром WRITE_OPERATION_COMMIT_RETRY_COUNT.
Изменения данных по операции становятся доступны по умолчанию (без FOR SYSTEM_TIME) после успешного завершения фазы 2.
Контроль целостности данных
Несмотря на запись данных в снапшот-таблицы через staging-таблицы типа UNLOGGED, неустойчивые к сбоям, система гарантирует целостность данных.
Для этого используются служебные таблицы, которые система создает во всех ADP-датасорсах. При создании таблицы и после каждого сбоя датасорса в таблице фиксируется текущая метка времени. Таблица имеет тип UNLOGGED и очищается при сбое датасорса, поэтому наличие в ней метки означает, что датасорс работает без сбоев с зафиксированной метки времени.
Перед завершением фазы 1 операции система проверяет наличие метки, предшествующей операции, в задействованных датасорсах. При успешной проверке операция переходит к фазе 2, при неуспешной — операция завершается с ошибкой, исключая сохранение нецелостных данных.
Разрешение конфликтов параллельной записи (deadlocks)
В системе предусмотрен встроенный механизм, который разрешает взаимные блокировки операций, возникающие при конфликтах параллельной записи в снапшот-таблицы.
Блокировки разрешаются следующим образом:
- [Обнаружение блокировки] Нода, исполняющая операцию, ждет завершения фазы 1 операции в течение
WRITE_OPERATION_PREPARE_TRANSACTION_TIMEOUT_MS, и при тайм-ауте сообщает лидеру кластера о подозрении на блокировку. - [Вердикт лидера] Лидер собирает информацию о блокировках, выносит вердикт и сообщает его нодам, исполняющим операции.
- [Разрешение блокировки] Ноды отменяют изменения по всем конфликтующим операциям, кроме первой, снимают блокировку и после завершения первой операции повторяют остальные.
Если лидер сообщил, что блокировки нет, нода продолжает ждать завершения фазы 1, повторяя проверки через WRITE_OPERATION_PREPARE_TRANSACTION_CHECK_PERIOD_MS. Медленная запись в датасорс может быть вызвана, например, замедлением самого датасорса.
Статистика по таблице
По умолчанию система собирает статистику по логическим сущностям. Подробнее о просмотре, отключении и обнулении статистики см. в разделе Управление статистикой.