Acredito que literalmente todos os principais bancos de dados NoSQL suportarão esse requisito, especialmente se você não tiver um grande volume de dados (o que levanta a questão, por que NoSQL?).
Dito isso, recentemente tive que projetar e trabalhar com um banco de dados NoSQL para dados de séries temporais para poder fornecer algumas informações sobre esse design, que podem ser extrapoladas para todos os outros.
Nosso banco de dados escolhido foi
Cassandra , e nosso projeto foi o seguinte:- Um único keyspace para todos os 'símbolos'
- Cada símbolo era uma nova linha
- Cada entrada de tempo era uma nova coluna para essa linha relevante
- Cada valor (pode ser mais de um valor único) era a parte do valor da entrada de tempo
Isso permite que você consiga tudo o que pediu, principalmente para ler os dados de um único símbolo e usar um intervalo, se necessário (chamadas de intervalo de coluna). Embora você tenha dito que o desempenho não era crítico, era para nós e isso também era bastante eficiente - todos os dados para qualquer símbolo único são classificados por definição (classificação do nome da coluna) e sempre armazenados no mesmo nó (sem comunicação entre nós para consultas simples ). Por fim, esse design se traduz bem em outros bancos de dados NoSQL que possuem colunas dinâmicas.
Além disso, aqui estão algumas informações sobre como usar o MongoDB (e coleções limitadas, se necessário) para um armazenamento de série temporal:MongoDB como um banco de dados de série temporal
Por fim, aqui está uma discussão sobre SQL vs NoSQL para séries temporais:https://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
Posso acrescentar a essa discussão o seguinte:
- A curva de aprendizado para NoSQL será maior, você não obtém a flexibilidade e a funcionalidade adicionais gratuitamente em termos de 'custos de software'. Quem dará suporte operacional a esse banco de dados?
- Se você espera que essa funcionalidade cresça no futuro (como mais campos a serem adicionados a cada entrada de tempo, ou uma capacidade muito maior em termos de número de símbolos ou tamanho da série temporal do símbolo), então definitivamente vá com o NoSQL. O benefício de flexibilidade é enorme, e a escalabilidade que você obtém (com o design acima) tanto na base 'por símbolo' quanto no 'número de símbolos' é quase ilimitada (eu digo quase ilimitada - o máximo de colunas por linha está na casa dos bilhões, máximo linhas por espaço de chave é ilimitada, acredito).
