Поделиться через

Сведения о том, как начисляются расходы на моментальные снимки BLOB-объектов

  • Статья

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

Важные вопросы выставления счетов

Следующий список включает ключевые пункты, которые следует рассмотреть при создании моментального снимка.

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

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

  • Замена блочного BLOB-объекта путем вызова метода UploadFile, UploadText, UploadStream или UploadByteArray заменяет все блоки в этом BLOB-объекте. При наличии моментального снимка, сопоставленного с этим большим двоичным объектом, все блокировки в базовом большом двоичном объекте и моментальном снимке разойдутся, и вы будете оплачивать ресурсы всех блокировок в обоих больших двоичных объектах. Это произойдет, даже если данные базового большого двоичного объекта и моментального снимка останутся идентичными.

  • В службе BLOB-объектов Azure нет средств, позволяющих определить, содержат ли два блока идентичные данные. Каждый блок, который был загружен и зафиксирован, обрабатывается как уникальный, даже если он содержит те же данные и имеет тот же идентификатор блока. Поскольку плата добавляется за уникальные блокировки, важно иметь в виду, что обновление BLOB-объекта, имеющего моментальные снимки, приведет к появлению дополнительных уникальных блокировок и дополнительным расходам.

Важно!

Рекомендуется управлять моментальными снимками осторожно, чтобы избежать наценок. Рекомендуется управлять моментальными снимками следующим образом.

  • Удаляйте и повторно создавайте моментальные снимки, связанные с большим двоичным объектом, при обновлении этого объекта, даже если вы обновляете его идентичными данными, если только структура вашего приложения не требует сохранения моментальных снимков. За счет удаления и повторного создания моментальных снимков больших двоичных объектов можно исключить расхождение большого двоичного объекта с моментальными снимками.
  • Если вы храните моментальные снимки для большого двоичного объекта, не вызывайте методы UploadFile, UploadText, UploadStream или UploadByteArray для обновления большого двоичного объекта, так как эти методы заменяют все блоки в большом двоичном объекте. Вместо этого обновляйте наименьшее возможное количество блоков с помощью методов PutBlock и PutBlockList.

Сценарии выставления счетов за моментальные снимки

В следующих сценариях показано, как добавляется плата за большой двоичный объект и его моментальные снимки. В сценарии 1 базовый большой двоичный объект не обновлялся с момента создания моментального снимка, поэтому плата начисляется только за уникальные блокировки 1, 2 и 3.

Схема, показывающая, как взимается плата за блоки в сценарии 1

Сценарий 1. Плата взимается только в блоках 1, 2 и 3.

В сценарии 2 базовый BLOB-объект обновлен, а snapshot — нет. Блок 3 был обновлен, и, хотя он содержит такие же данные и тот же идентификатор, он отличается от блока 3 в моментальном снимке. В результате плата в учетной записи взимается с 4 блокировок.

Схема, показывающая, как взимается плата за блоки в сценарии 2

Сценарий 2. За блоки 1, 2 и 3 в базовом BLOB-объекте взимается плата, а также за блок 3 в snapshot.

В сценарии 3 базовый большой двоичный объект был обновлен, а моментальный снимок нет. Блок 3 был заменен блоком 4 в базовом большом двоичном объекте, но моментальный снимок по-прежнему отражает блок 3. В результате плата в учетной записи взимается с 4 блокировок.

Схема, показывающая, как взимается плата за блоки в сценарии 3

Сценарий 3. На блоки 1, 2, 3 и 4 взимается плата.

В сценарии 4 базовый blob-объект был обновлен полностью и не содержит никаких первоначальных блокировок. В результате плата в учетной записи взимается за все восемь уникальных блоков. Этот сценарий может произойти при использовании такого методов обновления, как UploadFile, UploadText, UploadFromStream или UploadByteArray, так как эти методы заменяют все содержимое больших двоичных объектов.

Схема, показывающая, как взимается плата за блоки в сценарии 4

Сценарий 4. На блоки 1, 2, 3, 4, 5, 6, 7 и 8 взимается плата.

См. также:

Использование службы хранения BLOB-объектов
Как использовать службу хранилища очередей
Создание моментального снимка большого двоичного объекта