Πόσο μεγάλη μπορεί μια βάση δεδομένων MySQL πάρει πριν από την έναρξη των επιδόσεων να υποβαθμίσει

ψήφοι
253

Σε ποιο σημείο έχει μια βάση δεδομένων MySQL αρχίζουν να χάνουν τις επιδόσεις;

  • Μήπως φυσικό μέγεθος της βάσης δεδομένων έχει σημασία;
  • Να αριθμός εγγραφών έχει σημασία;
  • Υπάρχει επιδόσεις γραμμική υποβάθμιση ή εκθετική;

Έχω αυτό που πιστεύω ότι είναι μια μεγάλη βάση δεδομένων, με περίπου τα αρχεία 15M, που καταλαμβάνουν σχεδόν 2GB. Με βάση αυτούς τους αριθμούς, είναι κάθε κίνητρο για μένα να καθαρίσετε τα στοιχεία έξω, ή να είμαι ασφαλής ώστε να μπορέσει να συνεχίσει την κλιμάκωση για μερικά ακόμη χρόνια εκεί;

Δημοσιεύθηκε 04/08/2008 στις 15:31
πηγή χρήστη
Σε άλλες γλώσσες...                            


13 απαντήσεις

ψήφοι
169

Το φυσικό μέγεθος της βάσης δεδομένων δεν έχει σημασία. Ο αριθμός των εγγραφών δεν έχουν σημασία.

Σύμφωνα με την εμπειρία μου, το μεγαλύτερο πρόβλημα που θα έχετε την ευκαιρία να τρέξει για να είναι όχι το μέγεθος, αλλά ο αριθμός των ερωτήσεων που μπορεί να χειριστεί κάθε φορά. Το πιο πιθανό θα έχετε την ευκαιρία να χρειαστεί να προχωρήσουμε σε μια ρύθμιση παραμέτρων master / slave, έτσι ώστε τα ερωτήματα ανάγνωσης μπορεί να τρέξει ενάντια στους δούλους και τα ερωτήματα εγγραφής τρέχει κατά του πλοιάρχου. Ωστόσο, αν δεν είστε έτοιμοι για αυτό ακόμα, μπορείτε πάντα να τσίμπημα δείκτες σας για τα ερωτήματα που χρησιμοποιείτε για να επιταχύνει τους χρόνους απόκρισης. Επίσης, υπάρχει πολλή μικροαλλαγές που μπορείτε να κάνετε στη στοίβα δικτύου και του πυρήνα στο Linux, που θα σας βοηθήσουν.

Είχα δικό μου πάρει μέχρι και 10GB, με μόνο ένα μέτριο αριθμό των συνδέσεων και να τα παραδίδει τα αιτήματα μια χαρά.

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

Απαντήθηκε 04/08/2008 στις 16:26
πηγή χρήστη

ψήφοι
71

Σε γενικές γραμμές αυτό είναι ένα πολύ λεπτό θέμα και όχι απολύτως ασήμαντο. Σας ενθαρρύνω να διαβάσετε mysqlperformanceblog.com και MySQL υψηλής απόδοσης . Πιστεύω πραγματικά ότι δεν υπάρχει γενική απάντηση για αυτό.

Είμαι εργάζονται για ένα έργο το οποίο έχει μια βάση δεδομένων MySQL με σχεδόν 1TB δεδομένων. Ο πιο σημαντικός παράγοντας κλιμάκωσης είναι RAM. Αν οι δείκτες των πινάκων σας ταιριάζει στη μνήμη και τις απορίες σας ιδιαίτερα αισιόδοξος, μπορείτε να εξυπηρετήσει ένα εύλογο ποσό των αιτήσεων με ένα μέσο μηχάνημα.

Ο αριθμός των εγγραφών έχουν σημασία, ανάλογα με το πώς τραπέζια σας μοιάζουν. Είναι μια διαφορά να έχει πολλά πεδία varchar ή μόνο μια-δυο ints ή λαχταρά.

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

Υπάρχουν πολλά σε αυτό ζητήματα και όπως και σε πολλές περιπτώσεις ο διάβολος κρύβεται στις λεπτομέρειες.

Απαντήθηκε 04/08/2008 στις 19:44
πηγή χρήστη

ψήφοι
33

Το μέγεθος της βάσης δεδομένων έχει σημασία . Αν έχετε περισσότερα από ένα τραπέζι με περισσότερους από ένα εκατομμύριο εγγραφές, στη συνέχεια, την απόδοση αρχίζει πράγματι να υποβαθμίσει. Ο αριθμός των εγγραφών κάνει, φυσικά, να επηρεάσει την απόδοση: MySQL μπορεί να είναι αργή με μεγάλα τραπέζια . Αν χτυπήσει ένα εκατομμύριο εγγραφές θα έχετε προβλήματα απόδοσης, εάν οι δείκτες δεν έχουν ρυθμιστεί σωστά (π.χ. δεν δείκτες για τομείς στους «ΟΠΟΥ δηλώσεις» ή «ON συνθήκες» στην ενώνει). Αν χτυπήσει 10 εκατομμύρια εγγραφές, θα αρχίσετε να έχετε προβλήματα απόδοσης, ακόμη και αν έχετε όλα δείκτες σας σωστά. Αναβάθμιση του hardware - προσθέτοντας περισσότερη μνήμη και περισσότερη δύναμη επεξεργαστή, ειδικά μνήμης - συχνά να βοηθήσει να μειώσει τα πιο σοβαρά προβλήματα με την αύξηση της απόδοσης και πάλι, τουλάχιστον σε κάποιο βαθμό. Για παράδειγμα 37 σήματα πήγε από 32 GB RAM και 128 GB της μνήμης RAM για το διακομιστή της βάσης δεδομένων Basecamp.

Απαντήθηκε 26/01/2012 στις 11:33
πηγή χρήστη

ψήφοι
20

Θα ήθελα να επικεντρωθούν πρώτα στις πινακίδες σας, από ό, τι έχετε ένα διακομιστή διαχειριστή ματιά στο λειτουργικό σας σύστημα, και αν όλα αυτά δεν θα βοηθήσει ίσως ήρθε η ώρα για τη διαμόρφωση master / slave.

Αυτό είναι αλήθεια. Ένα άλλο πράγμα που λειτουργεί συνήθως είναι να μειωθεί μόνο την ποσότητα των δεδομένων που είναι κατ 'επανάληψη συνεργαστεί με. Αν έχετε «παλιά δεδομένα» και «νέα δεδομένα» και το 99% των ερωτημάτων σας να δουλεύουν με νέα δεδομένα, απλά μετακινήστε όλα τα παλιά δεδομένα σε έναν άλλο πίνακα - και δεν το δει κανείς?)

-> Ρίξτε μια ματιά σε στεγανοποίηση .

Απαντήθηκε 11/08/2008 στις 20:19
πηγή χρήστη

ψήφοι
19

2GB και περίπου 15M αρχείων είναι μια πολύ μικρή βάση δεδομένων - Έχω τρέξει πολύ μεγαλύτερα σε Pentium III και ό, τι έχει ακόμα τρέξει πολύ γρήγορα .. Αν η δική σας είναι αργή, είναι ένα πρόβλημα σχεδιασμού της βάσης δεδομένων / εφαρμογής, δεν είναι mysql (!) ένας.

Απαντήθηκε 05/08/2010 στις 10:03
πηγή χρήστη

ψήφοι
16

Είναι το είδος του άσκοπο να μιλάμε για «απόδοση της βάσης δεδομένων», «επιδόσεις ερώτημα» είναι ένας καλύτερος όρος εδώ. Και η απάντηση είναι: εξαρτάται από το ερώτημα, δεδομένα που λειτουργεί με, δείκτες, υλικό, κ.λπ. Μπορείτε να πάρετε μια ιδέα για το πώς πολλές σειρές πρόκειται να σαρωθεί και ποια ευρετήρια πρόκειται να χρησιμοποιηθεί με εξηγήσουν σύνταξη.

2GB πραγματικότητα δεν μετράνε ως ένα «μεγάλο» της βάσης δεδομένων - είναι περισσότερο από ένα μεσαίου μεγέθους.

Απαντήθηκε 06/08/2008 στις 20:53
πηγή χρήστη

ψήφοι
9

Ένα σημείο που εξετάζει είναι και ο σκοπός του συστήματος και τα δεδομένα στη μέρα σε μέρα.

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

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

Απαντήθηκε 06/12/2012 στις 06:13
πηγή χρήστη

ψήφοι
9

Κάποτε κλήθηκε να εξετάσει μια mysql που είχε «σταμάτησε να λειτουργεί». Ανακάλυψα ότι τα αρχεία DB κατοικούσαν σε ταξινομητής Network Appliance τοποθετείται με NFS2 και με μέγιστο μέγεθος αρχείου των 2GB. Και αρκετά βέβαιος, ο πίνακας που είχε σταματήσει την αποδοχή των συναλλαγών ήταν ακριβώς 2GB στο δίσκο. Αλλά σε σχέση με την καμπύλη απόδοσης μου έχουν πει ότι δούλευε σαν πρωταθλητής μέχρι και δεν λειτουργούν καθόλου! Η εμπειρία αυτή εξυπηρετεί πάντα για μένα σαν μια ωραία υπενθύμιση ότι είσαι εκεί πάντα διαστάσεις πάνω και κάτω από αυτό που φυσικά υποψιάζεστε.

Απαντήθηκε 06/08/2008 στις 05:27
πηγή χρήστη

ψήφοι
8

Επίσης, προσέξτε για τα σύνθετα ενώνει. πολυπλοκότητα συναλλαγών μπορεί να είναι ένας μεγάλος παράγοντας, εκτός από τον όγκο των συναλλαγών.

Refactoring βαριά ερωτήματα μερικές φορές προσφέρει μια μεγάλη αύξηση της απόδοσης.

Απαντήθηκε 04/08/2008 στις 20:01
πηγή χρήστη

ψήφοι
4

Είμαι διαχειρίζεται σήμερα μια βάση δεδομένων MySQL σε υποδομές cloud της Amazon που έχει αυξηθεί στα 160 GB. απόδοση του ερωτήματος είναι μια χαρά. Τι έχει γίνει εφιάλτης είναι αντίγραφα ασφαλείας, αποκαθιστά, προσθέτοντας σκλάβοι, ή οτιδήποτε άλλο που ασχολείται με το σύνολο σύνολο δεδομένων, ή ακόμα και DDL σε μεγάλους πίνακες. Να πάρει μια καθαρή εισαγωγή ενός αρχείου ένδειξης σφαλμάτων έχει καταστεί προβληματική. Για να καταστήσει τη διαδικασία αρκετά σταθερό για να αυτοματοποιήσουν, διάφορες επιλογές που απαιτούνται για να γίνει προτεραιότητα τη σταθερότητα των επιδόσεων. Αν είχαμε ποτέ να ανακτήσει από μια καταστροφή, χρησιμοποιώντας ένα αντίγραφο ασφαλείας του SQL, θα ήθελα να είναι προς τα κάτω για μέρες.

Οριζόντια κλιμάκωση SQL είναι επίσης πολύ επώδυνη, και στις περισσότερες περιπτώσεις οδηγεί σε χρήση με τρόπους που μάλλον δεν είχε την πρόθεση, όταν επέλεξε να θέσει τα στοιχεία σας στην SQL στην πρώτη θέση. Shards, διαβάστε σκλάβοι, multi-master, et al, είναι όλα πραγματικά χάλια λύσεις που προσθέτουν πολυπλοκότητα σε ό, τι ποτέ να κάνει με την DB, και όχι ένα από τα λύνει το πρόβλημα? να μετριάζει μόνο με κάποιους τρόπους. Θα ήθελα να προτείνω έντονα κοιτάζοντας κινείται ορισμένα από τα δεδομένα σας από MySQL (ή πραγματικά οποιοδήποτε SQL), όταν αρχίσει να προσεγγίζει ένα σύνολο δεδομένων με μέγεθος όπου αυτά τα είδη των πραγμάτων να γίνει ένα ζήτημα.

Απαντήθηκε 30/06/2017 στις 16:25
πηγή χρήστη

ψήφοι
4

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

Αν έχετε τη σωστή ευρετήρια, χρησιμοποιήστε την κατάλληλη μηχανές (δεν χρησιμοποιούν MyISAM όπου αναμένονται πολλαπλά ΟΘΔ), η χρήση στεγανοποίηση, διαθέτουν σωστή μνήμη ανάλογα με τη χρήση και φυσικά έχουν καλή διαμόρφωση του διακομιστή, MySQL μπορεί να διαχειριστεί τα δεδομένα ακόμα και σε terabytes!

Υπάρχουν πάντα τρόποι για να βελτιώσει την απόδοση της βάσης δεδομένων.

Απαντήθηκε 19/09/2013 στις 12:26
πηγή χρήστη

ψήφοι
2

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

Απαντήθηκε 05/06/2017 στις 10:27
πηγή χρήστη

ψήφοι
2

Εξαρτάται από το ερώτημα και την επικύρωση σας.

Για παράδειγμα, συνεργάστηκα με έναν πίνακα 100 000 φαρμάκων που έχει μια στήλη γενική ονομασία όπου έχει περισσότερους από 15 χαρακτήρες για κάθε φάρμακο στον εν λόγω πίνακα .I θέσει ένα ερώτημα για να συγκριθεί η γενική ονομασία των φαρμάκων μεταξύ των δύο tables.The ερώτημα παίρνει περισσότερα λεπτά για να run.The ίδιο, αν συγκρίνει κανείς τα φάρμακα που χρησιμοποιούν το δείκτη των ναρκωτικών, χρησιμοποιώντας μια στήλη id (όπως προαναφέρθηκε), διαρκεί μόνο λίγα δευτερόλεπτα.

Απαντήθηκε 29/11/2016 στις 12:05
πηγή χρήστη

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more