Votre recherche n’a donné aucun résultat.
Nous vous suggérons d’essayer ce qui suit pour trouver ce que vous recherchez :
Le service Oracle Cloud Infrastructure Streaming service représente une option de stockage durable, évolutif, entièrement géré pour les flux de données continus à fort volume, que vous pouvez consommer et traiter quasiment en temps réel.
Pour plus d'informations, consultez les rubriques suivantes dans la Documentation :
Pour obtenir la liste des régions qui exécutent actuellement le service de streaming, consultez la documentation.
Le point de terminaison API est construit comme suit : https://streaming.$_REGION.oci.oracleCloud.com
Exemple pour la variable :
OCI Streaming est entièrement géré, de l’infrastructure sous-jacente au provisionnement, au déploiement, à la maintenance, aux correctifs de sécurité, à la réplication et aux groupes de consommateurs, ce qui facilite le développement d’applications.
Lorsque vous créez un flux dans OCI Streaming, Oracle crée et gère automatiquement 3 nœuds de diffusion en continu répartis sur 3 AD différents (ou domaines de défaillance pour des régions AD uniques), garantissant ainsi la haute disponibilité de vos flux et la durabilité de vos données.
OCI Streaming permet d’émettre des données et de les récupérer quasiment en temps réel. Le nombre de cas d’utilisation est presque illimité, de la messagerie au traitement de flux de données complexes.
Voici quelques-unes des nombreuses utilisations possibles de la diffusion en continu :
Commencez à utiliser OCI Streaming en :
Dans l'ensemble, la quantité de débit à laquelle vous pouvez accéder n'a pas de limites. Il vous suffit de concevoir de manière proactive votre flux avec le bon nombre de partitions.
Les limites strictes du système sont :
Dans nos API, une partition est représentée sous forme de chaîne.
Si vous créez un flux avec cinq partitions, vous pouvez y accéder en utilisant les chaînes « 0 », « 1 », « 2 », « 3 » ou « 4 ».
Ne vous fiez pas aux identificateurs de partition représentés sous forme de valeur numérique.
Les décalages ne sont pas denses. Attendez-vous à ce que les décalages de message augmentent toujours, mais parfois pas de 1. Ne vous fiez pas à cela pour faire de futurs calculs de décalage.
Par exemple, si vous publiez deux messages sur la même partition, le premier message peut avoir le décalage 42 et le deuxième message peut avoir le décalage 45 (les décalages 43 et 44 étant inexistants).
Un flux peut être visualisé sous la forme d’un fichier journal en annexation uniquement contenant vos messages.
Les flux sont divisés en un certain nombre de partitions en vue de leur évolutivité. Les partitions permettent de distribuer un flux en divisant les messages sur plusieurs nœuds (ou courtiers). Chaque partition peut être placée sur un ordinateur distinct pour permettre à plusieurs consommateurs de lire un sujet en parallèle.
Un message codé sur 64 bits correspond à ce que vous émettez dans un sujet.
Chaque message au sein d’une partition possède un identifiant appelé décalage. Les consommateurs peuvent lire les messages à partir d’un décalage spécifique et sont autorisés à lire à partir de n’importe quel point de décalage de leur choix. Les consommateurs peuvent également valider le dernier décalage traité afin de reprendre leur travail sans répéter ni manquer un message en cas d’arrêt et de redémarrage.
Une clé est un identifiant utilisé pour regrouper les messages associés.
Vous pouvez créer un flux en utilisant notre console ou notre API. Consultez l’API ici.
Votre flux est créé pour une région et une entité particulières et éventuellement pour un compartiment dédié. Les données d’un flux sont répliquées dans toute la région, ce qui permet de tolérer les pertes AD ou les fractionnements de réseau sans perturber le service et offre une haute disponibilité intégrée dans une région.
La durée de mise en service dépend du nombre de partitions. La création d’une partition prend jusqu’à 10 secondes.
Le nombre de partitions pour votre flux dépend du débit attendu de votre application (débit attendu = taille moyenne de l’enregistrement x nombre maximal d’enregistrements écrits par seconde).
Le débit d’un flux Oracle Cloud Infrastructure est défini par une partition. Une partition fournit une entrée de données de 1 Mo/s et une sortie de données de 2 Mo/s.
Vous pouvez envoyer 1 000 demandes par seconde à une partition.
Des exemples des principales API du service de streaming sont décrits dans la documentation.
Les exemples incluent les API suivantes :
Streaming SDK prendra en charge les mêmes langues que les autres implémentations OCI SDK. Aucune autre langue supplémentaire ne sera prise en charge pour le service de streaming en particulier.
Une fois qu’un flux est créé et actif, vous pouvez publier des messages. Pour la publication, vous pouvez utiliser l’API en écriture (putMessages). Le message sera publié dans une partition du flux. S’il existe plusieurs partitions, la partition sur laquelle le message sera publié est calculée à l’aide de la clé du message.
Si la clé est nulle, la partition sera calculée avec un sous-ensemble de la valeur. Dans le cas de messages avec une clé nulle, ne vous attendez pas à ce que les messages ayant la même valeur soient placés sur la même partition, car le schéma de partitionnement peut changer. Le fait d’envoyer une clé nulle placera effectivement le message dans une partition aléatoire.
Si vous voulez vous assurer que les messages possédant la même valeur soient placés dans la même partition, vous devez utiliser la même clé pour ces messages.
Dès que l’API OCI Streaming reconnaît votre putMessage sans erreur, ce message est durable.
OCI Streaming bénéficie de lectures et écritures linéaires dans une clé de partitionnement.
Lorsque les demandes des clients dépassent les limites, OCI Streaming refuse la demande et envoie un message d’erreur.
Le mécanisme de limitation s'active lorsque les seuils suivants sont dépassés :
Nous vous recommandons de grouper les messages pour les raisons suivantes :
La taille d'un lot de messages ne doit pas dépasser 1 Mo. Si cette limite est dépassée, le mécanisme de limitation est déclenché.
Vous pouvez utiliser l'une des approches suivantes : couper ou envoyer le message via Object Storage.
Les grandes charges utiles peuvent être divisées en plusieurs morceaux plus petits que le service de streaming peut accepter.
Les morceaux sont stockés dans le service de la même manière que les messages ordinaires (non fragmentés) sont stockés. La seule différence est que le consommateur doit conserver les morceaux et les combiner dans le vrai message lorsque tous les morceaux ont été collectés.
Les morceaux de la partition peuvent être entrelacés avec un message ordinaire.
Une grande charge utile est placée dans Object Storage et seul le pointeur vers ces données est transféré. Le récepteur reconnaît ce type de charge utile de pointeur, lit de manière transparente les données dans Object Storage et les fournit à l'utilisateur final.
Une erreur courante consiste à fournir un format de date incorrect.
Le service Streaming prend en charge la norme ISO-8601, y compris le fuseau horaire pour toutes les dates.
La classe PutMessagesResultsEntry fournit les méthodes suivantes :
Pour le moment, il n'y a aucun moyen de voir le dernier message publié sans publier un message.
Il existe un mécanisme pour voir le dernier décalage validé, par groupe ou partition. Examinez le point de terminaison getGroup.
L’utilisation de messages nécessite de votre part :
Reportez-vous à la documentation technique pour connaître la procédure d’utilisation de données d’un flux.
OCI Streaming propose deux types d’API de consommation :
Il est possible de configurer des utilisateurs pour qu’ils utilisent des messages au sein d’un groupe. Les partitions de flux sont réparties entre les membres d’un groupe afin que les messages provenant d’une partition unique ne soient envoyés qu’à un seul utilisateur.
Les attributions de partition sont rééquilibrées lorsque les utilisateurs rejoignent ou quittent le groupe.
Nous recommandons que les applications grand public prennent en charge les doublons.
Si vous voulez savoir si votre utilisateur éprouve des difficultés à vous suivre (si vous produisez plus vite que vous ne consommez), vous pouvez utiliser la différence entre l’horodatage du message et l’heure actuelle. Si ce chiffre augmente, vous voudrez peut-être créer un nouveau utilisateur qui prendra en charge certaines des partitions de votre premier utilisateur.
Un seul consommateur est une entité qui lit les messages d'un ou plusieurs flux.
Cette entité pourrait exister seule ou faire partie d'un groupe de consommateurs.
Un pointeur vers un emplacement dans un flux. Cet emplacement peut être un pointeur vers un décalage ou une heure spécifique dans une partition, ou vers l'emplacement actuel d'un groupe.
Les types de curseur suivants sont disponibles : TRIM_HORIZON, AT_OFFSET, AFTER_OFFSET, AT_TIME et LATEST. Pour plus de détails, consultez la documentation.
Non, le curseur doit être créé en dehors de la boucle. Après avoir créé un curseur, vous pouvez commencer à consommer des messages à l'aide de la méthode GetMessages. Chaque appel à GetMessages renvoie le curseur à utiliser dans le prochain appel GetMessages.
Le curseur renvoyé n'est pas nul et expire dans 5 minutes. Tant que vous continuez à consommer, vous ne devriez jamais avoir à recréer un curseur.
GetMessages, Commit et Heartbeat renvoient tous un nouveau curseur à utiliser pour les appels suivants.
Un extrait de code Java est disponible dans la Documentation.
Dans quelques cas d'erreur, il est nécessaire de créer de nouveaux curseurs. Nous vous recommandons de gérer cela dans le cadre de la stratégie d'échec.
Cela est possible grâce à des politiques. Le locataire A doit créer une politique qui donne un accès par extraction de flux au locataire B.
Lorsque vous n'utilisez pas de curseurs de groupe, le stockage des décalages traités doit être géré par le consommateur.
Lorsque vous utilisez des consommateurs de groupe, des compensations traitées peuvent être validées en cas d'échec.
Lorsque vous créez un curseur, spécifiez le type de curseur à utiliser. Lorsque l'application commence à consommer des messages, elle doit indiquer quel décalage elle a atteint / à quel décalage elle s'est arrêtée.
Ce scénario est pratique lors d'une démonstration ou d'une preuve de concept, en utilisant une seule partition par flux. Dans un environnement de production avec plusieurs partitions, nous vous recommandons d'utiliser des groupes de consommateurs.
La méthode getLimit( ) de la classe GetMessageRequest renvoie le nombre maximum de messages. Vous pouvez spécifier n'importe quelle valeur jusqu'à 10 000. Par défaut, le service renvoie autant de messages que possible.
Tenez compte de la taille moyenne de vos messages pour éviter de dépasser le débit sur le flux.
Les tailles de lot du service de streaming getMessage sont basées sur la taille moyenne des messages publiés sur le flux particulier.
Pour obtenir une explication détaillée, consultez la documentation.
Les groupes de consommateurs offrent les avantages suivants :
Une instance est membre d'un groupe de consommateurs. Elle est définie lorsqu'un curseur de groupe est créé.
Les lectures de partition sont équilibrées entre les instances d'un groupe de consommateurs.
Le nom d'instance identifie ce membre du groupe pour les opérations liées à la gestion des décalages.
Nous vous recommandons d'utiliser des noms d'instance uniques pour chaque membre du groupe de consommateurs.
La bonne pratique consiste à utiliser une chaîne concaténée d'informations utiles.
Les composants suivants du service Streaming ont des délais d'expiration :
Chaque instance du groupe de consommateurs doit utiliser les pulsations avant le délai d'expiration de 30 secondes. Par exemple, si le traitement d'un message prend trop de temps, nous recommandons que l'instance envoie une pulsation.
Lorsque le délai de 30 secondes est atteint, l'instance est supprimée du groupe de consommateurs et sa partition est réaffectée à une autre instance (si possible). Cet événement est appelé rééquilibrage.
Le rééquilibrage est le processus dans lequel un groupe d'instances (appartenant au même groupe de consommateurs) se coordonne pour posséder un ensemble de partitions mutuellement exclusives qui appartient à un flux spécifique.
À la fin d'une opération de rééquilibrage réussie pour un groupe de consommateurs, chaque partition du flux appartient à une ou plusieurs instances de consommateur au sein du groupe.
Pour assurer une distribution uniforme, vous devez créer une bonne valeur pour vos clés de message. Pour ce faire, tenez compte de la sélectivité et de la cardinalité de vos données en streaming.
Essayez d'obtenir une cardinalité élevée avec une faible sélectivité.
Dans le service Streaming, la clé est hachée, puis utilisée pour déterminer la partition. Les messages avec la même clé vont dans la même partition. Les messages avec des clés différentes peuvent aller vers des partitions différentes ou vers les mêmes partitions.
En tant que producteur, vous ne pouvez pas contrôler explicitement la partition vers laquelle va un message.
Si les données sont envoyées avec des clés, le producteur ne peut pas les forcer à aller vers une partition particulière.
Oui, StreamClient est sûr pour les threads.
Lorsqu'un objet est sans état, il n'a pas à conserver de données entre les invocations. Il n'y a aucun état à modifier ; un thread ne peut donc pas affecter le résultat d'un autre thread qui appelle les opérations de l'objet. Pour cette raison, une classe sans état est intrinsèquement sûre pour les threads.
Le retard du consommateur n'est pas encore implémenté dans le service Streaming.
Le décalage produit pour chaque message est renvoyé après chaque appel putMessage réussi.
Le décalage de message est inclus avec chaque message renvoyé par les appels getMessage.
Vous pouvez déterminer le décalage en suivant le delta entre les décalages produits et consommés, par partition.
Pour déterminer si votre consommateur prend du retard (vous produisez plus vite que vous ne consommez), vous pouvez utiliser l'horodatage du message. Si le consommateur prend du retard, envisagez de créer un nouveau consommateur pour reprendre certaines des partitions de votre premier consommateur. Si vous êtes en retard sur une seule partition, il n'y a aucun moyen de récupérer ce retard.
Considérez les options suivantes :
Si vous voulez savoir combien de messages il reste à consommer dans une partition donnée, utilisez un curseur de type, obtenez le décalage du message LATESTpublished suivant et effectuez le delta avec le décalage que vous consommez actuellement.
Nous n'avons pas de décalage dense, vous obtiendrez donc un . Cependant, si votre producteur a cessé de produire, vous ne pourrez obtenir une estimation approximative que pour ces informations (car vous n'aurez jamais le décalage du prochain message publié).
La réaffectation se produit uniquement lors de la validation et du délai d'expiration. Nous vous recommandons d'utiliser et de compter une pulsation si commitOnGet=trueprocessing prend plus de 30 secondes.
L'écriture d'une logique de validation personnalisée est compliquée et soumise à de nombreuses conditions et considérations. Il existe de nombreux cas dans lesquels certains états internes sont modifiés et le client doit gérer la situation.
Oui, StreamClient est sûr pour les threads.
Une instance d'un groupe de consommateurs est considérée comme inactive si elle n'envoie pas de pulsation pendant plus de 30 secondes, ou si le processus est interrompu.
Lorsque cela se produit, un rééquilibrage au sein du groupe de consommateurs se produit pour gérer les partitions précédemment consommées par l'instance inactive.
Une telle instance est considérée comme une nouvelle instance. Un rééquilibrage est déclenché et une instance est affectée à une partition pour commencer à consommer les messages.
Le service de streaming ne garantit pas que la même partition (celle attribuée avant l'arrêt) soit réattribuée à cette instance.
Le service de streaming fournit une sémantique « au moins une fois » au groupe de consommateurs. Déterminez quand les décalages sont validés dans une boucle de message. Si un consommateur se bloque avant de valider un lot de messages, ce lot peut être remis à un autre consommateur. Lorsqu'une partition est donnée à un autre consommateur, le consommateur utilise le dernier décalage validé pour démarrer la consommation. Le consommateur ne reçoit pas de messages avant le décalage validé.
Le service Streaming gère automatiquement les validations de décalage pour le groupe de consommateurs lorsque thegetCommitOnGetis est défini sur true.
Nous vous recommandons d'utiliser cette méthode car elle réduit la complexité de l'application ; l'application ne doit implémenter aucun mécanisme de validation.
Pour remplacer ce paramètre et implémenter un mécanisme de validation de décalage personnalisé, définissez getCommitOnGetto sur false lors de la création du groupe de consommateurs.
CommitOnGet signifie que les décalages de la demande précédente sont validés. Pour illustrer cette fonctionnalité, considérons l'exemple suivant :
Pour un consommateur A :
Le système d'orchestration démarre un nouveau consommateur B :
Dans cet exemple, aucun message n'a été perdu, mais les décalages 101 à 115 ont été traités au moins une fois, ce qui signifie qu'ils auraient pu être traités plusieurs fois.
Dans cet exemple, une partie (15) des messages peut avoir été traitée et peut être redistribuée au nouveau consommateur après un défaut Bevent, mais aucune donnée n'est perdue.
Actuellement, il n'est pas possible de mettre à jour une partition individuelle dans un groupe de consommateurs.
Le comportement actuel de l'appel updateGroup consiste à réinitialiser commitOffset pour toutes les partitions, ce qui entraîne la récupération inutile d'anciens messages pour les partitions qui ont été attribuées aux autres consommateurs sains.
Dans un groupe de consommateurs, les instances qui consomment les messages doivent envoyer des pulsations avant d'atteindre le délai d'expiration de 30 secondes. Si une instance ne parvient pas à envoyer une pulsation, le service Streaming considère l'instance comme inactive et déclenche une réaffectation de sa partition.
Un curseur récupéré d'un appel validé ne doit pas avoir de décalage. Les pulsations prolongent le délai d'expiration des partitions dans le curseur.
L'application d'une pulsation sur un curseur vide n'aurait aucune conséquence. Le curseur validé précédent pourrait déclencher un rééquilibrage.
Si un curseur est validé, puis qu'une pulsation est effectuée sur le curseur (plutôt que celui renvoyé par l'appel de validation), il met à jour les mêmes délais d'expiration pour les décalages contenus.
Pour récupérer après une défaillance, vous devez stocker le décalage du dernier message que vous avez traité (pour chaque partition) afin de pouvoir commencer à consommer à partir de ce message si vous devez redémarrer votre consommateur.
Remarque : Ne stockez pas le curseur ; il expire après 5 minutes.
Nous ne fournissons aucune indication pour stocker le décalage du dernier message que vous avez traité. Vous pouvez donc utiliser la méthode de votre choix (par exemple, un autre flux, Kiev, un fichier sur votre machine ou Object Storage).
Lorsque votre consommateur redémarre, lisez le décalage du dernier message que vous avez traité, puis créez un curseur de type AFTER_OFFSET et spécifiez le décalage que vous venez d'obtenir.
Nous recommandons aux clients d’attribuer des partitions légèrement supérieures à leur débit maximal. Cela aide à gérer les pics des applications, car nous ne prenons pas en charge la modification du nombre de partitions une fois qu’un flux est créé.
Par défaut, nous stockons les données pendant 24 heures. Vous pouvez configurer la période de conservation jusqu’à 7 jours lors de la création d’un flux. Une fois la période de conservation définie, vous ne pouvez plus la modifier.
La console OCI Streaming fournit des indicateurs opérationnels et de performance, tels que le débit d’entrée et de sortie des données. OCI Streaming s’intègre également à OCI Telemetry afin que vous puissiez collecter, afficher et analyser les indicateurs de télémétrie pour vos flux.
Tous les flux de la même entité portent des noms uniques et immuables. Chaque flux a un compartiment assigné. Ainsi, toute la puissance des stratégies de contrôle d’accès Oracle Cloud Infrastructure peut être utilisée pour décrire des règles détaillées au niveau de l’entité, du compartiment ou du flux unique.
La stratégie d’accès est spécifiée sous la forme « Autoriser dans où ».
Notre API Internet utilise Oracle Identity Service. Oracle Identity Service constitue un moyen pratique d’authentifier les utilisateurs et d’autoriser l’accès à ces API à partir d’un navigateur (nom d’utilisateur/mot de passe) et de code (clé API).
Voir la documentation ici.
OCI Streaming est sécurisé par défaut, les données utilisateur sont chiffrées pendant leur transfert ainsi qu’au repos. Seuls les propriétaires de comptes et de flux de données ont accès aux ressources de flux qu’ils créent. OCI Streaming prend en charge l’authentification des utilisateurs pour contrôler l’accès aux données. Vous pouvez utiliser les stratégies IAM d’Oracle Cloud Infrastructure pour accorder des autorisations de manière sélective à des utilisateurs et à des groupes d’utilisateurs. Vous pouvez placer et récupérer vos données d’OCI Streaming en toute sécurité via des points de terminaison SSL à l’aide du protocole HTTPS.
Vous possédez les données que vous émettez, vous pouvez les chiffrer avant de les envoyer à OSS.
Ingestion (votre producteur - passerelle de diffusion en continu) : données chiffrées en mouvement grâce à SSL (HTTPS).
À l’intérieur du service de diffusion en continu : Sur la passerelle, SSL se termine, les données sont chiffrées à l’arrivée avec la clé AES-128 par flux, puis envoyées à la couche de stockage pour être conservées.
Pendant l’utilisation : Les données cryptées sont lues à partir d’OSS, déchiffrées par le nœud de passerelle et envoyées à l’utilisateur via SSL.
Pendant l’utilisation : Les données cryptées sont lues à partir d’OCI Streaming, déchiffrées par le nœud de passerelle et envoyées à l’utilisateur via SSL.
OCI Streaming utilise l’algorithme AES-GCM 128 pour le chiffrement.
Le streaming est entièrement intégré aux Services de surveillance OCI. La description des indicateurs clés de Streaming est disponible ici.
La surveillance du service Streaming se concentre sur les producteurs et les consommateurs. Pour obtenir la liste des indicateurs clés émis par le service Streaming, consultez la documentation.
Chaque indicateur clé disponible dans la Console fournit les statistiques suivantes :
Ces statistiques offrent quatre intervalles de temps
Pour les producteurs, envisagez de définir des alarmes sur les indicateurs clés suivants :
Pour les consommateurs, envisagez de définir les mêmes alarmes en fonction des indicateurs clés suivant :
Lorsqu'une alarme est déclenchée, le membre de l'équipe responsable doit enquêter sur l'alarme et évaluer la situation.
Si le problème est lié au client (producteur ou consommateur), le membre de l'équipe doit le résoudre ou approfondir l'enquête avec l'équipe de développement.
Si le problème est lié au serveur, le membre de l'équipe doit contacter le support du service Streaming.
Un flux sain est un flux actif : les messages sont reçus et consommés avec succès.
Les écritures vers le service sont durables. Si vous pouvez produire sur votre flux et si vous obtenez une réponse réussie, le flux est sain.
Une fois les données ingérées, elles sont accessibles aux consommateurs pendant la période de rétention configurée.
Si les appels de l'API GetMessages renvoient des niveaux élevés d'erreurs internes du serveur, le service n'est pas sain.
Un flux sain a également des indicateurs clés sains :
Les détails sur les erreurs API se trouvent dans la documentation.
Le service Streaming prend en charge les défaillances partielles dues à la limitation, par partition. En cas de défaillance partielle, le service renvoie un code d'état 200 et indique les défaillances dans la charge utile de réponse.
Si une demande entière est limitée, vous obtenez un code d'état 429.
Veuillez contacter le service Oracle Streaming pour augmenter la limite de votre location.
OCI Streaming utilise une tarification à l’utilisation simple. Aucuns frais à avancer ni montant minimum, vous ne payez que les ressources que vous utilisez.
Veuillez vous référer au guide des tarifs pour connaître les tarifs réels d'OCI Streaming.
Imaginons un scénario dans lequel un producteur de données place 500 enregistrements par seconde au total, chaque enregistrement faisant 2 Ko. Le client souhaite extraire/récupérer des données à un rythme deux fois supérieur à celui de l'entrée. Le client souhaite également stocker ces données pendant 7 jours.
Calcul du prix/jour (à titre d'exemple)
Chaque taille d'enregistrement = 4 Ko (arrondi à 4 Ko pour tout enregistrement inférieur à 4 Ko)
Facultatif :
OCI Streaming ne possède pas de niveau gratuit.