Лазурное хранение стола - индексы?

У меня есть таблица сущностей, например, «рассказы». Он будет содержать большой список «историй», на которые могут голосовать люди.Лазурное хранение стола - индексы?

Главной особенностью моего приложения будут пользователи, читающие «лучшие» истории, в которых больше всего голосов (и, возможно, в конечном итоге будут реализованы другие алгоритмы).

Моя первая мысль о структуре таблицы Azure является:

RowKey = уникальный идентификатор
PartitionKey = ??? (Возможно, Id пользователя, потому что вы можете просмотреть список Пользователя историй)
Название
Описание
Идентификатор пользователя
Url

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

Это мое первое зависание с использованием Azure Table Storage, остальное приложение будет работать отлично. Я бы не хотел обновляться до использования полного SQL Azure из-за этой проблемы.

PS - Я открыт для хранения «топ-историй» в другом месте, кроме таблицы Azure, если это имеет смысл. Мой сервер будет работать с C# web api, но, вероятно, не имеет значения.

источник

2014-02-21 jonathanpeppers

Настольное хранилище Azure - это плоский, нереляционный хранилище данных. Таким образом, способ хранения и моделирования данных существенно отличается. Общим примером является моделирование двух разных хранилищ данных для разных типов доступа. Итак, один стол для самого последнего, а другой - обновление для «наиболее понравилось».

источник

2014-02-21 16:20:49 BrentDaCodeMonkey

Да, я думаю, что есть два стола - путь. Поскольку люди голосуют за историю, я могу проверить количество голосов, чтобы скопировать запись на «верхнюю» таблицу историй. Если у меня есть таблица commments, к ней можно получить доступ с помощью идентификатора storie, и я думаю, что это будет нормально работать, если в таблице «top» stories есть копия записей. – jonathanpeppers

Лучше использовать два раздела или две таблицы? Мысли? – jonathanpeppers

Не имеет большого значения, так как раздел является шкалой, а хранилище таблиц Azure меньше. Больший вопрос, о котором вам нужно подумать, - это то, как управлять «голосованием». Если у вас есть тысячи людей, попавших в статью, таблица голосования может быть узкой. Возможно, посмотрите: http://channel9.msdn.com/Shows/Cloud+Cover/Cloud-Cover-Episode-43-Scalable-Counters-with-Windows-Azure – BrentDaCodeMonkey

Вы должны сначала отразить то, что на самом деле означает «высшие истории». Вы имеете в виду последние 10 самых популярных статей или, скорее, выше значения specyfic rate?

Вы можете использовать значение скорости в качестве ключа раздела (например, Rate_1, Rate_2, Rate_3, Rate_4, Rate_5). Но вам нужно округлить значения до целых чисел, поэтому, если значение равно 4.1, оно будет помещено в раздел Rate_4.

В качестве альтернативы вы можете использовать только 2 раздела: «TopStories» и «OtherStories».

источник

2014-02-21 16:15:01 johnnyno

Итак, какой механизм переместит историю из «верхнего» раздела истории в другой раздел? Мне нужно будет удалить запись и вставить новую? Это произойдет, когда люди проголосуют за историю вверх или вниз. – jonathanpeppers

Лучше ли использовать два раздела или две таблицы? Мысли? – jonathanpeppers

Да, вам нужно заменить объект. Какие шаблоны доступа к данным вы ожидаете? Если много обновлений, то обновление ключа раздела может оказаться не лучшим решением. Вы также можете обеспечить кеширование верхних историй, чтобы улучшить преформацию чтения. – johnnyno

Учитывая, что

ваш лучший алгоритм история может развиваться сверхурочное время
тот факт, что резюме как информация
и может устареть

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

источник

2014-02-21 17:34:00 hocho

Есть проблемы с масштабами при выполнении этого в РСУБД. 1) не влияет на подход к хранению 2) может быть адресован в таблице Azure, а также 3) также можно адресовать в таблице Azure – BrentDaCodeMonkey

. Моя рекомендация по использованию SQL Db предназначена только для отслеживания «топ-историй», а не для самих историй. Алгоритму верхнего этажа может потребоваться только отслеживание историй за последние 24 часа и, следовательно, не нужно работать в больших масштабах. SQL Db определенно поддерживает более универсальные сценарии запросов и будет моим «лучшим» выбором. – hocho

Ну, SQL DB - это то, как мы все обучаемся, но цена в 100 раз больше. – Sentinel

Azure Storage Table Design Guide предлагает вам различные подходы для создания ваших собственных вторичных указателей.Он также предоставляет принципы для рассмотрения при разработке баз данных NoSQL и руководств по внедрению.

источник

2016-10-04 01:17:57

Это хорошая информация, другие, возможно, захотят узнать @Jason является автором. Я не думаю, что ему нужен был -1, хотя, +1. – jonathanpeppers

Лазурное хранение стола - индексы?

ответ

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