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.

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 horodatages des données reçues.
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?

database big-data

— Utku
source

2000 enregistrements par seconde comme celui-là ne perturberont probablement pas un moteur SQL à jour. Un test de capacité simple consisterait à obtenir un programme de console écrivant au hasard des fichiers chargés en masse.

— Caleth

@Caleth Mais est-il évolutif? Qu'en est-il lorsque la base d'utilisateurs augmente 100 fois?

— Utku

Mesurez ce que votre matériel peut actuellement gérer. Le goulot d'étranglement est probablement le processeur «traitant» les valeurs, ou la vitesse du disque brut. Que comptez-vous faire de toutes ces données? Cela devrait façonner la technologie que vous choisissez pour le stockage

— Caleth

Caleth a absolument raison. Des millions de documents ne perturbent pas un système de base de données moderne. Les magasins NoSQL sont très bons pour écrire d' énormes quantités de données très rapidement, mais au final, vous voulez faire quelque chose qui implique de relire les choses. La quantité de lecture dont vous aurez besoin détermine souvent le type de magasin que vous devez utiliser.

— Kilian Foth du

Pour donner une bonne réponse, nous devons savoir comment vous prévoyez d' utiliser ces données. Une base de données peut être un bon choix si vous souhaitez des requêtes ad hoc, tandis qu'une solution basée sur des fichiers serait probablement meilleure pour l'analyse de l'ensemble de données. Voter pour clore.

— kdgregory

Réponses:

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 elles seront automatiquement partagé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é à 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 selon vos besoins. NoSQL n'est pas un correctif magique de performance, 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 .

— Joeri Sebrechts
source

J'ai fourni plus de détails sur la façon dont je prévois d'utiliser les données. Souhaitez-vous ajouter quelque chose compte tenu de ces informations?

— Utku

Je ne comprends toujours pas très bien ce que vous entendez par "résolution". Voulez-vous agréger au niveau géographique (ville, état, ...) ou sur un système de coordonnées comme un geohash? Ou êtes-vous intéressé par la quantité de delta parce que vous souhaitez créer des notifications basées sur des seuils de mouvement? En bref: à quoi cela sert-il?

— Joeri Sebrechts

C'est pour suivre les utilisateurs. Les utilisateurs se suivent et je représente graphiquement où les utilisateurs qu'ils suivent ont été au cours des 5 dernières heures sur les appareils. Essentiellement, plus le grain est fin, mieux c'est. Cependant, les appareils mobiles ont une quantité de mémoire limitée, vous ne pouvez donc pas envoyer les données sans réduire leur résolution. Autrement dit, supposons que l'utilisateur A effectue le suivi des utilisateurs B, C et D. Si je transfère simplement les données de localisation que je reçois de B, C et D vers A sans effectuer de traitement côté serveur, la mémoire de l'appareil de l'utilisateur A se remplira très rapidement. . Par conséquent, je dois faire un peu de traitement.

— Utku

Si je devais construire ce que vous décrivez, je le construirais comme une série de journaux kafka connectés via le streaming d'étincelles, où les positions sont intégrées entre les fenêtres dans le flux d'étincelles, et le journal kafka de sortie final est fourni sous forme de pull et envoyer des API Web aux clients. Cependant ... c'est beaucoup de technologie très particulière, et selon votre expérience et le temps disponible, ces choix peuvent être mauvais pour vous.

— Joeri Sebrechts

Merci. Je garderai cela à l'esprit mais en suivant le principe YAGNI, je prévois d'utiliser une base de données relationnelle pour l'instant. Lorsque le besoin s'en fera sentir, je passerai à quelque chose qui convient mieux à l'application. N'hésitez pas à modifier toute information dans votre réponse, si vous le souhaitez.

— Utku

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 est endormi depuis 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.

— JeffO
source

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.

— Arthur Havlicek
source