Как правило, по возможности следует избегать сканирования таблиц. Это очень дорогие операции (особенно если у вас много разделов). не столько с точки зрения нагрузки на таблицу, сколько у них очень высокая совокупная задержка (поясняется ниже). Тем не менее, иногда этого просто невозможно избежать.
Мы обновили архитектуру хранилища и подняли ряд целевых лимитов.
http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx
Каждая учетная запись хранения теперь составляет 20 тыс. Операций ввода-вывода в секунду / сек. Каждый раздел теперь 2k / sec
То, как взаимодействуют разделы, немного тонко и зависит от того, как они используются (и меняются со временем).
Хранилище Azure состоит из двух этапов: один набор серверов обрабатывает диапазоны, а другой задает фактическое хранилище (т. Е. 3 копии). Когда таблица холодная, все разделы могут обслуживаться одним сервером. Поскольку разделы подвергаются постоянной нагрузке, система начнет автоматически распределять рабочую нагрузку (т. Е. Осколок) на дополнительные серверы. Осколки создаются на границах разделов.
Для низкого / среднего уровня стресса вы можете не достигать порогового значения для осколков или только минимальное количество раз. Также некоторое влияние будет иметь шаблон доступа (если вы только добавляете, сегментирование не поможет). Произвольный доступ ко всем шаблонам будет лучше всего масштабироваться. Когда система выполняет ребалансировку, вы получите ответ 503 в течение нескольких секунд, а затем операции вернутся в нормальный режим.
Если вы проведете сканирование таблицы, вы фактически сделаете несколько обходов к столу. Когда запрос достигает конца раздела, ответ будет возвращен с любыми найденными данными (или без данных, если критерии не были соблюдены) и токеном продолжения. Затем запрос повторно отправляется (и возвращается с токеном) снова и снова, пока вы не дойдете до конца таблицы. Это абстрагируется SDK, но если вы сделаете прямые вызовы REST, вы это увидите.
С точки зрения производительности таблицы сканирование повлияет только на тот раздел, в котором оно сканируется в данный момент.
Чтобы ускорить широкий запрос, который попадает в несколько разделов, вы можете фактически разбить его на несколько параллельных доступов (например, один поток на раздел), а затем объединить в клиенте. На самом деле это зависит от того, сколько данных вы получаете обратно, насколько велика таблица и т. Д.
person
Pat Filoteo
schedule
19.02.2013
