La réponse dépend en grande partie de ce que vous voulez en faire après la collecte. Stocker de nombreuses données est facile : il suffit de les stocker dans des fichiers journaux, sans avoir besoin d'une base de données. En revanche, si vous souhaitez effectuer une analyse complexe et une exploration des données, une base de données est utile.
La question suivante est de savoir quel type d'analyse vous allez faire. Sera-t-elle effectuée sur un sous-ensemble de données ayant une propriété particulière, la dernière heure/le dernier jour/la dernière semaine/le dernier mois uniquement, les données peuvent-elles être agrégées ou pré-calculées d'une manière ou d'une autre ? En d'autres termes : avez-vous besoin d'accéder à l'ensemble des données sous la forme où elles sont collectées ? Pouvez-vous archiver les données lorsqu'elles deviennent trop anciennes pour être intéressantes ? Pouvez-vous agréger les données et effectuer l'analyse sur l'agrégation ?
D'après mon expérience dans le domaine de l'analyse de la publicité (collecte de milliards de points de données sur l'exposition aux publicités), l'agrégation est essentielle. Vous collectez des données brutes, vous les nettoyez et vous les placez dans une base de données comme MongoDB, Cassandra ou même MySQL qui vous permet de faire des mises à jour et des requêtes. Ensuite, vous regroupez périodiquement les données et les supprimez de la base de données (mais vous archivez les données brutes, car vous pourriez en avoir besoin plus tard).
L'agrégation pose essentiellement toutes les questions que vous voulez poser sur les données, et les enregistre sous une forme qui permet de récupérer facilement la réponse à une question particulière. Disons que vous voulez savoir quel jour de la semaine a le plus de X. L'implémentation naïve de ceci serait de garder tous les signaux enregistrés dans une énorme table et de faire une requête qui additionne toutes les lignes qui ont X. Comme le nombre de signaux collectés augmente, cette requête prendra de plus en plus de temps. Aucune indexation, aucun sharding ou aucune optimisation n'y changera quoi que ce soit. Au lieu de cela, tous les jours/heures/minutes (en fonction du cas d'utilisation exact et de la mise à jour nécessaire de vos rapports), vous regardez les nouveaux signaux que vous avez enregistrés, et pour chaque X, vous incrémentez le compteur qui garde la trace de combien de X il y a eu le lundi, si c'est un lundi, le mardi si c'est un mardi et ainsi de suite. De cette façon, vous pourrez plus tard récupérer le nombre de X pour chaque jour de la semaine et les comparer. Vous faites cela pour toutes les questions auxquelles vous voulez pouvoir répondre, puis vous supprimez les signaux de la base de données (mais, là encore, vous conservez les données brutes).
Le type de base de données dans lequel vous enregistrez les agrégats peut être le même que celui dans lequel vous stockez les signaux entrants, mais il n'a pas besoin d'être très sophistiqué. Elle stockera les clés qui représentent une réponse particulière, et les valeurs qui sont généralement de simples chiffres.
Dans le langage de l'entreposage de données de la vieille école, la base de données dans laquelle vous stockez les signaux entrants est appelée OLTP (pour on-line transactional processing) et la base de données dans laquelle vous stockez les agrégats est appelée OLAP (pour on-line analytical processing). OLTP est optimisé pour l'insertion et OLAP est optimisé pour l'interrogation. Ces termes sont anciens et lorsque les gens les entendent, ils ont tendance à penser immédiatement à SQL, aux schémas en étoile et à tout le reste. Je ne devrais peut-être pas les utiliser, mais ce sont des termes pratiques.
Quoi qu'il en soit, pour l'OLTP, vous voulez quelque chose qui soit rapide pour insérer des données, mais aussi quelque chose qui prenne en charge l'indexation des données et la recherche d'éléments. L'agrégation est grandement facilitée par une base de données qui fait la moitié du travail de sommation et de recherche des maximums et minimums. J'aime beaucoup MongoDB parce qu'il est très facile à configurer et à utiliser. Les données avec lesquelles je travaille ont tendance à être désordonnées et tous les éléments n'ont pas le même ensemble de propriétés, donc l'absence de schéma de Mongo est une bénédiction. D'un autre côté, vos données semblent beaucoup plus uniformes, donc Mongo ne vous apporterait peut-être pas autant d'avantages. Ne négligez pas pour autant les bonnes vieilles bases de données relationnelles. Si vous avez l'intention de faire beaucoup d'additions, etc., alors SQL est parfait, c'est pour cela qu'il a été conçu.
Pour OLAP, quelque chose de beaucoup plus simple fonctionne, un magasin clé-valeur est tout ce dont vous avez besoin. J'utilise Redis parce qu'il est également très facile à utiliser et à configurer. Il vous permet également de stocker plus que des valeurs scalaires, ce qui est pratique. Parfois, votre valeur est en fait une liste ou un hachage. Dans la plupart des magasins de valeurs clés, vous devez coder ces valeurs, mais Redis les gère de manière native. L'inconvénient de Redis est que vous ne pouvez pas faire de requêtes ("comme dans donnez-moi toutes les lignes qui ont cette valeur pour Y"), vous devez garder les indices de vos données vous-même. D'un autre côté, vous n'aurez pas beaucoup besoin d'index puisque les réponses à toutes vos questions ont été précalculées, tout ce que vous devez faire est de chercher la réponse par une clé qui est définie par la question. Pour la question ci-dessus, quel jour de la semaine a le plus de X, vous recherchez le nombre de travaux X lundi, mardi, etc. Vous les avez peut-être stockés sous X:lundi, X:mardi, etc.
En conclusion : MongoDB et Redis fonctionnent très bien pour moi. Je ne pense pas que MongoDB soit très bien adapté à votre cas d'utilisation, je pense plutôt que vous pourriez bénéficier davantage d'une base de données SQL traditionnelle (mais cela dépend, si vos données sont vraiment simples, vous pourriez peut-être utiliser Redis à fond). La chose la plus importante est de ne pas faire l'erreur de penser que vous devez avoir les données dans une base de données et les conserver pour toujours. L'agrégation et la suppression des anciennes données sont essentielles.
