Keine Ergebnisse gefunden

Suche ergab keine Treffer

Beachten Sie die folgenden Tipps, um das Gesuchte zu finden:

  • Prüfen Sie die Schreibweise des Suchbegriffs.
  • Verwenden Sie Synonyme für das eingegebene Stichwort, z. B. “Anwendung” statt “Software.”
  • Testen Sie eine der unten gezeigten beliebten Suchen.
  • Beginnen Sie eine neue Suche.

 

Aktuelle Fragen

Häufig gestellte Fragen

Alle öffnen Alle schließen

    Allgemeine Fragen

  • Was ist Oracle Cloud Infrastructure Streaming (OCI)?

    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:

  • Wo ist der Streaming-Dienst verfügbar?

    Eine Liste der Regionen, in denen der Streaming-Dienst derzeit ausgeführt wird, finden Sie in der Dokumentation.

  • Was sind die API-Endpunkte?

    Der API-Endpunkt ist wie folgt aufgebaut: https://streaming.$_REGION.oci.oraclecloud.com

    Als Beispiel für die Variable :

    • us-phoenix-1
    • us-ashburn-1
  • Was verwaltet OCI Streaming für mich?

    OCI Streaming wird vollständig verwaltet – von der zugrunde liegenden Infrastruktur bis hin zu Bereitstellung, Wartung, Sicherheitspatches, Replikation und Verbrauchergruppen, was die Anwendungsentwicklung vereinfacht.

  • Inwiefern bietet Oracle Cloud Infrastructure Streaming Ausfallsicherheit?

    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.

  • Welche Möglichkeiten habe ich mit OCI Streaming?

    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:

    • Messaging: Verwenden Sie Streaming, um Komponenten großer Systeme zu entkoppeln. Streaming bietet ein Pull-/pufferbasiertes Kommunikationsmodell mit ausreichender Kapazität, um Lastspitzen abzufedern und mehrere Verbraucher unabhängig voneinander mit denselben Daten zu versorgen. Key-Scoped-Ordering und garantierte Beständigkeit bieten zuverlässige Grundfunktionen für die Implementierung einer Vielzahl von Messaging-Mustern, während ein hohes Durchsatzpotenzial eine gute Skalierbarkeit eines solchen Systems ermöglicht.
    • Kennzahl- und Protokollerfassung: Verwenden Sie Streaming als Alternative zu herkömmlichen Datei-Scraping-Ansätzen, um wichtige Betriebsdaten schneller für die Indizierung, Analyse und Visualisierung verfügbar zu machen.
    • Erfassung von Daten zu Web- und mobilen Aktivitäten: Verwenden Sie Streaming, um Aktivitäten von Websites oder mobilen Apps zu erfassen (z. B. Seitenaufrufe, Suchen oder andere Aktionen, die Benutzer möglicherweise ausführen). Diese Informationen können zur Echtzeitüberwachung und -analyse sowie in Data Warehousing-Systemen für die Offline-Verarbeitung und -Berichterstellung verwendet werden.
    • Verarbeitung von Infrastruktur- und Apps-Ereignissen: Verwenden Sie Streaming als einheitlichen Einstiegspunkt für Cloud-Komponenten, um deren Lebenszyklusereignisse für die Prüfung, das Rechnungswesen und damit verbundene Aktivitäten aufzuzeichnen.
  • Wie verwende ich OCI Streaming?

    Beginnen Sie mit der Verwendung von OCI durch:

    • Erstellen eines neuen Streams über die OCI Streaming-Konsole oder über die CreateTopic-API
    • Senden von Daten von Produzenten zum Thema (siehe ausführliche Dokumentation)
    • Aufbauen von Verbrauchern zum Lesen und Verarbeiten von Daten aus Ihrem Stream
  • Was sind die Grenzen von OCI Streaming?

    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:

    • Dauer von maximal 7 Tagen für Beibehaltung.
    • Die maximale Größe einer eindeutigen Nachricht beträgt 1 MB.
    • Jede Partition kann 5 API-Leseaufrufe pro Sekunde verarbeiten und bis zu 1 MB pro Sekunde mit einer beliebigen Anzahl von Schreibanforderungen verarbeiten.
    • Jede Partition kann eine maximale Gesamtdatenschreibrate von 1 MB pro Sekunde und eine Leserate von 2 MB pro Sekunde unterstützen.
    • Jede Tenancy ist auf 5 Partitionen begrenzt. Sie können jedoch weitere Partitionen anfordern. – Kontaktieren Sie uns
  • Wie verwende ich Streaming mit der Oracle Cloud Infrastructure-CLI?

    Ein Beispiel finden Sie unter GitHub, inklusive oci-cli-Binärdateien.

  • Wie greife ich auf meine Partition zu?

    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).

    Schlüsselkonzepte

  • Was ist ein Stream?

    Ein Stream kann als reine Anfügeprotokolldatei angezeigt werden, die Ihre Nachrichten enthält.

  • Was ist eine Partition?

    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.

  • Was ist eine Nachricht?

    Eine 64-Bit-codierte Nachricht ist das, was Sie in ein Thema ausgeben.

  • Was ist ein Offset?

    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.

  • Was ist ein Schlüssel?

    Ein Schlüssel ist eine Kennung, mit der verwandte Nachrichten gruppiert werden.

    Einen Stream erstellen

  • Wie erstelle ich einen neuen Stream?

    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.

  • Wie lange dauert die Bereitstellung?

    Die Bereitstellungszeit hängt von der Anzahl der Partitionen ab. Das Erstellen einer neuen Partition dauert bis zu 10 Sekunden.

  • Wie bestimme ich die Anzahl der benötigten Partitionen?

    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).

  • Was ist der Mindestdurchsatz, den ich für einen Stream anfordern kann?

    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.

  • Wie viele Anfragen kann ich an eine Partition senden?

    Sie können 1.000 Anforderungen pro Sekunde an eine Partition senden.

  • Wie nutze ich die SDKs?

    Beispiele für die Haupt-APIs des Streaming-Dienstes werden in der Dokumentation beschrieben.

    Die Beispiele umfassen die folgenden APIs:

  • Wo finde ich die SDKs?
  • Planen Sie weitere Sprachen zu unterstützen?

    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.

  • Wo finde ich die Liste aller APIs, die ich für das Streaming benötige?

    Daten in einem Stream veröffentlichen

  • Wie gebe ich Daten in einen Stream aus?

    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.

  • Wie speichert OCI Streaming Daten, wenn ich einen Nullschlüssel sende?

    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.

  • Wie stelle ich die Anordnung von Nachrichten in OCI Streaming sicher?

    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.

  • Wie stelle ich sicher, dass meine Nachricht dauerhaft ist?

    Sobald die OCI Streaming-API Ihre putMessage ohne Fehler bestätigt, sind diese Nachrichten dauerhaft.

  • Wie stellen Sie die Datenkonsistenz in einem OCI Streaming-Stream sicher?

    OCI Streaming garantiert lineare Lese- und Schreibvorgänge für einen Partitionierungsschlüssel.

  • Was passiert, wenn ich mehr Daten ausgebe als maximal zulässig?

    Wenn Clientanforderungen die Grenzwerte überschreiten, lehnt OCI Streaming die Anforderung ab und sendet eine Fehlerausnahmemeldung.

  • Wann erfolgt eine Drosselung?

    Der Drosselmechanismus wird aktiviert, wenn die folgenden Schwellenwerte überschritten werden:

    • GetMessages: 5 Aufrufe pro Sekunde oder 2 MB/s pro Partition
    • PutMessages: 1 MB/s pro Partition.
    • Verwaltungs- und Steuerebenenoperationen (CreateCursor, listStream usw.): 5 Aufrufe pro Sekunde pro Stream.
  • Soll ich meine Nachrichten als Batch ausgeben?

    Wir empfehlen die Ausgabe von Nachrichten als Batch aus folgenden Gründen:

    • Die Anzahl der an den Dienst gesendeten Put-Anforderungen wird reduziert, wodurch eine Drosselung vermieden wird.
    • Es wird ein bessere Durchsatz ermöglicht.

    Die Größe eines Nachrichten-Batches sollte 1 MB nicht überschreiten. Wird dieser Grenzwert überschritten, wird der Drosselmechanismus ausgelöst.

  • Wie gehe ich mit Nachrichten um, die größer als 1 MB sind?

    Sie können einen der folgenden Ansätze verwenden: Blockerstellung oder Senden der Nachricht über Objektspeicher.

  • Blockerstellung

    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.

  • Object Storage

    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.

  • Welches Datumsformat akzeptiert der Dienst?

    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.

  • Wie erhalte ich die Partitionsnummer und den Offset vom Streaming-Dienst, während ich eine Nachricht veröffentliche?

    Die PutMessagesResultsEntry-Klasse bietet die folgenden Methoden:

    • getPartition – Gibt die Partitionsnummer an, auf der die Nachricht veröffentlicht wurde
    • getOffset – Stellt den Offset der veröffentlichten Nachricht bereit
  • Wie erhalte ich die Partitionsnummer und den Offset vom Streaming-Dienst ohne eine Nachricht zu veröffentlichen?

    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.

    Daten aus einem Stream verarbeiten – Einzelverbraucher

  • Wie lese und verarbeite ich Daten aus einem Stream?

    Für das Verarbeiten von Nachrichten müssen Sie Folgendes tun:

    • Erstellen Sie einen Cursor.
    • Verwenden Sie den Cursor, um Nachrichten zu lesen.
    • Weitere Informationen finden Sie in der technischen Dokumentation mit der schrittweisen Anleitung zum Verarbeiten von Daten aus einem Stream.

  • Welche verschiedenen Möglichkeiten gibt es, um Daten aus einem OCI Streaming-Stream zu verarbeiten?

    OCI Streaming bietet zwei Arten der Nutzung von APIs:

    • Low-Level-Inspektion zur präzisen Steuerung von Partitionen und Offsets zum Lesen von Daten
    • Verbrauchergruppen zur Vereinfachung der Anwendungsentwicklung durch Auslagerung von Lastausgleich, Koordination und Offset-Nachverfolgung an den Service
  • Wie funktionieren Verbrauchergruppen?

    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.

  • Wie vermeide ich doppelte Nachrichten an meine Verbraucher?

    Wir empfehlen, dass sich Verbraucheranwendungen um Duplikate kümmern.

  • Woher weiß ich, ob Verbraucher im Rückstand sind?

    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.

  • Was ist ein einzelner Verbraucher?

    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.

  • Was ist der Cursor?

    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.

  • Welche Cursortypen sind verfügbar?

    Folgende Cursortypen stehen zur Verfügung: TRIM_HORIZON, AT_OFFSET, AFTER_OFFSET, AT_TIME und LATEST. Weitere Informationen finden Sie in der Dokumentation.

  • Muss ich bei jedem Verarbeiten einer Nachricht einen Cursor neu generieren?

    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.

  • Kann ein Verbraucher, der zu Mandant B gehört, Nachrichten aus einem Stream verarbeiten, der zu Mandant A gehört?

    Dies ist durch Richtlinien möglich. Mandant A muss eine Richtlinie erstellen, die Mandant B Stream-Pull-Zugriff erteilt.

  • Wie gehe ich mit Offsets um?

    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.

  • Wie viele Nachrichten kann ich mit einem getMessage-Aufruf erhalten?

    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.

    Daten aus einem Stream verarbeiten – Verbrauchergruppen

  • Wie funktionieren Verbrauchergruppen?

    Eine ausführliche Erklärung finden Sie in der Dokumentation.

  • Warum sollte ich Verbrauchergruppen verwenden?

    Verbrauchergruppen bieten folgende Vorteile:

    • Jede Instanz empfängt Nachrichten von einer oder mehreren Partitionen (die ihr „automatisch“ zugewiesen werden). Diese Nachrichten werden von den anderen Instanzen (die verschiedenen Partitionen zugewiesen sind) nicht empfangen. Auf diese Weise können wir die Anzahl der Instanzen hochskalieren (wobei eine Instanz nur eine Partition liest). In diesem Fall befindet sich eine neue Instanz, die der Gruppe beitritt, in der Anzahl der Partitionen und im Ruhezustand, ohne einer Partition zugewiesen zu sein.
    • Instanzen als Teil von etwas zu haben bedeutet, eine Instanz bereitzustellen, in der die Nachrichten von verschiedenen Verbrauchergruppen-Partitionen mit publish/subscribe-Muster an alle Instanzen in den verschiedenen Gruppen gesendet werden. Innerhalb derselben Verbrauchergruppe gelten die Regeln wie im ersten nachfolgenden Bild gezeigt, aber über verschiedene Gruppen hinweg erhalten die Instanzen dieselben Nachrichten (wie im zweiten Bild gezeigt). Dies ist nützlich, wenn die Nachrichten in einer Partition für verschiedene Anwendungen von Interesse sind, die sie auf unterschiedliche Weise verarbeiten. Alle interessierten Anwendungen sollen dieselben Nachrichten von der Partition erhalten.
    • Ein weiterer Vorteil von Verbrauchergruppen ist die Rebalancing-Funktion. Wenn eine Instanz einer Gruppe beitritt und genügend Partitionen verfügbar sind (d. h., das Limit einer Instanz pro Partition wurde nicht erreicht), wird ein Rebalancing gestartet. Die Partitionen werden den aktuellen Instanzen sowie der neuen Instanz neu zugewiesen. Wenn eine Instanz eine Gruppe verlässt, werden die Partitionen entsprechend den verbleibenden Instanzen zugewiesen.
    • Offset-Commits werden automatisch verwaltet.
  • Was ist eine Instanz?

    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.

  • Gibt es eine bewährte Methode zum Benennen meiner Instanzen?

    Die beste Methode besteht darin, eine verkettete Zeichenfolge nützlicher Informationen zu verwenden.

  • Welche Zeitüberschreitungen muss ich beachten?

    Für die folgenden Komponenten des Streaming-Dienstes sind Zeitüberschreitungen relevant:

    • Cursor: Solange Sie weiterhin Nachrichten verarbeiten, müssen Sie keinen neuen Cursor erstellen. Wenn die Nachrichtenverarbeitung länger als 5 Minuten angehalten wird, muss der Cursor neu erstellt werden.
    • Instanz: Wenn eine Instanz länger als 30 Sekunden keine Nachrichten mehr verarbeitet, wird sie aus der Verbrauchergruppe entfernt und ihre Partition wird einer anderen Instanz zugewiesen (Rebalancing wird ausgelöst).
  • Wie lange muss eine Instanz einen Heartbeat ausführen, bevor eine Zeitüberschreitung erfolgt?

    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.

  • Was passiert, wenn das Zeitlimit einer Instanz überschritten wird?

    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.

  • Was ist Rebalancing innerhalb einer Verbrauchergruppe?

    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.

  • Wie generiere ich einen effektiven Partitionsschlüssel?

    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.

    • Kardinalität: Berücksichtigen Sie die Gesamtzahl der eindeutigen Schlüssel, die je nach Anwendungsfall potenziell generiert werden könnten. Eine höhere Schlüsselkardinalität bedeutet im Allgemeinen eine bessere Verteilung.
    • Selektivität: Berücksichtigen Sie die Anzahl der Nachrichten mit jedem Schlüssel. Höhere Selektivität bedeutet mehr Nachrichten pro Schlüssel, was zu Hotspots führen kann.

    Streben Sie eine hohe Kardinalität bei geringer Selektivität an.

  • An welche Partition werden meine Nachrichten gesendet?

    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.

  • Kann ich erzwingen, dass Nachrichten an eine bestimmte Partition gesendet werden?

    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.

  • Kann ich eine StreamClient-Instanz für Threads freigeben?

    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.

  • Wie viele Nachrichten enthält die aktuelle Partition?

    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.

  • Woher weiß ich, ob ich bei der Nachrichtenverarbeitung in Verzug gerate?

    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:

    • Erhöhen Sie die Anzahl der Partitionen im Stream.
    • Wenn das Problem durch einen Hotspot verursacht wird, ändern Sie die Nachrichtenschlüsselstrategie.
    • Reduzieren Sie die Nachrichtenverarbeitungszeit oder bearbeiten Sie Anforderungen parallel.

    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).

  • Was ist das erwartete Verhalten, wenn Verbraucher A einen Cursor für Partition 1 hat, die Partition jedoch vor Ablauf der 30 Sekunden einem neuen Verbraucher zugewiesen wird?

    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.

  • Was passiert, wenn eine Instanz der Verbrauchergruppe inaktiv wird?

    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.

  • Was passiert, wenn eine zuvor inaktive Instanz der Verbrauchergruppe wieder der Gruppe beitritt?

    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.

  • Wenn eine zuvor inaktive Instanz der Verbrauchergruppe wieder der Gruppe beitritt, verarbeitet sie dann doppelte Nachrichten?

    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.

  • Wie gehe ich mit Offset-Commits um?

    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.

  • Wie funktioniert CommitOnGet?

    CommitOnGet bedeutet, dass Offsets von der vorherigen Anforderung festgeschrieben werden. Betrachten Sie zur Veranschaulichung dieser Funktion das folgende Beispiel:

    Für einen Verbraucher A:

    • A ruft getMessages auf und empfängt Nachrichten von einer beliebigen Partition mit Offsets von 1–100.
    • A verarbeitet alle 100 Nachrichten erfolgreich
    • A ruft getMessages auf, der Streaming-Dienst schreibt den Offset 100 fest und gibt Nachrichten mit den Offsets 101–200 zurück.
    • A verarbeitet 15 Nachrichten und geht dann unerwartet offline (länger als 30 Sekunden).

    Das Orchestrierungssystem startet einen neuen Verbraucher B:

    • B ruft getMessages auf, der Streaming-Dienst verwendet den letzten festgeschriebenen Offset und gibt Nachrichten mit den Offsets 101–200 zurück.
    • B setzt die Nachrichtenschleife fort.

    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.

  • Wie aktualisiere ich die Offsets, die die Beibehaltungsfrist für eine einzelne Partition in einem Stream mit mehreren Partitionen überschritten haben?

    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.

  • Warum muss ich Heartbeats senden?

    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.

  • Welches Verhalten ist zu erwarten, wenn ich einen Heartbeat mit einer Cursorzeichenfolge sende, die bereits festgeschrieben ist?

    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.

  • Wie erfolgt die Wiederherstellung nach einem Verbraucherausfall?

    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.

    Verwalten eines OCI Streaming-Streams

  • Kann ich die Anzahl der Partitionen später ändern?

    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.

  • Kann ich die Lebensdauer meines Themas ändern?

    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.

  • Wie kann ich die Vorgänge und Performance meines OCI Streaming-Streams überwachen?

    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.

    Sicherheit und Verschlüsselung

  • Wie verwalte und kontrolliere ich den Zugriff auf meinen Stream?

    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.

  • Wie authentifiziere ich mich beim Senden oder Nutzen von Daten von OCI Streaming?

    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.

  • Wie sicher sind meine Daten bei der Verwendung von OCI Streaming?

    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.

  • Kann ich meine Daten verschlüsseln?

    Sie besitzen die von Ihnen ausgegebenen Daten. Sie können Ihre Daten verschlüsseln, bevor Sie sie an OSS senden.

  • Können Sie mich durch den Verschlüsselungslebenszyklus meiner Daten von dem Zeitpunkt an führen, an dem ich sie an einen OCI Streaming-Stream sende, bis ich sie abrufe?

    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.

  • Welcher Verschlüsselungsalgorithmus wird für die OCI Streaming-Verschlüsselung verwendet?

    OCI Streaming verwendet den AES-GCM 128-Algorithmus zur Verschlüsselung.

    Überwachung

  • Wo kann ich meinen Stream überwachen?

    Streaming ist vollständig in OCI-Überwachungsdienste integriert. Die Beschreibung der Streaming-Metriken finden Sie hier.

  • Welche Metriken gibt der Streaming-Dienst aus?

    Die Überwachung im Streaming-Dienst konzentriert sich auf Produzenten und Verbraucher. Eine Liste der vom Streaming-Dienst ausgegebenen Metriken finden Sie in der Dokumentation.

  • Welche Statistiken stehen für die Überwachung des Streaming-Dienstes zur Verfügung?

    Jede in der Konsole verfügbare Skala enthält die folgenden Statistiken:

    • Rate, Summe und Mittelwert
    • Minimum, Maximum und Anzahl
    • P50, P90, P95, P99 und P99.9

    Diese Statistiken bieten vier Zeitintervalle

    • Automatisch
    • 1 Minute
    • 5 Minuten
    • 1 Stunde
  • Für welche Kennzahlen sollte ich Alarme einstellen?

    Erwägen Sie für Produzenten Alarme für die folgenden Kennzahlen festzulegen:

    • Put Messages Latency:network issues.
    • Put Messages Total Throughput:
      • Eine wichtige Erhöhung des Gesamtdurchsatzes könnte darauf hinweisen, dass das Limit von 1 MB/s pro Partition erreicht wird und dieses Ereignis den Drosselungsmechanismus auslöst.
      • Ein deutlicher Rückgang könnte bedeuten, dass der Client-Produzent ein Problem hat oder im Anhalten begriffen ist.
    • Put Messages Throttle Records: Es ist wichtig, benachrichtigt zu werden, wenn Nachrichten gedrosselt werden.
    • Put Messages Failure: Es ist wichtig, benachrichtigt zu werden, wenn Put-Nachrichten fehlschlagen, damit das Ops-Team die Gründe ermitteln kann.

    Erwägen Sie für Verbraucher, dieselben Alarme basierend auf den folgenden Kennzahlen einzustellen:

    • Get Messages Latency
    • Get Messages Total Throughpu
    • Get Messages Throttled Requests
    • Get Messages Failure
  • Was soll ich tun, wenn ich einen Alarm erhalte?

    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.

  • Woher weiß ich, dass mein Stream fehlerfrei ist?

    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:

    • Put Messages Latency ist niedrig.
    • Put Messages Total Throughput liegt bei 1 MB/s pro Partition.
    • Put Messages Throttled Records liegt nahe 0.
    • Put Messages Failure liegt nahe 0.
    • Get Messages Latency ist niedrig.
    • Get Messages Total Throughput liegt bei 2 MB/s pro Partition.
    • Get Messages Throttled Requests liegt nahe 0.
    • Get Messages Failure liegt nahe 0.

    Fehlertypen und Bedeutungen

  • Wo finde ich die Liste der API-Fehler?

    Details zu den API-Fehlern finden Sie in der Dokumentation.

  • Was ist unter Teilausfall zu verstehen?

    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.

  • Warum wird der Fehler, dass ich die Anzahl der zulässigen Partitionen überschreite, angezeigt?

    Bitte wenden Sie sich an den Oracle Streaming Service, um das Limit für Ihre Tenancy zu erhöhen.

    Preisgestaltung und Abrechnung

  • Wie ist der Preis für OCI Streaming gestaltet?

    OCI Streaming verwendet einfache nutzungsbasierte Preise. Es gibt keine Vorabkosten oder Mindestgebühren und Sie zahlen nur für die Ressourcen, die Sie verwenden.

    • GET/PUT-Anforderungspreis (Gigabyte übertragene Daten)

    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)

    • In diesem Szenario beträgt die Gesamtmenge der pro Tag erzeugten Daten 500 * 4 * 24 * 60 * 60 KB = 172,8 GB
    • Gesamtmenge der abgerufenen Daten = doppelt so viel wie bei Produkt = 2*172,8 GB = 345,6 GB
    • PUT-Anforderungspreis/Tag = $172,8 * $xx = $A
    • GET-Anforderungspreis/Tag = $345.6 * $xx = $B
    • Datenspeicherkosten = $172,8*24*7*$yy = $C
    • Gesamtrechnung/Tag = $(A + B + C)

    Optional:

    • Für die erweiterte Datenbeibehaltung entstehen optionale Kosten, die durch die Anzahl der zusätzlichen Tage über die standardmäßige 24-stündige Beibehaltung (Gigabyte Storage pro Stunde) hinaus bestimmt werden.
  • Gibt es ein kostenloses Kontingent für OCI Streaming?

    OCI Streaming verfügt über kein kostenloses Kontingent.