Azureストレージテーブルはフィルタリングアドバイスを記録します

Question

Azure Storage Tableを使用して構築されたブログ投稿システムのようなイメージング。 ユーザーがメッセージを投稿し、データベースにユーザーの地域、市および言語が記録されます。

その後、ユーザーは他のユーザーのすべての投稿をブラウズし、地域、市区町村、言語の任意の組み合わせでフィルタリングすることができます。またはどちらも見ず、それらのすべてを見る。

私はいくつかのソリューションを参照してください。

1. 地域・都市言語（：読み取りの超高速のポイントクエリ;短所：長所書き込みのメッセージあたり8回の取引）の組み合わせで8つの異なるパーティションにそれぞれのメッセージを入れてください。
2. リージョンシティーとパーティションスキャンを実行して言語でフィルタリングする機能（プロ：1トランザクション未満のトランザクション）、コンプリケーション：パーティションスキャン、メッセージごとに4トランザクションの4つの異なるパーティションに各メッセージを配置します。
3. ユーザーのIDに基づいて各メッセージをパーティションに入れます（プロンプト：メッセージごとに1つのトランザクション、短所のテーブルスキャンとそれ以降のパーティションスキャン）。

私はそれを参照してください方法：

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 

---

を1ポストごとにたくさんのトランザクションが発生します。データベースにまだ存在していないもののみ。

つまり、同じregion-location-languageからの投稿が多い場合、フィルタテーブルは更新されず、トランザクションは使用されません。ユニークなテストでは、レディスを使用して少し速度を上げることができます。

フィルタリングは、適切なテーブルを選択するだけです。

Answer 2

シナリオや読み書きパターンによって異なります。

1. レコードの照会方法を設計します。エンティティデータとしてメッセージIDを持つ「Region-City-Language」パーティションにそれらを配置すると、高速クエリーに役立ちます。

2. 各メッセージに固有のメッセージIDとIDがある可能性があります。メッセージマッピングは他のテーブルに保存され、メッセージが更新され、他のテーブルで参照されるメッセージIDは変更されません。

3. ParityKeyとRowKeyを両方のキーを使用してテーブル設計とクエリエンティティで活用します。たとえば、パーティションキーとして「Region-City-Language」、行キーとして「User」があります。

4. クエリシナリオのエンティティの複製コピーを保存することを検討してください。たとえば、ユーザーベースの言語ベースのクエリと言語ベースのクエリを使用している場合、「ユーザー」と「言語」をキーとしてそれぞれ2つのテーブルがあると考えることがあります。

詳しくはhttps://azure.microsoft.com/en-us/documentation/articles/storage-table-design-guide/を参照してください。