Дизайн разделов для хранения лазурных таблиц

Question

У меня есть программное обеспечение, которое собирает данные в течение большого периода времени, приблизительно 200 отсчетов в секунду. Для этого используется база данных SQL. Я ищу использовать Azure для переноса большого количества моих старых «архивных» данных.

В программном обеспечении используется архитектура с несколькими арендаторами, поэтому я планирую использовать одну таблицу Azure для каждого арендатора. Каждый арендатор, возможно, отслеживает 10-20 разных показателей, поэтому я планирую использовать метрический идентификатор (int) в качестве ключа раздела.

Поскольку каждая метрика будет иметь только одно чтение в минуту (макс.), Я планирую использовать DateTime.Ticks.ToString («d19») как свой RowKey.

Мне не хватает понимания относительно того, как это будет масштабироваться; так что надеялся, что кто-то может это прояснить:

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

Однако моя строка может потенциально представлять данные в течение примерно 5 лет, поэтому я оцениваю приблизительно 2,5 миллиона строк.

Является ли Azure достаточно умным, чтобы затем разбить на основе rowkey, а также я проектирую в будущем узкое место? Я знаю, как правило, не досрочно оптимизировать, но с чем-то вроде Azure, который не кажется таким разумным, как нормальный!

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

Answer 1

Несколько комментариев:

Помимо хранения данных, вы можете также изучить, как вы хотели бы, чтобы извлечь данные, которые могут изменить свой дизайн значительно. Некоторые вопросы, которые вы могли бы задать себе сами:

• Когда я получаю данные, всегда получаю данные для определенной метрики и для диапазона даты и времени?
• Или мне нужно получить данные для всех показателей для определенного диапазона дат/времени? Если это так, вы просматриваете полное сканирование таблицы. Очевидно, вы могли бы избежать этого, выполнив несколько запросов (один запрос/PartitionKey)
• Нужно ли сначала увидеть самые последние результаты, или мне все равно. Если это первый, тогда ваша стратегия RowKey должна быть чем-то вроде (DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks).ToString("d19").

Кроме того, поскольку PartitionKey является строкой, вы можете преобразовать int значение в значение string с некоторыми «0» prepadding так, что все ваши идентификаторы появляются в порядке иначе вы получите 1, 10, 11, .., 19, 2, ... и т. Д.

Насколько я знаю, Windows Azure разделяет данные только на основе PartitionKey, а не RowKey. Внутри раздела RowKey служит уникальным ключом. Windows Azure попытается сохранить данные с одним и тем же PartitionKey в том же узле, но поскольку каждый узел является физическим устройством (и, следовательно, имеет ограничение по размеру), данные могут перетекать и на другой узел.

Возможно, вы захотите прочитать это сообщение в блоге от Windows Azure Storage Team: 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/2012/11/04/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx. В документации говорится, что:

Single Table Partition- раздел таблицы являются все объекты в таблице с тем же значением ключа раздела, и, как правило таблицы имеют много разделов. Целевая пропускная способность для одного раздела таблицы является:

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

Теперь вы упомянули, что у Вас есть 10 - 20 различных метрических точек и для каждой метрической точки вы напишете максимум 1 записей в минуту, что означает, что вы будете писать максимум 20 субъектов/минута/таблица, которая находится под целью масштабирования 2000 единиц в секунду.

Теперь вопрос остается от чтения. Предполагая, что пользователь будет считывать данные за 24 часа (т. Е. 24 * 60 = 1440 пунктов) для каждого раздела. Теперь, предполагая, что пользователь получает данные для всех 20 показателей за 1 день, каждый пользователь (таким образом, каждая таблица) будет извлекать максимум 28 800 точек данных. Вопрос, который остается для вас, я думаю, сколько запросов, как это, вы можете получить в секунду, чтобы соответствовать этому порогу. Если бы вы могли каким-то образом экстраполировать эту информацию, я думаю, вы можете прийти к выводу о масштабируемости вашей архитектуры.

Я бы также порекомендую посмотреть это видео: http://channel9.msdn.com/Events/Build/2012/4-004.

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