Skalierung

ERDDAP™- Schwere Lasten, Gitter, Cluster, Föderationen und Cloud Computing

 

ERDDAP:

ERDDAP™ist eine Web-Anwendung und ein Web-Service, der wissenschaftliche Daten aus verschiedenen lokalen und Remote-Quellen aggregiert und bietet eine einfache, konsequente Möglichkeit, Untermengen der Daten in gemeinsamen Dateiformaten herunterzuladen und Grafiken und Karten zu erstellen. Diese Seite diskutiert Probleme im Zusammenhang mit schwerERDDAP™Nutzungslasten und erforscht Möglichkeiten für den Umgang mit extrem schweren Lasten über Netze, Cluster, Verbände und Cloud Computing.

Die Originalversion wurde im Juni 2009 geschrieben. Es gab keine signifikanten Änderungen. Dies wurde zuletzt aktualisiert 2019-04-15.

DISCLAIMER

Die Inhalte dieser Seite sind Bob Simons persönliche Meinungen und spiegeln nicht unbedingt jede Position der Regierung oder derNational Oceanic and Atmospheric Administration. Die Berechnungen sind simplistisch, aber ich denke, die Schlussfolgerungen sind korrekt. Habe ich Fehler bei meinen Berechnungen gemacht? Wenn ja, ist die Schuld meine allein. Bitte senden Sie eine E-Mail mit der Korrektur anerd dot data at noaa dot gov.  

• • Ja.

Schwere Lasten / Einschränkungen

Mit schwerem Einsatz, StandaloneERDDAP™wird eingeschränkt werden (von höchster Wahrscheinlichkeit) von:

Remote Source Bandwidth

1. Bandbreite einer Remote-Datenquelle — Auch mit einer effizienten Verbindung (z.B. überOPeNDAP) , es sei denn, eine Remote-Datenquelle hat eine sehr hohe Bandbreite Internet-Verbindung,ERDDAP's Antworten werden dadurch eingeschränkt, wie schnellERDDAP™kann Daten von der Datenquelle erhalten. Eine Lösung ist das Kopieren des Datensatzes aufERDDAP's Festplatte, vielleicht mitEDDGridKopieoderEDDTableCopy.  

ERDDAPServerbandbreite

2. es sei denn,ERDDAP's Server hat eine sehr hohe Bandbreite Internet-Verbindung,ERDDAP's Antworten werden dadurch eingeschränkt, wie schnellERDDAP™Daten aus den Datenquellen erhalten und wie schnellERDDAP™kann Daten an die Kunden zurückgeben. Die einzige Lösung ist, eine schnellere Internetverbindung zu bekommen.  

Speichermedien

3. Wenn es viele gleichzeitige Anfragen gibt,ERDDAP™kann aus dem Speicher laufen und neue Anfragen zeitweise verweigern. (ERDDAP™hat ein paar Mechanismen, um dies zu vermeiden und die Konsequenzen zu minimieren, wenn es passiert.) Je mehr Speicher im Server desto besser. Auf einem 32-Bit-Server ist 4+ GB wirklich gut, 2 GB ist okay, weniger wird nicht empfohlen. Auf einem 64-Bit-Server können Sie das Problem fast vollständig vermeiden, indem Sie viel Speicher. Siehe\-Xmx und -Xms EinstellungenfürERDDAP-Tomcat. EineERDDAP™Schwere Nutzung auf einem Computer mit einem 64-Bit-Server mit 8 GB Speicher und -Xmx auf 4000M eingestellt ist selten, wenn überhaupt, durch Speicher eingeschränkt.  

Had Drive Bandwidth

4. Der Zugriff auf Daten, die auf der Festplatte des Servers gespeichert sind, ist weitaus schneller als der Zugriff auf Remote-Daten. Auch wennERDDAP™Server hat eine sehr hohe Bandbreite Internet-Verbindung, es ist möglich, dass der Zugriff auf Daten auf der Festplatte ein Engpass sein wird. Eine Teillösung ist schneller zu bedienen (z.B. 10.000 RPM) magnetische Festplatten oder SSD-Laufwerke (wenn es kostenmäßig Sinn macht) . Eine weitere Lösung besteht darin, verschiedene Datensätze auf verschiedenen Laufwerken zu speichern, so dass die kumulative Festplattenbandbreite viel höher ist.  

Zu viele Dateien Cached

5. Zu viele Dateien in einemCacheVerzeichnis —ERDDAP™Cache alle Bilder, aber nur Cache die Daten für bestimmte Arten von Datenanforderungen. Es ist möglich, dass das Cache-Verzeichnis für einen Datensatz eine große Anzahl von Dateien vorübergehend hat. Dies verlangsamt Anfragen zu sehen, ob eine Datei im Cache ist (wirklich!) .<Cache ProtokolleSetup.xmllässt Sie festlegen, wie lange eine Datei im Cache sein kann, bevor sie gelöscht wird. Eine kleinere Zahl zu setzen würde dieses Problem minimieren.  

CPU

6. Nur zwei Dinge nehmen viel CPU-Zeit:
   • NetCDF4 undHDF5 unterstützt nun die interne Komprimierung von Daten. Dekomprimieren eines großen komprimiertenNetCDF4 /HDF5 Datendatei kann 10 oder mehr Sekunden dauern. (Das ist kein Implementierungsfehler. Es ist die Natur der Kompression.) So können mehrere gleichzeitige Anfragen an Datensätze mit in komprimierten Dateien gespeicherten Daten auf jedem Server einen starken Stamm setzen. Wenn dies ein Problem ist, ist die Lösung, beliebte Datensätze in unkomprimierten Dateien zu speichern, oder einen Server mit einer CPU mit mehr Kernen zu erhalten.
   • Diagramme erstellen (einschließlich Karten) : etwa 0,2 - 1 Sekunde pro Graph. Also, wenn es viele gleichzeitig einzigartige Anfragen für Graphen (WMSKunden stellen oft 6 gleichzeitige Anfragen!) Es könnte eine CPU-Beschränkung geben. Wenn mehrere Benutzer laufenWMSKunden, das wird ein Problem.  

• • Ja.

Mehrere IdenERDDAPs mit Lastausgleich?

Die Frage kommt oft auf: "Um mit schweren Lasten umzugehen, kann ich mehrere identischeERDDAPs mit Lastausgleich?" Es ist eine interessante Frage, weil es schnell zum Kern vonERDDAPDesign. Die schnelle Antwort ist "Nein". Ich weiß, das ist eine enttäuschende Antwort, aber es gibt ein paar direkte Gründe und einige größere grundlegende Gründe, warum ich entworfen habeERDDAP™einen anderen Ansatz verwenden (eine Föderation vonERDDAPs, in der Masse dieses Dokuments beschrieben) , was ich glaube, ist eine bessere Lösung.

Einige direkte Gründe, warum Sie nicht/shouldn nicht mehrere identischERDDAPs sind:

• A gegebenERDDAP™liest jede Datendatei, wenn sie zuerst verfügbar wird, um die Datenbereiche in der Datei zu finden. Es speichert diese Informationen dann in einer Indexdatei. Später, wenn eine Benutzeranfrage für Daten eingeht,ERDDAP™verwendet diesen Index, um herauszufinden, welche Dateien nach den gewünschten Daten suchen. Wenn es mehrere identischeERDDAPs, sie würden jeweils diese Indexierung tun, die verschwendet Anstrengung. Bei dem weiter unten beschriebenen föderierten System wird die Indexierung nur einmal durch eine derERDDAPS.
• Für einige Arten von Benutzeranfragen (z.B. für.nc, .png, .pdf Dateien) ERDDAP™muss die gesamte Datei machen, bevor die Antwort gesendet werden kann. So.ERDDAP™Cache diese Dateien für eine kurze Zeit. Wenn eine identische Anfrage kommt (wie es oft tut, vor allem für Bilder, bei denen die URL in eine Webseite eingebettet ist) ,ERDDAP™kann diese Cache-Datei wiederverwenden. In einem System mit mehreren identischenERDDAPs, diese Cache-Dateien werden nicht geteilt, so dass jederERDDAP™würde unnötig und mühelos die.nc, .png oder .pdf Dateien. Mit dem unten beschriebenen föderierten System werden die Dateien nur einmal gemacht, von einer derERDDAPs, und wiederverwendet.
• ERDDAPDas Abonnementsystem ist nicht eingerichtet, um von mehreren geteilt zu werdenERDDAPS. Zum Beispiel, wenn der Load Balancer einen Benutzer an einen sendetERDDAP™und der Benutzer abonniert einen Datensatz, dann der andereERDDAPs wird sich dieses Abonnement nicht bewusst sein. Später, wenn der Load Balancer den Benutzer zu einem anderen sendetERDDAP™und fordert eine Liste seiner Abonnements, die andereERDDAP™würde sagen, es gibt keine (führt ihn/sie zu einem doppelten Abonnement auf dem anderen EREDDAP) . Mit dem weiter unten beschriebenen föderierten System wird das Abonnementsystem einfach von der Haupt-, öffentlichen, zusammengesetztenERDDAP.

Ja, für jedes dieser Probleme könnte ich (mit großem Aufwand) eine Lösung entwickeln (die Informationen zwischenERDDAPS) , aber ich glaube,Fütterung vonERDDAPs Ansatz (in der Masse dieses Dokuments beschrieben) ist eine viel bessere Gesamtlösung, zum Teil, weil es sich um andere Probleme handelt, die die multiple-identisch-ERDDAPDer s-with-a-load-balancer-Ansatz beginnt nicht einmal, insbesondere die dezentrale Natur der Datenquellen in der Welt anzusprechen.

Es ist am besten, die einfache Tatsache zu akzeptieren, dass ich nicht designteERDDAP™als mehrfach identisch eingesetzt werdenERDDAPs mit Lastausgleich. Ich habe bewusst entworfenERDDAP™gut in einem Verband zu arbeitenERDDAPs, was ich glaube, hat viele Vorteile. Besonders ein VerbandERDDAPs ist perfekt mit dem dezentralen, verteilten System von Rechenzentren ausgerichtet, die wir in der realen Welt haben (die verschiedenen IOOS-Regionen oder die verschiedenen Küstenwach-Regionen oder die verschiedenen Teile von NCEI oder die 100 anderen Rechenzentren inNOAA, oder die verschiedenen NASA DAACs, oder die 1000er Rechenzentren auf der ganzen Welt) . Anstatt allen Rechenzentren der Welt zu sagen, dass sie ihre Anstrengungen aufgeben und alle ihre Daten in einen zentralen "Datensee" setzen müssen. (selbst wenn es möglich wäre, ist es aus zahlreichen Gründen eine schreckliche Idee -- siehe die verschiedenen Analysen, die die zahlreichen Vorteile derdezentrale Systeme) ,ERDDAP's Design arbeitet mit der Welt, wie es ist. Jedes Rechenzentrum, das Daten erzeugt, kann weiterhin aufrecht erhalten, kuratieren und ihren Daten dienen (sie sollten) , und doch, mitERDDAP™, die Daten können auch sofort von einer zentralenERDDAP, ohne dass die Daten an die Zentralisierung übertragen werden müssenERDDAP™oder doppelte Kopien der Daten speichern. In der Tat kann ein bestimmter Datensatz gleichzeitig verfügbar sein vonERDDAP™bei der Organisation, die produziert und tatsächlich speichert die Daten (z.B. GoMOOS) , vonERDDAP™bei der Elternorganisation (z.B. IOOS Zentral) , aus einem ganzen...NOAA ERDDAP™, aus einer all-US-föderalen RegierungERDDAP™, aus einer WeltERDDAP™ (ZUSAMMENFASSUNG) , und von spezialisiertenERDDAPS (z.B. einERDDAP™an einer Einrichtung zur HAB-Forschung) , alle im Wesentlichen sofort und effizient, da nur die Metadaten zwischenERDDAPs, nicht die Daten. Am besten, nach der erstenERDDAP™bei der Ursprungsorganisation, alle anderenERDDAPs kann schnell aufgebaut werden (ein paar Stunden Arbeit) , mit minimalen Ressourcen (einen Server, der keine RAIDs für die Datenspeicherung benötigt, da er keine Daten lokal speichert) , und damit zu wirklich minimalen Kosten. Vergleichen Sie das mit den Kosten der Einrichtung und Aufrechterhaltung eines zentralisierten Rechenzentrums mit einem Datensee und der Notwendigkeit einer wirklich massiven, wirklich teuren, Internetverbindung, plus das damit verbundene Problem des zentralisierten Rechenzentrums ist ein einziger Fehlerpunkt. Für mich,ERDDAPs dezentrale, föderierte Ansatz ist weit, weit überlegen.

In Situationen, in denen ein vorgegebenes Rechenzentrum mehrere benötigtERDDAPdie hohe Nachfrage zu erfüllen,ERDDAP's Design ist voll in der Lage, die Leistung des Multiple-Identtical-ERDDAPs-with-a-load-balancer Ansatz. Sie haben immer die Möglichkeit der EinrichtungVielschichtiger VerbundERDDAPS (wie unten diskutiert) , von denen jede ihre Daten von anderen erhältERDDAPs, ohne Lastausgleich. In diesem Fall empfehle ich, dass Sie einen Punkt zu geben jedem der zusammengesetztenERDDAPs ein anderer Name / Identität und wenn möglich sie in verschiedenen Teilen der Welt einrichten (z.B. verschiedene AWS-Regionen) , z.ERD\_US\_Ost,ERD\_US\_West,ERD\_IE,ERD\_FR,ERD\_IT, so dass Benutzer bewusst, wiederholt, mit einem bestimmtenERDDAP, mit dem zusätzlichen Vorteil, dass Sie das Risiko von einem einzigen Punkt des Ausfalls entfernt haben.  

• • Ja.

Gitter, Cluster und Föderationen

Unter sehr schweren Einsatz, ein einziges StandaloneERDDAP™wird in ein oder mehrere derEinschränkungenund sogar die vorgeschlagenen Lösungen werden nicht ausreichen. Für solche SituationenERDDAP™verfügt über Funktionen, die es einfach machen skalierbare Gitter zu konstruieren (auch Cluster oder Verbände genannt) vonERDDAPs, die es erlauben, das System sehr schwer zu handhaben (z.B. für ein großes Rechenzentrum) .

Ich benutzeGitterals allgemeiner Begriff zur Angabe einer ArtComputer-Clusterwenn alle Teile in einer Einrichtung physikalisch oder nicht angeordnet sein können und nicht zentral appliziert werden können. Ein Vorteil von ko-lokierten, zentralbesitzenden und verwalteten Gittern (Cluster) ist, dass sie von Skalenwirtschaften profitieren (besonders die menschliche Arbeitsbelastung) und vereinfachen, die Teile des Systems gut zusammenzuarbeiten. Ein Vorteil von nicht-ko-lokierten Gittern, nicht-zentralen und verwalteten (Föderationen) ist, dass sie die menschliche Arbeitsbelastung und die Kosten verteilen und zusätzliche Fehlertoleranz bieten können. Die Lösung, die ich unten vorschlage, funktioniert gut für alle Raster-, Cluster- und Föderationstopographien.

Der Grundgedanke eines skalierbaren Systems besteht darin, die potenziellen Engpässe zu identifizieren und das System so zu gestalten, dass Teile des Systems nach Bedarf repliziert werden können, um die Engpässe zu lindern. Idealerweise erhöht jeder replizierte Teil die Kapazität des Teils des Systems linear (Effizienz der Skalierung) . Das System ist nicht skalierbar, es sei denn, es gibt eine skalierbare Lösung für jeden Engpass.Skalierbarkeitunterscheidet sich von der Effizienz (wie schnell eine Aufgabe erledigt werden kann — Effizienz der Teile) . Skalierbarkeit ermöglicht es dem System zu wachsen, um jedes Niveau der Nachfrage zu bewältigen. Effizienz (der Skalierung und der Teile) bestimmt, wie viele Server, etc., benötigt werden, um eine bestimmte Nachfrage zu erfüllen. Effizienz ist sehr wichtig, hat aber immer Grenzen. Skalierbarkeit ist die einzige praktische Lösung, um ein System zu bauen, das handhaben kann sehr schwerer Einsatz. Idealerweise wird das System skalierbar und effizient sein.

Ziele

Die Ziele dieses Designs sind:

• Eine skalierbare Architektur zu machen (eine, die leicht erweiterbar ist, indem sie jedes Teil, das übergebürdet wird) . Um ein effizientes System zu schaffen, das die Verfügbarkeit und den Durchsatz der Daten bei den verfügbaren Rechenressourcen maximiert. (Kosten sind fast immer ein Problem.)
• Um die Fähigkeiten der Teile des Systems auszugleichen, so dass ein Teil des Systems keinen anderen Teil überfordert.
• Um eine einfache Architektur zu machen, so dass das System einfach aufgebaut und verwaltet werden kann.
• Eine Architektur, die mit allen Rastertopographien gut funktioniert.
• Um ein System zu schaffen, das anmutig und in begrenzter Weise ausfällt, wenn ein Teil überbezahlt wird. (Die Zeit, die erforderlich ist, um eine große Datensätze zu kopieren, wird die Fähigkeit des Systems, mit plötzlichen Anstiegen der Nachfrage nach einem bestimmten Datensatz zu umgehen, immer begrenzen.)
• (Falls möglich) Um eine Architektur zu machen, die nicht an eine bestimmte gebunden istCloud ComputingService oder andere externe Dienste (weil es sie nicht braucht) .

Empfehlungen

Unsere Empfehlungen sind

• Grundsätzlich schlage ich vor, einen Verbund aufzubauenERDDAP™ ( D im Diagramm) , die regelmäßig istERDDAP™außer, es dient nur Daten von anderenERDDAPS. Die Architektur des Rasters soll so viel Arbeit wie möglich verschieben (CPU-Nutzung, Speichernutzung, Bandbreitennutzung) aus dem VerbundERDDAP™zum anderenERDDAPS.
• ERDDAP™hat zwei spezielle Datensatztypen,EDDGridVon ErddapundEDDTableFromErddap, die sich auf Datensätze auf anderenERDDAPS.
• Wenn der VerbundERDDAP™von diesen Datensätzen eine Anforderung an Daten oder Bilder erhält,ERDDAP™ Umleitungendie Datenanforderung zum anderenERDDAP™Server. Das Ergebnis ist:
  • Dies ist sehr effizient (CPU, Speicher und Bandbreite) , weil sonst
    1. Der VerbundERDDAP™muss die Datenanforderung an den anderen sendenERDDAP.
    2. Der andereERDDAP™die Daten zu erhalten, zu reformieren und die Daten an den Verbund zu übermittelnERDDAP.
    3. Der VerbundERDDAP™muss die Daten empfangen (mit extra Bandbreite) , reformieren (mit extra CPU-Zeit und Speicher) , und die Daten an den Benutzer übertragen (mit extra Bandbreite) . Durch Umleitung der Datenanforderung und Genehmigung des anderenERDDAP™die Antwort direkt an den Benutzer zu senden, den VerbundERDDAP™verbringt im Wesentlichen keine CPU-Zeit, Speicher oder Bandbreite auf Datenanforderungen.
  • Die Umleitung ist für den Benutzer unabhängig von der Client-Software transparent (ein Browser oder ein anderes Software- oder Befehlszeilentool) .

Netzteile

Die Teile des Rasters sind:

A : Für jede Remote-Datenquelle mit hoher BandbreiteOPeNDAPServer, Sie können direkt mit dem Remote-Server verbinden. Wenn der Remoteserver einERDDAP™, VerwendungEDDGridVonErddap oder EDDTableFromERDDAPdie Daten im Verbund dienenERDDAP. Wenn der Remote-Server eine andere Art vonDAPServer, z.B. THREDDS,Hyrax, oder GrADS verwendenEDDGridFromDap.

B. : Für jedenERDDAP-fähige Datenquelle (eine Datenquelle, aus derERDDAPkann Daten lesen) der einen High-Bandbreite-Server hat, einen anderen einrichtenERDDAP™im Netz, das für die Verwendung der Daten aus dieser Datenquelle verantwortlich ist.

• Wenn mehrere solcherERDDAPs werden nicht viele Anfragen für Daten erhalten, Sie können sie zu einem konsolidierenERDDAP.
• WennERDDAP™gewidmet, um Daten von einer Remote-Quelle zu viele Anfragen zu bekommen, gibt es eine Versuchung, zusätzlicheERDDAPs auf die entfernte Datenquelle zugreifen. In speziellen Fällen kann dies sinnvoll sein, aber es ist wahrscheinlicher, dass dies die entfernte Datenquelle überfordert. (die sich selbst entziehen) und auch verhindern, dass andere Benutzer auf die entfernte Datenquelle zugreifen (was nicht schön ist) . In einem solchen Fall ist die Einrichtung eines anderenERDDAP™zu dienen, dass ein Datensatz und kopieren Sie den Datensatz daraufERDDAP's Festplatte (siehe C ) , vielleicht mitEDDGridKopieund/oderEDDTableCopy.
• B. Server müssen öffentlich zugänglich sein.

C : Für jedenERDDAP-fähige Datenquelle, die einen Low-Bandbreite-Server hat (oder ist ein langsamer Service aus anderen Gründen) , in Erwägung ziehen, einen anderen zu schaffenERDDAP™und Speichern einer Kopie des Datensatzes daraufERDDAP's Festplatten, vielleicht mitEDDGridKopieund/oderEDDTableCopy. Wenn mehrere solcherERDDAPs werden nicht viele Anfragen für Daten erhalten, Sie können sie zu einem konsolidierenERDDAP. C Server müssen öffentlich zugänglich sein.

VerbundwerkstoffeERDDAP

D : Der VerbundERDDAP™ist ein StammERDDAP™außer, es dient nur Daten von anderenERDDAPS.

• Weil der VerbundERDDAP™hat Informationen im Speicher über alle Datensätze, es kann schnell auf Anfragen für Listen von Datensätzen reagieren (Volltextsuche, Kategoriesuche, die Liste aller Datensätze) , und Anfragen für das Data Access-Formular eines einzelnen Datensatzes, Erstellen eines Graph-Formulars oderWMSInfoseite. Dies sind alle kleinen, dynamisch generierten HTML-Seiten basierend auf Informationen, die im Speicher gespeichert werden. Die Antworten sind also sehr schnell.
• Da Anfragen an aktuelle Daten schnell auf den anderen umgeleitet werdenERDDAPs, der VerbundERDDAP™kann schnell auf Anfragen für aktuelle Daten reagieren, ohne CPU-Zeit, Speicher oder Bandbreite zu verwenden.
• Durch Verschieben so viel Arbeit wie möglich (CPU, Speicher, Bandbreite) aus dem VerbundERDDAP™zum anderenERDDAPs, der VerbundERDDAP™kann erscheinen, um Daten von allen Datensätzen zu bedienen und dennoch mit sehr vielen Datenanforderungen von einer Vielzahl von Benutzern aufrechtzuerhalten.
• Vorversuche zeigen, dass der VerbundERDDAP™kann auf die meisten Anfragen in ~1ms CPU-Zeit oder 1000 Anfragen/Sekunde antworten. So sollte ein 8-Kernprozessor in der Lage sein, auf etwa 8000 Anfragen/Sekunde zu reagieren. Obwohl es möglich ist, Bursts höherer Aktivität vorzustellen, die Verlangsamungen verursachen würden, das ist viel Durchsatz. Es ist wahrscheinlich, dass Datenzentrum Bandbreite wird der Engpass lange vor dem VerbundERDDAP™wird der Engpass.

Aktuelles max (Zeit) ?

DieEDDGrid/TableFromErddap im VerbundERDDAP™nur seine gespeicherte Information über jeden Quelldatensatz ändert, wenn der Quelldatensatz"Reload"und einige Metadatenänderungen (z.B. die Zeitvariableactual\_range) , wodurch eine Abonnement-Benachrichtigung erzeugt wird. Hat der Quelldatensatz Daten, die sich häufig ändern (zum Beispiel neue Daten jede Sekunde) und nutzt die"update"System, um häufige Änderungen der zugrunde liegenden Daten zu bemerken,EDDGrid/TableFromErddap wird nicht über diese häufigen Änderungen informiert, bis der nächste Datensatz "Reload", also dieEDDGrid/TableFromErddap wird nicht perfekt auf dem neuesten Stand sein. Sie können dieses Problem durch Änderung des Quelldatensatzes minimieren<reloadEveryNMinutes&gt auf einen kleineren Wert (60? 15?) so dass es mehr Abonnement-Benachrichtigungen, um dieEDDGrid/TableFromErddap, um seine Informationen über den Quelldatensatz zu aktualisieren.

Oder wenn Ihr Datenmanagementsystem weiß, wann der Quelldatensatz neue Daten hat (z.B. über ein Skript, das eine Datendatei kopiert) , und wenn das nicht super häufig ist (z.B. alle 5 Minuten oder weniger häufig) Es gibt eine bessere Lösung:

1. Nicht verwenden<updateEveryNMillis> um den Quelldatensatz aktuell zu halten.
2. Den Quelldatensatz festlegen<reloadEveryNMinutes&gt zu einer größeren Anzahl (1440?) .
3. Lassen Sie das Skript den Quelldatensatz kontaktierenZurück zur Übersichtrechts nachdem es eine neue Datendatei kopiert. Dies führt dazu, dass der Quelldatensatz perfekt aktuell ist und dazu führt, dass er eine Abonnement-Benachrichtigung generiert, die an dieEDDGrid/TableFromErddap Datensatz. Das führtEDDGrid/TableFromErddap-Datensatz ist perfekt auf dem neuesten Stand (gut, innerhalb von 5 Sekunden neue Daten hinzugefügt) . Und alles, was effizient getan wird (ohne unnötige Datensatz-Reloads) .

MehrfachkompositERDDAPS

• In sehr extremen Fällen, oder für Fehlertoleranz, können Sie mehr als einen zusammengesetztenERDDAP. Es ist wahrscheinlich, dass andere Teile des Systems (insbesondere die Bandbreite des Rechenzentrums) wird ein Problem lange vor dem VerbundERDDAP™wird ein Engpass. So ist die Lösung wahrscheinlich, zusätzliche, geografisch vielfältige, Rechenzentren einzurichten (Spiegel) , jeweils mit einem VerbundERDDAP™und Server mitERDDAPs und (mindestens) Spiegelkopien der Datensätze, die in hoher Nachfrage sind. Ein solches Setup bietet auch Fehlertoleranz und Datensicherung (über Kopieren) . In diesem Fall ist es am besten, wenn der VerbundERDDAPs haben verschiedene URLs.

Wenn Sie wirklich wollen alle CompositesERDDAPs die gleiche URL haben, verwenden Sie ein vorderes Endsystem, das einem bestimmten Benutzer nur einem der zusammengesetzten zuordnetERDDAPS (basierend auf der IP-Adresse) , so dass alle Anfragen des Benutzers gehen zu nur einem der zusammengesetztenERDDAPS. Es gibt zwei Gründe:

• Wenn ein zugrunde liegender Datensatz neu geladen wird und die Metadaten sich ändern (z.B. eine neue Datendatei in einem netzgebundenen Datensatz verursacht die Zeitvariableactual\_rangezu ändern) , der VerbundERDDAPs wird zeitweise leicht aus dem Synch, aber miteventuelle Konsistenz. Normalerweise werden sie innerhalb von 5 Sekunden wieder synchronisiert, aber manchmal wird es länger sein. Wenn ein Benutzer ein automatisiertes System macht, das aufERDDAP™Abonnementsdie Aktionen auslösen, die kurzen Synchronitätsprobleme werden signifikant.
• Der 2+ VerbundERDDAPs jede ihre eigene Satz von Abonnements (wegen des oben beschriebenen Synchproblems) .

So sollte ein bestimmter Benutzer auf nur einen der zusammengesetztenERDDAPs, um diese Probleme zu vermeiden. Wenn einer der VerbundwerkstoffeERDDAPs geht nach unten, das vordere Endsystem kann umleiten, dassERDDAPBenutzer zum anderenERDDAP™Das ist vorbei. Ist es jedoch ein Kapazitätsproblem, das den ersten Verbund verursachtERDDAP™zu scheitern (einen überzesslichen Benutzer? eineDenial-of-Service-Angriff?) , dies macht es sehr wahrscheinlich, dass die Weiterleitung seiner Benutzer zu anderen zusammengesetztenERDDAPs wird verursachenKaskadenversagen. So ist das robusteste Setup, zusammengesetzt zu habenERDDAPs mit verschiedenen URLs.

Oder vielleicht besser, mehrere zusammengesetzteERDDAPs ohne Lastausgleich. In diesem Fall sollten Sie einen Punkt zu geben, jedem derERDDAPs ein anderer Name / Identität und wenn möglich sie in verschiedenen Teilen der Welt einrichten (z.B. verschiedene AWS-Regionen) , z.ERD\_US\_Ost,ERD\_US\_West,ERD\_IE,ERD\_FR,ERD\_IT, so dass Benutzer bewusst, wiederholt mit einem bestimmtenERDDAP.

• \[Für ein faszinierendes Design eines Hochleistungssystems, das auf einem Server läuft, siehe diesausführliche Beschreibung von Mailinator.\]

Datensätze in sehr hoher Nachfrage

Im wirklich ungewöhnlichen Fall, dass einer der A , B. , oder C ERDDAPs kann aufgrund von Bandbreiten- oder Festplattenbeschränkungen nicht mit den Anfragen aufrecht erhalten, es macht Sinn, die Daten zu kopieren (wieder) auf einen anderen Server+hard Fahren Sie fortERDDAP, vielleicht mitEDDGridKopieund/oderEDDTableCopy. Während es vielleicht ideal erscheint, den ursprünglichen Datensatz und den kopierten Datensatz nahtlos als ein Datensatz im Verbund erscheinen zu lassenERDDAP™, dies ist schwierig, weil die beiden Datensätze zu unterschiedlichen Zeiten in leicht unterschiedlichen Zuständen liegen (insbesondere, nachdem das Original neue Daten erhält, aber bevor der kopierte Datensatz seine Kopie erhält) . Daher empfehle ich, dass die Datensätze leicht unterschiedliche Titel gegeben werden (z.B.: "... (Nummer 1) " und "... (Nummer 2) ", oder vielleicht " (Spiegel # n ) " oder " (Server n ) ") und erscheinen als separate Datensätze im VerbundERDDAP. Benutzer werden verwendet, um Listen vonSpiegelseitenauf beliebten Datei-Download-Seiten, so sollte dies nicht überraschen oder enttäuscht sie. Aufgrund der Bandbreitenbegrenzungen an einer bestimmten Stelle kann es sinnvoll sein, den Spiegel an einer anderen Stelle zu haben. Wenn die Spiegelkopie in einem anderen Rechenzentrum ist, nur von dem Composite des Rechenzentrums aufgerufenERDDAP™, die verschiedenen Titel (z.B. "Spiegel #1) sind nicht notwendig.

RAIDs gegen normale Festplatten

Wenn ein großer Datensatz oder eine Gruppe von Datensätzen nicht stark verwendet werden, kann es sinnvoll sein, die Daten auf einem RAID zu speichern, da es Fehlertoleranz bietet und da Sie nicht die Verarbeitungsleistung oder Bandbreite eines anderen Servers benötigen. Aber wenn ein Datensatz stark verwendet wird, kann es sinnvoller sein, die Daten auf einem anderen Server zu kopieren +ERDDAP™+ Festplatte (ähnlichwas Google tut) anstatt einen Server und eine RAID zu verwenden, um mehrere Datensätze zu speichern, da Sie beide Server+hardDrive+ verwendenERDDAPs im Raster, bis einer von ihnen ausfällt.

Ausfälle

Was passiert, wenn...

• Es gibt einen Burst von Anfragen für einen Datensatz (z.B. alle Schüler in einer Klasse gleichzeitig ähnliche Daten anfordern) ? Nur dieERDDAP™die Verwendung dieses Datensatzes wird überwältigt und verlangsamt oder abgelehnt Anträge. Der VerbundERDDAP™und andereERDDAPwerden nicht betroffen sein. Da der Grenzwert für einen bestimmten Datensatz innerhalb des Systems die Festplatte mit den Daten ist (nichtERDDAP) , die einzige Lösung (nicht unmittelbar) eine Kopie des Datensatzes auf einem anderen Server+hardDrive+ erstellenERDDAP.
• Eine A , B. , oder C ERDDAP™fehlschlägt (z.B. Festplattenausfall) ? Nur der Datensatz (S) von derERDDAP™sind betroffen. Wenn der Datensatz (S) wird auf einem anderen Server +hardDrive+ gespiegeltERDDAP, der Effekt ist minimal. Wenn das Problem ein Festplattenausfall in einem Level 5 oder 6 RAID ist, ersetzen Sie einfach das Laufwerk und haben die RAID wieder aufbauen die Daten auf dem Laufwerk.
• Der VerbundERDDAP™scheitert? Wenn Sie ein System mit sehrhohe Verfügbarkeit, Sie können einrichtenVielschichtiger VerbundERDDAPS (wie oben beschrieben) , mit etwas wieNGINXoderTraefikzum Lastausgleich. Anmerkung:ERDDAP™kann eine sehr große Anzahl von Anfragen von einer großen Anzahl von Benutzern behandeln, weil Anträge auf Metadaten sind klein und werden von Informationen behandelt, die im Speicher liegen, und Anfragen an Daten (die groß sein können) werden dem Kind umgeleitetERDDAPS.

Einfach, skalierbar

Dieses System ist einfach einzurichten und zu verwalten, und leicht ausfahrbar, wenn ein Teil davon überlastet wird. Die einzigen realen Einschränkungen für ein bestimmtes Rechenzentrum sind die Bandbreite des Rechenzentrums und die Kosten des Systems.

Bandbreite

Beachten Sie die ungefähre Bandbreite der häufig verwendeten Komponenten des Systems:

Komponente	Angemeldet bleiben (GB)
DDR-Speicher	ANHANG
SSD Laufwerk	1
SATA Festplatte	0,3%
Gigabit Ethernet	0,1 mg/kg
OC-12	0,06
OC-3	0,015
T1	0,0002

Also, eine SATA Festplatte (0,3 GB/s) auf einem Server mit einemERDDAP™kann wahrscheinlich ein Gigabit Ethernet LAN sättigen (0,1 GB/s) . Und ein Gigabit Ethernet LAN (0,1 GB/s) kann wahrscheinlich eine OC-12 Internet-Verbindung sättigen (0,06GB/s) . Und mindestens eine Quelle listet OC-12 Linien kostet etwa $100.000 pro Monat. (Ja, diese Berechnungen basieren darauf, das System auf seine Grenzen zu schieben, was nicht gut ist, weil es zu sehr trägen Antworten führt. Diese Berechnungen sind jedoch für die Planung und den Ausgleich von Teilen des Systems nützlich.) Eine entsprechend schnelle Internetverbindung für Ihr Rechenzentrum ist bei weitem der teuerste Teil des Systems. Sie können einfach und relativ günstig ein Raster mit einem Dutzend Servern bauen, die ein Dutzend laufenERDDAPs, die in der Lage ist, viele Daten schnell auszupumpen, aber eine entsprechend schnelle Internetverbindung wird sehr, sehr teuer sein. Die Teillösungen sind:

• Ermutigen Sie Kunden, Teilmengen der Daten anzufordern, wenn dies alles ist, was erforderlich ist. Wenn der Client nur Daten für eine kleine Region oder eine geringere Auflösung benötigt, sollten sie das anfordern. Subsetting ist ein zentraler Schwerpunkt der ProtokolleERDDAP™unterstützt die Anforderung von Daten.
• Ermutigen Sie die Übertragung von komprimierten Daten.ERDDAP™ Presseneine Datenübertragung, wenn sie in derHTTP GETBitte Header. Alle Webbrowser verwenden "accept-encoding" und dekomprimieren die Antwort automatisch. Sonstige Kunden (z.B. Computerprogramme) müssen sie explizit verwenden.
• Koordinieren Sie Ihre Server auf einer ISP oder einer anderen Website, die relativ kostengünstigere Bandbreitenkosten bietet.
• Die Server mit derERDDAPs an verschiedene Institutionen, so daß die Kosten verteilt werden. Sie können dann Ihren Verbund verlinkenERDDAP™ihrERDDAPS.

Anmerkung:Cloud Computingund Web-Hosting-Dienste bieten alle Internet-Bandbreite, die Sie benötigen, aber lösen Sie nicht das Preisproblem.

Allgemeine Informationen zur Gestaltung skalierbarer, hoher Kapazität, fehlertoleranter Systeme siehe Michael T. Nygards BuchVeröffentlichung.

Wie Legos

Software-Designer versuchen oft gut zu verwendenSoftware Design MusterProbleme zu lösen. Gute Muster sind gut, weil sie gute, einfach zu erstellen und zu arbeiten, allgemeine Lösungen, die zu Systemen mit guten Eigenschaften führen. Musternamen sind nicht standardisiert, also rufe ich das Muster an, dassERDDAP™verwendet das Lego Pattern. Jedes Lego (jeweilsERDDAP) ist ein einfacher, kleiner, Standard, Stand-alone, Ziegel (Datenserver) mit einer definierten Schnittstelle, die es ermöglicht, mit anderen Legos verbunden zu werden (ERDDAPS) . Die TeileERDDAP™die dieses System ausmachen sind: das Abonnement und die FlagURL-Systeme (die die Kommunikation zwischenERDDAPS) Die EDD... FromErdddap Umleitung System und das System vonRESTfulAnfragen an Daten, die von Nutzern oder anderen generiert werden könnenERDDAPS. Bei zwei oder mehr Legos (ERDDAPS) , Sie können eine große Anzahl von verschiedenen Formen erstellen (Netzwerktopologien vonERDDAPS) . Sicher, das Design und die Features vonERDDAP™hätte anders gemacht werden können, nicht Lego-ähnlich, vielleicht nur um eine bestimmte Topologie zu ermöglichen und zu optimieren. Aber wir fühlen unsERDDAP's Lego-ähnliches Design bietet eine gute, allgemeine Lösung, die jedeERDDAP™Administrator (oder Gruppe von Administratoren) alle Arten von verschiedenen Föderationstopologien zu erstellen. So könnte beispielsweise eine einzige Organisation drei (oder mehr) ERDDAPs wie in derERDDAP™Grid/Cluster Diagramm oben. Oder eine verteilte Gruppe (IOOS? CoastWatch? NCEI? NWS?NOAA? USGS? DataONE? NEON? LTER? OOI? BODC? ONC? JRC? WMO?) kann einERDDAP™in jedem kleinen Außenposten (so dass die Daten in der Nähe der Quelle bleiben können) und dann einen Verbund einrichtenERDDAP™im Zentralbüro mit virtuellen Datensätzen (die immer perfekt aktuell sind) aus jedem der kleinen AußenpostenERDDAPS. In der Tat, alleERDDAPs, an verschiedenen Institutionen auf der ganzen Welt installiert, die Daten von anderen erhaltenERDDAPs und/oder Daten an andereERDDAPs, bilden ein riesiges Netz vonERDDAPS. Wie cool ist das?! So, wie bei Legos, sind die Möglichkeiten endlos. Deshalb ist das ein gutes Muster. Deshalb ist das ein gutes Design fürERDDAP.

Verschiedene Arten von Anfragen

Eine der realen Komplikationen dieser Diskussion von Datenserver-Topologien ist, dass es verschiedene Arten von Anfragen und verschiedene Möglichkeiten gibt, um für die verschiedenen Arten von Anfragen zu optimieren. Dies ist meist ein separates Problem (Wie schnell kann dasERDDAP™die Daten auf die Anforderung von Daten reagieren?) aus der Topologie Diskussion (die sich mit den Beziehungen zwischen Datenservern befasst und welchen Server die tatsächlichen Daten hat) .ERDDAP™, natürlich versucht, alle Arten von Anträgen effizient zu behandeln, aber behandelt einige besser als andere.

• Viele Anfragen sind einfach. Zum Beispiel: Was sind die Metadaten für diesen Datensatz? Oder: Was sind die Werte der Zeitdimension für diesen Datensatz?ERDDAP™entwickelt, um diese möglichst schnell zu handhaben (in der Regel<= 2 ms), indem diese Informationen im Speicher gespeichert werden.  
• Einige Anträge sind mäßig schwer. Zum Beispiel: Geben Sie mir diese Untermenge eines Datensatzes (die in einer Datendatei) . Diese Anträge können relativ schnell bearbeitet werden, weil sie nicht so schwierig sind.  
• Einige Anfragen sind hart und damit zeitraubend. Zum Beispiel: Geben Sie mir diese Untermenge eines Datensatzes (die in einem der 10.000+ Datendateien liegen oder aus komprimierten Datendateien stammen können, die jeweils 10 Sekunden dauern, um zu dekomprimieren) .ERDDAP™v2.0 führte einige neue, schnellere Wege ein, um mit diesen Anfragen zu umgehen, insbesondere indem der Anfrage-Handling Faden mehrere Arbeitsfäden, die verschiedene Teilmengen der Anfrage anpacken, spawn. Aber es gibt einen anderen Ansatz dieses Problems,ERDDAP™noch nicht unterstützt: Untermengen der Datendateien für einen bestimmten Datensatz können auf separaten Computern gespeichert und analysiert werden, und dann die Ergebnisse auf dem ursprünglichen Server zusammengefasst werden. Dieser Ansatz wird aufgerufenKarteReduzierenund wird vonHadoop, die erste (?) open-source MapReduce Programm, das auf Ideen aus einem Google-Papier basiert. (Wenn Sie MapReduce benötigenERDDAP, bitte senden Sie eine E-Mail-Anfrage anerd.data at noaa.gov.) GoogleGroßes Angebotist interessant, weil es scheint eine Implementierung von MapReduce angewendet, um tabellarische Datensätze zu unterbinden, die einer vonERDDAPHauptziele. Es ist wahrscheinlich, dass Sie eineERDDAP™Datensatz von einem BigQuery Datensatz überEDDTableFromDatabaseweil BigQuery über eine JDBC-Schnittstelle aufgerufen werden kann.

Das sind meine Meinungen.

Ja, die Berechnungen sind vereinfacht (und jetzt leicht datiert) , aber ich denke, die Schlussfolgerungen sind korrekt. Habe ich Fehler bei meinen Berechnungen gemacht? Wenn ja, ist die Schuld meine allein. Bitte senden Sie eine E-Mail mit der Korrektur anerd dot data at noaa dot gov.

• • Ja.

Cloud Computing

Mehrere Unternehmen bieten Cloud Computing Services (z.B.,Amazon Web ServicesundGoogle Cloud Platform) .Webhosting-UnternehmenSeit Mitte der 1990er Jahre haben einfachere Dienstleistungen angeboten, aber die "Cloud"-Dienste haben die Flexibilität der Systeme und das Angebotsspektrum erheblich erweitert. SeitERDDAP™Gitter besteht nur ausERDDAPs und seitERDDAPsJavaWeb-Anwendungen, die in Tomcat laufen können (der häufigsten Anwendungsserver) oder andere Anwendungsserver, sollte es relativ einfach sein, eineERDDAP™auf einem Cloud-Service oder Webhosting-Site. Die Vorteile dieser Dienste sind:

• Sie bieten Zugriff auf sehr hohe Bandbreite Internet-Verbindungen. Dies allein kann die Nutzung dieser Dienste rechtfertigen.
• Sie berechnen nur für die Dienste, die Sie nutzen. Zum Beispiel erhalten Sie Zugriff auf eine sehr hohe Bandbreite Internetverbindung, aber Sie zahlen nur für tatsächlich übertragene Daten. Das lässt Sie ein System bauen, das selten überwältigt wird (sogar bei Spitzennachfrage) , ohne für die Kapazität zu zahlen, die selten verwendet wird.
• Sie sind leicht erweiterbar. Sie können Servertypen ändern oder so viele Server oder so viel Speicher wie Sie wollen, in weniger als einer Minute hinzufügen. Dies allein kann die Nutzung dieser Dienste rechtfertigen.
• Sie befreien Sie von vielen administrativen Aufgaben der Verwaltung der Server und Netzwerke. Dies allein kann die Nutzung dieser Dienste rechtfertigen.

Die Nachteile dieser Dienste sind:

• Sie berechnen für ihre Dienste, manchmal viel (in absoluten Begriffen; nicht, dass es kein guter Wert ist) . Die hier aufgeführten Preise sind fürAmazon EC2. Diese Preise (ab Juni 2015) kommt runter. In der Vergangenheit waren die Preise höher, aber Datendateien und die Anzahl der Anfragen waren kleiner. In Zukunft werden die Preise niedriger sein, aber Datendateien und die Anzahl der Anfragen wird größer sein. So ändern sich die Details, aber die Situation bleibt relativ konstant. Und es ist nicht, dass der Service überteuert ist, es ist, dass wir eine Menge des Dienstes verwenden und kaufen.
  • Datenübermittlung – Datenübermittlungen in das System sind jetzt kostenlos (Ja!) . Datentransfers aus dem System sind $0.09/GB. Eine SATA Festplatte (0,3 GB/s) auf einem Server mit einemERDDAP™kann wahrscheinlich ein Gigabit Ethernet LAN sättigen (0,1 GB/s) . Ein Gigabit Ethernet-LAN (0,1 GB/s) kann wahrscheinlich eine OC-12 Internet-Verbindung sättigen (0,06GB/s) . Wenn eine OC-12-Verbindung ~150.000 GB/Monat übertragen kann, könnten die Kosten für die Datenübermittlung bis zu 150.000 GB @ $0.09/GB = $13,500/Monat betragen, was eine erhebliche Kosten ist. Offensichtlich, wenn Sie ein Dutzend hart arbeitenERDDAPs auf einem Cloud-Service, Ihre monatlichen Datentransfer Gebühren könnten beträchtlich sein (bis zu $162.000/Monat) . (Wieder ist es nicht, dass der Service überteuert ist, es ist, dass wir eine Menge des Dienstes verwenden und kaufen.)
  • Datenspeicherung — Amazon berechnet $50/Monat pro TB. (Verglichen mit dem Kauf eines 4TB-Unternehmens-Laufwerks für ~$50/TB, obwohl die RAID, um es in setzen und Verwaltungskosten hinzufügen, um die Gesamtkosten.) Wenn Sie also viele Daten in der Cloud speichern müssen, könnte es ziemlich teuer sein (z.B. würde 100TB $5000/Monat kosten) . Aber es sei denn, Sie haben eine wirklich große Anzahl von Daten, ist dies ein kleineres Problem als die Bandbreite / Datentransferkosten. (Wieder ist es nicht, dass der Service überteuert ist, es ist, dass wir eine Menge des Dienstes verwenden und kaufen.)
     

Substitution

• Das Subset Problem: Die einzige Möglichkeit, Daten aus Datendateien effizient zu verteilen, ist das Programm zu haben, das die Daten verteilt (z.B.,ERDDAP) Betrieb auf einem Server, der die auf einer lokalen Festplatte gespeicherten Daten aufweist (oder ähnlich schnell Zugriff auf eine SAN oder lokale RAID) . Lokale Dateisysteme ermöglichenERDDAP™ (und zugrunde liegende Bibliotheken wie netcdf-java) um bestimmte Byte-Bereiche aus den Dateien zu verlangen und Antworten sehr schnell zu erhalten. Viele Arten von Datenanfragen vonERDDAP™in der Datei (insbesondere netzgebundene Datenanforderungen, wenn der Stridewert > 1) kann nicht effizient durchgeführt werden, wenn das Programm die gesamte Datei oder große Stücke einer Datei von einem Nicht-lokal anfordern muss (also langsamer) Datenspeichersystem und dann eine Teilmenge extrahieren. Wenn das Cloud-Setup nicht gibtERDDAP™schnellen Zugriff auf Byte-Bereiche der Dateien (so schnell wie mit lokalen Dateien) ,ERDDAP's Zugriff auf die Daten wird ein schwerer Engpass und negieren andere Vorteile der Verwendung eines Cloud-Service.

Gehostete Daten

Eine Alternative zur oben genannten Kostenleistungsanalyse (die auf dem Dateninhaber basiert (z.B.,NOAA) für die Speicherung ihrer Daten in der Cloud) kam um 2012, als Amazon (und in geringerem Maße einige andere Cloud-Anbieter) begann, einige Datensätze in ihrer Cloud zu hosten (AWS S3) kostenlos (vermutlich mit der Hoffnung, dass sie ihre Kosten erholen könnten, wenn Benutzer AWS EC2 Berechnungsinstanzen mieten würden, um mit diesen Daten zu arbeiten) . Dies macht das Cloud Computing deutlich kostengünstiger, denn die Zeit und die Kosten für das Upload der Daten und das Hosting sind jetzt Null. mitERDDAP™v2.0 gibt es neue Features, um das Laufen zu erleichternERDDAPin einer Wolke:

• Jetzt, aEDDGridFromFiles oder EDDTableFromFiles Datensatz kann aus Datendateien erstellt werden, die remote und über das Internet zugänglich sind (z.B. AWS S3 Eimer) durch die Verwendung<ccheFromUrl> und<CacheSize GB> Optionen.ERDDAP™wird einen lokalen Cache der zuletzt verwendeten Datendateien erhalten.
• Nun, wenn alle EDDTableFromFiles Quelldateien komprimiert werden (z.B.,.tgz) ,ERDDAP™wird sie automatisch dekomprimieren, wenn es sie liest.
• Jetzt, dieERDDAP™Thread, der auf eine bestimmte Anfrage reagiert, wird die Arbeitsfäden an Unterabschnitten des Antrags auslaufen, wenn Sie die<nThreads> Optionen. Diese Parallelisierung sollte schnellere Antworten auf schwierige Anfragen ermöglichen.

Diese Änderungen lösen das Problem von AWS S3 nicht mit lokalen, block-level-Dateispeicher und die (alt) Problem des Zugangs zu S3-Daten mit einer signifikanten Verzögerung. (Vor Jahren (~2014 ~) , die Lag war signifikant, aber ist jetzt viel kürzer und so nicht so signifikant.) Alles in allem bedeutet das die EinrichtungERDDAP™in der Cloud funktioniert jetzt viel besser.

Danke. — Vielen Dank an Matthew Arrott und seine Gruppe im ursprünglichen OOI-Anstrengung für ihre Arbeit an der UmsetzungERDDAP™in der Cloud und den daraus resultierenden Diskussionen.  

• • Ja.

Remote Replikation von Datensätzen

Es gibt ein gemeinsames Problem, das mit der obigen Diskussion von Netzen und Verbänden vonERDDAPs: Fernreplikation von Datensätzen. Das grundlegende Problem ist: Ein Datenanbieter hält einen Datensatz aufrecht, der sich gelegentlich ändert und ein Benutzer eine aktuelle lokale Kopie dieses Datensatzes aufrechterhält (aus einer Vielzahl von Gründen) . Offensichtlich gibt es eine große Anzahl von Variationen. Einige Variationen sind viel schwieriger zu behandeln als andere.

• Schnelle Updates Es ist schwieriger, den lokalen Datensatz aktuell zu halten sofort (z.B. innerhalb von 3 Sekunden) nach jeder Änderung der Quelle, anstatt beispielsweise innerhalb weniger Stunden.  
• Häufige Änderungen Häufige Änderungen sind schwerer zu behandeln als seltene Änderungen. Zum Beispiel sind einmal-a-day-Änderungen viel einfacher zu behandeln als Änderungen alle 0,1 Sekunden.  
• Kleine Veränderungen Kleine Änderungen in einer Quelldatei sind schwerer zu behandeln als eine völlig neue Datei. Dies gilt insbesondere, wenn die kleinen Änderungen irgendwo in der Datei sein können. Kleine Veränderungen sind schwerer zu erkennen und es schwer zu machen, die Daten zu isolieren, die repliziert werden müssen. Neue Dateien sind einfach zu erkennen und effizient zu übertragen.  
• Gesamter Datensatz Einen ganzen Datensatz auf dem Laufenden zu halten, ist schwieriger, als gerade aktuelle Daten zu erhalten. Einige Benutzer brauchen nur aktuelle Daten (z.B. die letzten 8 Tage wert) .  
• Mehrere Kopien Mehrere Fernkopien an verschiedenen Standorten zu erhalten, ist härter als die Aufrechterhaltung einer Fernkopie. Das ist das Skalierungsproblem.  

Es gibt offensichtlich eine Vielzahl von Variationen möglicher Arten von Änderungen am Quelldatensatz und der Bedürfnisse und Erwartungen des Benutzers. Viele der Variationen sind sehr schwer zu lösen. Die beste Lösung für eine Situation ist oft nicht die beste Lösung für eine andere Situation - es gibt noch keine universelle große Lösung.

RelevanteERDDAP™Werkzeuge

ERDDAP™bietet mehrere Tools, die als Teil eines Systems verwendet werden können, das eine Fernkopie eines Datensatzes aufrechtzuerhalten versucht:

• ERDDAP'RSS (Rich Site Zusammenfassung?) Service
  bietet einen schnellen Weg, um zu überprüfen, ob ein Datensatz auf einer FernbedienungERDDAP™hat sich geändert.  
• ERDDAP'Abonnement Service
  ist ein effizienter (alsRSS) Herangehen: Es wird sofort eine E-Mail senden oder an jeden Teilnehmer eine URL kontaktieren, wenn der Datensatz aktualisiert wird und das Update zu einer Änderung führte. Es ist effizient, dass es ASAP passiert und es gibt keine verschwendeten Anstrengungen (wie bei der Abstimmung einesRSSService) . Benutzer können andere Werkzeuge verwenden (wieIFT) auf die E-Mail-Benachrichtigungen aus dem Abonnement-System reagieren. Beispielsweise könnte ein Benutzer einen Datensatz auf einem Remote abonnierenERDDAP™und IFTTT verwenden, um auf die Abonnement-E-Mail-Benachrichtigungen zu reagieren und die Aktualisierung des lokalen Datensatzes auszulösen.  
• ERDDAP'Flaggensystem
  einen Weg für einERDDAP™Administrator, um einen Datensatz auf seinem/ihr zu sagenERDDAPum ASAP neu zu laden. Die URL-Form eines Flags kann einfach in Skripten verwendet werden. Die URL-Form einer Flagge kann auch als Aktion für ein Abonnement verwendet werden.  
• ERDDAP'"files"System
  kann Zugriff auf die Quelldateien für einen bestimmten Datensatz bieten, einschließlich einer Apache-style-Verzeichnisliste der Dateien (ein "Web Accessible Folder") die die Download-URL jeder Datei hat, zuletzt geänderte Zeit und Größe. Ein Nachteil der Verwendung"files"System ist, dass die Quelldateien verschiedene Variablennamen und verschiedene Metadaten haben können als der Datensatz, wie er inERDDAP. Wenn eine FernbedienungERDDAP™dataset bietet Zugriff auf seine Quelldateien, die die Möglichkeit einer armen Version von rsync eröffnet: es wird für ein lokales System leicht zu sehen, welche Remote-Dateien geändert und heruntergeladen werden müssen. (SiehecacheFromUrl Optiondarunter, die dies nutzen können.)
   

Lösungen

Obwohl es eine große Anzahl von Variationen des Problems und eine unendliche Anzahl von möglichen Lösungen gibt, gibt es nur eine Handvoll von grundlegenden Lösungen:

Individuelle Brute Force Solutions

Eine offensichtliche Lösung besteht darin, eine benutzerdefinierte Lösung zu handhaben, die daher für eine gegebene Situation optimiert ist: ein System zu erstellen, das ermittelt/ identifiziert, welche Daten geändert haben, und diese Informationen an den Benutzer sendet, damit der Benutzer die geänderten Daten anfordern kann. Nun, Sie können das tun, aber es gibt Nachteile:

• Benutzerdefinierte Lösungen sind viel Arbeit.
• Benutzerdefinierte Lösungen sind in der Regel so auf einen bestimmten Datensatz und gegebenen Benutzer-System, dass sie nicht einfach wiederverwendet werden können.
• Benutzerdefinierte Lösungen müssen von Ihnen gebaut und gepflegt werden. (Das ist nie eine gute Idee. Es ist immer eine gute Idee, Arbeit zu vermeiden und jemand anderes zu bekommen, um die Arbeit zu tun!)

Ich entmutige diesen Ansatz, weil es fast immer besser ist, nach allgemeinen Lösungen zu suchen, die von jemand anderem gebaut und gepflegt werden, die in verschiedenen Situationen leicht wiederverwendet werden können.  

rsync

rsyncist die bestehende, atemberaubend gute, allgemeine Ziellösung, um eine Sammlung von Dateien auf einem Quellcomputer in Synchronisierung auf dem Remotecomputer eines Benutzers zu halten. So funktioniert es:

1. eine Veranstaltung (z.B. einERDDAP™Veranstaltung des Abonnements) löst rsync aus, (oder, ein Cron Job läuft rsync zu bestimmten Zeiten jeden Tag auf dem Computer des Benutzers)

2. die rsync auf dem Quellcomputer kontaktiert,

3. die eine Reihe von Hashes für Stücke jeder Datei berechnet und diese Hashes an den Rsync des Benutzers übermittelt,

4. die diese Informationen mit den ähnlichen Informationen für die Kopie der Dateien des Benutzers vergleicht,

5. die dann die Stücke von Dateien, die sich geändert haben.

In Anbetracht dessen, was es tut, arbeitet rsync sehr schnell (z.B. 10 Sekunden plus Datentransferzeit) und sehr effizient. Es gibtVariationen von rsyncdie für verschiedene Situationen optimieren (z.B. durch Vorkalkulation und Cache der Hashes der Stücke jeder Quelldatei) .

Die wichtigsten Schwächen von rsync sind: es braucht einige Anstrengungen, um einzurichten (Sicherheitsfragen) ; es gibt einige Skalierungsprobleme; und es ist nicht gut, NRT-Datensätze wirklich aktuell zu halten (z.B. ist es unangenehm, rsync mehr als alle 5 Minuten zu verwenden) . Wenn Sie mit den Schwächen umgehen können, oder wenn sie Ihre Situation nicht beeinflussen, ist rsync eine ausgezeichnete, allgemeine Ziellösung, die jeder sofort verwenden kann, um viele Szenarien mit Remote-Replikation von Datensätzen zu lösen.

Es gibt einen Artikel auf derERDDAP™Zu Do-Liste, um zu versuchen, Unterstützung für rsync-Dienste hinzuzufügenERDDAP (wahrscheinlich eine ziemlich schwierige Aufgabe) , so dass jeder Kunde rsync verwenden kann (oder eine Variante) eine aktuelle Kopie eines Datensatzes aufrechtzuerhalten. Wenn jemand daran arbeiten will, bitte E-Mailerd.data at noaa.gov.

Es gibt andere Programme, die mehr oder weniger tun, was rsync tut, manchmal orientiert an dataset Replikation (obwohl oft auf einem Datei-Copy-Level) , z.Unidata'IDD.

Cache aus Url

Der CacheFromUrlEinstellung ist verfügbar (beginnend mitERDDAP™V2.0) für alleERDDAP's Dataset-Typen, die Datensätze aus Dateien machen (grundsätzlich alle Unterklassen vonEDDGridVonFilesundEDDTableFromFiles) . Cache FromUrl macht es trivial, die lokalen Datendateien automatisch herunterzuladen und aufrechtzuerhalten, indem sie über den Cache aus einer entfernten Quelle kopiert werden AusUrl. Die Remote-Dateien können in einem Web Accessible Folder oder einer von THREDDS angebotenen verzeichnisartigen Dateiliste liegen,Hyrax, ein S3-Bucket, oderERDDAP'"files"System.

Wenn die Quelle der Remote-Dateien eine Fernbedienung istERDDAP™Datensatz, der die Quelldateien über dieERDDAP™ "files"System, dann können Sieabonnierenzum Remote-Datensatz undZurück zur Übersichtfür Ihren lokalen Datensatz als Aktion für das Abonnement. Dann, wenn sich der Remote-Datensatz ändert, wird er die Flaggen-URL für Ihren Datensatz kontaktieren, was ihm sagen wird, ASAP neu zu laden, die die geänderten Remote-Datendateien erkennen und herunterladen wird. All dies geschieht sehr schnell (in der Regel ~5 Sekunden plus die Zeit, die benötigt wird, um die geänderten Dateien herunterzuladen) . Dieser Ansatz funktioniert großartig, wenn der Quelldatensatz Änderungen sind neue Dateien, die periodisch hinzugefügt werden und wenn sich die vorhandenen Dateien nie ändern. Dieser Ansatz funktioniert nicht gut, wenn Daten häufig an alle angepasst werden (oder höchstens) der vorhandenen Quelldatendateien, weil dann Ihr lokaler Datensatz häufig den gesamten Remote-Datensatz herunterlädt. (Hier wird ein rsync-ähnlicher Ansatz benötigt.)

ArchivADataset

ERDDAP™'ArchivADatasetist eine gute Lösung, wenn Daten zu einem Datensatz häufig hinzugefügt werden, aber ältere Daten werden nie geändert. Im Grunde, einERDDAP™Administrator kann ArchiveADataset ausführen (vielleicht in einem Skript, vielleicht von cron) und eine Untermenge eines Datensatzes angeben, die sie extrahieren möchten (vielleicht in mehreren Dateien) und Paket in einem.zipoder.tgzDatei, so dass Sie die Datei an interessierte Personen oder Gruppen senden können (z.B. NCEI zur Archivierung) oder sie zum Download zur Verfügung stellen. Zum Beispiel könnten Sie ArchiveADataset jeden Tag um 12:10 Uhr laufen und haben es eine.zipvon allen Daten von 12:00 Uhr der Vortag bis 12:00 Uhr heute. (Oder, tun Sie diese wöchentlich, monatlich oder jährlich, je nach Bedarf.) Da die verpackte Datei offline erzeugt wird, besteht keine Gefahr eines Timeouts oder zu viel Daten, wie es für einen Standard gäbe.ERDDAP™Bitte.  

ERDDAP™Standard-Anforderungssystem

ERDDAP™'s Standard-Anforderungssystem ist eine alternative gute Lösung, wenn Daten zu einem Datensatz häufig hinzugefügt werden, aber ältere Daten werden nie geändert. Grundsätzlich kann jeder Standardanfragen verwenden, um Daten für einen bestimmten Zeitraum zu erhalten. Zum Beispiel, um 12:10 Uhr jeden Tag, können Sie eine Anfrage für alle Daten aus einem Remote-Datensatz von 12:00 Uhr am Vortag bis 12:00 Uhr heute. Die Einschränkung (im Vergleich zum ArchivADataset Ansatz) ist das Risiko eines Timeouts oder es gibt zu viele Daten für eine einzelne Datei. Sie können die Einschränkung vermeiden, indem Sie häufigere Anfragen für kleinere Zeiträume stellen.  

EDDTableFromHtpGet

\[Diese Option existiert noch nicht, scheint aber in naher Zukunft zu bauen.\]
Der neueEDDTableFromHtpGetDatensatztyp inERDDAP™v2.0 ermöglicht eine weitere Lösung. Die zugrunde liegenden Dateien, die durch diese Art von Datensatz gehalten werden, sind im Wesentlichen Logdateien, die Änderungen am Datensatz erfassen. Es sollte möglich sein, ein System aufzubauen, das einen lokalen Datensatz durch periodische (oder basierend auf einem Trigger) alle Änderungen anfordern, die seit dieser letzten Anfrage an den Remote-Datensatz vorgenommen wurden. Das sollte so effizient sein (oder mehr) als rsync und würde viele schwierige Szenarien behandeln, aber würde nur funktionieren, wenn die entfernten und lokalen Datensätze EDDTableFromHtpGet-Datensätze sind.

Wenn jemand daran arbeiten will, kontaktieren Sie bitteerd.data at noaa.gov.

Verteilte Daten

Keine der oben genannten Lösungen hat eine große Aufgabe, die harten Variationen des Problems zu lösen, weil Replikation der nahen Echtzeit (NRT) Datensätze sind sehr hart, zum Teil wegen aller möglichen Szenarien.

Es gibt eine großartige Lösung: Versuchen Sie nicht einmal, die Daten zu replizieren. Verwenden Sie stattdessen die eine maßgebliche Quelle (ein Datensatz auf einemERDDAP) , aufrechterhalten durch den Datenanbieter (z.B. ein Regionalbüro) . Alle Benutzer, die Daten von diesem Datensatz wünschen, erhalten es immer von der Quelle. So erhalten z.B. browserbasierte Apps die Daten von einer URL-basierten Anfrage, so dass es nicht darauf ankommt, dass die Anfrage an die ursprüngliche Quelle auf einem Remoteserver liegt. (nicht der gleiche Server, der die ESM hostet) . Viele Menschen haben diesen Distributed Data Ansatz seit langem befürwortet (z.B. Roy Mendelssohn für die letzten 20+ Jahre) .ERDDAPModell für Netz/Föderation (die oberen 80% dieses Dokuments) basiert auf diesem Ansatz. Diese Lösung ist wie ein Schwert für einen Gordischen Knoten — das ganze Problem geht weg.

• Diese Lösung ist atemberaubend einfach.
• Diese Lösung ist erstaunlich effizient, da keine Arbeit getan wird, um einen replizierten Datensatz zu halten (S) aktuell.
• Benutzer können jederzeit die neuesten Daten erhalten (z.B. mit einer Latenz von nur ~0,5 Sekunden) .
• Es skaliert ziemlich gut und es gibt Möglichkeiten, Skalierung zu verbessern. (Siehe die Diskussion in den Top 80% dieses Dokuments.)
   

Nein, das ist keine Lösung für alle möglichen Situationen, aber es ist eine große Lösung für die große Mehrheit. Wenn es Probleme/Schwachstellen mit dieser Lösung in bestimmten Situationen gibt, lohnt es sich oft, diese Probleme zu lösen oder mit diesen Schwächen zu leben, weil die erstaunlichen Vorteile dieser Lösung. Wenn/wenn diese Lösung für eine bestimmte Situation wirklich inakzeptabel ist, z.B. wenn Sie wirklich eine lokale Kopie der Daten haben müssen, dann betrachten Sie die anderen oben diskutierten Lösungen.  

Schlussfolgerung

Während es keine einzige, einfache Lösung gibt, die alle Probleme in allen Szenarien perfekt löst (als rsync und verteilte Daten fast) , hoffentlich gibt es genügend Werkzeuge und Optionen, damit Sie eine akzeptable Lösung für Ihre besondere Situation finden können.