Что лучше: иметь много маленьких контейнеров больших двоичных объектов хранилища Azure (каждый с несколькими большими двоичными объектами) или один действительно большой контейнер с множеством больших двоичных объектов?

Итак, сценарий следующий:

У меня есть несколько экземпляров веб-службы, которая записывает большой двоичный объект данных в хранилище Azure. Мне нужно иметь возможность группировать большие двоичные объекты в контейнер (или виртуальный каталог) в зависимости от того, когда он был получен. Время от времени (в худшем случае - каждый день) старые капли обрабатываются, а затем удаляются.

У меня есть два варианта:

Вариант 1

Я создаю один контейнер, называемый «blobs» (например), и затем сохраняю в нем все блоги. Каждый большой двоичный объект будет использовать имя стиля каталога, где имя каталога будет временем его получения (например, «hr0min0 / data.bin», «hr0min0 / data2.bin», «hr0min30 / data3.bin», «hr1min45 / data.bin»). ", ...," hr23min0 / dataN.bin "и т. д. - новый каталог каждые X минут). То, что обрабатывает эти BLOB-объекты, будет обрабатывать сначала BLOB-объекты hr0min0, затем hr0minX и т. Д. (И эти BLOB-объекты все еще записываются при обработке).

Вариант 2

У меня есть много контейнеров, каждый с именем, основанным на времени прибытия (сначала будет контейнер с именем blobs_hr0min0, затем blobs_hr0minX и т. Д.), И все капли в контейнере - это те капли, которые прибыли в указанное время. То, что обрабатывает эти блоги, будет обрабатывать по одному контейнеру за раз.

Итак, мой вопрос: какой вариант лучше? Обеспечивает ли вариант 2 лучшее распараллеливание (поскольку контейнеры могут находиться на разных серверах) или вариант 1 лучше, поскольку многие контейнеры могут вызывать другие неизвестные проблемы?


azure azure-storage-blobs azure-storage
person encee    schedule 16.11.2011    source источник

Ответы (4)


arrow_upward
63
arrow_downward

Я не думаю, что это действительно важно (с точки зрения масштабируемости / распараллеливания), потому что секционирование в хранилище больших двоичных объектов Win Azure выполняется на уровне больших двоичных объектов, а не на уровне контейнера. Причины распределения по разным контейнерам больше связаны с контролем доступа (например, SAS) или общим размером хранилища.

Подробнее см. Здесь: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx

(Прокрутите вниз до «Разделы»).

Цитата:

Большие двоичные объекты - поскольку ключ раздела связан с именем большого двоичного объекта, мы можем балансировать нагрузку доступа к различным большим двоичным объектам на любом количестве серверов, чтобы масштабировать доступ к ним. Это позволяет контейнерам увеличиваться до необходимого размера (в пределах лимита места для учетной записи хранения). Компромисс заключается в том, что мы не предоставляем возможность выполнять атомарные транзакции между несколькими BLOB-объектами.

person Eugenio Pace    schedule 16.11.2011
comment
Пожалуйста, есть ли необходимость делать имя blob как можно короче? (У меня есть один действительно большой контейнер с тоннами капель, вариант 1 в вопросе.) - person nmit026; 26.10.2017

arrow_upward
62
arrow_downward

Все дали отличные ответы о прямом доступе к BLOB-объектам. Однако, если вам нужно перечислить большие двоичные объекты в контейнере, вы, вероятно, увидите лучшую производительность с моделью с несколькими контейнерами. Я только что разговаривал с компанией, которая хранила огромное количество блобов в одном контейнере. Они часто перечисляют объекты в контейнере, а затем выполняют действия с подмножеством этих больших двоичных объектов. Они наблюдают снижение производительности, поскольку время для получения полного списка растет.

Это может не относиться к вашему сценарию, но это нужно учитывать ...

person David Makogon    schedule 16.11.2011
comment
Это хороший момент. На момент написания (июнь 2016 г.) я считаю, что по-прежнему не существует другого способа подсчитать количество BLOB-объектов в контейнере, кроме как получить список всех BLOB-объектов в этом контейнере и проверить свойство списка Count. - person Steven Rands; 21.06.2016
comment
Есть ли необходимость делать имя blob как можно короче? (У меня есть один действительно большой контейнер с тоннами капель, вариант 1 в вопросе.) - person nmit026; 26.10.2017
comment
Именно тот сценарий, которого мы пытаемся избежать - person Glenit; 07.12.2018

arrow_upward
21
arrow_downward

Теоретически не должно быть разницы между большим количеством контейнеров или меньшим количеством контейнеров с большим количеством BLOB-объектов. Дополнительные контейнеры могут использоваться в качестве дополнительных границ безопасности (например, для публичного анонимного доступа или различных подписей SAS). Дополнительные контейнеры также могут немного упростить обслуживание при сокращении (удаление одного контейнера вместо нацеливания на каждый большой двоичный объект). По этим причинам я предпочитаю использовать больше контейнеров (не из соображений производительности).

Теоретически влияния на производительность не должно быть. Сам BLOB-объект (полный URL-адрес) является ключом раздела в Windows Azure (используется уже давно). Это самая маленькая вещь, которая будет сбалансирована по нагрузке с сервера разделов. Таким образом, вы можете (и часто будете) иметь два разных больших двоичных объекта в одном контейнере, обслуживаемые разными серверами.

Джереми указывает, что существует разница в производительности между большим и меньшим количеством контейнеров. Я недостаточно углубился в эти тесты, чтобы объяснить, почему это может быть так, но я подозреваю, что другие факторы (например, размер, продолжительность теста и т. Д.) Могут объяснить любые расхождения.

person dunnry    schedule 16.11.2011

arrow_upward
4
arrow_downward

Есть еще один фактор, влияющий на это. Цена!

В настоящее время стоимость операции «Список» и «Создать контейнер» одинакова: 0,054 US $ / 10.000 звонков.

Фактически такая же цена за написание капли.

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

  • удалить бесплатно

вы можете увидеть калькулятор здесь: https://azure.microsoft.com/en-us/pricing/calculator/

person Jiří Herník    schedule 13.10.2017