Ограничение и фильтр хранения Azure blob

Лазурное хранилище для многопользовательского приложения. Мы работаем над разработкой многопользовательской заявки на Azure, при которой на каждого арендатора требуется около 10 000 арендаторов и около 100 ГБ на 1 ТБ. Приложение должно поддерживать документы и бинарный контент вместе с метаданными для каждого арендатора отдельно. Мы думаем о хранении данных в блоке Azure Block Blob. Поскольку требование состоит в том, чтобы хранить данные отдельно для каждого арендатора, мы сталкивались со следующим подходом.

  • Создайте отдельную учетную запись хранилища для каждого арендатора
  • Это помогает поддерживать использование арендатора мудрым, что также помогает при выставлении счетов.
  • Создайте отдельный контейнер в каждой учетной записи хранилища, чтобы отделить на основе категории
  • Храните документ в блочном блочном хранилище вместе с метаданными.

У нас есть следующие запросы относительно нашего подхода:

  • Хорошо ли хранить документы или двоичный контент в блочном блоке наряду с метаданными? Или есть лучший способ его достижения (возможно, используя SQL Azure для метаданных и blob для контента, или лучше)?
  • Как запросить данные с некоторым условием фильтрации метаданных? то есть получить все blob, где metadat1 = value1 и metadata2 = value2
  • Это хорошая идея создать отдельную учетную запись хранилища для каждого арендатора?
    а. Если нет, то какова будет модель, через которую мы можем хранить конкретные данные арендатора в хранилище и приложении Azure, может эффективно их использовать?
  • Существует ли пропускная способность или любое другое ограничение на количество запросов на чтение/запись данных на хранилище Blob в контексте масштабируемости и высокой доступности?
  • В соответствии с моделью оценки azure они загружают планку для хранения, то есть сначала 1 ТБ $0,095/ГБ, затем 49 ТБ $0,08/ГБ. Эти сборы зачисляются на одну учетную запись или на подписку?
    а. Точно так же стоимость транзакции применима для каждой учетной записи или для каждой подписки?

Ответы

Ответ 1

  • Хорошо ли хранить документы или двоичный контент в блочном блобе вместе с метаданными? Или есть лучший способ его достижения (возможно, используя SQL Azure для метаданных и blob для контента или лучше)?
  • Как запросить данные с некоторым условием фильтрации метаданных? то есть получить все blob, где metadat1 = value1 и metadata2 = value2

Чтобы ответить 1 и 2, вы не можете запрашивать метаданные в хранилище blob. Поэтому я предполагаю, что лучшим вариантом будет использование SQL Azure или Azure Table Storage, так как у обоих из них есть возможности запросов. Учитывая, что вы будете хранить огромное количество blob (и, тем самым, даже больше метаданных), я больше склоняюсь к хранилищу таблиц, но для этого потребуются особые соображения дизайна, такие как правильное разбиение на разделы.

Можно ли создать отдельную учетную запись для каждого арендатора? а. Если нет, то какова будет модель, через которую мы можем хранить конкретные данные арендатора в хранилище и приложении Azure, может эффективно их использовать?

Я могу думать о 3 причинах, почему наличие отдельной учетной записи хранилища на одного арендатора является хорошей идеей:

  • Это упрощает ваше выставление счетов.
  • Это поможет вам сохранить цели масштабируемости.
  • Поскольку вы упомянули, что каждый арендатор может хранить до 1 Тбайта данных, учитывая текущее ограничение учетной записи хранилища 200 ТБ, вы можете поддерживать только 200 арендаторов на одну учетную запись. После этого вам нужно будет найти другую учетную запись и начать хранить данные там.

В целом очень элегантное решение, поддерживающее отдельную учетную запись/арендатор. Задача заключалась бы в том, чтобы ограничение по умолчанию увеличилось с 20 учетных записей/подписки. Вам будет необходимо поговорить с поддержкой.

Существует ли пропускная способность или любое другое ограничение на количество запросов на чтение/запись данных на хранилище Blob в контексте масштабируемости и высокой доступности?

Да, ознакомьтесь с блоком целевых показателей масштабируемости от группы хранения Windows Azure Blob: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx

Согласно модели ценообразования на лазурь, они загружают планку для хранения, то есть сначала 1 ТБ $0,095/ГБ, затем 49 ТБ 0,08 долл./ГБ. Эти сборы зачисляются на одну учетную запись или на подписку? а. То же самое, стоимость транзакции применима для каждой учетной записи или для каждой подписки?

Не уверен в этом, но я угадываю его на одну учетную запись. Вы можете обратиться в службу поддержки.

Надеюсь, что это поможет.