Χαιρετώ την παρέα

Δημιουργώ μία γραφική εφαρμογή σε περιβάλλον Visual Basic 2008 και θα ήθελα την συμβουλή σας σε θέματα αποθήκευσης δεδομένων.

Στην εφαρμογή έχω μεταξύ άλλων και ένα πίνακα ως εξής που ενημερώνεται κάθε φορά που ανοίγει η εφαρμογή:

Structure MenuΧΥ
      Public txID As Long
      Public txEIDOS As Integer
      Public txΧ1 As Long
      Public txΥ1 As Long
      Public txΧ2 As Long
      Public txΥ2 As Long
End Structure
Public ΧΥInMemory(100000) As MenuΧΥ

Θέλω να αποθηκεύσω τα δεδομένα του πίνακα ΧΥInMemory με τέτοιο τρόπο ώστε σε κάθε φόρτωμα της εφαρμογής να φορτώνονται όσο το δυνατόν ταχύτερα

Τι τρόπο αποθήκευσης να χρησιμοποιήσω έτσι ώστε να πετύχω γρήγορο φόρτωμα (ο χρόνος αποθήκευσης δεν με ενδιαφέρει)
αναφέρομαι κυρίως σε έμπειρους χρήστες.

Φόρτωμα από που  και γιατί θέλεις να κρατάς 1,000,000 εγγραφές στη μνήμη και μάλιστα σε πίνακα? Υπάρχει περίπτωση ο ένας και μοναδικός χρήστης της desktop εφαρμογής να χρειαστεί και το ένα εκατομμύριο εγγραφές ?

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

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

Αυτή την στιγμή είναι αποθηκευμένες σε πίνακα σε MySQL, αλλά όπως είπα δεν με ενδιαφέρει που θα αποθηκεύονται και με ποιον τρόπο.
Εξάλου ο τρόπος αποθήκευσης θα επιλεγχθεί με κριτήριο την γρήγορη ενημέρωση του πίνακα.

Αν τα δεδομένα τα διαβάζεις όλα όταν ξεκινάει η εφαρμογή, στην συνέχεια τα επεξεργάζεσαι στην μνήμη και πριν κλείσει η εφαρμογή τα σώζεις όλα και σε ενδιαφέρει η ταχύτητα τότε προσωπικά θα χρησιμοποιούσα Flat File και όχι κάποια βάση. Τώρα αν υπάρχουν και άλλα από πίσω τα οποία δεν έχεις αναφέρει ακόμα, όπως π.χ αναζήτηση, ταξινόμηση, διαγραφή τότε μείνε στην βάση και συμβιβάσου με την ταχύτητα που έχεις. Αν περιμένει πολύ ο χρήστης μέχρι να φορτωθούν τα δεδομένα και το UI δεν ανταποκρίνεται, δημιούργησε και ένα Thread που να φορτώνει τα δεδομένα.

Αλλά αν το σενάριο είναι απλό και η ταχύτητα για εμένα είναι το παν θα προτιμούσα flat file για αποθηκευτικό μου χώρο. 

Dataman:

οι εγγραφές αυτές είναι συντεταγμένες ενός διανυσματικού σχεδίου

Τί είδους σχέδιο? Τα σημεία είναι ανεξάρτητα μεταξύ τους είναι χρησιμοποιείς σχήματα, π.χ. πολύγωνα και γραμμές? Η MySQL έχει υποστήριξη για spatial types οπότε θα μπορούσες να το εκμεταλλευτείς. Είναι πολύ σημαντικό σε μία εφαρμογή απεικόνισης, είτε πρόκειται για GIS είτε για άλλο είδος εφαρμογής, να εμφανίζεις μόνο τα στοιχεία που χρειάζονται. Αν χρησιμοποιείς πολύγωνα μπορείς να χρησιμοποιήσεις spatial queries για να δείξεις μόνο τα σχήματα τα οποία φαίνονται στο "παράθυρο" της εφαρμογής κάθε φορά και όχι ολόκληρο το σχέδιο. Αν έχεις μόνο σημεία, π.χ. συντεταγμένες από GPS, αρκεί να φτιάξεις ένα index για τις δύο συντεταγμένες και να χρησιμοποιήσεις range queries.

Το άλλο σημείο που πρέπει να προσέξεις είναι ότι δεν αρκεί να φορτώσεις τα σημεία στη μνήμη. Όπως καθυστερεί το φόρτωμα του σχεδίου από τη βάση χωρίς spatial indexes, έτσι θα καθυστερήσει και η σχεδίαση του αν πρέπει κάθε φορά να ανατρέχεις ολόκληρο τον πίνακα για να επιλέξεις τα σημεία που θα σχεδιάσεις. Θα πρέπει να χρησιμοποιήσεις κάποια διαφορετική δομή όπως quadtrees για να βρεις γρήγορα τα σχήματα που πρέπει να σχεδιάσεις. Μία αναζήτηση στο codeplex επιστρέφει αρκετές βιβλιοθήκες για spatial δεδομένα, όπως π.χ. το Sharpmap αν και τα περισσότερα projects αφορούν SQL Server 2008.

Χωρίς να ξέρουμε τί θέλεις να κάνεις δεν μπορούμε να σου πούμε ότι χρειάζεσαι ή όχι το Sharpmap, το GeoAPI.NET ή .... την OpenGL. Υπάρχουν πολλών ειδών εφαρμογές οι οποίες δουλεύουν με διανύσματα όπως αρχιτεκτονικά σχέδια, παιχνίδια και GIS. Η κάθε κατηγορία έχει διαφορετικές απαιτήσεις και αρκετές έτοιμες βιβλιοθήκες. Θα πρέπει να μας πεις τί θέλεις να κάνεις για να μπορέσουμε να σε βοηθήσουμε.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Πρόκειται για GIS εφαρμογή και οι πληροφορίες που αποθηκεύω αναφέρονται σε συντεταγμένες, Line, Polygon, Shape.
Τα δεδομένα από την μνήμη φιλτράρονται ανάλογα με το επίπεδο του zoom που θέλω να εμφανίσω. Η εμφάνιση του σχεδίου στο πρόγραμμα δεν καθυστερεί καθόλου διότι τα στοιχεία είναι στη μνήμη και με κατάλληλο αλγόριθμο εμφανίζονται πολύ γρήγορα.

Το πρόβλημα είναι μέχρι να πάνε στην μνήμη.

Ο τρόπος που αποθηκεύω τα δεδομένα στην βάση MySQL είναι με μορφή int ή long και δεν υπάρχει πρόβλημα στην ταχύτητα αναζήτησης.

Μπορείς να γίνεις πιο σαφής στα spatial indexes και spatial δεδομένα?

Ρίξε μία ματιά στα spatial extensions της My SQL και ιδιαίτερα στο παράδειγμα χρήσης spatial indexes. Η MySQL υποστηρίζει τις κλάσεις του OpenGIS, δηλαδή Point, Curve, Polygon κλπ καθώς και functions όπως η MBRContains, MBRIntersects κλπ. Επιπλέον, αν χρησιμοποιείς MyISAM μπορείς να δημιουργήσεις spatial indexes βασισμένα σε R-Trees για να επιταχύνεις τις αναζητήσεις. Έτσι μπορείς να εκτελέσεις εντολές όπως η παρακάτω για να πάρεις όλα τα σχήματα που περιέχονται σε ένα πολύγωνο:

mysql> SET @poly =
-> 'Polygon((30000 15000,31000 15000,31000 16000,30000 16000,30000 15000))';
mysql> SELECT fid,AsText(g) FROM geom WHERE
-> MBRContains(GeomFromText(@poly),g);

Στην δική σου περίπτωση θα έπρεπε να χρησιμοποιήσεις μάλλον την MBRIntersects για να φορτώσεις τα αντικείμενα που τέμνονται από το παράθυρο της εφαρμογής σου και όχι μόνο όσα περιέχονται πλήρως. Με τον τρόπο αυτό θα φορτώσεις μόνο τα σχήματα που χρειάζεσαι. Αν χρειαστεί να κάνεις zoom in δεν θα χρειαστεί να ξαναφορτώσεις τα αντικείμενα. Αν κάνεις zoom out υποθέτω ότι θα μπορούσες να χρησιμοποιήσεις ένα συνδυασμό Contains στο νέο παράθυρο και Not Contains στο παλιό για να φορτώσεις πάλι μόνο τα επιπλέον αντικείμενα. Δεν είμαι σίγουρος όμως αν αυτό όντως γίνεται ή αν θα ήταν γρηγορότερο από το να φορτώσεις απλά όλα τα αντικείμενα ξανά.

Ίσως μάλιστα ο ποιό γρήγορος τρόπος να είναι να φορτώσεις τα πάντα στη μνήμη και μετά να κάνεις queries κάθε φορά που γίνεται zoom ή click για να βρεις τα ID και μόνο των σχημάτων που σε ενδιαφέρουν! Αν για παράδειγμα έχεις λίγα πολύγωνα με πολλά σημεία, είναι πολύ πιο γρήγορο να διαβάσεις τα λίγα ID από τη βάση παρά τα πολλά σημεία ένα-ένα

Από εκεί και πέρα, αφού επιλέξεις τα σχήματα που χρειάζεσαι ο γρηγορότερος τρόπος είναι να χρησιμοποιήσεις ένα DataReader για να τα φορτώσεις γραμμή-γραμμή χωρίς περαιτέρω επεξεργασία. Δεν είμαι σίγουρος πως θα φέρει τα σχήματα ο .NET adapter που χρησιμοποιείς, αλλά σίγουρα μπορείς να τα επιστρέψεις ως string μέσω της AsText και μετά να τα κάνεις parse. Ή, αν θες να ελευθερώσεις τη σύνδεση με τη βάση όσο γίνεται γρηγορότερα, να τα αποθηκεύσεις προσωρινά σε ένα string array και μετά να κάνεις το parsing.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Παναγιώτης Καναβός:

Ή, αν θες να ελευθερώσεις τη σύνδεση με τη βάση όσο γίνεται γρηγορότερα, να τα αποθηκεύσεις προσωρινά σε ένα string array και μετά να κάνεις το parsing.

Τελικά αυτή ήταν η καλύτερη λύση.
Αποθηκεύω όλες τις πληροφορίες σε άνα string longtext στην βάσης με λογική σειρά και φορτώνω τα στοιχεία κατά την εκκίνηση του προγράμματος.
Επίσης οτιδήποτε αλλαγή κάνω στα στοιχεία φιλτραρω και στελνω για αλλαγή μόνο τα συγκεκριμένα και έτσι έχω ταχύτητα και στην αποθήκευση (δεν έχω ολοκληρώσει ακόμη αυτήν την δυνατότητα - εξηγώ παρακάτω).

Το μόνο που αντιμετωπίζω σαν πρόβλημα (εάν μπορεί να ειπωθεί έτσι) είναι ότι όταν θέλω να ενημερώσω το πεδίο longtext το δίνω πάλι όλο μαζί, υπάρχει τρόπος να προσθέσω στοιχεία?
π.χ εάν έχω πλήθος χαρακτήρων 300.000 και θέλω να προσθέσω ένα χαρακτήρα ακόμη να δώσω μόνο τον χαρακτήρα αυτό να κάνω δηλαδή add στο πεδίο της MySQL Database, αυτή την στιγμή ξαναδίνω όλους τoυς χαρακτήρες (300.001).

Τα στοιχεία που αποθηκεύω είναι ΜΟΝΟ αριθμοί, τα αλφαριθμητικά πεδία φορτώνονται από πίνακα βάση των ids, θέλω να ρωτήσω εάν ο τύπος πεδίου longtext είναι καλύτερος από τον τύπο longblob (στην συγκεκριμένη περίπτωση) σε θέματα ταχύτητας και εάν μπορώ να κάνω συμπίεση των δεδομένων?

Μάλλον τώρα έθεσα δύσκολα ερωτήματα, ευχαριστώ πάντως για τις απαντήσεις.

Δύσκολα όχι, ωστόσο η ερώτησή σου αφορά σε MySQL που δεν είναι μέσα στο ...scope των γνώσεων που έχουν οι περισσότεροι χρήστες εδώ. Περισσότερες πιθανότητες έχεις να βρεις απάντηση σε κάποιο forum σχετικό με MySQL.

---

Vir prudens non contra ventum mingit

Δεν έθεσες δύσκολη ερώτηση, απλά έπεσες στην ημέρα που ετοίμαζα την ομιλία για το DotNetZone event! Εξάλλου μη νομίζεις ότι είμαι και ειδικός σε MySQL. Δεν την έχω δουλέψει ΠΟΤΕ. Απλά έψαξα στο site της MySQL για τις απαντήσεις. Από την άλλη, έχω δουλέψει με GIS οπότε ... μυρίστηκα τί μπορεί να συνέβαινε στην αρχική ερώτηση. Οι ερωτήσεις που κάνεις αφορούν όλες τις βάσεις και providers, το θέμα κάθε φορά είναι αν το κάνει και πως το κάνει μία βάση.

Στα longtext, longblob τώρα. Έχεις δίκιο ότι χρειάζεται κάτι άλλο πέρα από το διάβασε τα όλα, γράψε τα όλα. O provider για SQL Server περιέχει την κλάση SqlBinary με την οποία μπορείς να προσθέσεις/τροποποιήσεις bytes αλλά και να ανοίξεις ένα stream πάνω στο blob. Την ίδια τακτική ακολουθούν και όσοι άλλοι providers έχουν αυτή τη δυνατότητα. Ο MySQL Connector .... δεν την έχει. Όπως λένε σε άπταιστα μαρκετίστικα "Has no special requirements to read/write blob data". Με άλλα λόγια, no streaming.

Ευτυχώς, υπάρχουν άλλοι providers οι οποίοι το κάνουν. Δες το dotConnect for MySQL της Devart, το οποίο έχει τις κλάσεις MySqlBlob και MySqlText για να χειριστεί blob και text αντίστοιχα. Και υποστηρίζει και EF, Linq to MySQL.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Δηλαδή εάν κατάλαβα καλά ή pay ή Sql Server Express (με τους περιορισμούς του).
Θα εκτιμηθούν ιδιαίτερα τα λεγόμενά σας, ελπίζω να μην έχω άλλες εκπλήξεις από τις δυνατότητες του MySQL ADO Connector.

No such thing as free lunch λένε οι Άγγλοι...

Τι εννοείς όταν λες "με τους περιορισμούς του";

---

Vir prudens non contra ventum mingit

KelMan:

Τι εννοείς όταν λες "με τους περιορισμούς του";

Εννοώ τον περιορισμό στον όγκο της βάσης (4GB εάν θυμάμαι καλά).
Αυτός ήταν ένας από τους λόγους που επέλεξα MySQL.

Η εφαρμογή έχει σχεδιαστεί μεταξύ άλλων να αποθηκεύει περίπου 2100 records το λεπτό σε table 8 αριθμητικών πεδίων. Με πρόχειρο υπολογισμό με τον SQL Server θα είχα δεδομένα περίπου για 2 μήνες και το ζητούμενο είναι τουλάχιστον για ένα έτος.

Και για να σε προλάβω, υπάρχει σοβαρός λόγος που η βάση πρέπει να είναι ΜΙΑ και δεν μπορώ να την "σπάσω" έτσι ώστε να κερδίσω σε χώρο.

Το ότι ο Connector της ίδιας της MySQL δεν παίζει ωραία με BLOB δεν σημαίνει ότι είναι για πέταμα η ίδια η βάση! Εδώ είναι που λένε Throwing out the baby with the bathwater!
Η απλούστερη λύση είναι να αγοράσεις το dotConnect της DevArt. Αν δεν θέλεις να το χρησιμοποιήσεις ίσως να υπάρχουν άλλοι μηχανισμοί για να πετύχεις αυτό που θες. Όπως σου είπε και ο Μάνος δεν είμαστε και οι ειδικοί στη MySQL. Απ' ότι βλέπω μπορείς να χρησιμοποιήσεις string manipulation functions με text πεδία. Θα μπορούσες π.χ. να χρησιμοποιήσεις την INSERT για να εισάγεις ένα μικρό string μέσα σε ένα πεδίο text. Τουλάχιστον έτσι γλυτώνεις να τραβήξεις τα δεδομένα στον client και να τα ξαναστείλεις στον server.

Αν όμως ο χειρισμός των blob είναι σημαντικός και δεις ότι δεν υπάρχει επαρκής υποστήριξη τότε ναι, αξίζει να κοιτάξεις άλλη βάση.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos