Хранилище таблиц Azure - выбор между PartitionKey и RowKey для использования между запросами - PullRequest
Новая
       5

Хранилище таблиц Azure - выбор между PartitionKey и RowKey для использования между запросами

6 голосов
/ 03 мая 2011

Я новичок в Azure!Цель состоит в том, чтобы вернуть строки на основе временной метки, хранящейся в RowKey.Поскольку с каждым запросом связаны транзакционные издержки, я хочу минимизировать количество транзакций / запросов, сохраняя при этом производительность

. Предлагаемые ключи разделов и строк:

  • Ключ раздела: TextCache_ (AccountID) _ (ParentMessageId)
  • Ключ строки: (DateOfMessage) _ (MessageId)

Легенда :

  • AccountId - целое число
  • ParentMessageId - родительский идентификатор сообщения, если он есть, пустой, если он является родителем
  • DateOfMessage - дата сообщениябыл создан - формат будет DateTime.Ticks.ToString ("d19")
  • MessageId - уникальный идентификатор сообщения

Я хотел бы получить из одного запросастроки и любые дочерние элементы, которые> или

Можно ли это сделать с помощью предложенных мной PartitionKeys и RowKeys?

т.е. .. (в коде псевдо) 

var results = ctx.PartitionKey.StartsWith(TextCache_AccountId) 
   && ctx.RowKey > (TimeStamp)_MessageId

Во-вторых, если у меня есть несколько учетных записей, и я хочу только вернуть бПодтвердите первые 10, можно ли это сделать одним запросом

, т. е. (в коде псевдо) 

var results = ( 
      ( 
        ctx.PartitionKey.StartsWith(TextCache_(AccountId1)) && 
            && ctx.RowKey > (TimeStamp1)_MessageId1 )
      )
      ||
      ( 
        ctx.PartitionKey.StartsWith(TextCache_(AccountId2)) && 
            && ctx.RowKey > (TimeStamp2)_MessageId2 )
      ) ... 
          )
         .Take(10)

1 Ответ

5 голосов
/ 03 мая 2011

Короткий ответ на ваши вопросы - да, но есть некоторые вещи, за которыми вам нужно следить.

Хранилище таблиц Azure не имеет прямого эквивалента .StartsWith(). Если вы используете библиотеку хранилища в сочетании с LINQ, вы можете использовать .CompareTo() (> и <не переводить должным образом), что будет означать, что если вы запустите поиск по учетной записи 1 и попросите запрос вернуть 1000 результатов, но есть только 600 результатов для учетной записи 1, последние 400 результатов будут для учетной записи 10 (следующий номер счета лексически). Так что вам нужно быть немного умным в том, как вы справляетесь со своими результатами. </p>

Если вы добавите идентификатор учетной записи с начальными 0, вы можете сделать что-то вроде этого (псевдокод здесь также) 

ctx.PartionKey > "TextCache_0000000001"
&& ctx.PartitionKey < "TextCache_0000000002"
&& ctx.RowKey > "123465798"

Следует также учитывать, что запросы к таблицам Azure возвращают свои результаты в порядке PartitionKey, а затем RowKey. Таким образом, в вашем случае сообщения без ParentMessageId будут возвращены до сообщений с ParentMessageId. Если вы никогда не собираетесь запрашивать эту таблицу с помощью ParentMessageId, я бы переместил ее в свойство.

Если TextCache_ является просто строковой константой, она ничего не добавляет, будучи включенной в PartitionKey, если только это на самом деле не будет означать что-то для вашего кода при его возврате.

Пока ваш второй запрос будет выполняться, я не думаю, что он даст то, что вам нужно. Если вы хотите, чтобы первые десять строк были в порядке DateOfMessage, это не сработало (см. Мой пункт выше о порядке сортировки). Если вы выполнили этот запрос как есть, а в учетной записи 1 было 11 сообщений, он вернет только первые 10 сообщений, связанных с учетной записью 1, независимо от того, было ли в учетной записи 2 более раннее сообщение.

Хотя попытка свести к минимуму количество транзакций, которые вы используете, является хорошей практикой, не слишком переживайте по этому поводу. Стоимость выполнения ваших рабочих / веб-ролей приведет к снижению ваших операционных затрат. 1 000 000 транзакций обойдутся вам в 1 доллар США, что меньше стоимости одного небольшого экземпляра в течение 9 часов.

...