Кратко

  • Постоянные таблицы Snowflake проходят через семь дней Fail-safe после окончания Time Travel. Этот срок нельзя изменить, а исторические данные продолжают занимать оплачиваемое место.
  • Сокращение истории, выбор transient-таблиц и удаление клонов меняют разные причины хранения. Размер экономии зависит от оставшихся платных байтов, в том числе у удалённых таблиц.

У постоянной таблицы Snowflake есть оплачиваемая жизнь после удаления. Клиент завершает работу с объектом, но данные ещё нужны системе восстановления. За Time Travel следуют семь дней Fail-safe, и место под историю продолжает оплачиваться.

Для закупщика это довольно приземлённая особенность облака: освободить название в каталоге удаётся раньше, чем освободить весь связанный с ним платный объём. Проект очистки может успешно закрыть свои технические задачи, оставив финансовому отделу ещё некоторое время хранения.

В описании стоимости хранения Snowflake перечисляет активные данные, историю Time Travel, Fail-safe и данные, на которые продолжают ссылаться клоны. При расчёте используется сжатый размер таблиц. Поэтому количество удалённых объектов само по себе плохо объясняет изменение счёта: деньги следуют за сохраняемыми байтами.

Последние семь дней ведёт поставщик

По правилам Fail-safe, семидневный период начинается после окончания Time Travel и не настраивается. Обычный доступ клиента к истории к этому моменту заканчивается. Возможное восстановление переходит к Snowflake: для него нужно обратиться в поддержку.

Услуга рассчитана на тяжёлые эксплуатационные сбои после попыток использовать другие способы восстановления. Компания действует по принципу наилучших усилий, а процесс может занять от нескольких часов до нескольких дней. Работа по восстановлению также расходует тарифицируемые бессерверные вычислительные ресурсы. Плата за сохранение материала и плата за его извлечение относятся к разным действиям.

Такая дополнительная попытка может быть ценной, если данные трудно создать заново. Её стоимость возникает заранее: системе нужно оставить то, что предстоит спасать. Клиент оплачивает возможность восстановления через поставщика ещё в период нормальной работы.

Таблица сроков исторического хранения показывает основные варианты:

Тип таблицы Time Travel Затем Fail-safe
Постоянная, Standard Edition Ноль или один день Семь дней
Постоянная, Enterprise Edition и выше От нуля до 90 дней Семь дней
transient Ноль или один день Нет
temporary Ноль или один день, до удаления либо завершения сессии Нет

Для постоянной таблицы нулевой Time Travel оставляет следующую семидневную ступень. Долго выполняющийся исторический запрос может отложить переход в Fail-safe до своего завершения. Смена состояний также выполняется фоновыми процессами. Эти правила задают последовательность защиты, а оставшиеся ссылки и выполняющаяся работа влияют на фактическое освобождение данных.

Старое удаление живёт по старой настройке

В документации Time Travel приведён пример сокращения срока с десяти дней до одного. Последний день остаётся доступным через Time Travel. История возрастом от двух до десяти дней перемещается в Fail-safe. Клиент уменьшил своё окно прямого доступа, а старые данные перешли на следующую стадию хранения.

Другая иллюстрация касается уже удалённого объекта. Таблица унаследовала от схемы 90 дней, после чего была удалена. Если затем установить для схемы один день, удалённая таблица сохранит прежние 90 дней. Чтобы поменять её собственный срок, документация предусматривает сначала восстановление объекта, а затем изменение настройки.

Новая политика родительского объекта действует на активные таблицы. Удалённый объект продолжает ранее начатый путь. Кроме того, администратор аккаунта может задать минимальный срок, который увеличит фактическое хранение сверх локальной настройки. Одного нуля в свойствах таблицы недостаточно для чтения всей политики.

Так выбор при создании набора данных становится условием будущих расходов. К моменту закрытия проекта очисткой может заниматься уже другая команда. Она получает вместе с данными прежние решения о том, как долго сохранять возможность возврата.

Клон оставляет связь с прежними данными

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

Справочник TABLE_STORAGE_METRICS выделяет такие данные среди причин платного хранения. Основные группы — активные байты, Time Travel, Fail-safe и байты, удерживаемые для клонов. Последняя группа включает также данные, сохраняемые резервными копиями WORM.

Удалённые таблицы остаются в представлении, пока с ними связана плата за место. Повторное создание под тем же именем может оставить несколько версий со своей историей. Чтобы объяснить счёт, нужно сопоставить идентификаторы объектов с их байтами; привычное имя уже может принадлежать новой таблице.

Данные Account Usage могут запаздывать на 90 минут. Старая строка с нулём во всех четырёх основных счётчиках не создаёт плату за хранение. Для расчёта остаточного расхода конкретного аккаунта нужны его сжатые сохраняемые байты, действующая политика и применяемая цена.

Короткая защита оплачивается работой по восстановлению

Таблица transient позволяет максимум один день Time Travel и обходится без Fail-safe. Активные данные оплачиваются всё время существования таблицы. Однодневный предел касается дополнительной исторической защиты: таблица, оставленная на недели, занимает активное место в течение этих недель.

Для воспроизводимых рабочих данных этот выбор может быть удобным. После истечения истории Snowflake уже не сможет вернуть их через Fail-safe. Клиент берёт на себя время, вычисления и возможную остановку работы для повторного создания. Когда реконструкция обходится дорого, платная защита может оказаться экономнее.

У таблиц temporary есть ещё граница сессии. История заканчивается с удалением таблицы или завершением сессии. Разрыв соединения сам по себе сессию не завершает. Закрытое окно приложения может оставить незаконченной очистку, которую пользователь уже посчитал выполненной.

Snowflake даёт покупателю несколько способов выбрать срок и характер защиты. Все они требуют решения о том, какие данные ещё должны быть доступны для спасения. Экономию подтверждает уход оплачиваемых байтов. Команда удаления получает подтверждение успеха раньше.