
* Ποιο είναι το βέλτιστο επίπεδο του συναγωνισμού ότι η εφαρμογή της C ++ της BerkeleyDB μπορεί εύλογα να υποστηρίξει;
* Πόσα θέματα που μπορεί να έχω σφυρηλάτηση μακριά στο DB πριν διακίνηση αρχίσει να υποφέρουν εξαιτίας της έριδος πόρων;


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


Η εφαρμογή μου είναι αρκετά απλή, θα κάνω παίρνει και βάζει αρχείων που είναι περίπου 1KB κάθε μία. Δεν δρομείς, όχι διαγραφή.

 
BerkeleyDB Συνδρομικότητα
=========================



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


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

 

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


Εκτός από την περίπτωση χρήσης σας, εξαρτάται επίσης από το CPU, μνήμη, front-side bus, το λειτουργικό σύστημα, τις ρυθμίσεις της μνήμης cache, και τα λοιπά.


Σοβαρά, μόλις δοκιμάσετε το δικό σας σενάριο.


Εάν χρειάζεστε κάποιους αριθμούς (που στην πραγματικότητα μπορεί να σημαίνει τίποτα το σενάριο σας):


* [Oracle Berkeley DB: Μετρήσεις Επιδόσεων και τα σημεία αναφοράς](http://www.oracle.com/technology/products/berkeley-db/pdf/berkeley-db-perf.pdf)
* [Μετρήσεις απόδοσης & Benchmarks:   

Berkeley DB](http://staff.rcost.unisannio.it/visaggio/berkleyDB.pdf)

 

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


Υπήρχαν κινητούς μέσους όρους και όλα τα είδη των μετρήσεων που εμπλέκονται, αλλά το take-away μάθημα ήταν: μόλις προσαρμοστεί για το πώς τα πράγματα λειτουργούν αυτή τη στιγμή. Ποτέ δεν ξέρεις πότε οι DBAs θα βελτιώσει την απόδοση ή υλικό θα αναβαθμιστεί, ή ίσως μια άλλη διαδικασία, θα έρθει να φορτώσει κάτω από το σύστημα, ενώ τρέχετε. Έτσι προσαρμοστούν.


Α, και κάτι άλλο: να αποφευχθεί η διαδικασία αλλάζει, αν μπορείτε - παρτίδα τα πράγματα.




---


Ω, θα ήθελα να κάνω αυτό σαφές: όλα αυτά συνέβησαν κατά το χρόνο εκτέλεσης, όχι κατά τη διάρκεια της ανάπτυξης.

 

Ο τρόπος που αντιλαμβάνομαι τα πράγματα, Samba δημιουργήθηκε [γλε](http://sourceforge.net/projects/tdb/) να επιτρέψει «πολλαπλές ταυτόχρονες *συγγραφείς* » για κάποιο συγκεκριμένο αρχείο βάσης δεδομένων. Έτσι, αν το φόρτο εργασίας σας έχει πολλούς συγγραφείς απόδοσή σας μπορεί να είναι κακή (όπως, το πρόγραμμα Samba επέλεξε να γράψει το δικό του σύστημα, προφανώς επειδή δεν ήταν ευχαριστημένος με την απόδοση Berkeley DB σε αυτή την περίπτωση).


Από την άλλη πλευρά, εάν το φόρτο εργασίας σας έχει πολλά αναγνωστών, τότε το ερώτημα είναι πόσο καλά το λειτουργικό σας σύστημα χειρίζεται πολλαπλές αναγνώστες.

 

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


Εκτός από αυτόν, αυτά είναι γενικά παράγοντες Ι βρέθηκε να είναι από σημαντικό αντίκτυπο στην απόδοση:


1. μέθοδος πρόσβασης (η οποία στην περίπτωσή σας υποθέτω ότι είναι btree).
2. Επίπεδο της εμμονής με την οποία έχετε ρυθμίσει DBD (για παράδειγμα, στη δική μου περίπτωση το περιβάλλον σημαία της «DB\_TXN\_WRITE\_NOSYNC» βελτιωμένη απόδοση εγγραφής από μία τάξη μεγέθους, αλλά θέτει σε κίνδυνο ανθεκτικότητας)
3. Μήπως η εργατική που ταιριάζει στη μνήμη cache;
4. Αριθμός Διαβάζει Vs. Γράφει.
5. Πώς απλώνονται πρόσβασης σας (να θυμάστε ότι btree έχει ένα κλείδωμα σε επίπεδο σελίδας - έτσι την πρόσβαση σε διαφορετικές σελίδες με διαφορετικά θέματα που είναι ένα μεγάλο πλεονέκτημα).
6. μοτίβο πρόσβασης - meanig πόσο πιθανό είναι τα θέματα για να κλειδώσει το ένα το άλλο, ή ακόμα και αδιέξοδο, και ποια είναι η πολιτική επίλυσης αδιεξόδων σας (αυτό μπορεί να είναι ένας δολοφόνος).
7. Hardware (δίσκο & μνήμη για προσωρινή μνήμη).


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

 