Archiviazione tabella e SQL di Azure

4

Sono nel bel mezzo di una decisione architettonica che sarà importante per il futuro.

Ho un sistema in cui utilizzo ATS (Azure Table Storage) come archivio per dati semplici e molto piccoli. Non è stato scritto troppo spesso e non viene letto troppo spesso.

Ora ho bisogno di leggere / scrivere dati basati su questi dati ATS. Un sacco di dati Ma non leggerò i dati in ATS prima di scrivere gli "altri" dati.

La mia preoccupazione è che non riesco a leggere i dati abbastanza velocemente da ATS, in base alle esigenze che ho. E.g Ho bisogno di contare le righe abbastanza velocemente per dare il feedback agli utenti, e il conteggio non è una funzione all'interno di ATS. Potrei ottenere qualcosa dal "pattern" CQRS ma avrei comunque bisogno di contare le righe! E non sto cercando una soluzione in cui ho bisogno di aggiungere complessità per superare una cosa molto semplice su un'altra piattaforma (SQL).

Quindi il mio pensiero è di salvare questi dati all'interno di un database SQL in cui ho anche tutte le funzionalità di manipolazione dei dati di cui ho bisogno. Ma mi piacerebbe perdere la scalabilità e finire per mantenere quello invece di un datastore scalabile facile come ATS. E i dati che sto scrivendo qui sono molto semplici, ma sono molti.

Vorrei restare solo con ATS ma avrei bisogno di un modello per aggirare questi limiti. Qualche idea?

Grazie!

    
posta frostings 04.05.2015 - 13:49
fonte

1 risposta

4

La coerenza è importante? Se pensi di salvare i dati in SQL, perché non andare con SQL fino in fondo?

Comunque ... le funzioni di aggregazione come count non sono una funzionalità di Table Storage, quindi è necessario recuperare tutte le righe e contare "client side" (può essere molto lento) oppure trovare un modo per memorizzare il "conteggio" "in un'altra entità. Dipende molto dai tuoi dati e dalla tua architettura, e talvolta non è possibile selezionare una buona strategia di PartitionKey.

Puoi anche guardare Lucene, Azure Search, Hadoop, che è ottimizzato per la lettura. Tuttavia, la coerenza è un problema.

Costruiamo un'architettura piuttosto grande utilizzando i negozi di tabelle come soluzione di lettura / scrittura / aggiornamento e, sinceramente, non lo consiglierò. Lo storage di tabelle è ottimo per scrivere una sola volta scenari e soluzioni in cui le prestazioni non rappresentano un problema. Ma costruire una struttura relazionale in cui la performance è importante è tufo. Se è necessario effettuare query in cui si ricevono più di 1000 righe, è necessario creare un progetto in cui è possibile eseguire query in parallelo. Dovresti quindi aspettarti almeno 1 secondo per le query, anche se esegui una query per chiave di partizione.

Lo spazio di archiviazione della tabella è davvero veloce solo se effettui la ricerca di una singola voce da PartitionKey e RowKey.

Ma sì, il Table Storage scala bene, anche sotto carico. Ma ha un prezzo.

    
risposta data 04.05.2015 - 14:29
fonte

Leggi altre domande sui tag