Σκάλιση

ERDDAP™- Βαριά φορτία, πλέγματα, συστοιχίες, ομοσπονδίες, και υπολογιστικό σύννεφο

 

ERDDAP:

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

Η αρχική έκδοση γράφτηκε τον Ιούνιο του 2009. Δεν υπήρξαν σημαντικές αλλαγές. Αυτό ενημερώθηκε τελευταία φορά 2019-04-15.

ΔΙΕΥΘΥΝΤΗΣ

Τα περιεχόμενα αυτής της ιστοσελίδας είναι προσωπικές απόψεις του Bob Simons και δεν αντανακλούν απαραίτητα καμία θέση της κυβέρνησης ή τουNational Oceanic and Atmospheric Administration. Οι υπολογισμοί είναι απλοϊκοί, αλλά πιστεύω ότι τα συμπεράσματα είναι σωστά. Χρησιμοποίησα λάθος λογική ή έκανα λάθος στους υπολογισμούς μου; Αν ναι, το λάθος είναι δικό μου και μόνο. Παρακαλώ στείλτε ένα email με τη διόρθωσηerd dot data at noaa dot gov.  

• • Ναι.

Βαριά φορτία / περιορισμούς

Με βαριά χρήση, αυτόνομηERDDAP™θα περιοριστούν. (από το πιο στο λιγότερο πιθανό) από:

Εύρος απομακρυσμένης πηγής

1. Εύρος ζώνης μιας απομακρυσμένης πηγής δεδομένων — Ακόμη και με αποτελεσματική σύνδεση (π.χ. μέσωOPeNDAP) , εκτός εάν μια απομακρυσμένη πηγή δεδομένων έχει πολύ υψηλό εύρος ζώνης σύνδεσης στο Διαδίκτυο,ERDDAPΟι απαντήσεις θα περιοριστούν από το πόσο γρήγοραERDDAP™μπορεί να πάρει δεδομένα από την πηγή δεδομένων. Μια λύση είναι να αντιγράψετε το σύνολο δεδομένων πάνωERDDAPΟ σκληρός δίσκος, ίσως μεEDDGridΑντιγραφήήEDDTableCopy.  

ERDDAPΕύρος ζώνης εξυπηρετητή

2. Εκτός ανERDDAPΟ διακομιστής έχει πολύ υψηλή σύνδεση στο Internet,ERDDAPΟι απαντήσεις θα περιοριστούν από το πόσο γρήγοραERDDAP™μπορεί να πάρει τα δεδομένα από τις πηγές δεδομένων και πόσο γρήγοραERDDAP™μπορεί να επιστρέψει τα δεδομένα στους πελάτες. Η μόνη λύση είναι να αποκτήσετε μια ταχύτερη σύνδεση στο Διαδίκτυο.  

Μνήμη

3. Αν υπάρχουν πολλές ταυτόχρονες αιτήσεις,ERDDAP™μπορεί να ξεμείνει από μνήμη και προσωρινά να αρνηθεί νέα αιτήματα. (ERDDAP™έχει μερικούς μηχανισμούς για να το αποφύγει αυτό και να ελαχιστοποιήσει τις συνέπειες αν συμβεί.) Έτσι, όσο περισσότερη μνήμη στον διακομιστή τόσο το καλύτερο. Σε ένα διακομιστή 32-bit, 4+ GB είναι πραγματικά καλό, 2 GB είναι εντάξει, λιγότερο δεν συνιστάται. Σε έναν εξυπηρετητή 64-bit, μπορείτε σχεδόν εντελώς να αποφύγετε το πρόβλημα με το να πάρετε πολλές αναμνήσεις. Δείτε το\ Xmx και -XmsγιαERDDAPΤόμκατ. ΑERDDAP™να πάρει βαριά χρήση σε έναν υπολογιστή με 64-bit server με 8GB μνήμης και -Xmx που σε 4000M είναι σπάνια, αν ποτέ, περιορίζεται από τη μνήμη.  

Είχε εύρος ζώνης κίνησης

4. Η πρόσβαση στα δεδομένα που αποθηκεύονται στο σκληρό δίσκο του διακομιστή είναι πολύ πιο γρήγορη από την πρόσβαση σε απομακρυσμένα δεδομένα. Ακόμα κι έτσι, αν ηERDDAP™server έχει ένα πολύ υψηλό εύρος ζώνης σύνδεση στο Internet, είναι πιθανό ότι η πρόσβαση σε δεδομένα σχετικά με το σκληρό δίσκο θα είναι ένα αδιέξοδο. Μια μερική λύση είναι να χρησιμοποιήσετε πιο γρήγορα (π.χ., 10.000 Στροφές) μαγνητικοί σκληροί δίσκοι ή δίσκοι SSD (εάν έχει νόημα από πλευράς κόστους) . Μια άλλη λύση είναι να αποθηκεύσετε διαφορετικά σύνολα δεδομένων σε διαφορετικές κινήσεις, έτσι ώστε το σωρευτικό εύρος ζώνης του σκληρού δίσκου είναι πολύ υψηλότερο.  

Πάρα πολλά αρχεία Cached

5. Πάρα πολλά αρχεία σε ένακρύπτηκατάλογος —ERDDAP™αποθηκεύει όλες τις εικόνες, αλλά μόνο αποθηκεύει τα δεδομένα για ορισμένους τύπους αιτημάτων δεδομένων. Είναι δυνατόν ο κατάλογος cache για ένα σύνολο δεδομένων να έχει έναν μεγάλο αριθμό αρχείων προσωρινά. Αυτό θα επιβραδύνει τις αιτήσεις για να δείτε αν ένα αρχείο είναι στην κρύπτη (Αλήθεια!) .<κρύπτη Πρακτικά & gt, insetup.xmlσας επιτρέπει να ορίσετε πόσο ένα αρχείο μπορεί να είναι στην κρύπτη πριν διαγραφεί. Ο καθορισμός μικρότερου αριθμού θα ελαχιστοποιήσει αυτό το πρόβλημα.  

ΚΜΕ

6. Μόνο δύο πράγματα χρειάζονται πολύ χρόνο CPU:
   • NetCDF4 καιHDF5 τώρα υποστηρίζουν εσωτερική συμπίεση των δεδομένων. Αποσυμπίεση μιας μεγάλης συμπιεσμένηςNetCDF4 /HDF5 αρχείο δεδομένων μπορεί να διαρκέσει 10 ή περισσότερα δευτερόλεπτα. (Αυτό δεν είναι σφάλμα εφαρμογής. Είναι η φύση της συμπίεσης.) Έτσι, πολλαπλές ταυτόχρονες αιτήσεις για σύνολα δεδομένων με δεδομένα αποθηκευμένα σε συμπιεσμένα αρχεία μπορούν να βάλουν μια σοβαρή πίεση σε οποιοδήποτε διακομιστή. Εάν αυτό είναι ένα πρόβλημα, η λύση είναι να αποθηκεύσετε δημοφιλή σύνολα δεδομένων σε μη συμπιεσμένα αρχεία, ή να πάρετε έναν εξυπηρετητή με μια CPU με περισσότερους πυρήνες.
   • Κατασκευή γραφημάτων (συμπεριλαμβανομένων των χαρτών) : περίπου 0,2 - 1 δευτερόλεπτο ανά γράφημα. Έτσι, αν υπήρχαν πολλές ταυτόχρονες μοναδικές αιτήσεις για γραφήματα (WMSΟι πελάτες συχνά κάνουν 6 ταυτόχρονες αιτήσεις!) Μπορεί να υπάρχει περιορισμός της ΚΜΕ. Όταν πολλοί χρήστες τρέχουνWMSπελάτες, αυτό γίνεται πρόβλημα.  

• • Ναι.

Πολλαπλές ίδιεςERDDAPΜε Εξισορρόπηση Φορτίων;

Συχνά τίθεται το ερώτημα: "Για την αντιμετώπιση βαρέων φορτίων, μπορώ να ρυθμίσω πολλαπλά πανομοιότυπαERDDAPs με εξισορρόπηση φορτίου?" Είναι μια ενδιαφέρουσα ερώτηση γιατί γρήγορα φτάνει στον πυρήνα τηςERDDAPΤο σχέδιο. Η γρήγορη απάντηση είναι "όχι". Γνωρίζω ότι αυτή είναι μια απογοητευτική απάντηση, αλλά υπάρχουν δύο άμεσοι λόγοι και ορισμένοι μεγαλύτεροι βασικοί λόγοι για τους οποίους σχεδίασαERDDAP™να χρησιμοποιήσει διαφορετική προσέγγιση (μια ομοσπονδίαERDDAPs, που περιγράφεται στο μεγαλύτερο μέρος του παρόντος εγγράφου) , η οποία πιστεύω ότι είναι μια καλύτερη λύση.

Μερικοί άμεσοι λόγοι για τους οποίους δεν μπορείτε / δεν πρέπει να ρυθμίσετε πολλαπλά πανομοιότυπαERDDAPίνα είναι:

• Ένα δεδομένοERDDAP™διαβάζει κάθε αρχείο δεδομένων όταν για πρώτη φορά γίνεται διαθέσιμο για να βρει τα εύρος των δεδομένων στο αρχείο. Στη συνέχεια αποθηκεύει αυτές τις πληροφορίες σε ένα αρχείο ευρετηρίου. Αργότερα, όταν έρθει ένα αίτημα χρήστη για δεδομένα,ERDDAP™χρησιμοποιεί τον εν λόγω δείκτη για να βρει ποια αρχεία για να ψάξει για τα ζητούμενα δεδομένα. Αν υπήρχαν πολλαπλά πανομοιότυπαERDDAPS, ο καθένας θα κάνει αυτό το ευρετήριο, το οποίο είναι σπατάλη προσπάθειας. Με το σύστημα που περιγράφεται παρακάτω, η ευρετηρίαση γίνεται μόνο μία φορά, από ένα από ταERDDAPΣ.
• Για ορισμένους τύπους αιτήσεων χρηστών (π.χ. για.nc, .png, .pdf αρχεία) ERDDAP™πρέπει να κάνει ολόκληρο το αρχείο πριν από την απάντηση μπορεί να σταλεί. Λοιπόν...ERDDAP™αποθηκεύει αυτά τα αρχεία για ένα σύντομο χρονικό διάστημα. Αν έρθει μια παρόμοια αίτηση (όπως κάνει συχνά, ειδικά για εικόνες όπου το URL είναι ενσωματωμένο σε μια ιστοσελίδα) ,ERDDAP™μπορεί να επαναχρησιμοποιήσει το αρχείο cached. Σε ένα σύστημα πολλαπλών πανομοιότυπωνERDDAPs, αυτά τα αρχεία cached δεν μοιράζονται, έτσι το καθέναERDDAP™θα αναδημιουργούσε άσκοπα και άσκοπα το.nc, .png, ή .pdf αρχεία. Με το σύστημα που περιγράφεται παρακάτω, τα αρχεία γίνονται μόνο μία φορά, από ένα από ταERDDAPs, και επαναχρησιμοποιείται.
• ERDDAPΤο σύστημα συνδρομών δεν έχει ρυθμιστεί για να μοιράζεται με πολλαπλάERDDAPΣ. Για παράδειγμα, εάν ο ισοσταθμιστής φορτίου στέλνει ένα χρήστη σε έναERDDAP™και ο χρήστης εγγραφεί σε ένα σύνολο δεδομένων, τότε το άλλοERDDAPΔεν θα το γνωρίζουν αυτό. Αργότερα, αν ο ισοσταθμιστής φορτίου στείλει το χρήστη σε διαφορετικόERDDAP™και ζητά κατάλογο των συνδρομών του, η άλληERDDAP™Θα πω ότι δεν υπάρχουν. (οδηγώντας τον/την να κάνει μια διπλή συνδρομή στο άλλο EREDDAP) . Με το σύστημα που περιγράφεται παρακάτω, το σύστημα συνδρομών απλώς αντιμετωπίζεται από το κύριο, δημόσιο, σύνθετοERDDAP.

Ναι, για κάθε ένα από αυτά τα προβλήματα, θα μπορούσα (με μεγάλη προσπάθεια) μηχανικά ένα διάλυμα (να μοιραστεί τις πληροφορίες μεταξύERDDAPα) , αλλά νομίζω ότι τοΟμοσπονδίαERDDAPπροσέγγιση s (που περιγράφονται στο μεγαλύτερο μέρος του παρόντος εγγράφου) Συζητήσεις του Ευρωπαϊκού ΚοινοβουλίουERDDAPΗ προσέγγιση s-with-a-load-balancer δεν αρχίζει καν να αντιμετωπίζει, ιδίως τον αποκεντρωμένο χαρακτήρα των πηγών δεδομένων στον κόσμο.

Είναι καλύτερα να δεχτείς το απλό γεγονός ότι δεν σχεδίασαERDDAP™να αναπτυχθούν ως πολλαπλά πανομοιότυπαERDDAPs με ισοσταθμιστή φορτίου. Σχεδίασα συνειδητάERDDAP™να λειτουργήσει καλά εντός μιας ομοσπονδίαςERDDAPS, το οποίο πιστεύω ότι έχει πολλά πλεονεκτήματα. Συζητήσεις του Ευρωπαϊκού ΚοινοβουλίουERDDAPΤο s είναι απόλυτα ευθυγραμμισμένο με το αποκεντρωμένο, κατανεμημένο σύστημα των κέντρων δεδομένων που έχουμε στον πραγματικό κόσμο (Σκεφτείτε τις διάφορες περιοχές IOOS, ή τις διάφορες περιοχές CoastWatch, ή τα διάφορα μέρη του NCEI, ή τα 100 άλλα κέντρα δεδομένωνNOAA, ή τις διαφορετικές DAAC της NASA, ή τα 1000 των κέντρων δεδομένων σε όλο τον κόσμο) . Αντί να λένε σε όλα τα κέντρα δεδομένων του κόσμου ότι πρέπει να εγκαταλείψουν τις προσπάθειές τους και να βάλουν όλα τα δεδομένα τους σε μια κεντρική λίμνη δεδομένων. (Ακόμα και αν ήταν δυνατόν, είναι μια φρικτή ιδέα για πολλούς λόγους -- δείτε τις διάφορες αναλύσεις που δείχνουν τα πολυάριθμα πλεονεκτήματα τηςαποκεντρωμένα συστήματα) ,ERDDAPΟ σχεδιασμός λειτουργεί με τον κόσμο όπως είναι. Κάθε κέντρο δεδομένων που παράγει δεδομένα μπορεί να συνεχίσει να διατηρεί, να επιμελείται και να εξυπηρετεί τα δεδομένα τους (όπως θα έπρεπε) , και όμως, μεERDDAP™, τα δεδομένα μπορούν επίσης να είναι άμεσα διαθέσιμα από ένα κεντρικόERDDAP, χωρίς την ανάγκη διαβίβασης των δεδομένων στο κεντρικόERDDAP™ή αποθήκευση αντιγράφων των δεδομένων. Πράγματι, ένα δεδομένο σύνολο δεδομένων μπορεί να είναι ταυτόχρονα διαθέσιμο από έναERDDAP™στην οργάνωση που παρήγαγε και στην πραγματικότητα αποθηκεύει τα δεδομένα (π.χ., GoMOOS) , από έναERDDAP™στη μητρική οργάνωση (π.χ., κεντρική μονάδα IOOS) , από όλα...NOAA ERDDAP™, από μια ομοσπονδιακή κυβέρνηση όλων των ΗΠΑERDDAP™, από ένα παγκόσμιοERDDAP™ (ΓΟΥΑ) , και από εξειδικευμένοERDDAPα (π.χ.ERDDAP™σε ίδρυμα αφιερωμένο στην έρευνα HAB) , όλα ουσιαστικά στιγμιαία, και αποτελεσματικά επειδή μόνο τα μεταδεδομένα μεταφέρονται μεταξύERDDAPΌχι τα δεδομένα. Το καλύτερο από όλα, μετά το αρχικόERDDAP™στην οργάνωση καταγωγής, όλα τα άλλαERDDAPs μπορεί να συσταθεί γρήγορα (λίγες ώρες εργασίας) , με ελάχιστους πόρους (ένας εξυπηρετητής που δεν χρειάζεται RAID για αποθήκευση δεδομένων δεδομένου ότι δεν αποθηκεύει δεδομένα τοπικά) , και έτσι με πραγματικά ελάχιστο κόστος. Συγκρίνετε αυτό με το κόστος της εγκατάστασης και διατήρησης ενός συγκεντρωτικού data center με μια λίμνη δεδομένων και την ανάγκη για μια πραγματικά τεράστια, πραγματικά ακριβή, σύνδεση στο Διαδίκτυο, καθώς και το συνοδευτικό πρόβλημα του κεντρικού data center είναι ένα ενιαίο σημείο αποτυχίας. Για μένα,ERDDAPΗ αποκεντρωμένη, ομοσπονδιακή προσέγγιση είναι πολύ ανώτερη.

Σε περιπτώσεις όπου ένα δεδομένο κέντρο δεδομένων χρειάζεται πολλαπλάσιαERDDAPs για την κάλυψη της υψηλής ζήτησης,ERDDAPΟ σχεδιασμός είναι πλήρως ικανός να ταιριάζει ή να υπερβαίνει τις επιδόσεις του πολλαπλού-ταυτοποιημένου-ERDDAPS-με-ένα φορτίο-εξισορρόπηση προσέγγιση. Έχεις πάντα τη δυνατότητα να στήσειςπολλαπλών συνθέτωνERDDAPα (όπως αναφέρεται παρακάτω) , καθένα από τα οποία λαμβάνει όλα τα δεδομένα τους από άλλαERDDAPs, χωρίς εξισορρόπηση φορτίου. Σε αυτή την περίπτωση, σας συνιστώ να κάνετε ένα σημείο να δώσει σε κάθε ένα από τα σύνθεταERDDAPs ένα διαφορετικό όνομα / ταυτότητα και, αν είναι δυνατόν, την εγκατάστασή τους σε διάφορα μέρη του κόσμου (π.χ., διαφορετικές περιφέρειες AWS) , π.χ.,ERD\_ΗΠΑ\_Ανατολικά,ERD\ΗΠΑ\Δυτικά,ERD\ΙΕ,ERD\_FR,ERD\_IT, έτσι ώστε οι χρήστες συνειδητά, επανειλημμένα, εργάζονται με ένα συγκεκριμένοERDDAP, με το πρόσθετο όφελος ότι έχετε αφαιρέσει τον κίνδυνο από ένα μόνο σημείο αποτυχίας.  

• • Ναι.

Δίχτυα, συστάδες και ομοσπονδίες

Υπό πολύ βαριά χρήση, ένα μόνο αυτόνομοERDDAP™θα συναντήσει ένα ή περισσότερα από ταπεριορισμοίΌπως αναφέρεται παραπάνω, ακόμη και οι προτεινόμενες λύσεις θα είναι ανεπαρκείς. Για τέτοιες περιπτώσεις,ERDDAP™έχει χαρακτηριστικά που καθιστούν εύκολη την κατασκευή κλιμακωτών καννάβων (επίσης ονομάζεται συστάδες ή ομοσπονδίες) τουERDDAPs που επιτρέπουν στο σύστημα να χειρίζεται πολύ βαριά χρήση (π.χ. για μεγάλο data center) .

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

Η βασική ιδέα του σχεδιασμού ενός κλιμακούμενου συστήματος είναι να εντοπιστούν τα πιθανά σημεία συμφόρησης και στη συνέχεια να σχεδιαστεί το σύστημα έτσι ώστε τμήματα του συστήματος να μπορούν να αναπαραχθούν όπως απαιτείται για την ανακούφιση των σημείων συμφόρησης. Ιδανικά, κάθε αντιγραφόμενο μέρος αυξάνει γραμμικά την ικανότητα αυτού του τμήματος του συστήματος (απόδοση κλιμάκωσης) . Το σύστημα δεν είναι κλιμακωτό εκτός αν υπάρχει ένα κλιμακωτό διάλυμα για κάθε σημείο συμφόρησης.Κλιμάκωσηείναι διαφορετική από την αποδοτικότητα (πόσο γρήγορα μπορεί να γίνει μια εργασία — αποδοτικότητα των εξαρτημάτων) . Η κλιμακωσιμότητα επιτρέπει στο σύστημα να αναπτύσσεται για να χειριστεί οποιοδήποτε επίπεδο ζήτησης. Απόδοση (της κλιμάκωσης και των μερών) καθορίζει πόσους διακομιστές, κ.λπ., θα πρέπει να πληρούν ένα δεδομένο επίπεδο ζήτησης. Η αποδοτικότητα είναι πολύ σημαντική, αλλά πάντα έχει όρια. Η κλιμάκωση είναι η μόνη πρακτική λύση για την κατασκευή ενός συστήματος που μπορεί να χειριστεί πολύ Βαριά χρήση. Ιδανικά, το σύστημα θα είναι κλιμακωτό και αποτελεσματικό.

Στόχοι

Οι στόχοι αυτού του σχεδιασμού είναι:

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

Συστάσεις

Οι συστάσεις μας είναι

• Βασικά, προτείνω τη δημιουργία ενός ΣύνθετουERDDAP™ ( Δ στο διάγραμμα) , η οποία είναι τακτικήERDDAP™μόνο που εξυπηρετεί δεδομένα από άλλαERDDAPΣ. Η αρχιτεκτονική του πλέγματος έχει σχεδιαστεί για να μετατοπίζει όσο το δυνατόν περισσότερη εργασία. (Χρήση ΚΜΕ, χρήση μνήμης, χρήση εύρους ζώνης) από το CompositeERDDAP™προς την άλληERDDAPΣ.
• ERDDAP™έχει δύο ειδικούς τύπους συνόλου δεδομένων,EDDGridΑπό τοErddapκαιEDD TableFromErddap, που αναφέρονται σε σύνολα δεδομένων σε άλλαERDDAPΣ.
• Όταν το σύνθετοERDDAP™λαμβάνει αίτημα για δεδομένα ή εικόνες από αυτά τα σύνολα δεδομένων, το σύνθετοERDDAP™ ανακατευθύνσειςτα δεδομένα που ζητούνται στο άλλοERDDAP™Διακομιστής. Το αποτέλεσμα είναι:
  • Αυτό είναι πολύ αποτελεσματικό. (ΚΜΕ, μνήμη και εύρος ζώνης) , γιατί διαφορετικά
    1. Το σύνθετοERDDAP™πρέπει να αποστείλει το αίτημα δεδομένων στο άλλοERDDAP.
    2. Το άλλοERDDAP™πρέπει να πάρει τα δεδομένα, αναδιαμόρφωση σε αυτό, και να διαβιβάσει τα δεδομένα στο σύνθετοERDDAP.
    3. Το σύνθετοERDDAP™πρέπει να λάβει τα δεδομένα (χρησιμοποιώντας επιπλέον εύρος ζώνης) , αναδιαμόρφωση σε αυτό (χρησιμοποιώντας επιπλέον χρόνο και μνήμη ΚΜΕ) , και να διαβιβάσει τα δεδομένα στο χρήστη (χρησιμοποιώντας επιπλέον εύρος ζώνης) . Με ανακατευθύνοντας το αίτημα για δεδομένα και επιτρέποντας το άλλοERDDAP™για να στείλετε την απάντηση απευθείας στο χρήστη, το σύνθετοERDDAP™Ουσιαστικά δεν ξοδεύει χρόνο CPU, μνήμη, ή εύρος ζώνης σε αιτήματα δεδομένων.
  • Η ανακατεύθυνση είναι διαφανής στον χρήστη ανεξάρτητα από το λογισμικό του πελάτη (περιηγητής ή οποιοδήποτε άλλο λογισμικό ή εργαλείο γραμμής εντολών) .

Μέρη καννάβου

Τα μέρη του πλέγματος είναι:

Α : Για κάθε απομακρυσμένη πηγή δεδομένων που έχει ένα υψηλό εύρος ζώνηςOPeNDAPserver, μπορείτε να συνδεθείτε απευθείας στον απομακρυσμένο server. Αν ο απομακρυσμένος εξυπηρετητής είναι έναςERDDAP™, χρήσηEDDGridΑπόErddap ή EDDTableFromERDDAPγια την εξυπηρέτηση των δεδομένων στο CompositeERDDAP. Αν ο απομακρυσμένος εξυπηρετητής είναι κάποιος άλλος τύποςDAPserver, π.χ., ΤΡΕΙΣ,Hyrax, ή GrADS, χρήσηEDDGridΑπό τον Νταπ.

B : Για κάθεERDDAP- εφικτή πηγή δεδομένων (πηγή δεδομένων από την οποίαERDDAPμπορεί να διαβάσει δεδομένα) που έχει έναν εξυπηρετητή υψηλής ζώνης, που δημιουργεί ένα άλλοERDDAP™στο δίκτυο που είναι υπεύθυνο για την εξυπηρέτηση των δεδομένων από αυτήν την πηγή δεδομένων.

• Εάν περισσότερες από μίαERDDAPΤα s δεν λαμβάνουν πολλά αιτήματα για δεδομένα, μπορείτε να τα εδραιώσετε σε έναERDDAP.
• Εάν ηERDDAP™αφιερωμένο στην λήψη δεδομένων από μια απομακρυσμένη πηγή λαμβάνει πάρα πολλά αιτήματα, υπάρχει ένας πειρασμός να προσθέσετε επιπλέονERDDAPs για πρόσβαση στην απομακρυσμένη πηγή δεδομένων. Σε ειδικές περιπτώσεις αυτό μπορεί να έχει νόημα, αλλά είναι πιο πιθανό ότι αυτό θα κατακλύσει την απομακρυσμένη πηγή δεδομένων (που είναι αυτοκαταστροφικό) και επίσης να αποτρέψει άλλους χρήστες από την πρόσβαση στην απομακρυσμένη πηγή δεδομένων (Που δεν είναι ωραίο.) . Σε μια τέτοια περίπτωση, σκεφτείτε να δημιουργήσετε ένα άλλοERDDAP™να εξυπηρετήσει αυτό το ένα σύνολο δεδομένων και να αντιγράψει το σύνολο δεδομένων σε αυτόERDDAPΣκληρός δίσκος (Βλέπε Γ ) , ίσως μεEDDGridΑντιγραφήή/καιEDDTableCopy.
• B Οι διακομιστές πρέπει να είναι προσιτοί στο κοινό.

Γ : Για κάθεERDDAP-able πηγή δεδομένων που έχει έναν εξυπηρετητή χαμηλού εύρους ζώνης (ή είναι μια αργή υπηρεσία για άλλους λόγους) , να εξετάσει τη δημιουργία ενός άλλουERDDAP™και αποθήκευση αντιγράφου του συνόλου δεδομένων σε αυτόERDDAPΟι σκληροί δίσκοι, ίσως μεEDDGridΑντιγραφήή/καιEDDTableCopy. Εάν περισσότερες από μίαERDDAPΤα s δεν λαμβάνουν πολλά αιτήματα για δεδομένα, μπορείτε να τα εδραιώσετε σε έναERDDAP. Γ Οι διακομιστές πρέπει να είναι προσιτοί στο κοινό.

ΣύνθετηERDDAP

Δ : Το σύνθετοERDDAP™είναι τακτικήERDDAP™μόνο που εξυπηρετεί δεδομένα από άλλαERDDAPΣ.

• Επειδή το σύνθετοERDDAP™έχει πληροφορίες στη μνήμη για όλα τα σύνολα δεδομένων, μπορεί να ανταποκριθεί γρήγορα σε αιτήματα για λίστες συνόλων δεδομένων (πλήρεις αναζητήσεις κειμένου, αναζητήσεις κατηγοριών, ο κατάλογος όλων των συνόλων δεδομένων) , και τις αιτήσεις για το έντυπο πρόσβασης ενός μεμονωμένου συνόλου δεδομένων,WMSσελίδα πληροφοριών. Αυτές είναι όλες μικρές, δυναμικά παραγόμενες, σελίδες HTML βασισμένες σε πληροφορίες που κρατούνται στη μνήμη. Οπότε οι απαντήσεις είναι πολύ γρήγορες.
• Επειδή οι αιτήσεις για πραγματικά δεδομένα γρήγορα ανακατευθύνονται στο άλλοERDDAPs, το σύνθετοERDDAP™μπορεί να ανταποκριθεί γρήγορα σε αιτήματα για πραγματικά δεδομένα χωρίς τη χρήση οποιουδήποτε χρόνου CPU, μνήμης, ή εύρους ζώνης.
• Μετατοπίζοντας όσο το δυνατόν περισσότερη εργασία (ΚΜΕ, μνήμη, εύρος ζώνης) από το CompositeERDDAP™προς την άλληERDDAPs, το σύνθετοERDDAP™μπορεί να φαίνεται ότι εξυπηρετεί δεδομένα από όλα τα σύνολα δεδομένων και ωστόσο εξακολουθεί να συμβαδίζει με πολύ μεγάλους αριθμούς αιτημάτων δεδομένων από μεγάλο αριθμό χρηστών.
• Προκαταρκτικές δοκιμές δείχνουν ότι το σύνθετοERDDAP™μπορεί να ανταποκριθεί στα περισσότερα αιτήματα σε ~1ms του χρόνου ΚΜΕ, ή 1000 αιτήματα / δευτερόλεπτο. Έτσι, ένας επεξεργαστής 8 πυρήνα θα πρέπει να είναι σε θέση να ανταποκριθεί σε περίπου 8000 αιτήματα / δευτερόλεπτο. Αν και είναι δυνατόν να οραματιστούμε εκρήξεις μεγαλύτερης δραστηριότητας που θα προκαλούσε επιβραδύνσεις, αυτό είναι πολύ αποτέλεσμα. Είναι πιθανό ότι το εύρος ζώνης του κέντρου δεδομένων θα είναι το σημείο συμφόρησης πολύ πριν το σύνθετοERDDAP™Γίνεται το εμπόδιο.

Ενημέρωση max (χρόνος) ♪ ♪

ΗEDDGrid/TableFromErddap στο σύνθετοERDDAP™αλλάζει μόνο τις αποθηκευμένες πληροφορίες του για κάθε σύνολο δεδομένων πηγής όταν το σύνολο δεδομένων πηγή είναι" επαναφόρτωσηκαι κάποιες αλλαγές μεταδεδομένων (π.χ. η μεταβλητή του χρόνουactual\_range) , με τον τρόπο αυτό προβαίνει σε κοινοποίηση συνδρομής. Εάν το σύνολο δεδομένων πηγής έχει δεδομένα που αλλάζουν συχνά (για παράδειγμα, νέα δεδομένα κάθε δευτερόλεπτο) και χρησιμοποιεί το" ενημέρωση"σύστημα για την παρατήρηση συχνών αλλαγών στα υποκείμενα δεδομένα,EDDGrid/TableFromErddap δεν θα ενημερωθεί σχετικά με αυτές τις συχνές αλλαγές μέχρι το επόμενο σύνολο δεδομένων " επαναφόρτωση", έτσι ώστε ηEDDGrid/TableFromErddap δεν θα είναι απολύτως ενημερωμένο. Μπορείτε να ελαχιστοποιήσετε αυτό το πρόβλημα αλλάζοντας το σύνολο δεδομένων της πηγής<reloadEveryNMinutes> σε μικρότερη τιμή (60; 15;) Έτσι ώστε να υπάρχουν περισσότερες κοινοποιήσεις συνδρομής για να πληροφορηθεί τοEDDGrid/TableFromErddap για να ενημερώσει τις πληροφορίες του σχετικά με το σύνολο δεδομένων πηγή.

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

1. Μην το χρησιμοποιείς.<updateEveryNMillis&gt· για τη διατήρηση του συνόλου των δεδομένων πηγής ενημερωμένων.
2. Ορισμός του συνόλου δεδομένων πηγής<reloadEveryNMinutes> σε μεγαλύτερο αριθμό (1440;) .
3. Βάλε το σενάριο να επικοινωνήσει με το σύνολο δεδομένων πηγήςURL σημαίαςαμέσως μετά την αντιγραφή ενός νέου αρχείου δεδομένων στη θέση του. Αυτό θα οδηγήσει στην πλήρη ενημέρωση του συνόλου των δεδομένων πηγής και θα προκαλέσει τη δημιουργία μιας κοινοποίησης εγγραφής, η οποία θα αποσταλεί στηνEDDGrid/TableFromErddap dataset. Αυτό θα οδηγήσει στηνEDDGrid/TableFromErddap dataset για να είναι απόλυτα ενημερωμένα (Λοιπόν, μέσα σε 5 δευτερόλεπτα από την προσθήκη νέων δεδομένων) . Και όλα αυτά θα γίνουν αποτελεσματικά. (χωρίς περιττές επαναφορτίσεις συνόλου δεδομένων) .

Πολλαπλή σύνθεσηERDDAPα

• Σε πολύ ακραίες περιπτώσεις, ή για την ανοχή σφαλμάτων, μπορεί να θέλετε να δημιουργήσετε περισσότερες από μία σύνθετεςERDDAP. Είναι πιθανό ότι άλλα μέρη του συστήματος (Ειδικότερα, το εύρος ζώνης του κέντρου δεδομένων) θα γίνει πρόβλημα πολύ πριν το σύνθετοERDDAP™Γίνεται εμπόδιο. Έτσι, η λύση είναι πιθανώς να δημιουργήσει πρόσθετα, γεωγραφικά ποικίλα κέντρα δεδομένων (καθρέφτες) , το καθένα με ένα σύνθετοERDDAP™και εξυπηρετητές μεERDDAPs και (τουλάχιστον) αντίγραφα αντιγράφων των συνόλων δεδομένων που έχουν μεγάλη ζήτηση. Μια τέτοια ρύθμιση παρέχει επίσης ανοχή σφαλμάτων και υποστήριξη δεδομένων (μέσω αντιγραφής) . Σε αυτή την περίπτωση, είναι καλύτερο αν το σύνθετοERDDAPΤα s έχουν διαφορετικές διευθύνσεις URL.

Αν πραγματικά θέλετε όλο το σύνθετοERDDAPs για να έχετε το ίδιο URL, χρησιμοποιήστε ένα σύστημα εμπρόσθιου άκρου που αναθέτει ένα δεδομένο χρήστη σε ένα μόνο από τα σύνθεταERDDAPα (με βάση τη διεύθυνση IP) , έτσι ώστε όλα τα αιτήματα του χρήστη πηγαίνει μόνο σε ένα από τα σύνθεταERDDAPΣ. Υπάρχουν δύο λόγοι:

• Όταν ένα υποκείμενο σύνολο δεδομένων επαναφορτίζεται και τα μεταδεδομένα αλλάζουν (π.χ., ένα νέο αρχείο δεδομένων σε ένα πλέγμα σύνολο δεδομένων προκαλεί τη μεταβλητή του χρόνουactual\_rangeγια αλλαγή) , το σύνθετοERDDAPs θα είναι προσωρινά ελαφρώς εκτός συγχρονισμού, αλλά μεΕνδεχόμενη συνέπεια. Κανονικά, θα ξανασυναντηθούν μέσα σε 5 δευτερόλεπτα, αλλά μερικές φορές θα είναι περισσότερο. Εάν ένας χρήστης κάνει ένα αυτοματοποιημένο σύστημα που βασίζεται σεERDDAP™συνδρομέςπου ενεργοποιούν ενέργειες, τα σύντομα προβλήματα συγχρονισμού θα γίνουν σημαντικά.
• Το σύνθετο 2+ERDDAPΚάθε συνδρομή διατηρεί τη δική του σειρά συνδρομών (λόγω του προβλήματος συγχρονισμού που περιγράφεται παραπάνω) .

Έτσι ένας δοσμένος χρήστης πρέπει να κατευθύνεται μόνο σε ένα από τα σύνθεταERDDAPιπ για την αποφυγή αυτών των προβλημάτων. Εάν ένα από τα σύνθεταERDDAPs κατεβαίνει, το εμπρόσθιο άκρο σύστημα μπορεί να ανακατευθύνει ότιERDDAPΟι χρήστες σε άλλοERDDAP™Αυτό είναι επάνω. Ωστόσο, εάν είναι ένα πρόβλημα δυναμικότητας που προκαλεί το πρώτο σύνθετοERDDAP™να αποτύχει (Ένας υπερβάλλον χρήστης; αεπίθεση άρνησης υπηρεσίας♪ ♪) , αυτό καθιστά πολύ πιθανό ότι ανακατευθύνοντας τους χρήστες του σε άλλα σύνθεταERDDAPθα προκαλέσειαστοχία κατά την κασκέτα. Έτσι, η πιο ισχυρή ρύθμιση είναι να έχουν σύνθετοERDDAPs με διαφορετικές διευθύνσεις URL.

Ή, ίσως καλύτερα, να δημιουργήσει πολλαπλά σύνθεταERDDAPs χωρίς εξισορρόπηση φορτίου. Σε αυτή την περίπτωση, θα πρέπει να κάνετε ένα σημείο να δώσει σε κάθε ένα από ταERDDAPs ένα διαφορετικό όνομα / ταυτότητα και, αν είναι δυνατόν, την εγκατάστασή τους σε διάφορα μέρη του κόσμου (π.χ., διαφορετικές περιφέρειες AWS) , π.χ.,ERD\_ΗΠΑ\_Ανατολικά,ERD\ΗΠΑ\Δυτικά,ERD\ΙΕ,ERD\_FR,ERD\_IT, έτσι ώστε οι χρήστες συνειδητά, επανειλημμένα εργάζονται με ένα συγκεκριμένοERDDAP.

• \[Για ένα συναρπαστικό σχεδιασμό ενός συστήματος υψηλών επιδόσεων που εκτελείται σε έναν εξυπηρετητή, δείτε αυτόλεπτομερή περιγραφή του Mailinator.\]

Datasets σε πολύ υψηλή ζήτηση

Στην πραγματικά ασυνήθιστη περίπτωση ότι ένα από τα Α , B , ή Γ ERDDAPΤα s δεν μπορούν να συμβαδίσουν με τα αιτήματα λόγω του εύρους ζώνης ή των περιορισμών του σκληρού δίσκου, είναι λογικό να αντιγράψετε τα δεδομένα (Ξανά.) σε έναν άλλο εξυπηρετητή+hard Μονάδα +ERDDAP, ίσως μεEDDGridΑντιγραφήή/καιEDDTableCopy. Ενώ μπορεί να φαίνεται ιδανικό να έχουμε το αρχικό σύνολο δεδομένων και το αντιγραφόμενο σύνολο δεδομένων να φαίνεται απρόσκοπτα ως ένα σύνολο δεδομένων στο σύνθετοERDDAP™, αυτό είναι δύσκολο επειδή τα δύο σύνολα δεδομένων θα είναι σε ελαφρώς διαφορετικές καταστάσεις σε διαφορετικές χρονικές στιγμές (Ειδικότερα, αφού το πρωτότυπο λάβει νέα δεδομένα, αλλά πριν το αντιγραφόμενο σύνολο δεδομένων λάβει το αντίγραφό του) . Ως εκ τούτου, συνιστώ να δοθούν στα σύνολα δεδομένων ελαφρώς διαφορετικοί τίτλοι (π.χ., "... (αντίγραφο # 1) " και "... (αντίγραφο # 2) ~ ή ίσως ~ (καθρέπτης # n ) " ή " (εξυπηρετητής # n ) ") και εμφανίζονται ως ξεχωριστά σύνολα δεδομένων στο σύνθετοERDDAP. Οι χρήστες χρησιμοποιούνται για να δουν τις λίστεςθέσεις καθρέπτησε δημοφιλείς ιστότοπους λήψης αρχείων, οπότε αυτό δεν θα πρέπει να τους εκπλήσσει ή να τους απογοητεύει. Λόγω των περιορισμών του εύρους ζώνης σε μια δεδομένη τοποθεσία, μπορεί να έχει νόημα να βρίσκεται ο καθρέφτης σε μια άλλη τοποθεσία. Αν το αντίγραφο καθρέφτη είναι σε ένα διαφορετικό κέντρο δεδομένων, προσπελάστηκε μόνο από το σύνθετο κέντρο δεδομένων τουERDDAP™, οι διαφορετικοί τίτλοι (Π.χ., "κατόπτρο #1) Δεν είναι απαραίτητο.

RAIDs έναντι κανονικών σκληρών δίσκων

Εάν ένα μεγάλο σύνολο δεδομένων ή μια ομάδα συνόλων δεδομένων δεν χρησιμοποιούνται σε μεγάλο βαθμό, μπορεί να έχει νόημα να αποθηκεύσετε τα δεδομένα σε ένα RAID δεδομένου ότι προσφέρει ανοχή ελαττωμάτων και δεδομένου ότι δεν χρειάζεστε την ισχύ επεξεργασίας ή το εύρος ζώνης ενός άλλου εξυπηρετητή. Αλλά αν ένα σύνολο δεδομένων χρησιμοποιείται σε μεγάλο βαθμό, μπορεί να έχει περισσότερο νόημα να αντιγράψετε τα δεδομένα σε έναν άλλο διακομιστή +ERDDAP™+ σκληρός δίσκος (παρόμοια μετι κάνει το Google) αντί να χρησιμοποιήσετε έναν εξυπηρετητή και ένα RAID για να αποθηκεύσετε πολλαπλά σύνολα δεδομένων, δεδομένου ότι μπορείτε να χρησιμοποιήσετε και τους δύο server+hardDrive+ERDDAPείναι στο πλέγμα μέχρι να αποτύχει ένας από αυτούς.

Αποτυχίες

Τι θα συμβεί αν...

• Υπάρχει μια έκρηξη αιτημάτων για ένα σύνολο δεδομένων (π.χ., όλοι οι μαθητές μιας τάξης ζητούν ταυτόχρονα παρόμοια δεδομένα) ♪ ♪ Μόνο ηERDDAP™η εξυπηρέτηση αυτού του συνόλου δεδομένων θα κατακλύζεται και θα επιβραδύνεται ή θα αρνείται τις αιτήσεις. Το σύνθετοERDDAP™και άλλαERDDAPΔεν θα επηρεαστεί. Δεδομένου ότι ο περιοριστικός παράγοντας για ένα δεδομένο σύνολο δεδομένων εντός του συστήματος είναι ο σκληρός δίσκος με τα δεδομένα (όχιERDDAP) , η μόνη λύση (όχι άμεσα) είναι να κάνει ένα αντίγραφο του συνόλου δεδομένων σε ένα διαφορετικό διακομιστή+hardDrive+ERDDAP.
• Α Α , B , ή Γ ERDDAP™αποτυχία (π.χ., αποτυχία του σκληρού δίσκου) ♪ ♪ Μόνο το σύνολο δεδομένων (α) Σερβίρεται από αυτόERDDAP™επηρεάζονται. Αν το σύνολο δεδομένων (α) καθρεφτίζεται σε έναν άλλο server+hardDrive+ERDDAP, το αποτέλεσμα είναι ελάχιστο. Αν το πρόβλημα είναι μια αποτυχία του σκληρού δίσκου σε επίπεδο 5 ή 6 RAID, απλά αντικαθιστάτε τον δίσκο και να έχετε το RAID ανακατασκευάσει τα δεδομένα του δίσκου.
• Το σύνθετοERDDAP™Αποτυγχάνει; Αν θέλετε να κάνετε ένα σύστημα με πολύυψηλή διαθεσιμότητα, μπορείτε να στήσετεπολλαπλών συνθέτωνERDDAPα (όπως αναφέρθηκε ανωτέρω) , χρησιμοποιώντας κάτι σανNGINXήΤραεφίκγια να χειριστεί την εξισορρόπηση φορτίου. Σημειώστε ότι ένα δεδομένο σύνθετοERDDAP™μπορεί να χειριστεί έναν πολύ μεγάλο αριθμό αιτημάτων από ένα μεγάλο αριθμό χρηστών, επειδή οι αιτήσεις για μεταδεδομένα είναι μικρές και χειρίζονται με πληροφορίες που είναι στη μνήμη, και αιτήσεις για δεδομένα (που μπορεί να είναι μεγάλα) ανακατευθύνονται στο παιδίERDDAPΣ.

Απλό, κλιμακωτό

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

Εύρος ζώνης

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

Συστατικό	Κατά προσέγγιση πλάτος ζώνης (GBytes/s)
μνήμη DDR	2. 5
Μονάδα SSD	1
Σκληρός δίσκος SATA	0,3
Έθερνετ Gigabit	0.1
OC-12	0.06
OC-3	0.015
Τ1	0.0002

Λοιπόν, ένας σκληρός δίσκος της SATA (0, 3GB/s) σε έναν εξυπηρετητή με έναERDDAP™μπορεί πιθανώς να κορεστεί ένα Gigabit Ethernet LAN (0.1GB/s) . Και ένα Gigabit Ethernet LAN (0.1GB/s) μπορεί πιθανώς να κορεστεί μια σύνδεση OC-12 στο Internet (0.06GB/s) . Και τουλάχιστον μια πηγή απαριθμεί OC-12 γραμμές κοστίζει περίπου 100.000 δολάρια το μήνα. (Ναι, αυτοί οι υπολογισμοί βασίζονται στην ώθησι του συστήματος στα όριά του, πράγμα που δεν είναι καλό διότι οδηγεί σε πολύ οκνηρές αντιδράσεις. Αλλά αυτοί οι υπολογισμοί είναι χρήσιμοι για τον σχεδιασμό και την εξισορρόπηση τμημάτων του συστήματος.) Σαφώς, μια κατάλληλα γρήγορη σύνδεση στο Internet για το data center σας είναι μακράν το πιο ακριβό μέρος του συστήματος. Μπορείτε εύκολα και σχετικά φθηνά να χτίσετε ένα πλέγμα με μια ντουζίνα servers τρέχει μια ντουζίναERDDAPs που είναι σε θέση να αντλήσει πολλά δεδομένα γρήγορα, αλλά μια κατάλληλα γρήγορη σύνδεση στο Internet θα είναι πολύ, πολύ ακριβό. Οι επιμέρους λύσεις είναι:

• Ενθάρρυνση των πελατών να ζητήσουν υποσύνολα των δεδομένων, εάν αυτό είναι το μόνο που χρειάζεται. Εάν ο πελάτης χρειάζεται μόνο δεδομένα για μια μικρή περιοχή ή σε χαμηλότερη ανάλυση, αυτό πρέπει να ζητήσει. Η υποκατάσταση είναι ένα κεντρικό επίκεντρο των πρωτοκόλλωνERDDAP™υποστηρίζει την αίτηση δεδομένων.
• Ενθάρρυνση μετάδοσης συμπιεσμένων δεδομένων.ERDDAP™ συμπιεστέςδιαβίβαση δεδομένων, εάν διαπιστώσει " αποδοχή-κωδικοποίηση" στοHTTP GETαίτηση κεφαλίδας. Όλα τα προγράμματα περιήγησης web χρησιμοποιούν "αποδοχή-κωδικοποίηση" και αποσυμπιέζουν αυτόματα την απόκριση. Άλλοι πελάτες (π.χ. προγράμματα ηλεκτρονικών υπολογιστών) Πρέπει να το χρησιμοποιήσω ρητά.
• Κολλήστε τους διακομιστές σας σε ένα ISP ή άλλο site που προσφέρει σχετικά λιγότερο ακριβό κόστος εύρους ζώνης.
• Διαλύστε τους διακομιστές με τοERDDAP s σε διαφορετικά ιδρύματα, ώστε να διασπαστούν τα έξοδα. Μπορείτε στη συνέχεια να συνδέσετε το σύνθετο σαςERDDAP™προς τουςERDDAPΣ.

Σημειώστε ότιΥπολογισμός Cloudκαι web hosting υπηρεσίες προσφέρουν όλο το εύρος ζώνης Internet που χρειάζεστε, αλλά δεν λύνουν το πρόβλημα της τιμής.

Για γενικές πληροφορίες σχετικά με το σχεδιασμό κλιμακωτών, υψηλής χωρητικότητας, ελαττωματικών συστημάτων, δείτε το βιβλίο του Michael T. NygardΕλευθέρωσέ το.

Σαν τον Λέγκο.

Οι σχεδιαστές λογισμικού συχνά προσπαθούν να χρησιμοποιήσουν το καλόπρότυπα σχεδιασμού λογισμικούνα λύσω προβλήματα. Τα καλά μοτίβα είναι καλά γιατί ενσωματώνουν καλές, εύκολες στη δημιουργία και την εργασία, λύσεις γενικής χρήσης που οδηγούν σε συστήματα με καλές ιδιότητες. Τα ονόματα προτύπων δεν είναι τυποποιημένα, οπότε θα ονομάσω το μοτίβο πουERDDAP™χρησιμοποιεί το Lego Pattern. Κάθε Lego (κάθεERDDAP) είναι ένα απλό, μικρό, πρότυπο, αυτόνομη, τούβλο (Διακομιστής δεδομένων) με καθορισμένη διεπαφή που επιτρέπει τη σύνδεση της με άλλα legos (ERDDAPα) . Τα μέρη τηςERDDAP™που αποτελούν αυτό το σύστημα είναι: τα συστήματα συνδρομών και flagURL (που επιτρέπει την επικοινωνία μεταξύERDDAPα) Ο EDD... Από το σύστημα ανακατεύθυνσης Erddap, και το σύστημα τουRESTfulαιτήσεις για δεδομένα που μπορούν να παραχθούν από χρήστες ή άλλουςERDDAPΣ. Έτσι, σε δύο ή περισσότερα legos (ERDDAPα) , μπορείτε να δημιουργήσετε ένα τεράστιο αριθμό διαφορετικών σχημάτων (Τοπολογίες δικτύουERDDAPα) . Σίγουρα, ο σχεδιασμός και τα χαρακτηριστικά τουERDDAP™θα μπορούσε να είχε γίνει διαφορετικά, όχι Lego-όπως, ίσως μόνο για να επιτρέψει και να βελτιστοποιήσει για μια συγκεκριμένη τοπολογία. Αλλά αισθανόμαστε ότιERDDAPΤο Lego-like design προσφέρει μια καλή, γενική λύση που επιτρέπει οποιαδήποτεERDDAP™διαχειριστής (ή ομάδα διαχειριστών) να δημιουργήσει κάθε είδους ομοσπονδιακές τοπολογίες. Για παράδειγμα, μια ενιαία οργάνωση θα μπορούσε να δημιουργήσει τρεις (ή περισσότερο) ERDDAPόπως φαίνεται στοERDDAP™Διάγραμμα πλέγματος/κλίστρας παραπάνω. Ή μια κατανεμημένη ομάδα (- Ναι. Ακτοφυλακή; ΝΣΙ; ΝΔ;NOAA♪ ♪ Το USGS; Ντέιταον; Νήον; - Ο Λότερ; Εντάξει; BODC; ΟΝC; ΚΚΕ; WMO;) μπορεί να δημιουργήσει έναERDDAP™σε κάθε μικρό φυλάκιο (ώστε τα δεδομένα να μείνουν κοντά στην πηγή) και στη συνέχεια να δημιουργήσει ένα σύνθετοERDDAP™στο κεντρικό γραφείο με εικονικά σύνολα δεδομένων (που είναι πάντα απόλυτα ενημερωμένα) από κάθε μικρό φυλάκιοERDDAPΣ. Πράγματι, όλαERDDAPs, εγκατεστημένα σε διάφορα ιδρύματα σε όλο τον κόσμο, τα οποία λαμβάνουν δεδομένα από άλλαERDDAPs ή/και να παρέχουν δεδομένα σε άλλαERDDAPs, αποτελούν ένα γιγαντιαίο δίκτυοERDDAPΣ. Πόσο γαμάτο είναι αυτό;! Έτσι, όπως και με του Lego, οι πιθανότητες είναι ατελείωτες. Γι' αυτό είναι καλό μοτίβο. Γι' αυτό είναι καλό σχέδιο.ERDDAP.

Διαφορετικοί τύποι αιτήσεων

Μία από τις επιπλοκές της πραγματικής ζωής αυτής της συζήτησης των τοπολογιών διακομιστή δεδομένων είναι ότι υπάρχουν διαφορετικοί τύποι αιτημάτων και διαφορετικοί τρόποι για να βελτιστοποιηθεί για τους διάφορους τύπους αιτημάτων. Αυτό είναι κυρίως ένα ξεχωριστό ζήτημα. (Πόσο γρήγορα μπορεί τοERDDAP™με τα δεδομένα να ανταποκρίνονται στην αίτηση για δεδομένα;) από τη συζήτηση της τοπολογίας (που ασχολείται με τις σχέσεις μεταξύ των εξυπηρετητών δεδομένων και ποιος διακομιστής έχει τα πραγματικά δεδομένα) .ERDDAP™, φυσικά, προσπαθεί να αντιμετωπίσει όλα τα είδη των αιτήσεων αποτελεσματικά, αλλά χειρίζεται μερικά καλύτερα από άλλα.

• Πολλά αιτήματα είναι απλά. Για παράδειγμα: Ποια είναι τα μεταδεδομένα για αυτό το σύνολο δεδομένων; Ή: Ποιες είναι οι τιμές της χρονικής διάστασης για αυτό το πλέγμα δεδομένων;ERDDAP™έχει σχεδιαστεί για να χειριστεί αυτά όσο το δυνατόν γρηγορότερα (συνήθως σε<=2 ms) διατηρώντας αυτές τις πληροφορίες στη μνήμη.  
• Μερικά αιτήματα είναι μέτρια σκληρά. Για παράδειγμα: Δώσε μου αυτό το υποσύνολο ενός συνόλου δεδομένων (το οποίο βρίσκεται σε ένα αρχείο δεδομένων) . Αυτά τα αιτήματα μπορούν να αντιμετωπιστούν σχετικά γρήγορα επειδή δεν είναι τόσο δύσκολα.  
• Μερικά αιτήματα είναι δύσκολα και συνεπώς καταναλώνουν χρόνο. Για παράδειγμα: Δώσε μου αυτό το υποσύνολο ενός συνόλου δεδομένων (που μπορεί να είναι σε οποιοδήποτε από τα αρχεία δεδομένων 10.000+, ή μπορεί να είναι από συμπιεσμένα αρχεία δεδομένων που το καθένα παίρνει 10 δευτερόλεπτα για να αποσυμπίεση) .ERDDAP™v2.0 εισήγαγε ορισμένους νέους, ταχύτερους τρόπους για την αντιμετώπιση αυτών των αιτημάτων, ιδίως επιτρέποντας στο νήμα που χειρίζεται το αίτημα να παράγει διάφορα νήματα εργαζομένων που αντιμετωπίζουν διαφορετικά υποσύνολα του αιτήματος. Αλλά υπάρχει μια άλλη προσέγγιση σε αυτό το πρόβλημα πουERDDAP™δεν υποστηρίζει ακόμη: υποσύνολα των αρχείων δεδομένων για ένα δεδομένο σύνολο δεδομένων θα μπορούσαν να αποθηκευτούν και να αναλυθούν σε ξεχωριστούς υπολογιστές, και στη συνέχεια τα αποτελέσματα συνδυασμένα στον αρχικό εξυπηρετητή. Αυτή η προσέγγιση ονομάζεταιΜείωση χάρτηκαι αποτελεί παράδειγμαΧαντουπ, η πρώτη (♪ ♪) Open-source MapReduce program, το οποίο βασίστηκε σε ιδέες από ένα έγγραφο της Google. (Εάν χρειάζεστε MapReduce inERDDAP, παρακαλώ στείλτε ένα αίτημα ηλεκτρονικού ταχυδρομείουerd.data at noaa.gov.) Στο GoogleΜεγάλο Queryείναι ενδιαφέρον, διότι φαίνεται να είναι μια εφαρμογή του MapReduce που εφαρμόζεται στην υποκατάσταση συνόλων δεδομένων πίνακα, το οποίο είναι ένα από ταERDDAPΟι κύριοι στόχοι. Είναι πιθανό ότι μπορείτε να δημιουργήσετε έναERDDAP™σύνολο δεδομένων από ένα σύνολο δεδομένων BigQuery μέσωΠίνακας EDD από τη βάση δεδομένωνεπειδή το BigQuery μπορεί να έχει πρόσβαση μέσω μιας διασύνδεσης JDBC.

Αυτές είναι οι απόψεις μου.

Ναι, οι υπολογισμοί είναι απλοϊκοί (και τώρα ελαφρώς χρονολογημένα) , αλλά νομίζω ότι τα συμπεράσματα είναι σωστά. Χρησιμοποίησα λάθος λογική ή έκανα λάθος στους υπολογισμούς μου; Αν ναι, το λάθος είναι δικό μου και μόνο. Παρακαλώ στείλτε ένα email με τη διόρθωσηerd dot data at noaa dot gov.

• • Ναι.

Υπολογισμός Cloud

Αρκετές εταιρείες προσφέρουν υπηρεσίες υπολογιστικής cloud (π.χ.,Υπηρεσίες διαδικτύου του AmazonκαιΠλατφόρμα Google Cloud) .Εταιρείες φιλοξενίας ιστοσελίδωνέχουν προσφέρει απλούστερες υπηρεσίες από τα μέσα της δεκαετίας του 1990, αλλά οι υπηρεσίες "σύννεφο" έχουν επεκτείνει σε μεγάλο βαθμό την ευελιξία των συστημάτων και το φάσμα των υπηρεσιών που προσφέρονται. Από τηνERDDAP™πλέγμα αποτελείται μόνο απόERDDAPιπ και απόERDDAPίναJavaweb εφαρμογές που μπορούν να τρέξουν σε Tomcat (ο πιο κοινός εξυπηρετητής εφαρμογών) ή άλλους διακομιστές εφαρμογών, θα πρέπει να είναι σχετικά εύκολο να συσταθεί έναERDDAP™δίκτυο σε μια υπηρεσία cloud ή ιστοσελίδα φιλοξενίας. Τα πλεονεκτήματα αυτών των υπηρεσιών είναι:

• Προσφέρουν πρόσβαση σε πολύ υψηλής ζώνης συνδέσεις στο Διαδίκτυο. Αυτό και μόνο μπορεί να δικαιολογήσει τη χρήση αυτών των υπηρεσιών.
• Χρεώνουν μόνο τις υπηρεσίες που χρησιμοποιείς. Για παράδειγμα, μπορείτε να αποκτήσετε πρόσβαση σε ένα πολύ υψηλό εύρος ζώνης σύνδεσης στο Internet, αλλά πληρώνετε μόνο για πραγματικά δεδομένα που μεταφέρονται. Αυτό σε αφήνει να φτιάξεις ένα σύστημα που σπάνια κατακλύζεται. (ακόμη και σε μέγιστη ζήτηση) , χωρίς να χρειάζεται να πληρώσει για την ικανότητα που χρησιμοποιείται σπάνια.
• Είναι εύκολα επεκτάσιμα. Μπορείτε να αλλάξετε τους τύπους server ή να προσθέσετε όσες servers ή όσες αποθήκευση θέλετε, σε λιγότερο από ένα λεπτό. Αυτό και μόνο μπορεί να δικαιολογήσει τη χρήση αυτών των υπηρεσιών.
• Σας απαλλάσσουν από πολλά από τα διοικητικά καθήκοντα λειτουργίας των servers και των δικτύων. Αυτό και μόνο μπορεί να δικαιολογήσει τη χρήση αυτών των υπηρεσιών.

Τα μειονεκτήματα αυτών των υπηρεσιών είναι:

• Χρεώνουν για τις υπηρεσίες τους, μερικές φορές πολύ. (Όχι ότι δεν είναι καλή τιμή.) . Οι τιμές που αναφέρονται εδώ είναι γιαAmazon EC2. Οι τιμές αυτές (από τον Ιούνιο του 2015) Θα κατέβει κάτω. Στο παρελθόν, οι τιμές ήταν υψηλότερες, αλλά τα αρχεία δεδομένων και ο αριθμός των αιτήσεων ήταν μικρότερος. Στο μέλλον, οι τιμές θα είναι χαμηλότερες, αλλά τα αρχεία δεδομένων και ο αριθμός των αιτήσεων θα είναι μεγαλύτερος. Οι λεπτομέρειες αλλάζουν, αλλά η κατάσταση παραμένει σχετικά σταθερή. Και δεν είναι ότι η υπηρεσία είναι υπερτιμημένη, είναι ότι χρησιμοποιούμε και αγοράζουμε πολλά από την υπηρεσία.
  • Μεταφορά δεδομένων — Οι μεταφορές δεδομένων στο σύστημα είναι πλέον ελεύθερες (Ναι!) . Οι μεταφορές δεδομένων εκτός συστήματος είναι $0.09/GB. Ένας σκληρός δίσκος SATA (0, 3GB/s) σε έναν εξυπηρετητή με έναERDDAP™μπορεί πιθανώς να κορεστεί ένα Gigabit Ethernet LAN (0.1GB/s) . Ένα Gigabit Ethernet LAN (0.1GB/s) μπορεί πιθανώς να κορεστεί μια σύνδεση OC-12 στο Internet (0.06GB/s) . Εάν μια σύνδεση OC-12 μπορεί να μεταδώσει ~150.000 GB/μήνα, το κόστος μεταφοράς δεδομένων μπορεί να είναι μέχρι 150.000 GB @ $0.09/GB = $13.500/μήνα, το οποίο είναι ένα σημαντικό κόστος. Προφανώς, αν έχετε μια ντουζίνα σκληρά εργαζόμενουςERDDAPs σε υπηρεσία cloud, τα μηνιαία τέλη μεταφοράς δεδομένων μπορεί να είναι σημαντικά (έως 162,000 δολάρια/μήνα) . (Και πάλι, δεν είναι ότι η υπηρεσία είναι υπερτιμημένη, είναι ότι χρησιμοποιούμε και αγοράζουμε πολλά από την υπηρεσία.)
  • Η LuxOpCo θα πρέπει να έχει πρόσβαση σε πληροφορίες σχετικά με την ποιότητα των δεδομένων. (Συγκρίνετε αυτό με την αγορά μιας επιχείρησης 4TB οδηγεί οριακά για ~ $ 50/TB, αν και το RAID για να το θέσει και τα διοικητικά έξοδα να προσθέσετε στο συνολικό κόστος.) Έτσι, αν πρέπει να αποθηκεύσετε πολλά δεδομένα στο σύννεφο, μπορεί να είναι αρκετά ακριβά (π.χ., 100TB θα κόστιζε $500/μήνα) . Αλλά αν δεν έχετε ένα πραγματικά μεγάλο ποσό των δεδομένων, αυτό είναι ένα μικρότερο θέμα από το κόστος ζώνης / μεταφοράς δεδομένων. (Και πάλι, δεν είναι ότι η υπηρεσία είναι υπερτιμημένη, είναι ότι χρησιμοποιούμε και αγοράζουμε πολλά από την υπηρεσία.)
     

Υποκατάσταση

• Το πρόβλημα υποκατάστασης: Ο μόνος τρόπος για να διανείμουμε αποτελεσματικά δεδομένα από αρχεία δεδομένων είναι να έχουμε το πρόγραμμα που διανέμει τα δεδομένα (π.χ.,ERDDAP) εκτέλεση σε εξυπηρετητή ο οποίος έχει τα δεδομένα αποθηκευμένα σε τοπικό σκληρό δίσκο (ή παρόμοια γρήγορη πρόσβαση σε SAN ή τοπικό RAID) . Τα τοπικά συστήματα αρχείων επιτρέπουνERDDAP™ (και υποκείμενες βιβλιοθήκες, όπως το netcdf-java) να ζητήσει συγκεκριμένα byte κυμαίνεται από τα αρχεία και να πάρει απαντήσεις πολύ γρήγορα. Πολλά είδη αιτημάτων δεδομένωνERDDAP™στο αρχείο (ιδίως αιτήματα δεδομένων με πλέγμα όταν η τιμή διασκελισμού είναι > 1) δεν μπορεί να γίνει αποτελεσματικά αν το πρόγραμμα πρέπει να ζητήσει ολόκληρο το αρχείο ή μεγάλα κομμάτια ενός αρχείου από ένα μη τοπικό (ως εκ τούτου πιο αργά) σύστημα αποθήκευσης δεδομένων και στη συνέχεια να εξαγάγετε ένα υποσύνολο. Αν το σύννεφο δεν δώσειERDDAP™γρήγορη πρόσβαση στις σειρές byte των αρχείων (τόσο γρήγορα όσο με τα τοπικά αρχεία) ,ERDDAPΗ πρόσβαση στα δεδομένα θα είναι μια σοβαρή συμφόρηση και θα αναιρεί άλλα οφέλη από τη χρήση μιας υπηρεσίας cloud.

Δεσμευμένα δεδομένα

Μια εναλλακτική λύση στην παραπάνω ανάλυση κόστους-οφέλους (που βασίζεται στον ιδιοκτήτη των δεδομένων (π.χ.,NOAA) για την πληρωμή των δεδομένων τους που αποθηκεύονται στο νέφος) έφτασε γύρω στο 2012, όταν Amazon (και σε μικρότερο βαθμό, κάποιοι άλλοι πάροχοι cloud) άρχισαν να φιλοξενούν κάποια σύνολα δεδομένων στο σύννεφο τους (AWS S3) δωρεάν (Προφανώς, με την ελπίδα ότι θα μπορούσαν να ανακτήσουν το κόστος τους εάν οι χρήστες ενοικιάσουν AWS EC2 υπολογίσουν περιπτώσεις για να συνεργαστούν με τα δεδομένα αυτά) . Σαφώς, αυτό καθιστά το cloud computing πολύ πιο οικονομικά αποτελεσματικό, επειδή ο χρόνος και το κόστος αποστολής των δεδομένων και φιλοξενίας είναι τώρα μηδέν. ΜεERDDAP™v2.0, υπάρχουν νέα χαρακτηριστικά που διευκολύνουν την εκτέλεσηERDDAPσε ένα σύννεφο:

• Τώρα,EDDGridFromFiles ή EDDTableFromFiles dataset μπορεί να δημιουργηθεί από αρχεία δεδομένων που είναι απομακρυσμένα και προσβάσιμα μέσω του διαδικτύου (π.χ. κουβάδες AWS S3) με τη χρήση του<cacheFromUrl&gt, και<Μέγεθος cache GB> επιλογές.ERDDAP™θα διατηρήσει μια τοπική κρύπτη των πιο πρόσφατα χρησιμοποιημένων αρχείων δεδομένων.
• Τώρα, αν κάποια αρχεία πηγαίου κώδικα EDDTableFromFiles συμπιέζονται (π.χ.,.tgz) ,ERDDAP™θα αποσυμπιέσουν αυτόματα όταν τα διαβάσει.
• Τώρα, τοERDDAP™το νήμα που ανταποκρίνεται σε ένα δεδομένο αίτημα θα γεννά νήματα εργαζομένων για να εργαστούν σε υποενότητες του αιτήματος, εάν χρησιμοποιείτε το<nThreads> επιλογές. Αυτή η παραλληλοποίηση θα επιτρέψει την ταχύτερη ανταπόκριση σε δύσκολα αιτήματα.

Αυτές οι αλλαγές λύνουν το πρόβλημα του AWS S3 που δεν προσφέρει τοπική, block-level αποθήκευση αρχείων και το (παλιά) πρόβλημα πρόσβασης σε δεδομένα S3 με σημαντική καθυστέρηση. (Πριν από χρόνια (~2014) , ότι η υστέρηση ήταν σημαντική, αλλά είναι τώρα πολύ μικρότερη και έτσι όχι τόσο σημαντική.) Συνολικά, σημαίνει ότι το στήσιμοERDDAP™Στο σύννεφο λειτουργεί πολύ καλύτερα τώρα.

Ευχαριστώ. — Πολλές ευχαριστίες προς τον Matthew Arrott και την ομάδα του στην αρχική προσπάθεια OOI για το έργο τους σχετικά με τηνERDDAP™στο σύννεφο και τις συζητήσεις που προκύπτουν.  

• • Ναι.

Απομακρυσμένη αντιγραφή συνόλων δεδομένων

Υπάρχει ένα κοινό πρόβλημα που σχετίζεται με την παραπάνω συζήτηση για τα δίκτυα και τις ομοσπονδίεςERDDAPs: απομακρυσμένη αντιγραφή συνόλων δεδομένων. Το βασικό πρόβλημα είναι: ένας πάροχος δεδομένων διατηρεί ένα σύνολο δεδομένων που αλλάζει περιστασιακά και ένας χρήστης θέλει να διατηρήσει ένα ενημερωμένο τοπικό αντίγραφο αυτού του συνόλου δεδομένων (για διάφορους λόγους) . Είναι σαφές ότι υπάρχουν πάρα πολλές παραλλαγές σε αυτό. Μερικές παραλλαγές είναι πολύ πιο δύσκολο να αντιμετωπιστούν από άλλες.

• Γρήγορη ενημέρωση Είναι πιο δύσκολο να κρατάς τα τοπικά δεδομένα ενημερωμένα. αμέσως (π.χ. εντός 3 δευτερολέπτων) μετά από κάθε αλλαγή στην πηγή, αντί, για παράδειγμα, μέσα σε λίγες ώρες.  
• Συχνές αλλαγές Οι συχνές αλλαγές είναι πιο δύσκολο να αντιμετωπιστούν από τις σπάνιες αλλαγές. Για παράδειγμα, οι αλλαγές μιας φοράς την ημέρα είναι πολύ πιο εύκολο να αντιμετωπιστούν από τις αλλαγές κάθε 0,1 δευτερόλεπτο.  
• Μικρές αλλαγές Οι μικρές αλλαγές σε ένα πηγαίο αρχείο είναι δυσκολότερο να αντιμετωπιστούν από ένα εντελώς νέο αρχείο. Αυτό ισχύει ιδιαίτερα αν οι μικρές αλλαγές μπορεί να είναι οπουδήποτε στο αρχείο. Οι μικρές αλλαγές είναι δυσκολότερο να ανιχνευθούν και καθιστούν δύσκολη την απομόνωση των δεδομένων που πρέπει να αναπαραχθούν. Τα νέα αρχεία είναι εύκολο να ανιχνευθούν και αποτελεσματικά στη μεταφορά.  
• Ολόκληρο σύνολο δεδομένων Η διατήρηση ενός ολόκληρου συνόλου δεδομένων επίκαιρων είναι δυσκολότερη από τη διατήρηση μόνο πρόσφατων δεδομένων. Μερικοί χρήστες χρειάζονται απλά πρόσφατα δεδομένα (π.χ. η αξία των τελευταίων 8 ημερών) .  
• Πολλαπλά αντίγραφα Η διατήρηση πολλών απομακρυσμένων αντιγράφων σε διαφορετικές τοποθεσίες είναι δυσκολότερη από τη διατήρηση ενός απομακρυσμένου αντιγράφου. Αυτό είναι το πρόβλημα της κλιμάκωσης.  

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

ΣχετικόERDDAP™Εργαλεία

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

• ERDDAPΣRSS (Πλούσια Περίληψη Ιστοσελίδας;) υπηρεσία
  προσφέρει ένα γρήγορο τρόπο για να ελέγξετε αν ένα σύνολο δεδομένων σε ένα απομακρυσμένοERDDAP™έχει αλλάξει.  
• ERDDAPΣσυνδρομητική υπηρεσία
  είναι μια πιο αποτελεσματική (απόRSS) προσέγγιση: θα στείλει αμέσως ένα email ή θα επικοινωνήσει με ένα URL σε κάθε συνδρομητή όποτε το σύνολο δεδομένων ενημερώνεται και η ενημέρωση έχει ως αποτέλεσμα μια αλλαγή. Είναι αποτελεσματικό να συμβαίνει το συντομότερο δυνατόν και δεν υπάρχει χαμένη προσπάθεια (Όπως και με τη δημοσκόπησηRSSυπηρεσία) . Οι χρήστες μπορούν να χρησιμοποιήσουν άλλα εργαλεία (ΌπωςΙFTTT) να αντιδράσουν στις ειδοποιήσεις ηλεκτρονικού ταχυδρομείου από το σύστημα συνδρομής. Για παράδειγμα, ένας χρήστης θα μπορούσε να εγγραφεί σε ένα σύνολο δεδομένων σε ένα απομακρυσμένοERDDAP™και να χρησιμοποιήσετε IFTTT για να αντιδράσετε στις ειδοποιήσεις email συνδρομής και να ενεργοποιήσετε την ενημέρωση του τοπικού συνόλου δεδομένων.  
• ERDDAPΣσύστημα σημαίας
  παρέχει έναν τρόπο για μιαERDDAP™διαχειριστής να ενημερώσει ένα σύνολο δεδομένων για το/τηνERDDAPνα ξαναγεμίσει αμέσως. Η μορφή URL μιας σημαίας μπορεί εύκολα να χρησιμοποιηθεί σε σενάρια. Η μορφή URL μιας σημαίας μπορεί επίσης να χρησιμοποιηθεί ως ενέργεια για μια συνδρομή.  
• ERDDAPΣ"files"σύστημα
  μπορεί να προσφέρει πρόσβαση στα αρχεία πηγής για ένα δεδομένο σύνολο δεδομένων, συμπεριλαμβανομένου ενός καταλόγου τύπου Apache λίστα των αρχείων (A "Web Accessible Φάκελος") που έχει το URL λήψης του κάθε αρχείου, την τελευταία τροποποιημένη ώρα, και το μέγεθος. Ένα μειονέκτημα της χρήσης του"files"σύστημα είναι ότι τα αρχεία πηγαίου κώδικα μπορεί να έχουν διαφορετικά μεταβλητά ονόματα και διαφορετικά μεταδεδομένα από το σύνολο δεδομένων όπως εμφανίζεται στοERDDAP. Αν ένα τηλεχειριστήριοERDDAP™Το dataset προσφέρει πρόσβαση στα πηγαία του αρχεία, που ανοίγει τη δυνατότητα έκδοσης του rsync ενός φτωχού: γίνεται εύκολο για ένα τοπικό σύστημα να δει ποια απομακρυσμένα αρχεία έχουν αλλάξει και πρέπει να μεταφορτωθούν. (Δείτε τοεπιλογή cacheFromUrlκάτω από το οποίο μπορεί να χρησιμοποιηθεί αυτό.)
   

Λύσεις

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

Προσαρμοσμένες Λύσεις Δύναμης

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

• Οι προσαρμοσμένες λύσεις είναι πολλή δουλειά.
• Οι προσαρμοσμένες λύσεις είναι συνήθως τόσο προσαρμοσμένες σε ένα δεδομένο σύνολο δεδομένων και δεδομένου του συστήματος του χρήστη που δεν μπορούν εύκολα να επαναχρησιμοποιηθούν.
• Προσαρμοσμένες λύσεις πρέπει να κατασκευαστούν και να διατηρηθούν από εσάς. (Δεν είναι καλή ιδέα. Είναι πάντα καλή ιδέα να αποφεύγεις τη δουλειά και να βάζεις κάποιον άλλον να κάνει τη δουλειά!)

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

rsync

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

1. κάποιο γεγονός (π.χ.ERDDAP™εκδήλωση συστήματος συνδρομής) ενεργοποιήσεις λειτουργίας rsync, (ή, μια εργασία cron τρέχει rsync σε συγκεκριμένες φορές καθημερινά στον υπολογιστή του χρήστη)
2. το οποίο έρχεται σε επαφή με τον υπολογιστή πηγής,
3. που υπολογίζει μια σειρά από χασίς για κομμάτια του κάθε αρχείου και μεταδίδει αυτά τα χασίς στο rsync του χρήστη,
4. που συγκρίνει τις πληροφορίες αυτές με τις παρόμοιες πληροφορίες για το αντίγραφο των αρχείων του χρήστη,
5. που τότε ζητά τα κομμάτια των αρχείων που έχουν αλλάξει.

Λαμβάνοντας υπόψη όλα όσα κάνει, Rsync λειτουργεί πολύ γρήγορα (π.χ. 10 δευτερόλεπτα συν χρόνο μεταφοράς δεδομένων) και πολύ αποτελεσματικά. Υπάρχουν.Παραλλαγές του rsyncπου βελτιστοποιούν για διαφορετικές καταστάσεις (π.χ. προυπολογίζοντας και κόβοντας τα κομμάτια κάθε πηγαίου αρχείου) .

Οι κύριες αδυναμίες της rsync είναι: χρειάζεται κάποια προσπάθεια για τη δημιουργία (θέματα ασφάλειας) ; υπάρχουν κάποια προβλήματα κλιμάκωση? και δεν είναι καλό για τη διατήρηση NRT σύνολα δεδομένων πραγματικά ενημερωμένη (π.χ., είναι άβολο να χρησιμοποιείτε rsync περισσότερο από περίπου κάθε 5 λεπτά) . Αν μπορείτε να αντιμετωπίσετε τις αδυναμίες, ή αν δεν επηρεάζουν την κατάστασή σας, rsync είναι μια εξαιρετική, γενική λύση σκοπού που ο καθένας μπορεί να χρησιμοποιήσει αυτή τη στιγμή για να λύσει πολλά σενάρια που περιλαμβάνουν απομακρυσμένη αντιγραφή των συνόλων δεδομένων.

Υπάρχει ένα θέμα σχετικά με τοERDDAP™Για να κάνετε λίστα για να προσπαθήσετε να προσθέσετε υποστήριξη για τις υπηρεσίες rsync σεERDDAP (πιθανώς μια αρκετά δύσκολη εργασία) , έτσι ώστε κάθε πελάτης μπορεί να χρησιμοποιήσει rsync (ή παραλλαγή) να διατηρεί ενημερωμένο αντίγραφο συνόλου δεδομένων. Αν κάποιος θέλει να δουλέψει σε αυτό, παρακαλώ στείλε μου email.erd.data at noaa.gov.

Υπάρχουν και άλλα προγράμματα που κάνουν περισσότερο ή λιγότερο αυτό που κάνει ο rsync, μερικές φορές προσανατολισμένα στην αντιγραφή συνόλου δεδομένων (αν και συχνά σε επίπεδο αρχείου) , π.χ.,UnidataΣΔΑΚ.

λανθάνουσα μνήμη από το Url

Η cacheFromUrlη ρύθμιση είναι διαθέσιμη (αρχίζοντας μεERDDAP™v2.0) για όλουςERDDAPΤύποι συνόλου δεδομένων που κάνουν σύνολα δεδομένων από αρχεία (Βασικά, όλες οι υποκλάσειςEDDGridΑπό αρχείακαιΠίνακας EDD από αρχεία) . κρύπτη FromUrl καθιστά ασήμαντη την αυτόματη λήψη και διατήρηση των τοπικών αρχείων δεδομένων με την αντιγραφή τους από μια απομακρυσμένη πηγή μέσω της cache Από τη ρύθμιση URL. Τα απομακρυσμένα αρχεία μπορούν να είναι σε έναν προσιτό φάκελο Web ή μια λίστα αρχείων που μοιάζει με κατάλογο που προσφέρεται από THREDDS,Hyrax, κάδος S3, ήERDDAPΣ"files"σύστημα.

Αν η πηγή των απομακρυσμένων αρχείων είναι απομακρυσμένηERDDAP™σύνολο δεδομένων που προσφέρει τα πηγαία αρχεία μέσω τουERDDAP™ "files"σύστημα, τότε μπορείτεεγγραφήστο απομακρυσμένο σύνολο δεδομένων και χρησιμοποιήστε τοURL σημαίαςγια το τοπικό σας σύνολο δεδομένων ως τη δράση για την εγγραφή. Στη συνέχεια, κάθε φορά που το απομακρυσμένο σύνολο δεδομένων αλλάζει, θα επικοινωνήσει με το URL της σημαίας για το σύνολο δεδομένων σας, το οποίο θα του πει να επαναφορτώσει το ASAP, το οποίο θα ανιχνεύσει και θα κατεβάσει τα αλλαγμένα απομακρυσμένα αρχεία δεδομένων. Όλα αυτά συμβαίνουν πολύ γρήγορα. (συνήθως ~5 δευτερόλεπτα συν το χρόνο που απαιτείται για τη λήψη των τροποποιημένων αρχείων) . Αυτή η προσέγγιση λειτουργεί πολύ καλά αν οι αλλαγές του συνόλου δεδομένων πηγής είναι νέα αρχεία που προστίθενται περιοδικά και όταν τα υπάρχοντα αρχεία δεν αλλάζουν ποτέ. Αυτή η προσέγγιση δεν λειτουργεί καλά αν τα δεδομένα είναι συχνά προσαρτημένα σε όλους (ή περισσότερο) του υπάρχοντος πηγαίου αρχείου δεδομένων, επειδή τότε το τοπικό σύνολο δεδομένων σας συχνά μεταφορτώνει ολόκληρο το απομακρυσμένο σύνολο δεδομένων. (Αυτό είναι όπου χρειάζεται μια προσέγγιση rsync-όπως.)

ΑρχείοADataset

ERDDAP™ΣΑρχείοADatasetείναι μια καλή λύση όταν τα δεδομένα προστίθενται σε ένα σύνολο δεδομένων συχνά, αλλά τα παλαιότερα δεδομένα δεν αλλάζουν ποτέ. Βασικά, έναERDDAP™ο διαχειριστής μπορεί να τρέξει ArchiveADataset (Ίσως σε ένα σενάριο, ίσως διοικείται από cron) και να καθορίσει ένα υποσύνολο ενός συνόλου δεδομένων που θέλουν να εξάγουν (ίσως σε πολλαπλά αρχεία) και συσκευασία σε ένα.zipή.tgzαρχείο, έτσι ώστε να μπορείτε να στείλετε το αρχείο σε ενδιαφερόμενους ανθρώπους ή ομάδες (π.χ. NCEI για αρχειοθέτηση) ή να το κάνετε διαθέσιμο για λήψη. Για παράδειγμα, θα μπορούσατε να εκτελέσετε ArchiveADataset καθημερινά στις 12:10 π.μ. και να το κάνει ένα.zipαπό όλα τα δεδομένα από τις 12:00 πμ την προηγούμενη ημέρα έως τις 12:00 πμ σήμερα. (Ή, να το κάνετε αυτό εβδομαδιαία, μηνιαία ή ετήσια, ανάλογα με τις ανάγκες.) Επειδή το πακέτο αρχείο δημιουργείται offline, δεν υπάρχει κίνδυνος ενός χρονικού ορίου ή πάρα πολλά δεδομένα, όπως θα υπήρχε για ένα πρότυποERDDAP™Αίτημα.  

ERDDAP™Τυπικό σύστημα αίτησης

ERDDAP™Το πρότυπο σύστημα αιτήσεων είναι μια εναλλακτική καλή λύση όταν τα δεδομένα προστίθενται σε ένα σύνολο δεδομένων συχνά, αλλά τα παλαιότερα δεδομένα δεν αλλάζουν ποτέ. Βασικά, ο καθένας μπορεί να χρησιμοποιήσει τυποποιημένες αιτήσεις για να πάρει δεδομένα για ένα συγκεκριμένο εύρος χρόνου. Για παράδειγμα, στις 12:10 το πρωί κάθε μέρα, θα μπορούσατε να ζητήσετε όλα τα δεδομένα από ένα απομακρυσμένο σύνολο δεδομένων από τις 12:00 το πρωί μέχρι τις 12:00 το πρωί. Ο περιορισμός (σε σύγκριση με την προσέγγιση ArchiveADataset) είναι ο κίνδυνος ενός χρονικού ορίου ή υπάρχουν πάρα πολλά δεδομένα για ένα μόνο αρχείο. Μπορείτε να αποφύγετε τον περιορισμό κάνοντας συχνότερες αιτήσεις για μικρότερες χρονικές περιόδους.  

Πίνακας EDDFromHttpGet

\[Αυτή η επιλογή δεν υπάρχει ακόμα, αλλά φαίνεται πιθανό να χτιστεί στο εγγύς μέλλον.\]
Το νέοΠίνακας EDDFromHttpGetΤύπος συνόλου δεδομένωνERDDAP™v2.0 καθιστά δυνατή την οραματιζόμενη άλλη λύση. Τα υποκείμενα αρχεία που διατηρούνται από αυτόν τον τύπο συνόλου δεδομένων είναι ουσιαστικά αρχεία καταγραφής που καταγράφουν αλλαγές στο σύνολο δεδομένων. Θα πρέπει να είναι δυνατή η δημιουργία ενός συστήματος που θα διατηρεί ένα τοπικό σύνολο δεδομένων περιοδικά (ή με βάση τη σκανδάλη) ζητώντας όλες τις αλλαγές που έχουν γίνει στο σύνολο απομακρυσμένων δεδομένων από την τελευταία αυτή αίτηση. Αυτό πρέπει να είναι εξίσου αποτελεσματικό. (ή περισσότερο) από rsync και θα χειριστεί πολλά δύσκολα σενάρια, αλλά θα λειτουργήσει μόνο αν τα απομακρυσμένα και τοπικά σύνολα δεδομένων είναι EDDTableFromHttpGet σύνολα δεδομένων.

Αν κάποιος θέλει να δουλέψει σ' αυτό, παρακαλώ επικοινωνήστε.erd.data at noaa.gov.

Διανεμημένα δεδομένα

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

Υπάρχει μια μεγάλη λύση: μην προσπαθήσετε καν να αναπαραγάγετε τα δεδομένα. Αντ 'αυτού, χρησιμοποιήστε τη μία έγκυρη πηγή (ένα σύνολο δεδομένων σε έναERDDAP) , συντηρείται από τον πάροχο δεδομένων (π.χ. περιφερειακό γραφείο) . Όλοι οι χρήστες που θέλουν δεδομένα από αυτό το σύνολο δεδομένων παίρνουν πάντα από την πηγή. Για παράδειγμα, οι εφαρμογές με βάση το πρόγραμμα περιήγησης παίρνουν τα δεδομένα από ένα αίτημα βασισμένο στο URL, οπότε δεν έχει σημασία ότι το αίτημα είναι στην αρχική πηγή σε έναν απομακρυσμένο εξυπηρετητή (όχι ο ίδιος διακομιστής που φιλοξενεί το ESM) . Πολλοί άνθρωποι υποστηρίζουν αυτή την προσέγγιση Διανεμημένων Δεδομένων για μεγάλο χρονικό διάστημα (π.χ., Roy Mendelssohn τα τελευταία 20+ χρόνια) .ERDDAPΠρότυπο δικτύου/ομοσπονδίας (το κορυφαίο 80% του παρόντος εγγράφου) βασίζεται σε αυτήν την προσέγγιση. Αυτή η λύση είναι σαν σπαθί για έναν Γόρδιο Νότο — το όλο πρόβλημα εξαφανίζεται.

• Αυτή η λύση είναι εκπληκτικά απλή.
• Αυτή η λύση είναι εκπληκτικά αποτελεσματική, καθώς δεν γίνεται καμία εργασία για να διατηρηθεί ένα αντιγραφόμενο σύνολο δεδομένων (α) Ενημέρωση.
• Οι χρήστες μπορούν να λάβουν τα τελευταία δεδομένα ανά πάσα στιγμή (π.χ. με κενό μόνο ~0,5 δευτερόλεπτα) .
• Είναι ζυγαριά αρκετά καλά και υπάρχουν τρόποι για να βελτιωθεί η κλιμάκωση. (Δείτε τη συζήτηση στο κορυφαίο 80% του παρόντος εγγράφου.)
   

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

Συμπέρασμα

Ενώ δεν υπάρχει ενιαία, απλή λύση που λύνει τέλεια όλα τα προβλήματα σε όλα τα σενάρια (ως rsync και Διανεμημένα δεδομένα είναι σχεδόν) , ελπίζουμε ότι υπάρχουν επαρκή εργαλεία και επιλογές, έτσι ώστε να μπορείτε να βρείτε μια αποδεκτή λύση για τη συγκεκριμένη κατάστασή σας.