J'ai un projet où des capteurs physiques envoient des données sur le serveur. Les données sont envoyées irrégulièrement - après quelque chose activé un capteur, mais pas moins souvent que toutes les 20 minutes. Sur les données du serveur sont stockées dans une base de données POSGRESQL.
La structure de données ressemble à: On ne devrait pas dépasser 100 Demande / seconde totale. Les enregistrements de données dans la base de données doivent être persistés pendant 90 jours et même plus dans certains cas (pas seulement 2 semaines, comme je l'ai pensé plus tôt). Donc, le montant total des enregistrements ne serait pas plus de 120 960 000/14 jours. C'est une estimation "sûre". En réalité, cela pourrait être 10 fois moins (10 req / seconde, 12 960 000 enregistrements). Je dois faire une analyse sur les données, comme: Le "temps déclaré" ci-dessus est supérieur ou égal à 1 seconde. La partie du serveur entière est développée dans Django (et Django-Rest-Framework pour recueillir des données). < / p> Les questions sont de savoir comment effectuer une telle analyse de données de manière efficace, en supposant qu'il devrait y avoir une heure en temps réel ou proche de la surveillance des données et des périodes de temps pour déclencher les actions souhaitées. < p> Mes pensées: exécutez un processus qui interrogerait la base de données chaque seconde pour les enregistrements répondant à des critères et à des actions spécifiques (cela prendrait probablement plus de 1 seconde)
exécutez quelques processus distincts (evenlet?) Un pour chaque type d'analyse, puis interrogeez la base de données toutes les actions spécifiques de 1 seconde et incendie.
Exécuter un processus par chaque capteur qui rapporte en permanence des abonnés: je suis vrai sur "Valeur 2" pendant plus de x secondes, etc. Le processus est réinitialisé après que de nouvelles données pour ce capteur arrivent. Certaines solution de publication-abonnement comme Zeromq peuvent être utilisées ici?
Utilisez une autre solution / plus rapide
indice? mise à jour. Actuellement la solution qui semble être simple et efficace pour moi est la suivante: Cela nécessiterait que je faudrait des tests de feu chaque fois que la demande arrive pour un capteur spécifique, mais de l'autre côté, je ne devrai que numériser uniquement la table des "tests", toutes les 1 seconde. < p> mise à jour 2 J'ai découvert des pytables ( http: //www.pytables. org / moing / pytables ), semble assez bien adapté à mon étui d'utilisation en tant que stockage de données.
4 Réponses :
Mon premier coup de poing à ce sujet serait de créer un index multi-colonnes sur "Tableau de données de capteur", de similaire: Voir si vos requêtes SQL sont assez rapides. Vous pouvez l'interroger via eventlets ou cron. À partir d'une perspective de performance, peu importe que vous utilisez aussi longtemps que cette requête est assez rapide, elle est très susceptible d'être votre goulot d'étranglement. Une autre suggestion est d'essayer des tables de mémoire MySQL ou l'équivalent postgre ( -Mémory Tableau dans PostgreSQL ). Une autre suggestion est d'essayer Redis. Vous pouvez stocker des "données de capteur" comme collection de jeux triés; Un jeu de réglage trié par iD de capteur et champ de valeur, et trier les données par horodatage. REDIS nécessitera une logique d'application pour accumuler les données, mais elle sera très rapide si elle tous convient à la RAM. RE: MONGODB. Vous pouvez obtenir du bon perf. Tant que vos données requises + index peuvent installer dans la RAM et il n'y a pas trop de serrures d'écriture. Bien que c'est un fardeau administratif (et codant) pour exécuter 2 bases de données lourdes qui fournissent des fonctionnalités qui se chevauchent. Étant donné que le compactage n'est pas vraiment un problème. Vous pouvez créer des index TTL sur les données du capteur et Mongo supprimera des données plus anciennes dans un thread BG. La taille du fichier restera constante après un certain temps. espère que cela aide
Merci, ce sont des solutions vraiment précieuses. J'irais d'abord avec SQL et voyez à quel point c'est rapide.
Trop vite avec commentaire précédent, alors: J'irais d'abord avec SQL et voyez à quel point c'est rapide. Les tables en mémoire seraient rapides mais je dois persister les données. Redis ... Intéressant mais je ne suis pas sûr que si cela serait approprié de: 1. Conserver autant de données là-bas (il doit être persisté) 2. Filtrer ces données, par exemple, je dois calculer la période totale des inactivités dans un 24 heures (je fais aussi une autre analyse des données rassemblées, mais cela n'arrive pas très souvent) Mongo. 100 req / seconde seraient-ils susceptibles de causer des serrures en écriture? Je devrais probablement tester à quel point Mongo est rapide et comparez-la aux résultats de SQL DB.
Super! Heureux que vous appréciiez cela. Redis, contrairement à Memcache, stocke des données de manière persistante. Il stocke autant que possible dans la RAM et les pages dans / Out quand les besoins. Étant donné que, il me semble que vos besoins sont mieux adaptés à SQL. Re: Mongo. Nombre de reqs. n'a rien à voir avec les serrures. Mongo est génial à la lecture seule, bonne w en écriture uniquement, pas si bon avec lecture-écriture car écrit bloque la base de données complète (aucune autre lecture / écriture ne peut se produire). Si vos données + index sont adaptées à la RAM, ce sera agréable. Comme vous l'avez dit, vous ne saurez que si vous essayez.
Si vos règles sont simples ou peu, vous pourriez essayer d'utiliser des déclencheurs SQL pour mettre à jour les vues stockées, ce qui pourrait être rapidement interrogé. Par exemple. En supposant que vous souhaitez détecter, qu'un certain capteur a été actif pour une durée donnée, vous pourriez avoir une table contenant des heures d'activation de capteurs actifs actuellement. Chaque fois que vous stockez un événement brut, un déclencheur mettrait à jour une telle table.
Il serait plus difficile pour les règles de type 3. Sauf si vous y en ayez quelques-unes, et vous pouvez configurer un ensemble de déclencheurs et de vues pour chacun ou des périodes de temps autorisées sont connues à l'avance.
Option n ° 4. La base de données relationnelle est le goulot d'étranglement clair. Organisez la livraison de données sous une forme plus simple (fichiers dans un répertoire, nommé par nom de capteur ou quelle que soit la clé unique). Vous pouvez traiter beaucoup plus rapidement, vérifier les horodatages et la lecture - puis poussez les données sur la RDB à l'arrière, après avoir analysé.
Je ne peux pas m'attendre à des fichiers contenant des données de toute la journée. Les données sont envoyées en continu au serveur. Donc, je dois le recevoir et enregistrer. De plus, je ne peux pas dire que je n'aurai pas besoin de réanalyser ces données - par exemple lorsqu'une nouvelle requête de surveillance est créée, comme si vous voulez maintenant être informé lorsque le capteur est ouvert plus longtemps qu'une semaine. Donc, mon système doit analyser des données aussi anciennes qu'une semaine)
Avez-vous pensé au serouillage par problème et le traitement du traitement des données d'entrée?
Une approche d'échantillon de ce type serait la suivante: Le mécanisme de stockage idéal pour telle Un flux de transaction est celui qui se prête bien aux écrivies / mises à jour de la latence faible. Les solutions NOSQL fonctionnent très bien pour ce type de travail (j'ai personnellement utilisé REDIS pour un type d'analyse similaire, mais vous n'êtes pas intégré à cette solution particulière.)