1

次のAzureストレージテーブルがあります。

PositionDataテーブル： 

PartitionKey: ClientID + VehicleID 
RowKey: GUID 
Properties:  ClientID, VehicleID, DriverID, Date, GPSPosition

各車両は、クライアントごとに年間最大1,000,000エンティティをログに記録します。各クライアントは数千台の車両を所有する可能性があります。そこで、小さくて管理しやすいパーティションにするために、 ClientID+でパーティション化することにしました。とでVehicleIDクエリを実行する場合、検索を1つのパーティションに絞り込んでいるため、操作は迅速に実行されます。ClientIDVehicleID

問題：

ここでの問題は、とだけClientIDでクエリを実行する必要がある場合があることDriverIDです。部分的なPartitionKey比較を実行することはできないため、すべてのパーティションをスキャンする必要があります。これにより、パフォーマンスが低下します。

すべてのPartitionKeyを使用することはできませんClientID。VehicleIDまたDriverID、クエリはVehicleIDORDriverIDでのみクエリを実行するため、両方でクエリを実行することはできません。

解決策1：

VehicleIDとDriverIDのペアを表す値を他の場所に格納し、次にClientID + VehicleDriverPairIDPartitionKeyを使用することを検討しましたが、その結果、数十万のパーティションが作成され、コード内のパーティション間でデータが大幅に結合されます。

解決策2：

のパーティションClient + VehicleIDとの別のパーティションがありClient + DriverIDます。つまり、テーブルの更新は2倍の作業（2回の更新）ですが、どちらのクエリも高速になります。また、冗長データがあります。

これらのソリューションのいずれかが実行可能に聞こえますか？他の解決策？

4

3 に答える 3

4

解決策 2 のように、レコードを複製する必要があります。各レコードが独自のパーティションにあるコピーを保持することをお勧めします。これにより、VehiculeId によってもパーティション化されます。これにより、vehicleid から始まり、その他。

データの保存は非常に安価です。事前に正しく保存しない限り、クエリはピタです。したがって、私のアドバイスは次のとおりです。

于 2013-02-28T12:31:46.517 に答える
1

部分的なPartitionKey比較を実行することはできないため、すべてのパーティションをスキャンする必要があります。

本当ではありません。たとえば、パーティションキーが（文字通り）ClientID$VehicleIDの場合、PartitionKey gt 'ClientID$' and PartitionKey lt 'ClientID%'（が機能するため(Char)($+1)に機能し%ます。これにより、ClientIDで始まるパーティションのみがスキャンされます。

于 2013-02-28T11:44:41.050 に答える
1

ここでは、RowKeyは無意味なGUIDであるように見えます。単に一意性を保つために、これを置き換え/拡張して、次のことを考え出すことができます。

すべての挿入は同じパーティションへの2エンティティの挿入であるため、両方が成功または両方が失敗するようにバッチ処理して、一貫性を確保できます。[]の音価はオプションです。

PartitionKey = ClientID  
RowKey = [Prefix] + VehicleID + [Suffix]

と 

PartitionKey = ClientID  
RowKey = [Prefix] + DriverID + [Suffix]

VehicleIDanが一意でない場合は、 DriverID「V」や「D」などのプレフィックスを追加して一意にすることができます。

RowKeyの一意性が必要な場合は、必要に応じて日付の接尾辞を付けるか、現在行われているGUIDを付けることができます。

于 2013-02-28T16:45:24.673 に答える