Лазурное хранение стола: заказ от

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

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

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

источник

2012-03-27 s1mm0t

На сегодняшнем оборудовании, имеющем 1000 строк для хранения, в списке, в памяти и сортировке легко поддается поддержке. Какова реальная проблема, насколько возможно вам получить доступ к строкам в хранилище таблиц с помощью клавиш и не выполнять сканирование таблицы. Дублирование строк на нескольких таблицах может оказаться довольно громоздким для поддержания.

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

источник

2012-03-27 15:00:41 hocho

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

... ваше второе предложение интересно. Вы когда-нибудь делали что-нибудь подобное? Передача данных между разными хранилищами сама по себе будет похожа на то, что было бы медленным. – s1mm0t

Я этого не делал недавно. Учитывая, что это, вероятно, работает в отключенном мире и с учетом масштабируемости в нескольких экземплярах, загрузка набора результатов из хранилища таблиц в локальную память для каждого запроса может быть неэффективной. Вместо этого в SQL Azure можно было бы получить доступ к данным из нескольких экземпляров после одной загрузки. С другой стороны, если ваша реализация основана на одном экземпляре с ограниченным набором данных, загрузка в памяти может быть достаточной. Сначала я попробую опцию памяти, а затем перейду к параметрам SQL, если это не оправдывает ожиданий. – hocho

Почему бы не сделать все это в .net, используя список.

Для такого типа приложений я бы подумал, что SQL Azure было бы более подходящим.

источник

2012-03-27 14:20:22

В случае списка пожеланий может быть указан список/IEnumerable Соответственно, но у меня есть другие подобные экраны, где может быть 1000 результатов.Я не хочу, чтобы все это делалось в памяти. В этом случае я использую хранилище таблиц в пользу SQL Azure из-за выгодных затрат. – s1mm0t

Память для 1000 строк не так уж и много. Также, когда вы определяете экономическую выгоду, вам нужно подумать о своем времени. Если вы собираетесь экономить час или более в месяц от использования SQL Azure, гораздо эффективнее использовать SQL Azure. Если вы не имеете дело с данными BIG, и я имею в виду огромные, то затраты на использование табличного хранилища над SQL Azure не приравниваются. –

Я дал вам плюс +1. Это не всегда о стоимости или размере. Для приложения с несколькими арендаторами, где вы хотите, чтобы разделение данных, создающих таблицу хранения, было проще и быстрее, чем создание базы данных. – Paparazzi

-1

Что-то вроде этого работало нормально для меня:

List<TableEntityType> rawData = 
    (from c in ctx.CreateQuery<TableEntityType>("insysdata") 
    where ((c.PartitionKey == "PartitionKey") && (c.Field == fieldvalue)) 
    select c).AsTableServiceQuery().ToList(); 
List<TableEntityType> sortedData = rawData.OrderBy(c => c.DateTime).ToList();

источник

2012-09-27 13:17:47 ProfNimrod

Это будет сортировать строки в памяти – BritishDeveloper

Это игнорирует исходный вопрос, включая подкачку в области, а не только сортировку. –

Azure Storage сохраняет объекты в лексикографическом порядке, индексированные по Partition ключ в качестве первичного индекса и ключа строки в качестве вторичного индекса. В общем, для вашего сценария это звучит так, как UserId будет хорошо подходит для ключа раздела, поэтому у вас есть Row Key для оптимизации для каждого запроса.

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

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

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

Чтобы различать различные схемы строк, вы можете добавить каждое значение со строкой const. Как и ваше ключевое значение строки инвертированного тика, например woul dbe, например, «InvertedTicks_ [InvertedDateTimeTicksOfTheWishList]», и значение ключа строки имен элементов будет «ItemName_ [ItemNameOfTheWishList]»

источник

2017-03-24 12:05:43

Лазурное хранение стола: заказ от

ответ

Смежные вопросы