Вопросы о целях масштабируемости Azure и использовании нескольких учетных записей хранения Azure?

Question

В блоге Абстракции хранилища Windows Azure и их целях масштабирования сообщение в блоге указывает, что для одной учетной записи хранения существует ограничение в 5000 сущностей / секунду для транзакции и ограничение в 500 сущностей / секунду для одного раздела таблицы , И чтобы соответствовать первому пределу, нужно использовать несколько учетных записей, а для ограничения раздела следует тщательно спроектировать их разделы.

Я хотел бы попросить тех, кто имеет опыт работы с лимитом 5000, использовать одну учетную запись хранения. Прямо сейчас я создаю сообщество блогов / вики и говорю, что однажды сайт становится популярным и привлекает много трафика. Должен ли я разделить пользовательские таблицы на одну учетную запись хранения и таблицы блогов на другую учетную запись, а таблицы на вики-сайты - на другую, чтобы предотвратить это ограничение прямо сейчас? Или я должен добавить дополнительные учетные записи по мере необходимости, кстати, есть ли способ перенести таблицы хранения Azure из одной учетной записи в другую? В статье говорится, что, когда вы достигнете этого предела, вы получите ответы «503 сервер занят», есть ли способ узнать, что лимит приближается, чтобы я мог что-то сделать заранее, не получив 503 ошибок? *

Answer 1

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

Насколько я знаю, предупреждения "Вы собираетесь достичь предела" нет. Первый раз, когда вы узнаете, что достигли предела, вы получите ошибку 503.

При передаче данных из одной учетной записи в другую, нет встроенной функциональности, которая сделает это за вас. Вы должны либо свернуть свое собственное решение, чтобы прочитать каждую строку в исходной таблице и записать его в таблицу назначения, либо использовать что-то вроде Cerebrata Cloud Storage Studio , которая позволяет загружать и выгружать содержимое столы или их CMDLTS , которые позволяют делать то же самое, но стоят дешевле / бесплатно.

Если вы только начинаете и у вас есть логические способы распределения данных по учетным записям хранения, и это не делает код слишком сложным, то сделайте это. Но я бы не стал сильно волноваться об этом на данном этапе. Скорее всего, если ваш сайт станет популярным, и вы начнете превышать лимит транзакций, он, скорее всего, будет происходить из области, которую вы не ожидали, или может состоять из слишком большого количества транзакций только для одной таблицы. Как вы сказали, это было для сообщества блогов, область, в которой, вероятно, будет больше всего транзакций, - это место, где вы храните комментарии. Если вы получаете более 5000 транзакций в секунду с таблицей комментариев, возможно, вам придется разделить комментарии между несколькими учетными записями хранения. Конечно, если блоги так популярны, скорее всего, у вас будут и другие проблемы.

Answer 2

Если вам нужна масштабируемость, вы можете рассмотреть Sql Azure Federations вместо хранилища таблиц Azure.Функция федераций стала доступна, начиная с декабря 2011 года. Хороший обзор можно найти здесь .

С помощью федераций Sql Azure вы сможете лучше контролировать объем используемых ресурсов.В Table Storage вам предлагается создавать много разделов, чтобы базовый механизм мог в какой-то момент распределить ваши данные на нескольких машинах, и вы получите увеличенную пропускную способность.Однако раздел - это всего лишь подсказка для движка Table Storage.Это не обязательно переместит данные на новую машину.Он может сделать это, основываясь на использовании и на его внутренних алгоритмах, но вы никогда не можете быть уверены, когда это произойдет.С Sql Azure Federations вы - тот, кто контролирует количество используемых вами экземпляров.Вы будете контролировать баланс между небольшим количеством экземпляров (= небольшая стоимость) и большим количеством экземпляров (= большая пропускная способность).

С федерациями вы все равно сможете пользоваться большинством преимуществ реляционных баз данных.То есть у вас еще могут быть транзакции, объединения, индексы.Фактически вы можете использовать все функциональные возможности автономной базы данных Sql Azure.Единственным ограничением является то, что вы можете работать только с одним экземпляром федерации за один раз (в настоящее время нет встроенной поддержки выбора между экземплярами внутри федерации).

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

Вероятно, единственная причина, по которой следует учитывать Table Storage, связана с его ценой / ГБ, которая намного ниже по сравнению с Sql Azure (цена таблицы хранения описана здесь ,Цены Sql Azure описаны здесь ).Поэтому, если вы планируете хранить огромные объемы данных, тогда вы действительно можете рассмотреть возможность хранения таблиц (если вы можете жить с его ограничениями).

Строго с точки зрения пропускной способности, один экземпляр Sql Azure можетобеспечить аналогичную производительность с помощью учетной записи Table Storage.До тех пор, пока вы можете получить хорошее распределение запросов, с федерациями вы можете умножить пропускную способность одной базы данных на общее количество использованных экземпляров.

Если вас интересуют некоторые цифры, несколько месяцев назадЯ сделал эталонный тест и запустил его для базы данных объединения.Результаты можно найти здесь .