Design della tabella di archiviazione di Azure con più punti di interrogazione

Question

Design della tabella di archiviazione di Azure con più punti di interrogazione

#1 da (1 voti)

1

Ho la seguente tabella di archiviazione di Azure.

Tabella PositionData:

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

Ogni veicolo registrerà fino a 1.000.000 di entità all'anno per cliente. Ogni cliente potrebbe avere migliaia di veicoli. Quindi, ho deciso di partizionare per ClientID + VehicleID in modo da avere partizioni piccole e gestibili. Quando esegui una query in base a ClientID e VehicleID , l'operazione viene eseguita rapidamente perché stiamo restringendo la ricerca a una partizione.

PROBLEMA:

Il problema qui è che a volte ho bisogno di interrogare solo su ClientID e DriverID . Poiché non è possibile eseguire confronti parziali PartitionKey, ogni singola partizione dovrà essere sottoposta a scansione. Questo ucciderà le prestazioni.

Non posso avere un PartitionKey con tutto ClientID , VehicleID e DriverID perché le query interrogheranno solo su VehicleID OR DriverID , mai entrambe.

SOLUZIONE 1:

Ho considerato di avere un valore memorizzato altrove che rappresentava una coppia VehicleID e DriverID, e quindi avere una PartitionKey ClientID + VehicleDriverPairID , ma che risulterebbe in centinaia di migliaia di partizioni e ci sarà molta unione di dati tra le partizioni nel mio codice .

SOLUZIONE 2:

Avere una partizione per Client + VehicleID e un'altra partizione per Client + DriverID . Ciò significa che l'aggiornamento della tabella è il doppio del lavoro (due aggiornamenti) ma entrambe le query saranno veloci. Inoltre ci saranno dati ridondanti.

Qualcuna di queste soluzioni è valida? Altre soluzioni?

design nosql database-design azure

posta davenewza 28.02.2013 - 12:11

fonte

1 risposta

Leggi altre domande sui tag design nosql database-design azure

Programming Wavelet Wavelet Transform Come memorizzare intervalli temporali occorrenti settimanalmente in oggetti Java

score 1 · Accepted Answer

Penso che tu abbia diverse soluzioni di programmazione fattibili che potrebbero funzionare: le tue soluzioni originali e quelle che erano pubblicato su SO . Come dici tu, il problema diventa decidere quale design è ottimale per il tuo caso - e anche quello che sarà facilmente compreso da altri programmatori che modificano il tuo codice in futuro.

Non hai veramente detto se i veicoli sono di proprietà e gestiti dai clienti o dai conducenti. Mi aspetto che sarebbe raro che i clienti che possiedono e gestiscano i loro veicoli commercializzino veicoli in un anno. Se i veicoli sono di proprietà e gestiti esclusivamente dai conducenti, mi aspetto che guiderebbero il veicolo per la maggior parte del tempo.

Quando ho letto la tua domanda ho pensato di partizionare il tavolo con VehicleID + DriverID se i veicoli sono di proprietà e gestiti esclusivamente dai clienti. E se i veicoli sono di proprietà e gestiti esclusivamente dai driver, una partizione di ClientID + DriverID sarebbe più efficiente.

Questo approccio sarebbe rapido, ma diventerebbe meno accurato o meno efficiente in quanto i proprietari di autisti o proprietari di client si scambiavano veicoli.