Jag tror att bokstavligen alla större NoSQL-databaser kommer att stödja det kravet, speciellt om du faktiskt inte har en stor mängd data (vilket väcker frågan, varför NoSQL?).
Som sagt, jag har nyligen varit tvungen att designa och arbeta med en NoSQL-databas för tidsseriedata så kan ge lite input om den designen, som sedan kan extrapoleras för alla andra.
Vår valda databas var Cassandra , och vår design var följande:
- En enda knappsats för alla "symboler"
- Varje symbol var en ny rad
- Varje inmatning var en ny kolumn för den relevanta raden
- Varje värde (kan vara mer än ett enstaka värde) var värdedelen av tidsinmatningen
Detta låter dig uppnå allt du bad om, framför allt att läsa data för en enskild symbol och använda ett intervall om det behövs (kolumnintervallanrop). Även om du sa att prestanda inte var avgörande, var det för oss och det var också ganska presterande - all data för en enskild symbol sorteras per definition (kolumnnamnssortering) och lagras alltid på samma nod (ingen korsnodskommunikation för enkla frågor ). Slutligen översätts denna design väl till andra NoSQL-databaser som har dynamiska kolumner.
Utöver detta, här är lite information om hur du använder MongoDB (och begränsade samlingar om det behövs) för en tidsseriebutik:MongoDB som en tidsseriedatabas
Slutligen, här är en diskussion om SQL vs NoSQL för tidsserier:https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
Jag kan lägga till följande till diskussionen:
- Inlärningskurvan för NoSQL blir högre, du får inte den extra flexibiliteten och funktionaliteten gratis när det gäller "mjuka kostnader". Vem kommer att stödja denna databas operativt?
- Om du förväntar dig att denna funktionalitet kommer att växa i framtiden (antingen som fler fält som ska läggas till varje tidsinmatning, eller mycket större kapacitet när det gäller antalet symboler eller storleken på symbolens tidsserie), ska du definitivt välja NoSQL. Flexibilitetsfördelen är enorm, och skalbarheten du får (med ovanstående design) på både "per symbol" och "antal symboler" är nästan obegränsad (jag säger nästan obegränsad - maximala kolumner per rad är i miljarder, maximalt rader per nyckelutrymme är obegränsat tror jag).