Табличка с таблицей хранения данных Azure для хранения фильтров

Question

Обработка изображений в виде блога, построенная с использованием таблицы хранения Azure. Пользователь отправляет сообщение, а база данных записывает регион, город и язык пользователя вместе с ним.

После этого пользователь может просматривать все сообщения других пользователей и фильтровать их с помощью любой комбинации Region, City и Language. Или ни того, ни другого.

Я вижу несколько решений:

1. Поместите каждое сообщение в 8 различных разделах с комбинациями Регион-Сити-Language (плюсы: грозовых запросами быстрыми на чтении; минусы: 8 сделок за сообщение о записи).
2. Поместите каждое сообщение в 4 разных разделах с комбинациями Region-City и возможность выполнять сканирование разделов для фильтрации по языкам (профи: меньше транзакций, чем (1); минус: разбиение на разделы, 4 транзакции на сообщение).
3. Поместите каждое сообщение в разделы на основе идентификатора пользователя (профи: одна транзакция на сообщение, минусы: медленное сканирование таблицы и сканирование разделов после этого).

Путь я вижу это:

1. Быстро читает, медленно (и, возможно, дорогостоящим) пишет.
2. Сбалансированное считывание/запись/стоимость.
3. Быстрая запись, медленная (но дешевая).

«Стоимость/дешево» означает цену, основанную на транзакциях (а не на пробелах). И «сбалансированным» я имею в виду только среди этих вариантов.

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

Answer 1

Я решил пойти с вариацией (1).

Разница в том, что я не буду хранить ВСЕ комбинации для Region-Location-Language. Вместо этого я решил хранить только уников:

Table: FiltersByRegion 
---------------------- 
Partition: Region 
Row:  Location.Language 
Prop:  Message 

---

Table: FiltersByRegionPlace 
--------------------------- 
Partition: Region.Location 
Row:  Language 
Prop:  Message 

---

Table: FiltersByRegionLanguage 
------------------------------ 
Partition: Region.Language 
Row:  Location 
Prop:  Message 

---

Table: FiltersByLanguage 
------------------------ 
Partition: Language 
Row:  Region.Location 
Prop:  Message 

---

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

Другими словами, если есть много сообщений с того же языка местоположения региона, таблицы фильтров не обновляются и транзакции не будут потрачены. Тесты для uniques могут использовать Redis для ускорения действий.

Фильтровать сейчас только вопрос выбора правильного стола.

Answer 2

Это зависит от ваших сценариев и схемы чтения/записи. Возможно, вы захотите рассмотреть некоторые аспекты:

1. Дизайн, по которому будут запрашиваться записи. Включение их в раздел «Регион-город-язык» с идентификатором сообщения как данными сущности может помочь в вашем быстром запросе.

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

3. Используйте ParitionKey и RowKey в своем дизайне таблиц и запросите объекты с помощью обоих ключей. Например: «Region-City-Language» в качестве разделов и «Пользователь» в качестве ключей строк.

4. Рассмотрите возможность хранения дубликатов копий сущностей для сценариев запросов. Например, если у вас есть тяжелые запросы на основе пользователей и на языке, вы можете рассмотреть наличие двух таблиц с «пользователем» и «языком» в качестве ключей соответственно.

Обратитесь к https://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/ за полным руководством.