Чем отличается одна таблица хранилища таблиц Azure с большим количеством ключей секций от множества таблиц с меньшим количеством ключей секций?

У меня есть приложение Windows Azure, в котором все запросы на чтение таблицы A выполняются в отдельных разделах для диапазона ключей строк. Ключи раздела, которые упрощают эту схему хранения, на самом деле представляют собой плоские имена объектов в иерархии, так что ключ раздела имеет формат {root}_{child1}_{child2}_{leaf}. Я могу понять, как может быть выгодно разделить эту одну большую таблицу A на множество таблиц, используя корневое измерение ключей разделов в именовании таблиц (таким образом, ключ раздела станет {child1}_{child2}_{leaf}).

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

Более конкретные вопросы о предлагаемом мной изменении:

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

azure azure-table-storage partitioning scalability
person user483679    schedule 12.06.2011    source источник
comment
Пожалуйста, опубликуйте несколько примеров TPL и асинхронных запросов.   -  person paparazzo    schedule 06.07.2012

Ответы (2)


arrow_upward
12
arrow_downward

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

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

person user94559    schedule 12.06.2011
comment
Интересно, как я понимаю, ограничение ввода-вывода для одновременных рабочих ролей, запрашивающих хранилище таблиц, находится на уровне учетной записи? - person user483679; 12.06.2011
comment
Существуют ограничения на количество операций в секунду на уровне раздела (таблица+раздел) и на уровне учетной записи. - person user94559; 13.06.2011

arrow_upward
6
arrow_downward

+1 за ответ Стива.

Некоторые вещи, чтобы добавить

  • возможно, стоит рассмотреть возможность использования нескольких учетных записей хранения — поскольку в настоящее время именно учетная запись хранения является единицей масштабируемости — каждая учетная запись хранения официально нацелена примерно на 5000 объектов/транзакций в секунду, поэтому, если вы хотите больше, чем это, вам нужно использовать несколько Счета.
  • в производительности есть некоторые деликатные детали того, как вы запрашиваете свои данные - если элементы не находятся в одном разделе, то, как правило, быстрее выполнять отдельные параллельные запросы вместо выполнения одного запроса со сложным параметром where.
  • особенно полезными могут оказаться сообщения в блоге группы хранения — http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx и http://blogs.msdn.com/b/windowsazurestorage/archive/2010/05/10/windows-azure-storage-abstractions-and-their-scalability-targets.aspx
  • вам также может понадобиться знать о затратах — примерно 1 доллар за миллион просмотров.
person Stuart    schedule 12.06.2011
comment
Да, отлично, спасибо за ваши идеи. Во время тестирования я столкнулся с отдельными параллельными запросами (по одному на раздел), но приятно знать, что это действительно правильный подход. TPL и асинхронные запросы работают хорошо. Я проверю несколько аккаунтов. Проблема в том, что у меня может быть только определенное количество учетных записей, верно? Мне не сразу понятно, как логически разделить мое приложение на 5 или около того частей, которые, вероятно, будут масштабироваться. - person user483679; 12.06.2011
comment
Чтобы добавить... На самом деле было бы очень полезно для целей выставления счетов, если бы я мог создать столько учетных записей хранения таблиц, сколько мне нужно. Раздел учетной записи хранения высокого уровня, который имеет смысл для проектов, которые мы хотим - person user483679; 12.06.2011
comment
Чтобы добавить... На самом деле было бы очень полезно для целей выставления счетов, если бы я мог создать столько учетных записей хранения таблиц, сколько мне нужно. Раздел учетной записи хранения высокого уровня, который имеет смысл для проектов, которые мы хотим реализовать, будет на уровне клиента. Если бы мы могли назначить каждому клиенту уникальную учетную запись хранения таблиц, то мы, вероятно, достигли бы наших целей по масштабируемости операций ввода-вывода и эффективно использовали вашу систему выставления счетов как часть нашей собственной. - person user483679; 12.06.2011
comment
Просто чтобы прояснить... это не моя биллинговая система :) И я думаю, что вы можете иметь более 5 учетных записей хранения - но вам нужно спросить об этом Microsoft. - person Stuart; 12.06.2011
comment
Вы определенно можете запросить у MS дополнительные учетные записи хранения, но они, похоже, подводят черту примерно к 20. - person knightpfhor; 13.06.2011