Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Bereite dich auf Wachstum vor
Wenn Sie das Poolmodell erfolgreich einsetzen, wachsen Sie irgendwann über die Größe eines einzelnen Neptun-Clusters hinaus. Die Zahl der Mandanten wächst oder die Anzahl der Mandanten wächst, und die Datenaufnahmerate, die von all Ihren Kunden benötigt wird, übersteigt die Kapazität des Clusters. In diesem Fall müssen Sie Ihre Kunden auf mehrere Cluster aufteilen. Entwerfen Sie diese Konfiguration im Voraus, anstatt zu versuchen, sie später nachzurüsten. Selbst wenn Ihre anfängliche Skalierung nur einen einzigen Cluster verwenden soll, sollten Sie sich die Komponenten, die Sie benötigen, um Mandanten in future über mehrere Cluster hinweg weiterzuleiten, simulieren, wenn Sie diese Größenordnung erreichen.
Wenn Ihre Lösung je nach Größe Ihres Mandanten mehr Ressourcen benötigt, sollten Sie sich auch auf deren Wachstum vorbereiten. Wenn mehrere Kunden in einem einzigen Cluster erheblich wachsen, unterstützt dieser Cluster Ihre Anforderungen möglicherweise nicht mehr. Entwerfen Sie eine Strategie, um entweder Mandanten in einen anderen Cluster zu verschieben oder einen vorhandenen Cluster mithilfe der Amazon Neptune DB-Klonfunktion in zwei Teile aufzuteilen.
Machen Sie sich mit dem Copy-on-Write Neptune-Protokoll vertraut, mit dem Sie bei der Implementierung von DB-Cloning Geld sparen können., Wenn Sie einen Cluster aufgrund von Engpässen bei der Datenerfassung aufteilen, ist es möglicherweise effizienter, keine Daten aus den Clustern zu löschen, sofern Ihre Richtlinien dies zulassen. Die beiden Cluster teilen sich eine Datenseite, wenn sie unverändert ist, aber nicht, wenn die Datenseite geändert wurde (weil einige Daten darauf gelöscht wurden).
Anmerkung
Diese Anleitung bezieht sich auf die neueste Neptun-Version zum Zeitpunkt der Erstellung dieses Artikels, nämlich Neptune-Version 1.3.1. Diese Anleitung könnte sich in future Versionen ändern, wenn sich die Neptun-Speicherschicht weiterentwickelt.
Einschränkungen für Multi-Tenancy-Szenarien
Beachten Sie, dass einige Neptune-Funktionen nicht für Multi-Tenancy-Szenarien konzipiert sind. Mandanten sollten in einem Poolmodell keinen direkten Zugriff auf Neptune-Endpunkte erhalten, da diese Multi-Tenancy-Strategien auf Datenbankebene nicht durchgesetzt werden. Halten Sie immer eine Art Proxy zwischen Ihren Kunden und dem Neptune-Endpunkt bereit, der die in diesem Dokument beschriebenen Designs durchsetzt. Zu den Beispielen für einen solchen Proxy gehören die folgenden:
-
Anhängen der Labelfilter in Ihrer Client-Ebene
-
Über eine API verfügen, die das Authentifizierungstoken einer Mandanten-ID zuordnet und diesen Filter in die Abfrage einfügt
Diese Anleitung gilt auch für den direkten Zugriff von Kunden auf Funktionen wie Neptune Graph Notebooks, NeptuneGraph-Explorer oder Neptune Streams.
