Ihre Suche ergab keine Treffer.
Beachten Sie die folgenden Tipps, um das Gesuchte zu finden:
Der Service Oracle Cloud Infrastructure Streaming bietet eine vollständig verwaltete, skalierbare und dauerhafte Storage-Option für kontinuierliche Datenströme mit hohem Datenvolumen, die Sie nahezu in Echtzeit nutzen und verarbeiten können.
Weitere Informationen finden Sie in den folgenden Themen der Dokumentation:
Eine Liste der Regionen, in denen der Streaming-Dienst derzeit ausgeführt wird, finden Sie in der Dokumentation.
Der API-Endpunkt ist wie folgt aufgebaut: https://streaming.$_REGION.oci.oraclecloud.com
Als Beispiel für die Variable
OCI Streaming wird vollständig verwaltet – von der zugrunde liegenden Infrastruktur bis hin zu Bereitstellung, Wartung, Sicherheitspatches, Replikation und Verbrauchergruppen, was die Anwendungsentwicklung vereinfacht.
Wenn Sie einen Stream in OCI erstellen, erstellt und verwaltet Oracle automatisch 3 Streaming-Knoten, die auf 3 verschiedene AD(s) (oder Fehlerdomänen für einzelne AD-Regionen) verteilt sind, um sicherzustellen, dass Ihre Streams hochverfügbar und Ihre Daten dauerhaft sind.
Mit OCI Streaming können Sie Daten nahezu in Echtzeit senden und abrufen. Die Anzahl der Anwendungsfälle ist nahezu unbegrenzt, vom Messaging bis zur Verarbeitung komplexer Daten-Streams.
Hier sind einige der vielen Verwendungsmöglichkeiten für Streaming:
Beginnen Sie mit der Verwendung von OCI durch:
Insgesamt sind dem Durchsatz, auf den Sie zugreifen können, keine Grenzen gesetzt. Sie müssen Ihren Stream nur proaktiv mit der richtigen Anzahl von Partitionen entwerfen.
Das System unterliegt folgenden festen Grenzen:
In unseren APIs wird eine Partition als Zeichenfolge dargestellt.
Wenn Sie einen Stream mit fünf Partitionen erstellen, können Sie mit den Zeichenfolgen „0“, „1“, „2“, „3“ oder „4“ darauf zugreifen.
Verlassen Sie sich nicht darauf, dass Partitionskennungen als numerischer Wert dargestellt werden.
Offsets sind nicht dicht. Erwarten Sie, dass Nachrichten-Offsets immer inkrementiert werden, manchmal jedoch nicht um 1. Verlassen Sie sich nicht darauf, wenn Sie zukünftige Offset-Berechnungen durchführen.
Wenn Sie beispielsweise zwei Nachrichten veröffentlichen, die sich auf derselben Partition befinden, kann die erste Nachricht den Offset 42 und die zweite Nachricht den Offset 45 haben (Offset 43 und 44 sind nicht vorhanden).
Ein Stream kann als reine Anfügeprotokolldatei angezeigt werden, die Ihre Nachrichten enthält.
Streams sind aus Gründen der Skalierbarkeit in mehrere Partitionen unterteilt. Mithilfe von Partitionen können Sie einen Stream verteilen, indem Sie die Nachrichten auf mehrere Knoten (oder Broker) aufteilen. Jede Partition kann auf einem separaten Computer platziert werden, damit mehrere Verbraucher gleichzeitig von einem Thema lesen können.
Eine 64-Bit-codierte Nachricht ist das, was Sie in ein Thema ausgeben.
Jede Nachricht in einer Partition verfügt über eine Kennung, die als Offset bezeichnet wird. Verbraucher können Nachrichten beginnend bei einem bestimmten Offset und von jedem ausgewählten Offset aus lesen. Verbraucher können auch den zuletzt verarbeiteten Offset bestätigen, damit sie ihre Arbeit fortsetzen können, ohne eine Nachricht erneut wiederzugeben oder auszulassen, wenn sie anhalten und dann neu starten.
Ein Schlüssel ist eine Kennung, mit der verwandte Nachrichten gruppiert werden.
Sie können einen neuen Stream mithilfe unserer Konsole oder unserer API erstellen. Siehe API hier.
Ihr Stream wird für eine bestimmte Region und einen bestimmten Mandanten und optional für eine spezielle Abteilung erstellt. Die Daten eines Streams werden in der gesamten Region repliziert, sodass AD-Verluste oder Netzwerkteilungen toleriert werden können, ohne dass der Dienst unterbrochen wird. Dabei wird die integrierte Hochverfügbarkeit in einer Region bereitgestellt.
Die Bereitstellungszeit hängt von der Anzahl der Partitionen ab. Das Erstellen einer neuen Partition dauert bis zu 10 Sekunden.
Die Anzahl der Partitionen für Ihren Stream hängt von den Durchsatzerwartungen Ihrer Anwendung ab (erwarteter Durchsatz = durchschnittliche Datensatzgröße x maximale Anzahl der pro Sekunde geschriebenen Datensätze).
Der Durchsatz eines Oracle Cloud Infrastructure-Streams wird durch eine Partition definiert. Eine Partition bietet eine Dateneingabe von 1 MB/s und eine Datenausgabe von 2 MB/s.
Sie können 1.000 Anforderungen pro Sekunde an eine Partition senden.
Beispiele für die Haupt-APIs des Streaming-Dienstes werden in der Dokumentation beschrieben.
Die Beispiele umfassen die folgenden APIs:
Das Streaming SDK unterstützt dieselben Sprachen wie andere OCI SDK-Implementierungen. Es gibt keine zusätzlichen Sprachen, die speziell für Streaming-Dienste unterstützt werden.
Sobald ein Stream erstellt und aktiv ist, können Sie Nachrichten veröffentlichen. Zum Veröffentlichen können Sie die Write-API (putMessages) verwenden. Die Nachricht wird auf einer Partition im Stream veröffentlicht. Wenn es mehr als eine Partition gibt, wird die Partition, auf der die Nachricht veröffentlicht wird, anhand des Schlüssels der Nachricht berechnet.
Wenn der Schlüssel null ist, wird die Partition unter Verwendung einer Teilmenge des Werts berechnet. Erwarten Sie bei Nachrichten mit einem Nullschlüssel nicht, dass Nachrichten mit demselben Wert auf derselben Partition abgelegt werden, da sich das Partitionsschema ändern kann. Durch das Senden eines Nullschlüssels wird die Nachricht effektiv in eine zufällige Partition verschoben.
Wenn Sie sicherstellen möchten, dass Nachrichten mit demselben Wert auf dieselbe Partition verschoben werden, sollten Sie für diese Nachrichten denselben Schlüssel verwenden.
Sobald die OCI Streaming-API Ihre putMessage ohne Fehler bestätigt, sind diese Nachrichten dauerhaft.
OCI Streaming garantiert lineare Lese- und Schreibvorgänge für einen Partitionierungsschlüssel.
Wenn Clientanforderungen die Grenzwerte überschreiten, lehnt OCI Streaming die Anforderung ab und sendet eine Fehlerausnahmemeldung.
Der Drosselmechanismus wird aktiviert, wenn die folgenden Schwellenwerte überschritten werden:
Wir empfehlen die Ausgabe von Nachrichten als Batch aus folgenden Gründen:
Die Größe eines Nachrichten-Batches sollte 1 MB nicht überschreiten. Wird dieser Grenzwert überschritten, wird der Drosselmechanismus ausgelöst.
Sie können einen der folgenden Ansätze verwenden: Blockerstellung oder Senden der Nachricht über Objektspeicher.
Große Nutzdaten können in mehrere kleinere Blöcke aufgeteilt werden, die der Streaming-Dienst akzeptieren kann.
Die Blöcke werden im Dienst auf dieselbe Weise gespeichert wie normale (nicht in Blöcke aufgeteilte) Nachrichten. Der einzige Unterschied besteht darin, dass der Verbraucher die Blöcke behalten und zu der eigentlichen Nachricht kombinieren muss, sobald alle Blöcke gesammelt wurden.
Die Blöcke in der Partition können mit normalen Nachrichten verwoben werden.
Eine große Nutzlast wird im Object Storage abgelegt und nur der Zeiger auf diese Daten wird übertragen. Der Empfänger erkennt diese Art von Zeigernutzdaten, liest die Daten transparent aus dem Object Storage und stellt sie dem Endnutzer bereit.
Ein häufiger Fehler ist die Angabe des falschen Datumsformats.
Der Streaming-Dienst unterstützt ISO-8601, einschließlich der Zeitzone für alle Daten.
Die PutMessagesResultsEntry-Klasse bietet die folgenden Methoden:
Derzeit ist es nicht möglich, die zuletzt veröffentlichte Nachricht anzuzeigen, ohne eine Nachricht zu veröffentlichen.
Es gibt einen Mechanismus, um den letzten festgeschriebenen Offset pro Gruppe oder Partition anzuzeigen. Untersuchen Sie den getGroup-Endpunkt.
Für das Verarbeiten von Nachrichten müssen Sie Folgendes tun:
Weitere Informationen finden Sie in der technischen Dokumentation mit der schrittweisen Anleitung zum Verarbeiten von Daten aus einem Stream.
OCI Streaming bietet zwei Arten der Nutzung von APIs:
Verbraucher können so konfiguriert werden, dass sie Nachrichten als Teil einer Gruppe verarbeiten. Stream-Partitionen werden auf Mitglieder einer Gruppe verteilt, sodass Nachrichten von einer einzelnen Partition nur an einen einzelnen Verbraucher gesendet werden.
Für Partitionszuweisungen wird ein neuer Lastausgleich durchgeführt, wenn sich Verbraucher der Gruppe anschließen oder diese verlassen.
Wir empfehlen, dass sich Verbraucheranwendungen um Duplikate kümmern.
Wenn Sie wissen möchten, ob Ihr Verbraucher im Rückstand ist (Sie produzieren schneller als Sie verbrauchen), können Sie die Differenz zwischen dem Zeitstempel der Nachricht und der aktuellen Zeit verwenden. Wenn diese Zahl sich erhöht, empfiehlt es sich ggf. einen neuen Verbraucher zu erzeugen, um einige Partitionen von Ihrem ersten Verbraucher zu übernehmen.
Ein einzelner Verbraucher ist eine Entität, die Nachrichten aus einem oder mehreren Streams liest.
Diese Entität könnte alleine existieren oder Teil einer Verbrauchergruppe sein.
Ein Zeiger auf eine Position in einem Stream. Diese Position kann ein Zeiger auf einen bestimmten Offset, eine bestimmte Zeit in einer Partition oder den aktuellen Ort einer Gruppe sein.
Folgende Cursortypen stehen zur Verfügung: TRIM_HORIZON, AT_OFFSET, AFTER_OFFSET, AT_TIME und LATEST. Weitere Informationen finden Sie in der Dokumentation.
Nein, der Cursor sollte außerhalb der Schleife erstellt werden. Nachdem Sie einen Cursor erstellt haben, können Sie mithilfe der GetMessages-Methode Nachrichten verarbeiten. Jeder Aufruf von GetMessages gibt den Cursor zurück, der im nächsten GetMessages-Aufruf verwendet werden soll.
Der zurückgegebene Cursor ist nicht null und läuft in 5 Minuten ab. Solange Sie weiter Nachrichten verarbeiten, sollten Sie niemals einen Cursor neu erstellen müssen.
GetMessages, Commit und Heartbeat geben alle einen neuen Cursor zurück, der für nachfolgende Aufrufe verwendet werden kann.
Einen Java-Code-Snippet finden Sie in der Dokumentation.
Bei einigen Fehlern müssen neue Cursor erstellt werden. Wir empfehlen, dass Sie diesen Schritt im Rahmen der Fehlerstrategie ausführen.
Dies ist durch Richtlinien möglich. Mandant A muss eine Richtlinie erstellen, die Mandant B Stream-Pull-Zugriff erteilt.
Wenn Sie keine Gruppencursor verwenden, muss das Speichern verarbeiteter Offsets vom Verbraucher verwaltet werden.
Wenn Sie Gruppenverbraucher verwenden, können verarbeitete Offsets im Fehlerfall festgeschrieben werden.
Wenn Sie einen Cursor erstellen, geben Sie an, welche Art von Cursors verwendet werden soll. Wenn die Anwendung mit der Nachrichtenverarbeitung beginnt, muss sie speichern, welches Offset sie erreicht bzw. bei welchem Offset sie angehalten hat.
Dieses Szenario ist praktisch, wenn Sie eine Demo oder einen Proof-of-Concept mit nur einer Partition pro Stream durchführen. In einer Produktionsumgebung mit mehreren Partitionen empfehlen wir die Verwendung von Verbrauchergruppen.
Die Methode getLimit () der GetMessageRequest-Klasse gibt die maximale Anzahl von Nachrichten zurück. Sie können einen beliebigen Wert bis zu 10.000 angeben. Standardmäßig gibt der Dienst so viele Nachrichten wie möglich zurück.
Berücksichtigen Sie Ihre durchschnittliche Nachrichtengröße, um zu vermeiden, dass der Durchsatz im Stream überschritten wird.
Die Batch-Größen des Streaming-Dienstes getMessage basieren auf der durchschnittlichen Nachrichtengröße, die für den jeweiligen Stream veröffentlicht wurde.
Eine ausführliche Erklärung finden Sie in der Dokumentation.
Verbrauchergruppen bieten folgende Vorteile:
Eine Instanz ist ein Mitglied einer Verbrauchergruppe. Sie wird definiert, wenn ein Gruppencursor erstellt wird.
Partitionslesevorgänge werden zwischen Instanzen in einer Verbrauchergruppe ausgeglichen.
Der Instanzname identifiziert das Mitglied der Gruppe für Vorgänge im Zusammenhang mit der Offsetverwaltung.
Wir empfehlen, dass Sie für jedes Mitglied der Verbrauchergruppe eindeutige Instanznamen verwenden.
Die beste Methode besteht darin, eine verkettete Zeichenfolge nützlicher Informationen zu verwenden.
Für die folgenden Komponenten des Streaming-Dienstes sind Zeitüberschreitungen relevant:
Jede Instanz innerhalb der Verbrauchergruppe muss vor der 30-Sekunden-Zeitüberschreitung einen Heartbeat ausführen. Wenn die Verarbeitung einer Nachricht beispielsweise zu lange dauert, empfehlen wir, dass die Instanz einen Heartbeat sendet.
Bei Erreichen der 30-Sekunden-Zeitüberschreitung wird die Instanz aus der Verbrauchergruppe entfernt und ihre Partition einer anderen Instanz zugewiesen (falls möglich). Dieses Ereignis wird als Rebalancing bezeichnet.
Rebalancing ist der Prozess, bei dem sich eine Gruppe von Instanzen (die zur selben Verbrauchergruppe gehören) koordiniert, um einen sich gegenseitig ausschließenden Satz von Partitionen zu besitzen, der zu einem bestimmten Stream gehört.
Am Ende einer erfolgreichen Rebalance-Operation für eine Verbrauchergruppe gehört jede Partition innerhalb des Streams einer einzelnen oder mehreren Verbraucherinstanzen innerhalb der Gruppe.
Um eine gleichmäßige Verteilung sicherzustellen, sollten Sie einen guten Wert für Ihre Nachrichtenschlüssel erstellen. Berücksichtigen Sie dazu die Selektivität und Kardinalität Ihrer Streaming-Daten.
Streben Sie eine hohe Kardinalität bei geringer Selektivität an.
Im Streaming-Dienst wird der Schlüssel gehasht und dann zum Bestimmen der Partition verwendet. Nachrichten mit demselben Schlüssel werden an dieselbe Partition gesendet. Nachrichten mit unterschiedlichen Schlüsseln werden ggf. an unterschiedliche oder an dieselben Partitionen gesendet.
Als Produzent haben Sie keine Möglichkeit, die Partition, an die eine Nachricht gesendet wird, explizit zu steuern.
Wenn die Daten mit Schlüsseln gesendet werden, kann der Produzent nicht erzwingen, dass sie an eine bestimmte Partition gesendet werden.
Ja, StreamClient ist threadsicher.
Wenn ein Objekt zustandslos ist, muss es zwischen den Aufrufen keine Daten speichern. Da kein Status geändert werden muss, kann ein Thread das Ergebnis eines anderen Threads, der die Operationen des Objekts aufruft, nicht beeinflussen. Aus diesem Grund ist eine zustandslose Klasse von Natur aus threadsicher.
Consumer Lag ist im Streaming-Dienst noch nicht implementiert.
Der erzeugte Offset für jede Nachricht wird nach jedem erfolgreichen putMessage-Aufruf zurückgegeben.
Der Nachrichtenoffset ist in jeder Nachricht enthalten, die von getMessage-Aufrufen zurückgegeben wird.
Sie können die Verzögerung bestimmen, indem Sie das Delta zwischen produzierten und verbrauchten Offsets nach Partition verfolgen.
Um festzustellen, ob Ihr Verbraucher in Verzug gerät (Sie produzieren schneller als Sie verbrauchen), können Sie den Zeitstempel der Nachricht nutzen. Wenn der Verbraucher in Verzug gerät, sollten Sie einen neuen Verbraucher erzeugen, der einige der Partitionen von Ihrem ersten Verbraucher übernimmt. Wenn Sie auf einer einzelnen Partition in Verzug geraten, können Sie keine Wiederherstellung durchführen.
Betrachten Sie die folgenden Optionen:
Wenn Sie wissen möchten, wie viele Nachrichten in einer bestimmten Partition noch verarbeitet werden müssen, verwenden Sie einen Cursor vom Typ x, rufen Sie den Offset der nächsten zuletzt veröffentlichten Nachricht ab und erstellen Sie das Delta mit dem Offset, den Sie gerade verarbeiten.
Da wir keinen dichten Offset haben, erhalten Sie einen. Wenn Ihr Produzent jedoch die Produktion einstellt, können Sie diese Informationen nicht abrufen und nur grob abschätzen (da Sie niemals den Offset der nächsten veröffentlichten Nachricht erhalten).
Die Neuzuweisung erfolgt nur bei Commit und Zeitüberschreitung. Wir empfehlen, einen Heartbeat zu verwenden und sich darauf zu verlassen, wenn die Verarbeitung von commitOnGet = true länger als 30 Sekunden dauert.
Das Schreiben einer benutzerdefinierten Commit-Logik ist kompliziert und umfasst eine Fülle von Racebedingungen und Überlegungen. Es gibt viele Fälle, in denen ein interner Status geändert wird und der Client die Situation bewältigen muss.
Ja, StreamClient ist threadsicher.
Eine Instanz einer Verbrauchergruppe gilt als inaktiv, wenn sie länger als 30 Sekunden keinen Heartbeat sendet oder der Prozess beendet wird.
In diesem Fall erfolgt ein Rebalancing innerhalb der Verbrauchergruppe, um die Partitionen zu berücksichtigen, die zuvor von der inaktiven Instanz verarbeitet wurden.
Eine solche Instanz wird als neue Instanz betrachtet. Ein Rebalancing wird ausgelöst und der Instanz wird eine Partition zugewiesen, um Nachrichten zu verarbeiten.
Der Streaming-Dienst übernimmt keine Garantie dafür, ob die Instanz, die vor der Beendigung zugewiesen wurde, dieser Instanz neu zugewiesen wird.
Der Streaming-Dienst stellt der Verbrauchergruppe „mindestens einmal“-Semantik bereit. Überlegen Sie, wann Offsets in einer Nachrichtenschleife festgeschrieben werden. Wenn ein Verbraucher vor dem Festschreiben eines Nachrichten-Batches abstürzt, wird dieser Batch möglicherweise an einen anderen Verbraucher übergeben. Wenn eine Partition an einen anderen Verbraucher übergeben wird, verwendet der Verbraucher den letzten festgeschriebenen Offset, um die Verarbeitung zu starten. Der Verbraucher erhält keine Nachrichten vor dem festgeschriebenen Offset.
Der Streaming-Dienst verarbeitet Offset-Commits automatisch für die Verbrauchergruppe, wenn „thegetCommitOnGetis“ auf „true“ eingestellt ist.
Wir empfehlen die Verwendung dieser Methode, da sie die Anwendungskomplexität verringert. Das heißt, die Anwendung sollte keinen Commit-Mechanismus implementieren.
Um diese Einstellung zu überschreiben und einen benutzerdefinierten Offset-Commit-Mechanismus zu implementieren, legen Sie „getCommitOnGetto“ beim Erstellen der Verbrauchergruppe auf „false“ fest.
CommitOnGet bedeutet, dass Offsets von der vorherigen Anforderung festgeschrieben werden. Betrachten Sie zur Veranschaulichung dieser Funktion das folgende Beispiel:
Für einen Verbraucher A:
Das Orchestrierungssystem startet einen neuen Verbraucher B:
In diesem Beispiel gingen keine Nachrichten verloren, aber die Offsets 101–115 wurden mindestens einmal verarbeitet. Dies bedeutet, dass sie möglicherweise mehr als einmal verarbeitet wurden.
In diesem Beispiel wurde möglicherweise ein Teil (15) der Nachrichten verarbeitet und nach einem Fehlerereignis erneut dem neuen Verbraucher zugestellt. Es gehen jedoch keine Daten verloren.
Derzeit ist es nicht möglich, eine einzelne Partition in einer Verbrauchergruppe zu aktualisieren.
Das aktuelle Verhalten des updateGroup-Aufrufs besteht darin, den festgeschriebenen Offset für alle Partitionen zurückzusetzen. Dies führt zu unnötigen Abrufen alter Nachrichten für die Partitionen, die den anderen fehlerfreien Verbrauchern zugewiesen wurden.
In einer Verbrauchergruppe müssen die Instanzen, die die Nachrichten verarbeiten, Heartbeats senden, bevor das Zeitlimit von 30 Sekunden erreicht wird. Wenn eine Instanz keinen Heartbeat sendet, betrachtet der Streaming-Dienst die Instanz als inaktiv und löst eine Neuzuweisung ihrer Partition aus.
Ein Cursor, der aus einem festgeschriebenen Anruf abgerufen wurde, sollte keine Offsets aufweisen. Heartbeats verlängern die Zeitüberschreitung von Partitionen im Cursor.
Einen Heartbeat für einen leeren Cursor auszuführen, sollte keine Auswirkungen haben. Der zuvor festgeschriebene Cursor könnte ein Rebalancing auslösen.
Wenn ein Cursor festgeschrieben wird und dann ein Heartbeat für den Cursor gesendet wird (statt für den vom Commit-Aufruf zurückgegebenen), werden die Zeitüberschreitungen für die enthaltenen Offsets aktualisiert.
Zur Wiederherstellung nach einem Ausfall müssen Sie den Offset der zuletzt verarbeiteten Nachricht (für jede Partition) speichern, damit Sie diese Nachricht bei einem eventuellen Neustart Ihres Verbrauchers zum Starten der Verarbeitung verwenden können.
Hinweis: Speichern Sie den Cursor nicht. Er läuft nach 5 Minuten ab.
Wir bieten keine Anleitung zum Speichern des Offsets der zuletzt verarbeiteten Nachricht, sodass Sie eine beliebige Methode verwenden können (z. B. einen anderen Stream, Kiew, eine Datei auf Ihrem Computer oder Object Storage).
Lesen Sie beim Neustart Ihres Verbrauchers den Versatz der zuletzt verarbeiteten Nachricht und erstellen Sie dann einen Cursor vom Typ AFTER_OFFSET. Geben Sie den Versatz an, den Sie gerade erhalten haben.
Wir empfehlen Kunden, Partitionen zuzuweisen, die geringfügig höher sind als ihr maximaler Durchsatz. Dies unterstützt sie bei der Verwaltung ihrer Anwendungsspitzen, da es derzeit nicht möglich ist, die Anzahl der Partitionen zu ändern, nachdem ein Stream erstellt wurde.
Standardmäßig speichern wir Daten für 24 Stunden. Sie können die Aufbewahrungsfrist für bis zu 7 Tage festlegen, während Sie einen Stream erstellen. Sobald die Beibehaltungsfrist definiert ist, kann sie nicht mehr bearbeitet werden.
Die OCI Streaming-Konsole bietet sowohl Betriebs- als auch Performance-Metriken, z. B. Durchsatz der Dateneingabe und -ausgabe. OCI Streaming ist auch in OCI Telemetry integriert, sodass Sie Telemetriemetriken für Ihre Streams erfassen, anzeigen und analysieren können.
Alle Streams in derselben Tenancy haben eindeutige, unveränderliche Namen. Jedem Stream ist einer Abteilung zugeordnet. Daher kann die gesamte Leistungsfähigkeit der Oracle Cloud Infrastructure-Zugriffssteuerungsrichtlinien genutzt werden, um differenzierte Regeln auf Tenancy-, Abteilungs- oder Einzelstream-Ebene zu beschreiben.
Die Zugriffsrichtlinie wird in der Form „Zulassen, wohin“ angegeben.
Unsere Internet-API verwendet den Oracle Identity Service. Oracle Identity Service bietet eine bequeme Möglichkeit, Nutzer zu authentifizieren und den Zugriff auf APIs sowohl über den Browser (Benutzername/Passwort) als auch über den Code (API-Schlüssel) zu autorisieren.
Weitere Informationen finden Sie hier in der Dokumentation.
OCI Streaming ist standardmäßig sicher – Nutzerdaten werden sowohl im Ruhezustand als auch in Bewegung verschlüsselt. Nur die Eigentümer des Kontos und des Daten-Streams haben Zugriff auf die von ihnen erstellten Stream-Ressourcen. OCI Streaming unterstützt die Nutzerauthentifizierung, um den Zugriff auf Daten zu steuern. Sie können die Oracle Cloud Infrastructure IAM-Richtlinien verwenden, um Benutzern und Benutzergruppen selektiv Berechtigungen zu erteilen. Sie können Ihre Daten mithilfe des HTTPS-Protokolls sicher über SSL-Endpunkte in OCI Streaming speichern und von dort abrufen.
Sie besitzen die von Ihnen ausgegebenen Daten. Sie können Ihre Daten verschlüsseln, bevor Sie sie an OSS senden.
Datenaufnahme (Ihr Produzent – Streaming-Gateway): Daten werden aufgrund von SSL (HTTPS) in Bewegung verschlüsselt.
Innerhalb des Streaming-Services: Auf dem Gateway wird SSL beendet, die Daten werden beim Eintreffen mit dem AES-128-Schlüssel pro Stream verschlüsselt und für Persistenz an die Speicherebene gesendet.
Nach Verbrauch: Verschlüsselte Daten werden aus dem OSS gelesen, vom Gateway-Knoten entschlüsselt und über SSL an den Verbraucher gesendet.
Nach Verbrauch: Verschlüsselte Daten werden aus OCI Streaming gelesen, vom Gateway-Knoten entschlüsselt und über SSL an den Verbraucher gesendet.
OCI Streaming verwendet den AES-GCM 128-Algorithmus zur Verschlüsselung.
Streaming ist vollständig in OCI-Überwachungsdienste integriert. Die Beschreibung der Streaming-Metriken finden Sie hier.
Die Überwachung im Streaming-Dienst konzentriert sich auf Produzenten und Verbraucher. Eine Liste der vom Streaming-Dienst ausgegebenen Metriken finden Sie in der Dokumentation.
Jede in der Konsole verfügbare Skala enthält die folgenden Statistiken:
Diese Statistiken bieten vier Zeitintervalle
Erwägen Sie für Produzenten Alarme für die folgenden Kennzahlen festzulegen:
Erwägen Sie für Verbraucher, dieselben Alarme basierend auf den folgenden Kennzahlen einzustellen:
Wenn ein Alarm ausgelöst wird, muss das verantwortliche Teammitglied den Alarm untersuchen und die Situation bewerten.
Wenn das Problem mit dem Client (Produzent oder Verbraucher) zusammenhängt, muss das Teammitglied es beheben oder weitere Untersuchungen mit dem Entwicklerteam durchführen.
Wenn das Problem mit dem Server zusammenhängt, sollte sich das Teammitglied an den Support des Streaming-Diensts wenden.
Ein fehlerfreier Stream ist ein Stream, der aktiv ist: Nachrichten werden erfolgreich empfangen und verarbeitet.
Schreibvorgänge an den Dienst sind dauerhaft. Wenn Sie Nachrichten für Ihren Stream produzieren können und eine erfolgreiche Antwort erhalten, ist der Stream fehlerfrei.
Nachdem Daten aufgenommen wurden, können Verbraucher für die Dauer der konfigurierten Beibehaltungsfrist auf diese zugreifen.
Wenn API-Aufrufe zum Abrufen von Nachrichten erhöhte interne Serverfehler zurückgeben, ist der Dienst nicht fehlerfrei.
Ein fehlerfreier Stream wird auch durch fehlerfreie Kennzahlen gekennzeichnet:
Details zu den API-Fehlern finden Sie in der Dokumentation.
Der Streaming-Dienst unterstützt Teilausfälle aufgrund von Drosselung pro Partition. Im Falle eines Teilausfalls gibt der Dienst einen 200-Statuscode zurück und zeigt die Fehler in der Antwortnutzlast an.
Wenn eine Anforderung insgesamt gedrosselt wird, erhalten Sie einen 429-Statuscode.
Bitte wenden Sie sich an den Oracle Streaming Service, um das Limit für Ihre Tenancy zu erhöhen.
OCI Streaming verwendet einfache nutzungsbasierte Preise. Es gibt keine Vorabkosten oder Mindestgebühren und Sie zahlen nur für die Ressourcen, die Sie verwenden.
Die tatsächlichen Preise für OCI Streaming finden Sie im Preisleitfaden.
Betrachten wir ein Szenario, in dem ein Datenproduzent insgesamt 500 Datensätze pro Sekunde erstellt und jeder Datensatz 2 KB groß ist. Der Kunde möchte Daten mit einer doppelt so hohen Eingangsrate ausgeben/abrufen. Außerdem möchte der Kunde diese Daten 7 Tage speichern.
Preisberechnung/Tag (nur als Beispiel)
Jede Datensatzgröße = 4 KB (gerundet auf 4 KB für alle Datensätze unter 4 KB)
Optional:
OCI Streaming verfügt über kein kostenloses Kontingent.