Подтвердить что ты не робот

Пейджинг таблицы хранения Azure

Чтобы реализовать простую подкачку в Azure Storage в относительно прямом направлении: Пейджинг с Windows Azure Table Storage. Это может быть реализовано с использованием функции токена продолжения.

Но.

Это только начало серьезного пейджинга. Первая проблема - сортировка. Вы не можете делать OrderBy в таблице Azure. Что было бы лучшим решением для преодоления этого? Страницы должны быть отсортированы, что факт.

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

Третья проблема связана со вторым, даже вы можете подсчитать, сколько страниц у вас есть, как "подключить" подсчитанные страницы к действительным токенам продолжения? Это самая большая загадка для меня. Как получить продолжение из конкретной строки таблицы?

Я был бы очень доволен, если бы можно было предоставить правильное решение. Я должен признать, что у меня тоже есть один, и я напишу его в одном из ответов ниже.

4b9b3361

ОТВЕТЫ

Ответ 1

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

Я бы получил данные в локальном кеше, выполнил порядок и пейджинг там и сделаю с ним. Существует рекомендуемое решение для этого ограничения при тщательном построении rowkey/partitionkey, но я бы настоятельно предложил вам не следовать этому.

Blog blog=  new Blog();
// Note the fixed length of 19 being used since the max tick value is 19 digits long.
string rowKeyToUse = string.Format("{0:D19}", 
        DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks);
blog.RowKey = rowKeyToUse;

Итак, блог b1 от 10/1/2008 10:00:00 AM будет иметь 2521794455999999999 как RowKey, а b2 от 10/2/2008 10:00:00 AM будет иметь 25217935919999999999 как RowKey, и, следовательно, b2 будет preceede b1.

Чтобы получить все блоги от 10/1/2008 10:00:00 AM, мы будем использовать следующий запрос:

     string rowKeyToUse = string.Format("{0:D19}", 
        DateTime.MaxValue.Ticks - DateTime.UtcNow.Ticks);
var blogs = 
    from blog in context.CreateQuery<Blog>("Blogs")
    where blog.PartitionKey == "Football" 
        && blog.RowKey.CompareTo(rowKeyToUse) > 0
  select blog;

(это было взято из документации Windows Azure, декабрь 2008 г. предоставлено Microsoft)

Что касается подсчета количества страниц, это легко, просто операция разделения будет делать трюк здесь; как и для токенов продолжения, одним из способов было бы (по первому запросу) "пройти" на каждой странице и получить токен продолжения, который в основном просто сообщает вам, какие строки и разделы разделяются дальше. Но все они означают, что вы уязвимы для ошибок согласованности (например, если кто-то что-то помещает в одно хранилище таблиц).

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

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

На стороне примечания, я считаю, что пейджинг предоставлен, чтобы не разрешить пейджинг на интерфейсе, а чтобы обойти предел результата 1000. Но это всего лишь мои 0,02 доллара.