Memorizzazione di dati di indice archiviati

Question

Memorizzazione di dati di indice archiviati

#1 da (1 voti)
#2 da (1 voti)

2

Usiamo RavenDB come nostro archivio dati per le informazioni transazionali e funziona bene per i dati che sono attualmente "in uso".

Raccogliamo anche eventi di controllo mentre le persone usano la nostra applicazione, in cui ogni evento ha un aspetto simile a:

Tipo, data, riepilogo, ecc. - piuttosto standard
ID documento correlato (potrebbe essere uno, potrebbe essere 5)

Come archivio di documenti, Raven fa un ottimo lavoro di indicizzazione di questi in modo che possiamo porre domande come "trova tutti gli eventi relativi al documento XYZ".

Sfortunatamente man mano che i dati si accumulano nel tempo, questi eventi di controllo possono rappresentare il 90% dei dati memorizzati nel nostro database ed è usato raramente. Vorremmo ottenere questi dati da Raven e in una sorta di storage che potrebbe essere più adatto.

Quali altre soluzioni di archiviazione esistono per la memorizzazione di centinaia di migliaia di eventi di tipo audit? Siamo felici di sacrificare la velocità per risparmiare costi di archiviazione e indicizzazione.

storage

posta Paul Stovell 07.07.2014 - 02:43

fonte

2 risposte

Leggi altre domande sui tag storage

Architettura dell'API su larga scala (Gestione utenti) Componenti hot swap / plug in clojure?

score 1 · Answer 1

SQLite + JSON.NET

L'uso di SQLite fornisce una memoria indicizzata veloce, robusta, mentre JSON.NET mantiene la compatibilità tra i tipi di modello nell'archivio e in Raven. Deserializza da Raven, ri-serializza, archivia in SQLite.

Puoi utilizzare colonne e indici SQLite per accelerare l'accesso selezionando prima di analizzare JSON.

Henrik (Andersson) ha sottolineato che esiste un wrapper .NET per SQLite utilizzato in Akavache: link

SQLite sicuramente non sembra eccessivamente limitato per questo: link

score 1 · Answer 2

Ero abituato a lavorare in un progetto che ha capacità di controllo per tutte le tabelle SQL. Tuttavia, i dati di audit sono molto più piccoli dei dati effettivi perché i dati principali sono raramente modificati.

Per il tuo caso particolare e il suo utilizzo, ho visto persone fare una cosa che potrebbe essere appropriata alla tua situazione. Quello che hanno fatto è che hanno spostato parte dei dati archiviati (dati di controllo in questo caso) in un nuovo DB o in un file flat. Il sistema di controllo supporta solo il controllo dei dati recenti.

Per i dati di audit archiviati, è possibile configurarli in un nuovo DB che ha il vantaggio della facilità d'uso OPPURE è possibile impostare la propria funzione di memorizzazione differita dei dati e archiviarli in file flat con accesso indicizzato.