Data Structure για time-based υπολογισμούς

[lion2486]

Καλησπέρα, αυτό που γράφω αγορά web-project, η γλώσσα είναι php αλλά το γράφω εδώ γιατί στην ουσία ασχολούμαι με διαδικασία εκτέλεσης που δεν σχετίζεται με web development.

 

Έχω μια ιεραρχία φακέλων της μορφής

root/<περιοχή>/<εξοπλισμός>/<μήνας>/<ημέρα>/αρχείο.txt

 

όπου έχω πολλές περιοχές (~10), 3 εξοπλισμούς ανα περιοχή συνήθως και ένα αρχείο κάθε μέρα..

Τα αρχεία αφορούν στατιστικά στοιχεία και είναι log-files. Εγώ θέλω περιοδικά να επεξεργάζομαι τα αρχεία και να τα βάζω σε μία βάση (mysql) για εξαγωγή στατιστικών στοιχείων.

 

Τα αρχεία δημιουργούνται από μια άλλη εφαρμογή και στην ουσία είναι τιμές αισθητήρων με την ώρα λήψης της τιμής. Οι τιμές συνήθως έχουν ανανέωση κάθε 4-8λεπτά αλλά δεν είναι σπάνια και προβλήματα επικοινωνίας ή ρεύματος και απώλεια δεδομένων 20-200λεπτών. 

 

αυτό που προσπαθώ να κάνω και θέλω κάποια άποψη/συζήτηση είναι να "διασταυρώνω" τα δεδομένα από κάθε μέρα & περιοχή και να γράφω στη βάση. Αυτά που θέλω στη βάση είναι το σύνολο από τις αυξομειώσεις την ένδειξης του ενός αισθητήρα (άθροισμα διαφορών σε κάθε μέτρηση), και τα λεπτά ένδειξης του δεύτετου αισθητήτα (είναι 2 ειδών, οι δεύτεροι μεταφράζονται σε ανοιχτό/κλειστό και με ενδιαφέρει να μετράω πόσα λεπτά ήταν ανοιχτό, ώστε μετά να πολλαπλασιάσω λεπτά * σταθερή τιμή). Στη βάση όμως δεν με ενδιαφέρει η ακρίβεια που έχουν οι μετρήσεις, αλλά θέλω να τα ανάγω ανα ώρα.

 

Έχω κάνει μια υλοποίηση αλλά η πολυπλοκήτητα της ροής έχει δημιουργήσει προβλήματα και προσπαθώ να βρω κάποιον πιο σωστώ και καθαρό τρόπο να το φτιάξω. 

 

Οι ιδέες που έχω τώρα είναι να περάσω όλα τα δεδομένα ανα μέρα σε arrays και να κάνω μετά την επεξεργασία ή να τα περάσω σε προσωρινό πίνακα βάσης για να κάνω πιο εύκολα groupαρίσματα και αθροίσματα ή να βρω/φτιάξω κάποια άλλη δομή δεδομένων για να με βοηθήσει να κρατήσω καθαρό τον κώδικα και να αποφύγω λάθη.. (σε αρχικές/τελικές εγγραφές, με νοιάζει να βρω της επόμενης μέρα για να κάνω τη διαφορά, μπορεί σε κάποιες περιπτώσεις να λείπουν φάκελοι για ολόκληρο μήνα, μπορεί να μου έρθουν εγγραφές στη μέση της μέρας και στην επόμενη ανανέωση να ξαναέρθουν ...)

 

Αν θέλετε μπορώ να αναλύσω πιο πολύ τη φύση των δεδομένων/μορφή κτλ αλλά προσπαθώ να μην σας μπλέξω με λεπτομέρειες. Ευχαριστώ πολύ όποιον το διάβασε όλο (και τους υπόλοιπους εννοείται!), κάθε βοήθεια/απορία/διευκρίνηση και συζήτηση πάνω στο πρόβλημα ευπρόσδεκτα!

[ParhsG]

Πιστεύω πως πρέπει να κοιτάξεις πέρα απο σχεσιακές βάσεις για το πρόβλημα σου.

[lion2486]

προτείνεις κάτι συγκεκριμένο;

[parsifal]

Καλησπέρα,

 

 

Διάβασα λίγο γρήγορα το post #1, αλλά μου δημιουργήθηκε η απορία: Γιατί δεν απλοποιείς την λογική της αποθήκευσης, κρατώντας στη Β.Δ. σου απλά και μόνο τις μετρήσεις; Μετά, με κατάλληλα SQL queries θα πρέπει λογικά να είσαι σε θέση να υπολογίζεις οποιοδήποτε στατιστικό (ή μη) δεδομένο χρειάζεσαι.

[lion2486]

Καλησπέρα,

 

 

Διάβασα λίγο γρήγορα το post #1, αλλά μου δημιουργήθηκε η απορία: Γιατί δεν απλοποιείς την λογική της αποθήκευσης, κρατώντας στη Β.Δ. σου απλά και μόνο τις μετρήσεις; Μετά, με κατάλληλα SQL queries θα πρέπει λογικά να είσαι σε θέση να υπολογίζεις οποιοδήποτε στατιστικό (ή μη) δεδομένο χρειάζεσαι.

χμμμ, πάνω σε αυτό απλά αν τα βάλω χύμα στη βάση θα είναι λίγο δύσκολο μετά για την εξαγωγή των στατιστικών γιατί υπάρχουν 2 ειδών πληροφορίες που πρέπει να συνδιαστούν στο στοιχείο του χρόνου και να βρει ένα αποτέλεσμα. Το βασικότερο πρόβλημα σε αυτήν την προσέγκιση είναι ο όγκος των δεδομένων, έχω για περίπου 30 μετρητές μέτρηση κάθε 4-7 λεπτά συνήθως, οπότε χοντρικά σε ένα χρόνο ~3kk εγγραφές, υπάρχει προοπτική να μεγαλώσει η συλλογή των δεδομένων και χρειάζομαι τουλάχιστον 1-2 έτη στατιστικά..

[parsifal]

Και το μέγιστο resolution που χρειάζεσαι μακροπρόθεσμα, αν κατάλαβα σωστά, είναι επιπέδου ημέρας;

 

Μία ιδέα που ανέφερες πιο πάνω (χρήση προσωρινού πίνακα στη βάση) είναι ενδιαφέρουσα, νομίζω. Με την χρήση σωστών triggers, ενδεχομένως να μπορούσες να βάλεις το DBMS σου να "δουλεύει" για σένα κάνοντας περιοδικα τα απαραίτητα buffer table flushes και υπολογισμούς, περιορίζοντας τον κώδικα PHP σε ρόλο καθαρά αποθήκευσης και ανάκτησης πληροφορίας...

[lion2486]

Και το μέγιστο resolution που χρειάζεσαι μακροπρόθεσμα, αν κατάλαβα σωστά, είναι επιπέδου ημέρας;

 

Μία ιδέα που ανέφερες πιο πάνω (χρήση προσωρινού πίνακα στη βάση) είναι ενδιαφέρουσα, νομίζω. Με την χρήση σωστών triggers, ενδεχομένως να μπορούσες να βάλεις το DBMS σου να "δουλεύει" για σένα κάνοντας περιοδικα τα απαραίτητα buffer table flushes και υπολογισμούς, περιορίζοντας τον κώδικα PHP σε ρόλο καθαρά αποθήκευσης και ανάκτησης πληροφορίας...

χμμ, η ιδέα με τα triggers είναι ενδιαφέρουσα θα έλεγα, ίσως αν το κάνω με queries-variables-loops σε php να βγεί ακόμα πιο απλό. Τα δεδομένα τα έχω τώρα σε επίπεδο ώρας στη βάση, αντί για 5λεπτο που έχω τις μετρήσεις μου. 

[defacer]

Το βασικότερο πρόβλημα σε αυτήν την προσέγκιση είναι ο όγκος των δεδομένων, έχω για περίπου 30 μετρητές μέτρηση κάθε 4-7 λεπτά συνήθως, οπότε χοντρικά σε ένα χρόνο ~3kk εγγραφές, υπάρχει προοπτική να μεγαλώσει η συλλογή των δεδομένων και χρειάζομαι τουλάχιστον 1-2 έτη στατιστικά..

 

Τα νούμερα αυτά είναι αστεία. "Όγκος δεδομένων" και "πρόβλημα" μπαίνουν στην ίδια πρόταση μόνο αν μιλάμε για τριψήφιους αριθμούς μετρήσεων το δευτερόλεπτο και πάνω.

 

Δεν έχω καταλάβει πάντως από το πρώτο post ακριβώς σε τι κολλάς. "Η πολυπλοκότητα της ροής" έχει δημιουργήσει τι είδους ακριβώς προβλήματα; Θες να πεις ότι το πρόγραμμα γίνεται περίπλοκο πέρα από την ικανότητά σου να διαχειριστείς αυτή την πολυπλοκότητα;

[Papakaliati]

Μπορεις να κοιταξεις και τιποτα σε Cassandra η αλλη NoSQL, αλλα με την καμια δεν εχεις τετοιο ογκο δεδομενων ωστε να μην μπορεις να χρησιμοποιησεις SQL.

  Ta triggers δεν καταλαβα γιατι να τα χρησιμοποιησεις. Το μονο που θελεις , ειναι ενα service που να διαβαζει τα αρχεια και να τα σωζει στην βαση δεδομενων.

[ParhsG]

Μετρήσεις απο φωτοβολταικά παίρνεις; Μιας και δε το έχεις ξανακάνει νομιζω πως πρεπει να σπασεις το προβλημα σε μικρότερα υλοποίησε το όπως μπορείς και όσο προχωράς βελτιώνεις το σχεδιασμό.

[lion2486]

Τα νούμερα αυτά είναι αστεία. "Όγκος δεδομένων" και "πρόβλημα" μπαίνουν στην ίδια πρόταση μόνο αν μιλάμε για τριψήφιους αριθμούς μετρήσεων το δευτερόλεπτο και πάνω.

 

Δεν έχω καταλάβει πάντως από το πρώτο post ακριβώς σε τι κολλάς. "Η πολυπλοκότητα της ροής" έχει δημιουργήσει τι είδους ακριβώς προβλήματα; Θες να πεις ότι το πρόγραμμα γίνεται περίπλοκο πέρα από την ικανότητά σου να διαχειριστείς αυτή την πολυπλοκότητα;

στην αρχή θυμάμαι ότι είχα υπολογισμούς για 50kk εγγραφές τον χρόνο και το σκεφτόμουν, αλλά δεν ξέρω αν είχα κάνει κάποιο λάθος τότε ή τώρα.. Όσον αφορά το πρόβλημάμου ναι, η πολυπλοκότητα εμποδίζει εμένα να αποσφαλματώσω τις μεθόδους και γενικά να μπορεί να είναι ξεκάθαρο τι γίνεται και να υπάρχουν μέσα και οι έλεγχοι σφαλμάτων.

 

Μπορεις να κοιταξεις και τιποτα σε Cassandra η αλλη NoSQL, αλλα με την καμια δεν εχεις τετοιο ογκο δεδομενων ωστε να μην μπορεις να χρησιμοποιησεις SQL.

  Ta triggers δεν καταλαβα γιατι να τα χρησιμοποιησεις. Το μονο που θελεις , ειναι ενα service που να διαβαζει τα αρχεια και να τα σωζει στην βαση δεδομενων.

Η ιδέα με τη βάση μου έρχεται μετά, έχω κάνει μια αρχική υλοποίηση όλης της διαδικασία σε php αλλά σκέφτομαι εναλλακτικές για καλύτερες λύσεις.

 

Μετρήσεις απο φωτοβολταικά παίρνεις; Μιας και δε το έχεις ξανακάνει νομιζω πως πρεπει να σπασεις το προβλημα σε μικρότερα υλοποίησε το όπως μπορείς και όσο προχωράς βελτιώνεις το σχεδιασμό.

Όχι, τα δεδομένα είναι στοιχεία κατανάλωσης και άντλησης νερού από το δίκτυο ύδρευσης δήμου.

[ParhsG]

Δε ξέρω τι σε δυσκολεύει αλλα λογικά το script που βάζει δεδομένα πρέπει να τρέχει μόνο του ανεξάρτητα. Αν θες εύκολη διαχείριση δεδομένων μπορείς να κάνεις και προσωρινούς πίνακες στη βάση(temporary table) και μετα τα βάζεις στο κανονικό όπως είπες εξάλλου. Επίσης μας παρουσιάζεις πολυ γενικα το πρόβλημα ώστε να μπορέσουμε να βρούμε κάποια άλλη λυση

[lion2486]

Δε ξέρω τι σε δυσκολεύει αλλα λογικά το script που βάζει δεδομένα πρέπει να τρέχει μόνο του ανεξάρτητα. Αν θες εύκολη διαχείριση δεδομένων μπορείς να κάνεις και προσωρινούς πίνακες στη βάση(temporary table) και μετα τα βάζεις στο κανονικό όπως είπες εξάλλου. Επίσης μας παρουσιάζεις πολυ γενικα το πρόβλημα ώστε να μπορέσουμε να βρούμε κάποια άλλη λυση

Ναι αλλά το παλεύω προς το παρόν να το κάνω με απλές δομές δεδομένων και να το γράψω λίγο πιο κομψά. Σε μια αναζήτηση που έκανα σκέφτηκα μήπως δοκίμαζα μια δομή skip list, και να έχω ιεραρχίες σύνδεσης που να καλύπτει τις χρονικές απαιτήσεις στον χρόνο που έχω, αλλά το παλεύω κάπως αλλιώς τώρα. Επίτηδες κράτησα απλή την περιγραφή μου και γενική, πρώτον γιατί μια γενική λύση μπορεί να είναι χρήσιμη και για άλλους και άλλες περιπτώσεις και δεύτερον δεν είμαι σίγουρος αν περισσότερες λεπτομέρειες βοηθούσαν για κάποια λύση (αν όμως θέλετε μπορώ να γίνω και πιο αναλυτικός στα δεδομένα και τη διαδικασία εισαγωγής). Ευχαριστώ πολύ όλους για το χρόνο σας μέχρι τώρα.

[nikolaos_]

Δουλεύω κι εγώ σε ένα παρόμοιο δίκτυο διάσπαρτων αισθητήρων, τις μετρήσεις των οποίων αποθηκεύω σε βάση δεδομένων, ωστόσο δεν ασχολούμαι να κάνω στατιστικά στοιχεία. Ειδικά για στατιστικά στοιχεία δεν είναι και πολύ βολικό να τα βγάλεις από ΒΔ. Η ΒΔ χρησιμεύει στο να φτιάξεις queries, δηλαδή θα βάζεις διάφορα κριτήρια με τα οποία φιλτράρεις τα στοιχεία, ώστε το αποτέλεσμα να είναι μια μεγάλη λίστα (πίνακας, rows, όπως θες τα λες) με τα στοιχεία στα μέτρα σου. Αυτό το αποτέλεσμα το διοχετεύεις μετά σε ένα στατιστικό πρόγραμμα, π.χ. R, για να βγάλεις στατιστικά συμπεράσματα.

 

Η MySQL και κάθε αξιοσέβαστο πρόγραμμα για ΒΔ έχει timestamp, οπότε μπορείς να αποθηκεύεις την ώρα της μέτρησης που κάνει κάθε αισθητήρας, με όση ακρίβεια επιθυμείς.

 

Μπορείς να φτιάξεις ένα μοντέλο ΒΔ που να μιμείται τα φύλλα excel - ένα εξελόφυλλο - π.χ. με την μηχανή MyISAM της MySQL, ή ένα σχεσιακό μοντέλο, εάν έχεις ανάγκη να μην επαναλαμβάνονται τιμές σε κάθε γραμμή του εξελόφυλλου. Η απόδοση της ΒΔ αλλάζει ανάλογα.

 

Αντίθετα, το να συμπληρώσεις με κάποιο interpolation τις χαμένες μετρήσεις που θα έπρεπε να υπάρχουν στη ΒΔ, είναι στατιστική και πέρα από κάποια απλά, η SQL δεν κάνει για τέτοια.

 

Τέλος, μπορείς να γράψεις εύκολα ένα perl script και να διατρέχει τα log files και να φτιάχνει όλα όσα γυρεύεις χωρίς να ανακατεύεσαι με ΒΔ ή με στατιστικά προγράμματα.

 

Έχω τη γνώμη ότι το πρόβλημα σου φαίνεται περίπλοκο γιατί απλά δεν έχεις εντελώς ξεκάθαρο τι θες να κάνεις και προσπαθείς να βρεις ποιο προγραμματιστικό εργαλείο σου κάνει χωρίς να χάσεις χρόνο δοκιμάζοντας.

[defacer]

Όσον αφορά το πρόβλημά μου ναι, η πολυπλοκότητα εμποδίζει εμένα να αποσφαλματώσω τις μεθόδους και γενικά να μπορεί να είναι ξεκάθαρο τι γίνεται και να υπάρχουν μέσα και οι έλεγχοι σφαλμάτων.

 

Ναι αλλά το παλεύω προς το παρόν να το κάνω με απλές δομές δεδομένων και να το γράψω λίγο πιο κομψά. Σε μια αναζήτηση που έκανα σκέφτηκα μήπως δοκίμαζα μια δομή skip list, και να έχω ιεραρχίες σύνδεσης που να καλύπτει τις χρονικές απαιτήσεις στον χρόνο που έχω, αλλά το παλεύω κάπως αλλιώς τώρα.

Και κει που νόμισα ότι έχω καταλάβει κάπως...

 

Τελικά το πρόβλημα είναι η πολυπλοκότητα του προγράμματος ή ότι δεν τρέχει αρκετά γρήγορα; Αν είναι το πρώτο τότε γιατί π.χ. τρώγεσαι με skip lists; Και γιατί skip list που είναι σχετικά "εξωτική" data structure και όχι κάτι απλούστερο; Και αυτά πας να τα κάνεις μόνος σου ή υπάρχουν έτοιμα σε κάποιο library?

 

Αισθάνομαι ότι δεν έχω καταλάβει απολύτως τίποτα.