...Το ανεβασαμε...Τώρα πώς το "ελαφρώνουμε";;;;

[STEVEtheGREEK]

Δεν φαίνεται τίποτα από αυτό το "κουτάκι" αλλά και το διπλανό του (ένα καραβάκι!?) δεν έχει link.

Για κάνε τα .... κουμάντα σου

 

Επίσης η παρακάτω φωτό του κράνους είναι επιοικώς απαράδεκτη.ΜΙΚΡΥΝΕ ΤΗ

http://www.alahanion.gr/front_photos/do111B0.jpg

[vagpap]

Ψάχνεται κάτι; Google!!!

 

Σόρρυ αλλά εκεί έπεσε το μάτι μου, και με ενόχλησε λίγο περισσότερο από το πόσο αργεί η σελίδα, αν και δεν είναι δραματική η κατάσταση, τουλάχιστον για την πρώτη σελίδα.

 

Η επιλογή Home, τουλάχιστον σε μένα δεν πάει πουθενά. Ομοίως και το Chat.

Άντε και καλή συνέχεια

[bandito]

Θα πρέπει να επέμβεις στον κώδικα' date=' να μικρύνεις τις εικόνες, να αδειάσεις τη ΒΑΣΗ (με τη βάση θα δεις διαφορά στην ταχύτητα)...[/quote']

 

Το πόσο μέγεθος έχει μια βάση τι σχέση εχει με την ταχύτητα;

Και πώς αδειάζεις μια βάση που χρειάζεσαι;

[alkisg]

Α ρε bandito πάλι στα ίδια...

Anyway, μια sql select σε 1000000 εγγραφές ελπίζω να μπορείς να καταλάβεις ότι χρειάζεται πολύ περισσότερο χρόνο από μια sql select σε 10 εγγραφές.

 

Και αυτά τα είπα όταν δεν είχε δώσει η κοπέλα το site της, στη συνέχεια φάνηκε ότι είναι στατικό και άρα δεν τίθεται λόγος.

 

Και τέλος, ανάλογα με τα δεδομένα κάθε βάσης πάει και το άδειασμα. Π.χ. αρκετά fora αδειάζουν τα μηνύματα που είναι παλιότερα από π.χ. 5 χρόνια...

 

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

[panosru]

episeis an aparethtons thes kai tis 1000000 eggrafes sthn selida sou (kala oute mia sto ekatomyrio ayto alla leme tora) toulaxiston me php mporeis na kaneis header compression (diladi prin sthleis ta dedomena ston parser na ta sympieseis ) px ob_start(); me ena ob_gzhandler kai ob_end_flush();

[bandito]

Α ρε bandito πάλι στα ίδια...

Anyway' date=' μια sql select σε 1000000 εγγραφές ελπίζω να μπορείς να καταλάβεις ότι χρειάζεται πολύ περισσότερο χρόνο από μια sql select σε 10 εγγραφές.

 

Και αυτά τα είπα όταν δεν είχε δώσει η κοπέλα το site της, στη συνέχεια φάνηκε ότι είναι στατικό και άρα δεν τίθεται λόγος.

 

Και τέλος, ανάλογα με τα δεδομένα κάθε βάσης πάει και το άδειασμα. Π.χ. αρκετά fora αδειάζουν τα μηνύματα που είναι παλιότερα από π.χ. 5 χρόνια...

 

Αυτά, δεν έχω καμία όρεξη να ξανακάνω συζήτηση μαζί σου, ας μείνει εδώ.[/quote']

 

Οι βάσεις χρησιμοποιούν indexes.

Ενα select που χρησιμοποιεί key σε μια βάση 10 εγγραφών

π.χ select * from aTinyTinyTable where id = 8 , παιρνει ακριβώς το ίδιο σε μια βάση 1000000000000 εγγραφών. Όταν η βάση σου αργεί ΔΕΝ την αδειάζεις, αλλά την γράφεις καλυτερα.

 

real world example

Απο την βάση δεδομένων του skroutz

Πινακας searchstats:

>
mysql> select count(*) from searchstats;
+----------+
| count(*) |
+----------+
|   664764 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from searchstats2;
+----------+
| count(*) |
+----------+
|      100 |
+----------+
1 row in set (0.00 sec)

 

664.000 εγγραφες ο ενας, 100 μολις ο άλλος.

το ID ειναι primary key

 

>
mysql> select id, dateofsearch from searchstats where id = 80;
+----+---------------------+
| id | dateofsearch        |
+----+---------------------+
| 80 | 2006-01-13 01:04:08 |
+----+---------------------+
1 row in set (0.00 sec)

mysql> select id, dateofsearch from searchstats2 where id = 80;
+----+---------------------+
| id | dateofsearch        |
+----+---------------------+
| 80 | 2006-01-13 01:04:08 |
+----+---------------------+
1 row in set (0.00 sec)

 

Ο ιδιος χρονος αναζητησης. Το phpmyadmin δίνει 0,4ms και για τα δυο queries.

Γιατι συμβαίνει αυτο;

Η Mysql το εξηγει...

 

>
mysql> explain select id, dateofsearch from searchstats where id = 80;
+----+-------------+-------------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table       | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | searchstats | const | PRIMARY       | PRIMARY | 8       | const |    1 |       |
+----+-------------+-------------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)

 

Στον πίνακα με τις 640.000 εγγραφές, δεν έκανε serial search, αλλα πηγε κατευθείαν στην εγγραφή που ήξερε οτι βρίσκεται στην θεση 80.

Συμπέρασμα 1: Είτε 1 gazillion εγγραφες είτε 10 η αναζήτηση με βάση keys ειναι ίδια ή με απειροελάχιστη διαφορά , τόση που την περιορίζει το block transfer. Αν το select επεστρεφε 100 εγγραφές, ο επεξεργαστής, το dma, οι δίσκοι κτλ θα χρειαζόνταν περισσότερο χρόνο να μεταφερει τις 100 εγγραφές παρά να πάει στο σωστο LBA (+ ο χρονος αυτος ειναι ίδιος και για 10 και για 1δις εγγραφές anyway...)

 

Σε ενα forum, για παράδειγμα το vbulletin, υπάρχει περίπτωση να χρησιμοποιηθεί non-indexed select , update? Σε μια περίπτωση μόνο: σε αυτή την αναζήτησης με wildcards. Σε όλες τις άλλες περιπτώσεις καποιο index θα αναλάβει να κάνει την δουλειά.

 

Το ίδιο ισχύει για updates όταν δεν γινεται update το index.

Για inserts , εξαρτάται πολύ απο το είδος του index.

Σε full text index, στον σκρουτζ σε 400.000 records η ταχύτητα εισαγωγής υποδιπλασιαστηκε. Σε όλες τις περιπτώσεις μιλάμε για χρόνους, που το network transfer τους ακυρώνει (π.χ 0,8 ms όταν με 100.000 records ήταν στα 0,4ms).

 

Συμπέρασμα 2: Αν η βάση μας αργεί, την γράφουμε σωστα, δεν την αδειάζουμε.

 

Και στο παραδειγμα αυτο, μιλαω για mysql.

Αν εξετάσουμε καποια βάση περισσότερο optimized, οπως η oracle τα πράγματα αλλάζουν ακόμα περισσότερο. H oracle υποστηρίζει indexes ακομα και οταν κανεις search με like (και οχι μονο η oracle), Εκει ακομα και η αναζητηση με wildcards , μπορει να έχει ελάχιστη διαφορά για εκατομμύρια records.

Και οπως πάντα η διαφορά ειναι τόση που την ακυρώνει το bottleneck του δικτου.

 

Τα ίδια ισχύουν για τα joins.

Tα join ειναι πολύ χαμηλά στο optimization tree, θα γίνουν τελευταια, και τις περισσότερες φορές σε πολύ λίγες εγγραφές.

Οπότε, το μέγεθος του πίνακα δεν έχει πάλι καμια διαφορά.

 

My 2 cents

 

P.S O server του skroutz ειναι ένας ταπεινος server με απλους serial ata δισκους, 1gb μνήμη, [email protected] cpu.

Την ώρα των αναζητησεων, το site έπαιζε κανονικά και στο backround έτρεχαν 5-10 spiders.

H mysql ειναι 5.0.18, και το λειτουργικό gentoo-2.6.11

[anna1976]

Σόρρυ αλλά εκεί έπεσε το μάτι μου' date=' και με ενόχλησε λίγο περισσότερο από το πόσο αργεί η σελίδα, αν και δεν είναι δραματική η κατάσταση, τουλάχιστον για την πρώτη σελίδα.

 

Η επιλογή Home, τουλάχιστον σε μένα δεν πάει πουθενά. Ομοίως και το Chat.

Άντε και καλή συνέχεια

 

Thx για τις επισημάνσεις σου.... Τα διόρθωσα... Και να σου πώ κάτι για τα ορθογραφικά λαθη... Απο τότε που "βγήκε" ο ορθογραφικός έλεγχος του WORD πολλά ξεχάστηκαν.....

Ευχαριστώ και πάλι !!!

[anna1976]

Οι βάσεις χρησιμοποιούν indexes.

Ενα select που χρησιμοποιεί key σε μια βάση 10 εγγραφών

........και στο backround έτρεχαν 5-10 spiders.

H mysql ειναι 5.0.18' date=' και το λειτουργικό gentoo-2.6.11[/quote']

 

Ωρέ κοπέλια, μην σφαχτούμε κιόλας.... Μια ερώτηση έκανα....Βεντέτα θα καταλήξει ;;;;;

[stoidis]

 

Συμπέρασμα 1: Είτε 1 gazillion εγγραφες είτε 10 η αναζήτηση με βάση keys ειναι ίδια ή με απειροελάχιστη διαφορά ' date=' τόση που την περιορίζει το block transfer.

[b']Συμπέρασμα 2[/b]: Αν η βάση μας αργεί, την γράφουμε σωστα, δεν την αδειάζουμε.

 

 

Χαίρομαι να βλέπω τέτοια posts στο Insomnia

[alkisg]

Τέλος πάντων... Bandito ευτυχώς στα νιάτα μου είχα κι εγώ σπουδάσει βάσεις δεδομένων, optimization trees και τα σχετικά... Αρκετά από αυτά που γράφεις ισχύουν, αλλά τα συμπεράσματά σου είναι λάθος (π.χ. επειδή άλλοτε δεν υπάρχουν indexes στο συγκεκριμένο πεδίο αναζήτησης, άλλοτε επειδή η select είναι πολύ γενική και επιστρέφει μεγάλο μέγεθος εγγραφών κτλ).

 

Δεν έχω το χρόνο να ξανασχοληθώ με τη συγκέντρωση επιστημονικών δεδομένων για να σε πείσω. Να αναφέρω μόνο ότι όλα σχεδόν τα CMS έχουν επιλογή για επιλεκτικό άδειασμα βάσης, ε, αν δεν εμπιστεύεσαι κάποιον άσχετο σε ένα forum (δλδ εμένα) εμπιστέψου τους προγραμματιστές CMS που για κάποιον μυστήριο λόγο θεωρούν αναγκαία αυτή τη λειτουργία. Άσε που ακριβώς επειδή το μέγεθος της βάσης παίζει ρόλο, υπάρχουν και λειτουργίες caching στα ερωτήματα... Κάνε δυο ίδια συνεχόμενα search εδώ στο insomnia, θα δεις ότι ο αριθμός ερωτήματος είναι ο ίδιος γιατί το vbulleting το κρατάει σε cache...

 

Anyway, αρκετά με το offtopic και τις αντιπαραθέσεις/επιδείξεις γνώσεων, έχουμε και οι δύο πιο χρήσιμα πράγματα να ασχοληθούμε...

 

White flag accepted!

[panosru]

@bandito : o alkisg an katalaba kala enoouse na bazoume ena LIMIT sta sql query mas etsi oste na mhn trabame amesos oles tis eggrafes mas os apotelesma na mhn kathisterei h selida mas. episeis oson afora to Συμπέρασμα 2 eymfono 1000%!!! den ftaine ta systhmata pou argoune alla oi baseis tous pou einai lathos gramena!

[anna1976]

Εγώ μια ταπεινή πλήν τίμια ερώτηση έκανα, και βρέθηκα μάρτυρας στο συνέδριο της ΝΑΣΑ !!!!! Ήμαρτον Κύριε.....

[tenten99]

kai den exeis akousei tipota akoma 8a ta poume thn deutera

apoliese