Credo che letteralmente tutti i principali database NoSQL supporteranno questo requisito, soprattutto se in realtà non si dispone di un grande volume di dati (il che pone la domanda, perché NoSQL?).
Detto questo, di recente ho dovuto progettare e lavorare con un database NoSQL per i dati delle serie temporali in modo da poter fornire un input su quel progetto, che può quindi essere estrapolato per tutti gli altri.
Il nostro database scelto era Cassandra e il nostro design era il seguente:
- Un unico spazio chiave per tutti i 'simboli'
- Ogni simbolo era una nuova riga
- Ogni volta che c'era una nuova colonna per quella riga pertinente
- Ogni valore (può essere più di un singolo valore) era la parte del valore dell'immissione di tempo
Ciò ti consente di ottenere tutto ciò che hai richiesto, in particolare leggere i dati per un singolo simbolo e utilizzare un intervallo se necessario (chiamate di intervallo di colonne). Anche se hai detto che le prestazioni non erano critiche, lo era per noi e anche questo è stato abbastanza performante:tutti i dati per ogni singolo simbolo sono ordinati per definizione (ordinamento del nome della colonna) e sempre archiviati sullo stesso nodo (nessuna comunicazione tra nodi per query semplici ). Infine, questo design si traduce bene in altri database NoSQL che hanno colonne dinamiche.
Inoltre, ecco alcune informazioni sull'utilizzo di MongoDB (e raccolte limitate se necessario) per un negozio di serie temporali:MongoDB come database di serie temporali
Infine, ecco una discussione su SQL vs NoSQL per le serie temporali:https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
Posso aggiungere a quella discussione quanto segue:
- La curva di apprendimento per NoSQL sarà più alta, non avrai la flessibilità e la funzionalità aggiuntive gratuitamente in termini di "costi ridotti". Chi supporterà operativamente questo database?
- Se ti aspetti che questa funzionalità cresca in futuro (sia come più campi da aggiungere a ogni immissione di tempo, sia come capacità molto maggiore in termini di numero di simboli o dimensione delle serie temporali dei simboli), allora scegli sicuramente NoSQL. Il vantaggio in termini di flessibilità è enorme e la scalabilità che ottieni (con il design sopra) sia sulla base "per simbolo" che "numero di simboli" è quasi illimitata (dico quasi illimitata:il numero massimo di colonne per riga è di miliardi, massimo righe per spazio chiave è illimitato, credo).
