Je crois que littéralement toutes les principales bases de données NoSQL prendront en charge cette exigence, surtout si vous n'avez pas réellement un grand volume de données (ce qui soulève la question, pourquoi NoSQL ?).
Cela dit, j'ai récemment dû concevoir et travailler avec une base de données NoSQL pour les données de séries chronologiques afin de pouvoir donner des informations sur cette conception, qui peuvent ensuite être extrapolées pour toutes les autres.
Notre base de données choisie était Cassandra , et notre conception était la suivante :
- Un espace clé unique pour tous les 'symboles'
- Chaque symbole était une nouvelle ligne
- Chaque fois que l'entrée était une nouvelle colonne pour cette ligne pertinente
- Chaque valeur (peut être plus d'une seule valeur) était la partie valeur de l'entrée de temps
Cela vous permet de réaliser tout ce que vous avez demandé, notamment de lire les données d'un seul symbole et d'utiliser une plage si nécessaire (appels de plage de colonnes). Bien que vous ayez dit que les performances n'étaient pas critiques, elles l'étaient pour nous et elles étaient également assez performantes - toutes les données d'un seul symbole sont par définition triées (tri par nom de colonne) et toujours stockées sur le même nœud (pas de communication entre les nœuds pour les requêtes simples ). Enfin, cette conception se traduit bien dans d'autres bases de données NoSQL qui ont des colonnes dynamiques.
En plus de cela, voici quelques informations sur l'utilisation de MongoDB (et les collections plafonnées si nécessaire) pour un magasin de séries chronologiques :MongoDB en tant que base de données de séries chronologiques
Enfin, voici une discussion sur SQL vs NoSQL pour les séries temporelles :https ://dba.stackexchange.com/questions/7634/timeseries-sql-or-nosql
Je peux ajouter à cette discussion ce qui suit :
- La courbe d'apprentissage pour NoSQL sera plus élevée, vous ne bénéficiez pas gratuitement de la flexibilité et des fonctionnalités supplémentaires en termes de "coûts accessoires". Qui prendra en charge cette base de données sur le plan opérationnel ?
- Si vous vous attendez à ce que cette fonctionnalité se développe à l'avenir (soit avec plus de champs à ajouter à chaque entrée de temps, soit avec une capacité beaucoup plus grande en termes de nombre de symboles ou de taille de la série temporelle du symbole), alors optez définitivement pour NoSQL. L'avantage de la flexibilité est énorme, et l'évolutivité que vous obtenez (avec la conception ci-dessus) à la fois sur la base "par symbole" et sur la base du "nombre de symboles" est presque illimitée (je dis presque illimitée - le nombre maximum de colonnes par ligne se chiffre en milliards, maximum lignes par espace clé est illimité je crois).
