κατασκευή website με multilanguage

Σε αυτή την περιοχή μπορείτε να βρείτε ή να αναζητήσετε πληροφορίες σχετικές με την PHP

Συντονιστές: WebDev Moderators, Super-Moderators, PHP Moderators

gvre
Δημοσιεύσεις: 992
Εγγραφή: 14 Οκτ 2010 11:34
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από gvre » 15 Μαρ 2013 22:04

Πολύ ωραία τα είπες :) Το μόνο που έχω να προσθέσω είναι ότι το case 3 θα είναι ακόμα γρηγορότερο αν ξεκινήσεις τα joins με τις κατηγορίες (και με ενότητες αν έχεις). Επίσης, χρειάζεσαι ακόμα ένα πεδίο id (ίδιο για όλες τις γλωσσικές εκδόσεις κάθε περιεχομένου), το οποίο θα σου δίνει τη δυνατότητα να τραβήξεις τις μεταφράσεις κάποιου item σε άλλη γλώσσα. Γενικά θα προσθέσει μια μικρή πολυπλοκότητα στη διαχείριση, αλλά αξίζει τον κόπο όταν θέλεις να εξυπηρετήσεις πολλούς επισκέπτες (υπάρχει και η λύση του caching βέβαια).

Το case 1 το θεωρώ μπακαλίστικο και το προσπερνάω.
Στο case 2 μπορείς να καταργήσεις το πεδίο id από τον πίνακα translations_items και να χρησιμοποιήσεις ως pk τα πεδία item_id και lang_id.
Βλέπω ότι οι πίνακές σου είναι MyISAM (όχι και ό,τι καλύτερο). Μπορείς να το τρέξεις και σε InnoDB;

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από burnmind » 15 Μαρ 2013 23:44

Τα 1 & 2 βασίστηκαν στα παραδείγματα που υπήρχαν ήδη στη συζήτηση που προηγήθηκε, και πρόσθεσα το 3ο σαν μία ακόμα επιλογή (εναλλακτική του 1).

Το ότι (όλα) μπορούν να βελτιωθούν και ότι σε ένα πραγματικό σενάριο θα υπάρχουν και άλλα fields, joins με κατηγορίες κλπ, είναι σίγουρο. Για τις ανάγκες του συγκεκριμένου test, νομίζω πως επαρκούν. :)

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

Άβαταρ μέλους
dva_dev
Script Master
Δημοσιεύσεις: 3790
Εγγραφή: 16 Σεπ 2005 01:32
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από dva_dev » 16 Μαρ 2013 00:37

Στο case 3 έχεις παραλείψει να βάλεις στον πίνακα items το πεδίο για το itemid (θέλεις το προϊόν με itemid=50000 σε lang=1 και μετά θέλεις το ίδιο προϊόν άρα πάλι itemid=50000 σε lang=2
To πεδίο id όπως το έχεις τώρα δεν κάνει τη δουλειά που χρειάζεσαι γιατί μπορεί να βρεί το id=50000 and lang=1 αλλά όχι το id=50000 and lang=2 αφού αν καταχωρήσεις τη μετάφραση θα πάρει άλλο id (π.χ. 50001)

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από burnmind » 16 Μαρ 2013 01:35

Αν και είμαι αρκετά κουρασμένος για να σκεφτώ καθαρά αυτή τη στιγμή, νομίζω πως είναι σωστό. Μόνο το "AND lang_id=1" είναι περιττό στο query (τουλάχιστον για το συγκεκριμένο παράδειγμα), καθώς υποτίθεται πως στο συγκεκριμένο case, το κάθε record αφορά μόνο μία γλώσσα, και δεν έχει σχέση με τα υπόλοιπα.

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

Εκεί που έχω κάνει λάθος σίγουρα, είναι ότι με την παραπάνω λογική, θα έπρεπε να είχε 200.000 records και όχι 100.000, άρα θα πιάνει πολύ περισσότερο χώρο στη βάση. Θα το ξαναδώ μόλις βρω χρόνο και θα διορθώσω τα νούμερα.

Apostolis_38
Δημοσιεύσεις: 1969
Εγγραφή: 14 Φεβ 2008 16:20
Τοποθεσία: ΠΕΙΡΑΙΑΣ

κατασκευή website με multilanguage

Δημοσίευση από Apostolis_38 » 16 Μαρ 2013 13:41

Αξιος ο burnmind :pint:

gvre έγραψε:Τα queries τα γράφεις μια φορά. Δεν έχει σημασία αν είναι 1 ή 3 γραμμές.
Εδώ είναι το θέμα.
Εχει σημασία αν είναι 1 ή 3 ή 10 γραμμές.
3 γραμμές για το select, άλλες 3 για το insert, άλλες 3 για το delete, άλλες 3 αν τύχει να κρέμεται κάποιο αρχείο από το πεδίο και θες να το τσεκάρεις για να ειδοποιήσεις το χρήστη, βάλε και το unlink...αρχίζει και ξεφεύγει το θέμα για έναν και μόνο πίνακα.

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

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από burnmind » 16 Μαρ 2013 14:38

Δυστυχώς το edit δε λειτουργεί, άρα δε μπορώ να διορθώσω το αρχικό post, οπότε θα τα γράψω εδώ:

Κατ' αρχήν, όπως ανέφερα στο προηγούμενο post, έκανα λάθος στο πλήθος των records του case 3, καθώς αφού υποτίθεται πως το κάθε record ανήκει μόνο σε μία κατηγορία (και υπάρχει διπλό περιεχόμενο), θα έπρεπε να έχει 200.000 records και όχι 100.000. Με 200.000 records λοιπόν, τα νούμερά του μεταβάλλονται σε 522.7 MB χώρο στη βάση (αφού πλέον έχει τις διπλάσιες εγγραφές από τις άλλες λύσεις), και περίπου 0.2824 milliseconds για το κάθε query (0.28238017559052 seconds ο μέσος όρος των 1000).

Το structure του (νομίζω πως) είναι σωστό γι' αυτό που θέλουμε να μετρηθεί και αυτό που θέλουμε να δείξει (ένα απλό query για ένα record για το οποίο ξέρουμε ήδη το id). Όπως ανέφερα ήδη, ταιριάζει περισσότερο σε περιπτώσεις που το περιεχόμενο είναι ανεξάρτητο μεταξύ του, λόγω του duplicate content αλλά και της μη άμεσης συσχέτισης μεταξύ των εγγραφών, που όμως μπορεί να λυθεί με κάποια λύση όπως πχ ενός grouping table.
Το case 3, είναι εξίσου γρήγορο με το 1, είναι ευέλικτο λόγω του ότι δεν το ενοχλεί αν προστεθούν γλώσσες ή/και fields, αλλά πάσχει στο ότι υπάρχουν duplicate data τα οποία από θέμα χώρου δε μας ενδιαφέρουν καθώς η διαφορά είναι ελάχιστη, αλλά αν σε οποιοδήποτε update πρέπει να αλλάζουν σε κάθε χώρα, είναι πρόβλημα.
Πλέον το case 3 είναι ελάχιστα πιο αργό από το 1 (η διαφορά είναι πολύ μικρή όμως), και μας ενδιαφέρει ο χώρος που λόγω των διπλών εγγραφών διπλασιάζεται, αλλά εξακολουθεί να αποτελεί μια καλή λύση για τις περιπτώσεις που ανέφερα πριν. Ούτως ή άλλως, δεν ταίριαζε ποτέ σε μια λύση από αυτές που καλύπτει το case 2.

Έπειτα από τις παραπάνω αλλαγές, μετέτρεψα τις βάσεις σε InnoDB (από MyISAM), όπως είχε προτείνει ο gvre. Για να μη ξαναπερνάω τα δεδομένα από την αρχή, το έκανα με ένα "ALTER TABLE tablename ENGINE = INNODB" για τον κάθε table.

Χώρος στον δίσκο:

Case 1: 313.8 MB
Case 1: 317.3 MB
Case 3: 627.0 MB

Χρόνος Queries:

Case 1: ~0.2181 milliseconds το ένα (0.21814720630646 seconds ο μ.ο. των 1000)
Case 2: ~5.7591 seconds το ένα (εννοείται πως δεν τόλμησα να τρέξω για 1000)
Case 3: ~0.2207 milliseconds το ένα (0.22068200111389 seconds ο μ.ο. των 1000)

Αρχικά πίστεψα πως έχω κάνει κάτι πολύ λάθος στη μετατροπή σε InnoDB στο 2ο, αλλά τα δεδομένα φαίνονται σωστά με κάποια random queries που έκανα, και ο χρόνος του query δεν έπεσε, παρά μόνο ελάχιστα, όσες αλλαγές και αν δοκίμασα στο αρχικό query. Δεν αποκλείω ακόμα το λάθος, αλλά διαβάζοντας κάποια πράγματα, έπεσα πάνω σε αυτό που αναφέρει επιγγραμματικά πως η Innodb χρειάζεται αρκετό tuning για να λειτουργήσει σωστά σε μεγάλους πίνακες ώστε να κάνει γρήγορο sorting κλπ, οπότε πιστεύω πως φταίνε οι default ρυθμίσεις που έχω αφήσει για την τόσο μεγάλη διαφορά σε σχέση με τα νούμερα της MyISAM. Αν κάποιος ξέρει κάτι παραπάνω ας το γράψει.

gvre
Δημοσιεύσεις: 992
Εγγραφή: 14 Οκτ 2010 11:34
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από gvre » 16 Μαρ 2013 20:44

@burnmind Το 1 δεν το είπα για εσένα, απλά τη θεωρώ μπακαλίστικη λύση. Αυτό με το extra id στο case 3 είναι αυτό που έγραψε και ο dva_dev. Το ανέφερα απλά για την περίπτωση που κάποιος θέλει να εφαρμόσει τη συγκεκριμένη υλοποίηση. Στον πίνακα translations_items δεν έχεις φτιάξει indexes. Δοκίμασε να σβήσεις το πεδίο id, κάνε primary key τα (item_id, lang_id με αυτή τη σειρά) και δοκίμασε ξανά. Αν καθυστερεί, τρέξε το query με explain στην αρχή για να δεις αν χρησιμοποιεί indexes. Αν μπορείς, ενεργοποίησε το query cache της mysql και τρέξε το ξανά.

@Apostolis_38 Δεν έχει σημασία αν είναι 1 ή 3 γραμμές. Τα γράφεις σωστά μια φορά, τρέχουν πάρα πολλές φορές και καλύπτουν όλες τις ανάγκες. Η μόνη διαφορά έχει να κάνει με την απόδοση σε περίπτωση πολλαπλών joins, κάτι το οποίο στις περισσότερες περιπτώσεις δε γίνεται καν αντιληπτό. Αν χρειαστεί να γίνει ταχύτερο, προσθέτεις caching και κάνεις τη δουλειά σου. Ειδικά τα inserts στις περισσότερες περιπτώσεις είναι πολύ λιγότερα από τα selects. Το να γράψεις σωστό software έχει πολύ μεγάλη σχέση με τη συντηρησιμότητα και την επεκτασιμότητά του. Δε νομίζω για κάθε πελάτη να έχεις και άλλη έκδοση του προγράμματός σου.

Apostolis_38
Δημοσιεύσεις: 1969
Εγγραφή: 14 Φεβ 2008 16:20
Τοποθεσία: ΠΕΙΡΑΙΑΣ

κατασκευή website με multilanguage

Δημοσίευση από Apostolis_38 » 16 Μαρ 2013 21:16

gvre έγραψε: Δε νομίζω για κάθε πελάτη να έχεις και άλλη έκδοση του προγράμματός σου.
Φυσικά και ναι man :wink:
Εχω μια βάση και τροποποιώ ανάλογα με το τι θέλει και τι πληρώνει ο πελάτης.
Εν πάσει περιπτώσει, έχω διαφορετική άποψη στο συγκεκριμένο θέμα και νομίζω οτι αρκετά ξεφύγαμε από το topic οπότε σταματάω εδώ.
Αλλωστε αυτό που κάνει o burnmind έχει ενδιαφέρον :)

gvre
Δημοσιεύσεις: 992
Εγγραφή: 14 Οκτ 2010 11:34
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από gvre » 16 Μαρ 2013 21:22

no prob :) Συζήτηση κάνουμε.

Άβαταρ μέλους
korgr
Honorary Member
Δημοσιεύσεις: 5067
Εγγραφή: 07 Οκτ 2008 18:30
Τοποθεσία: Corinth
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από korgr » 16 Μαρ 2013 21:43

Και ας μην ξεχνάμε πως στο μέσο όρο των sites οι πίνακες δεν ξεπερνούν τις 1000 εγγραφές!
Φυσικά όταν σου τύχει η περίπτωση πολλών δεδομένων θα ασχοληθείς ιδιαιτέρως με το tuning της βάσης.

Άβαταρ μέλους
jpk
Δημοσιεύσεις: 441
Εγγραφή: 09 Μαρ 2011 21:17

κατασκευή website με multilanguage

Δημοσίευση από jpk » 16 Μαρ 2013 21:56

Δεν υπάρχουν φυσικά μόνο αυτές οι τρεις δομές δεδομένων που εξετάζει ο burnmind υπάρχουν και πολλές ακόμα που κάποιες αυτές που μου έρχονται στο μυαλό σχετίζονται με τις προαναφερθείσες , άλλες πάλι όχι.

Όσο για το InnoDB vs MyISAM που θέτεις burnmind δεν θα μπορούσα να πω ότι δεν υπάρχει ξεκάθαρη απάντηση που έχει να κάνει μόνο με τις ρυθμίσεις. Το έχω ξαναδιαβάσει εδώ ότι υπάρχει η άποψη ότι γενικά το InnoDb engine είναι καλύτερο, αλλά εξαρτάτε από τα specs, αν ήταν τόσο απλό ποτέ δεν θα χρησιμοποιούσαμε MyISAM.

Φυσικά και στο ερώτημα υπάρχουν πολλές προσεγγίσεις. Την απλούστερη κατ’ εμέ δεν είπαμε όμως. Το να πεις ότι είναι διαφορετικά app ανά subdomain – γλώσσα, και να αντιμετωπίσεις το θέμα με διαφορετική βάση ανά subdomain.

Παλιότερα είχα αντιμετωπίσει το θέμα έτσι ( και με suffixes σε tables ) αν και ήξερα ότι απλά παρακάμπτω άκουσα πολύ σωστές απόψεις από εδώ και κατάλαβα ότι και σε αυτό πρέπει να υπάρχει λογική οντότητας (ένας από τους λόγους που είμαι εδώ). Μπορεί η λογική οντότητας να μην λέχθηκε έτσι και δεν θα μπω στο να την εξηγήσω περεταίρω μιας και κάπου γειτνιάζει με το 3 σενάριο του burnmind αλλά σίγουρα υπάρχουν δυο διαφορετικές δομές – προγράμματα που φτιάχνουμε για την περιοχή διαχείρισης .

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

Άβαταρ μέλους
burnmind
Script Master
Δημοσιεύσεις: 954
Εγγραφή: 26 Σεπ 2009 02:14
Τοποθεσία: UK
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από burnmind » 16 Μαρ 2013 22:12

@gvre: Ναι, κατάλαβα για το 1, συμφωνούμε άλλωστε, απλά διευκρίνησα πως υπήρχε ήδη στη συζήτηση και πως εκεί πάτησα για το test. :)

Είπα να μη δοκιμάσω το double primary key (μεγάλος fan btw) γιατί ήμουν πεπεισμένος πως κάτι πάει στραβά με το InnoDB στην εγκατάστασή μου για να έχει τέτοια τεράστια διαφορά στην απόδοση, αλλά τελικά δεν είχα δίκιο:

Κώδικας: Επιλογή όλων

CREATE TABLE IF NOT EXISTS `translations_items` (
  `item_id` int(10) NOT NULL,
  `lang_id` int(3) NOT NULL,
  `name` varchar(1000) NOT NULL,
  `description` text NOT NULL,
  PRIMARY KEY (`item_id`,`lang_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Χώρος: 362.5 MB

Με το ίδιο query με πριν, 0.24136590957642 seconds μ.ο. στα 1000 => ~0.2414 milliseconds το ένα. Δοκίμασα και με left join (το συμπαθώ περισσότερο από το select από πολλαπλούς πίνακες), αλλά η διαφορά ήταν ελάχιστη (~0.2405 ms).

Να και τα αποτελέσματα σε MyISAM:

260.9 MB και ~0.2480 ms (0.24801681041717 sec τα 1000).

@korgr: Εννοείται πως οι 100k εγγραφές είναι πολλές για ένα μέσο site, απλά είναι πιο εύκολο να δεις διαφορές σε tests με τέτοια νούμερα. Για τα περισσότερα sites η συζήτηση για performance είναι ανούσια λόγω των σχετικά λίγων εγγραφών και του χαμηλού (ταυτόχρονου) traffic. :)

@jpk: Καλά, όσον αφορά το MyISAM vs InnoDB (όλο πάω να πατήσω submit και υπάρχει καινούριο post :lol:), η συζήτηση είναι τεράστια. Υπάρχουν πολλά άλλα θέματα εκτός του απλού performance όπως foreign keys, data integrity, table locking, full text search, κλπ.

Γενικά όπως είπες κι εσύ και οι υπόλοιποι, υπάρχουν τόσες διαφορερετικές προσεγγίσεις που πραγματικά η "σωστή" απάντηση (ΑΝ υπάρχει) στη δομή της βάσης, στην επιλογή του engine κλπ μπορεί να γίνει μόνο μετά από αρκετή μελέτη και ανάλυση για το συγκεκριμένο project που πρέπει να υλοποιήσεις τη συγκεκριμένη φορά. Αυτό που έχει ιδιαίτερη σημασία, όποια επιλογή και να κάνουμε, είναι να σκεφτόμαστε πάντα το μέλλον και την επεκτασιμότητα της λύσης που θα επιλέξουμε (γι' αυτό "πετάμε" το case 1 :P ).

gvre
Δημοσιεύσεις: 992
Εγγραφή: 14 Οκτ 2010 11:34
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από gvre » 16 Μαρ 2013 22:26

Υπάρχει ένα συγκριτικό μεταξύ MyISAM και InnoDB. Παλιότερα ο μόνος λόγος χρήσης (για εμένα) του MyISAM ήταν το fulltext search (ήταν ένας από τους λόγους που πέρασα από MySQL σε PostgreSQL). Βλέπω τώρα ότι έχει προστεθεί και στο InnoDB. Από την MySQL 5.5 και μετά, το default database engine είναι το InnoDB.

@burnmind Το select από πολλαπλούς πίνακες είναι αντίστοιχο του inner join (συνήθως σε τέτοιες περιπτώσεις χρειάζεσαι αυτό αντί του left join).

@jpk Σενάριο (συμβαίνει σχετικά συχνά). Φτιάχνεις το site σε μια γλώσσα με το μονόγλωσσο CMS. Μετά από x διάστημα σου λέει ο πελάτης ότι θέλει κι άλλη γλώσσα. Τι κάνεις;

Άβαταρ μέλους
jpk
Δημοσιεύσεις: 441
Εγγραφή: 09 Μαρ 2011 21:17

κατασκευή website με multilanguage

Δημοσίευση από jpk » 16 Μαρ 2013 22:30

gvre μου έχει συμβεί πάνω από μια φορά για αυτό έχω και job να τα κάνει αυτόματα. Παρ’ όλα αυτά δεν θα θυσίαζα την απλότητα ενός μονόγλωσσου CMS γιατί κάποτε ο πελάτης μπορεί να θέλει πολύγλωσσο. Είναι τόσο απλό να κάνω data integration που δεν έχω λόγο να μην έχω σαφέστατο διαχωρισμό μεταξύ ενός μονόγλωσσου CMS και ενός πολύγλωσσου.

gvre
Δημοσιεύσεις: 992
Εγγραφή: 14 Οκτ 2010 11:34
Τοποθεσία: Ηράκλειο Κρήτης
Επικοινωνία:

κατασκευή website με multilanguage

Δημοσίευση από gvre » 16 Μαρ 2013 22:35

Δε βλέπω κάποια διαφορά στην απλότητα του CMS όταν είναι μονόγλωσσο σε σχέση με όταν είναι πολύγλωσσο. Στη 2η περίπτωση αντί να έχει μια καρτέλα (πχ ελληνικά) έχει επιπλέον καρτέλες με τις υπόλοιπες γλώσσες.
Το βασικότερο πρόβλημα δεν είναι τόσο το data integration όσο το ότι πρέπει να συντηρείς 2 διαφορετικά συστήματα χωρίς ουσιαστικό λόγο.

Απάντηση

Επιστροφή στο “PHP Προγραμματισμός”

Μέλη σε σύνδεση

Μέλη σε αυτήν τη Δ. Συζήτηση: Δεν υπάρχουν εγγεγραμμένα μέλη και 2 επισκέπτες