Comment stocker de grandes quantités de données _structurées_?
L'application collectera en continu (environ toutes les secondes) l'emplacement des utilisateurs et les stockera.
Ces données sont structurées. Dans une base de données relationnelle, il serait stocké sous la forme: | user | timestamp | latitude | longitude |
Cependant, il y a trop de données. Il y aura 60 × 60 × 24 = 86 400 enregistrements par utilisateur et par jour. Même avec 1 000 utilisateurs, cela signifie 86 400 000 enregistrements par jour.
Et ce ne sont pas seulement 86 400 000 enregistrements par jour. Parce que ces enregistrements seront traités et leurs versions traitées seront également stockées. Donc, multipliez ce nombre par environ 2.
Comment je prévois d'utiliser les données
Essentiellement, je prévois de créer des versions plus grossières des données de localisation pour une consommation plus facile. C'est:
- Triez les données reçues sans horodatage.
- Iteating sur cette liste dans l'ordre, déterminez si l'emplacement a changé de manière significative (en vérifiant à quel point la latitude et la longitude ont changé)
- Représentez les changements de localisation non significatifs comme une seule entrée dans la sortie (par conséquent, la sortie est une version plus grossière des données de localisation).
- Répétez ce processus sur la sortie, en exigeant un changement de latitude et de longitude encore plus important pour un changement significatif. Par conséquent, la sortie à produire à partir de la sortie précédente sera encore plus grossière.
- Répétez l'ensemble du processus autant que nécessaire.
- Agréger une gamme de résolutions et les envoyer aux utilisateurs. Stockez également toutes les résolutions des données pour une consommation ultérieure.
Que dois-je utiliser pour stocker ces données? Dois-je utiliser une base de données relationnelle ou une solution NoSQL? Quelles autres choses dois-je considérer lors de la conception de cette application?
Quelques alternatives pour stocker ces données:
- File d'attente de messages (éventuellement distribuée), comme Apache Kafka
Cela sera optimisé pour l'écriture et la lecture d'un flux de données. Il est idéal pour collecter des flux de données dans un format facile à traiter, mais il ne peut généralement pas être interrogé sauf en lisant le flux dans son intégralité. Donc, ce serait soit à des fins d'archivage, soit une étape intermédiaire sur le chemin d'une couche de traitement.
- Base (s) relationnelle (s)
Vous pouvez simplement l'écrire dans la base de données, et lorsque le volume dépasse la capacité de la base de données à gérer, vous pouvez partager la base de données (= avoir plusieurs sous-ensembles de données assis sur différents serveurs de base de données). Avantage: vous pouvez utiliser une base de données relationnelle et vous n'avez rien à apprendre de nouveau. Inconvénient: tout le code traitant de la base de données doit être conscient de la partition de chaque élément de données, les requêtes agrégées doivent être effectuées dans le logiciel d'application.
- Base de données NoSQL distribuée, comme Cassandra.
Vous écrivez vos données dans une base de données NoSQL distribuée, et elle scindera automatiquement les données pour vous. Cassandra vous permet de faire des requêtes à travers le cluster, nécessitant moins de code d'application pour revenir aux données. Avantage: plus naturellement adapté pour de grandes quantités de données, inconvénient: nécessitera une expertise spécifique et une compréhension approfondie des mécanismes de fonctionnement de ces systèmes pour obtenir de bonnes performances et rendre les données interrogeables en fonction de vos besoins. NoSQL n'est pas une solution magique pour les performances, c'est un ensemble de compromis qui doit être compris pour être parcouru.
- Hadoop/fichier
Les données sont ajoutées à des fichiers qui sont distribués automatiquement sur les serveurs par la plate-forme Hadoop, traitées sur ces serveurs à l'aide d'outils comme M/R ou Apache Spark, et enfin interrogées (sous forme de fichier) à l'aide d'un moteur SQL Hadoop comme Hive ou Impala.
Lequel choisir?
Les compromis entre ces alternatives sont complexes, et ils dépendent beaucoup à la fois de vos schémas d'écriture et de lecture, donc la seule personne qui peut décider de ces compromis est vous. Si vous n'avez pas le temps d'acquérir une compréhension approfondie de ces alternatives, utilisez simplement une base de données relationnelle et trouvez une solution de partitionnement au fur et à mesure. Selon toute vraisemblance, YAGNI .
Examinez vos besoins un peu plus en profondeur. Il existe un moyen de créer l'illusion d'une position de suivi à chaque seconde.
Si vous avez une application qui connaît votre position GPS actuelle et l'écrit dans une base de données, pourquoi continuer à écrire la position si elle ne change pas? Même si vous avez besoin des données, si l'utilisateur a endormi pendant 7 heures, vous pouvez remplir par programme les intervalles de temps manquants avec un emplacement en double pour faire vos calculs ou votre cartographie ou tout ce que vous devez faire.
Si vous suivez l'emplacement à chaque seconde, devez-vous stocker ces données pour toujours? Vous pouvez archiver les enregistrements dans une autre base de données pour éviter que la table actuelle ne devienne trop volumineuse. Ou vous pouvez même simplement conserver les enregistrements en cas de changement de position. Ceci est courant dans les entrepôts de données.
Vos données sont un ensemble de séries chronologiques. Vous avez donné des ensembles de nombres (deux par utilisateur) qui évoluent avec le temps. En règle générale, vous ne recherchez PAS de stockage relationnel, mais plutôt un stockage RRD. Ce stockage se concentre fortement sur la réduction du travail d'E/S de nombreuses petites écritures en le tamponnant.
Le stockage relationnel est une hérésie pour ce volume de séries chronologiques. Cependant, sachez que le développement de RRD n'est pas aussi bien supporté en termes d'exploitations programmables que le SQL. Vous envisagez probablement un travail d'intégration sérieux, mais il est difficilement évitable compte tenu de vos besoins.