Aucun résultat trouvé

Votre recherche n'a donné aucun résultat.

Nous vous suggérons d’essayer ce qui suit pour trouver ce que vous recherchez :

  • Vérifiez l’orthographe de votre recherche par mot clé.
  • Utilisez des synonymes pour le mot clé que vous avez saisi, par exemple, essayez « application » au lieu de « logiciel ».
  • Essayez l’une des recherches les plus utilisées ci-dessous.
  • Lancez une nouvelle recherche.
Questions fréquentes

Questions fréquemment posées

Tout ouvrir Tout fermer

    Questions générales

  • Qu’est-ce qu’Oracle Cloud Infrastructure Streaming (OCI Streaming) ?

    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 :

  • Où le service de streaming est-il disponible ?

    Pour obtenir la liste des régions qui exécutent actuellement le service de streaming, consultez la documentation.

  • Que sont les points de terminaison API ?

    Le point de terminaison API est construit comme suit : https://streaming.$_REGION.oci.oracleCloud.com

    Exemple pour la variable : :

    • us-phoenix-1
    • us-ashburn-1
  • Que gère OCI Streaming à ma place ?

    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.

  • Comment Oracle Cloud Infrastructure Streaming offre-t-il la résilience ?

    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.

  • Que puis-je faire avec OCI Streaming ?

    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 :

    • Messagerie : Utilisez la diffusion en continu pour découpler les composants de grands systèmes. La diffusion en continu fournit un modèle de communication basé sur l’extraction/la mise en mémoire tampon offrant une capacité suffisante pour aplanir les pics de charge et la possibilité de fournir à plusieurs utilisateurs les mêmes données de manière indépendante. Les commandes à clé délimité et la durabilité garantie offrent des primitives fiables pour la mise en œuvre de divers modèles de messagerie, tandis qu’un potentiel de débit élevé permet une bonne adaptation du système.
    • Ingestion d’indicateurs et de journaux : Utilisez la diffusion en continu comme alternative aux méthodes traditionnelles de nettoyage de fichiers pour rendre les données opérationnelles critiques disponibles plus rapidement pour l’indexation, l’analyse et la visualisation.
    • Ingestion de données d’activité web/mobile : Utilisez la diffusion en continu pour capturer l’activité provenant de sites web ou d’applications mobiles (telles que les pages vues, les recherches ou d’autres actions que les utilisateurs peuvent entreprendre). Ces informations peuvent être utilisées pour la surveillance et l’analyse en temps réel, ainsi que dans les systèmes de data warehouse pour le traitement hors connexion et le reporting.
    • Traitement des événements d’infrastructure et d’applications : Utilisez la diffusion en continu en tant que point d’entrée unifié pour les composants Cloud afin de signaler leurs événements de cycle de vie pour des activités d’audit, de comptabilité et des activités connexes.
  • Comment utiliser OCI Streaming ?

    Commencez à utiliser OCI Streaming en :

    • créant un nouveau flux via la console OCI Streaming ou via l’API CreateTopic ;
    • envoyant des données des producteurs au sujet (voir la documentation détaillée) ;
    • créant des consommateurs pour lire de traiter les données de votre flux.
  • Quelles sont les limites d'OCI Streaming ?

    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 :

    • Durée maximale de 7 jours pour la rétention.
    • La taille maximale d'un message unique est de 1 Mo.
    • Chaque partition peut gérer 5 appels d'API de lecture par seconde, jusqu'à 1 Mo par seconde avec un nombre illimité de demandes d'écriture.
    • Chaque partition peut prendre en charge un taux d'écriture de données total maximum de 1 Mo par seconde et un taux de lecture de 2 Mo par seconde
    • Chaque location a une limite de 5 partitions, mais vous pouvez demander plus de partitions - Nous contacter
  • Comment utiliser le streaming avec la CLI Oracle Cloud Infrastructure ?

    Un exemple est disponible sur GitHub, inclus avec les binaires oci-cli.

  • Comment accéder à ma partition ?

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

    Concepts clés

  • Qu’est-ce qu’un flux ?

    Un flux peut être visualisé sous la forme d’un fichier journal en annexation uniquement contenant vos messages.

  • Une partition ?

    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 ?

    Un message codé sur 64 bits correspond à ce que vous émettez dans un sujet.

  • Qu’est-ce qu’un décalage ?

    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.

  • Qu’est-ce qu’une clé ?

    Une clé est un identifiant utilisé pour regrouper les messages associés.

    Création d’un flux

  • Comment créer un nouveau flux ?

    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.

  • Combien de temps prend la mise en service ?

    La durée de mise en service dépend du nombre de partitions. La création d’une partition prend jusqu’à 10 secondes.

  • Comment puis-je décider du nombre de partitions dont j’ai besoin ?

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

  • Quel débit minimal puis-je demander pour un flux ?

    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.

  • Combien de demandes puis-je envoyer à une partition ?

    Vous pouvez envoyer 1 000 demandes par seconde à une partition.

  • Comment utiliser les SDK ?
  • Où puis-je trouver les SDK ?
  • Envisagez-vous de prendre en charge plus de langues ?

    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.

  • Où puis-je trouver la liste de toutes les API dont j'ai besoin pour le streaming ?

    Publication de données dans un flux

  • Comment puis-je émettre des données dans un flux ?

    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.

  • Comment OCI Streaming stocke-t-il les données si j’envoie une clé nulle ?

    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.

  • Comment puis-je assurer le classement des messages dans OCI Streaming ?

    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.

  • Comment puis-je m’assurer que mon message est durable ?

    Dès que l’API OCI Streaming reconnaît votre putMessage sans erreur, ce message est durable.

  • Comment assurez-vous la cohérence des données dans un flux OCI Streaming ?

    OCI Streaming bénéficie de lectures et écritures linéaires dans une clé de partitionnement.

  • Que se passe-t-il si j’émets plus de données que le maximum autorisé ?

    Lorsque les demandes des clients dépassent les limites, OCI Streaming refuse la demande et envoie un message d’erreur.

  • Quand suis-je limité ?

    Le mécanisme de limitation s'active lorsque les seuils suivants sont dépassés :

    • GetMessages : 5 appels par seconde ou 2 Mo/s par partition
    • PutMessages : 1 Mo/s par partition.
    • Opérations de gestion et de plan de contrôle (CreateCursor, listStream, etc.) : 5 appels par seconde par flux.
  • Dois-je regrouper mes messages ?

    Nous vous recommandons de grouper les messages pour les raisons suivantes :

    • Réduit le nombre de requêtes Put envoyées au service, ce qui évite la limitation
    • Permet un meilleur débit

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

  • Comment gérer les messages de plus de 1 Mo ?

    Vous pouvez utiliser l'une des approches suivantes : couper ou envoyer le message via Object Storage.

  • Couper

    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.

  • Object Storage

    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.

  • Quel format de date le service accepte-t-il ?

    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.

  • Comment puis-je obtenir le numéro de partition et le décalage du service Streaming lors de la publication d'un message ?

    La classe PutMessagesResultsEntry fournit les méthodes suivantes :

    • getPartition, qui fournit le numéro de partition sur lequel le message a été publié
    • getOffset, qui fournit le décalage du message publié
  • Comment puis-je obtenir le numéro de partition et le décalage du service Streaming sans publier un message ?

    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.

    Consommation de données à partir d'un flux - consommateur unique

  • Comment lire et utiliser les données d’un flux ?

    L’utilisation de messages nécessite de votre part :

    • La création d’un curseur
    • L’utilisation du curseur pour lire les messages
    • Reportez-vous à la documentation technique pour connaître la procédure d’utilisation de données d’un flux.

  • Quelles sont les différentes manières d’utiliser les données d’un flux OCI Streaming ?

    OCI Streaming propose deux types d’API de consommation :

    • Inspection de base pour contrôler avec précision les partitions et les décalages pour la lecture des données
    • Des groupes d’utilisateurs pour simplifier le développement d’applications en chargeant l’équilibrage de la charge, la coordination et le suivi des décalages dans le service
  • Comment fonctionnent les groupes d’utilisateurs ?

    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.

  • Comment éviter les doublons de messages à destination de mes utilisateurs ?

    Nous recommandons que les applications grand public prennent en charge les doublons.

  • Comment savoir si les utilisateurs parviennent à suivre ?

    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.

  • Qu'est-ce qu'un seul consommateur ?

    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.

  • Qu'est-ce que le curseur ?

    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.

  • Quels types de curseurs sont disponibles ?

    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.

  • Dois-je régénérer un curseur à chaque fois que je consomme un message ?

    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.

  • Un consommateur appartenant au locataire B peut-il consommer des messages provenant d'un flux appartenant au locataire A ?

    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.

  • Comment gérer les décalages ?

    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.

  • Combien de messages puis-je recevoir d'un appel getMessage ?

    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.

    Consommation de données à partir d'un flux - Groupes de consommateurs

  • Comment fonctionnent les groupes d’utilisateurs ?

    Pour obtenir une explication détaillée, consultez la documentation.

  • Pourquoi devrais-je utiliser des groupes de consommateurs ?

    Les groupes de consommateurs offrent les avantages suivants :

    • Chaque instance reçoit des messages d'une ou plusieurs partitions (qui lui sont « automatiquement » affectées), et les mêmes messages ne seront pas reçus par les autres instances (affectées à différentes partitions). De cette façon, nous pouvons augmenter le nombre d'instances (une seule instance lit une seule partition). Dans ce cas, une nouvelle instance rejoignant le groupe correspond au numéro de l'état d'inactivité partitionsan sans être affectée à une partition.
    • Le fait d'avoir des instances permet de fournir un cadre dans lequel les messages de différents groupes de consommateurs publient / souscrivent des partitions de modèle envoyées à toutes les instances des différents groupes. À l'intérieur du même groupe de consommateurs, les règles sont comme indiqué dans la première image suivante, mais dans les différents groupes, les instances reçoivent les mêmes messages (comme indiqué dans la deuxième image). Ceci est utile lorsque les messages à l'intérieur d'une partition présentent un intérêt pour différentes applications qui les traiteront de différentes manières. Nous voulons que toutes les applications intéressées reçoivent les mêmes messages de la partition.
    • La fonction de rééquilibrage est un autre avantage des groupes de consommateurs. Lorsqu'une instance rejoint un groupe, si suffisamment de partitions sont disponibles (c'est-à-dire que la limite d'une instance par partition n'a pas été atteinte), un rééquilibrage démarre. Les partitions sont réaffectées aux instances actuelles, plus la nouvelle. De la même manière, si une instance quitte un groupe, les partitions sont réaffectées aux instances restantes.
    • Les validations de décalage sont gérées automatiquement.
  • Qu'est-ce qu'une instance ?

    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.

  • Existe-t-il une bonne pratique pour nommer mes instances ?

    La bonne pratique consiste à utiliser une chaîne concaténée d'informations utiles.

  • Quels délais d'expiration dois-je connaître ?

    Les composants suivants du service Streaming ont des délais d'expiration :

    • Curseur : Tant que vous continuez à consommer des messages, il n'est pas nécessaire de créer un nouveau curseur. Si la consommation des messages est arrêtée pendant plus de 5 minutes, le curseur doit être recréé.
    • Instance : Si une instance cesse de consommer des messages pendant plus de 30 secondes, elle est supprimée du groupe de consommateurs et sa partition est réaffectée à une autre instance (le rééquilibrage est déclenché).
  • Combien de temps une instance a-t-elle besoin d'utiliser les pulsations avant de s'arrêter ?

    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.

  • Que se passe-t-il lorsqu'une instance arrive à expiration ?

    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.

  • Qu'est-ce que le rééquilibrage au sein d'un groupe de consommateurs ?

    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.

  • Comment générer une clé de partition efficace ?

    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.

    • Cardinalité : Tenez compte du nombre total de clés uniques susceptibles d'être générées en fonction du cas d'utilisation spécifique. Une cardinalité de clé plus élevée est généralement synonyme de meilleure distribution.
    • Sélectivité : Considérez le nombre de messages avec chaque clé. Une sélectivité plus élevée signifie plus de messages par clé, ce qui peut conduire à des points d'accès.

    Essayez d'obtenir une cardinalité élevée avec une faible sélectivité.

  • À quelle partition mes messages iront-ils ?

    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.

  • Puis-je forcer les messages à aller vers une partition spécifique ?

    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.

  • Puis-je partager une instance StreamClient entre des threads ?

    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.

  • Combien de messages se trouvent dans la partition actuelle ?

    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.

  • Comment savoir si je prends du retard dans la consommation de messages ?

    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 :

    • Augmentez le nombre de partitions sur le flux.
    • Si le problème est causé par un point d'accès, modifiez la stratégie de clé de message.
    • Réduisez le temps de traitement des messages ou gérez les demandes en parallèle.

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

  • Quel est le comportement attendu si le consommateur A possède un curseur pour la partition 1, mais que la partition est réaffectée à un nouveau consommateur avant l'expiration du délai de 30 secondes ?

    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.

  • Que se passe-t-il lorsqu'une instance du groupe de consommateurs devient inactive ?

    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.

  • Que se passe-t-il lorsqu'une instance du groupe de consommateurs qui était auparavant inactive rejoint le groupe ?

    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.

  • Lorsqu'une instance précédemment inactive du groupe de consommateurs rejoint le groupe, consomme-t-elle des messages en double ?

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

  • Comment dois-je gérer les validations de décalage ?

    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.

  • Comment fonctionne CommitOnGet ?

    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 :

    • A appelle getMessages et reçoit des messages d'une partition arbitraire, avec des décalages de 1 à 100.
    • A traite les 100 messages avec succès
    • Aappelle getMessages, le service Streaming valide le décalage de 100 et renvoie les messages avec les décalages 101–200.
    • A traite 15 messages, puis se déconnecte de manière inattendue (pendant plus de 30 secondes).

    Le système d'orchestration démarre un nouveau consommateur B :

    • B appelle getMessages, le service Streaming utilise le dernier décalage validé et renvoie des messages avec des décalages 101-200.
    • B continue la boucle de message.

    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.

  • Comment mettre à jour les décalages qui ont dépassé la période de rétention pour une seule partition dans un flux à plusieurs partitions ?

    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.

  • Pourquoi dois-je envoyer des pulsations ?

    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.

  • Quel est le comportement attendu si j'envoie des pulsations avec une chaîne de curseur déjà validée ?

    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.

  • Comment récupérer après une défaillance du consommateur ?

    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.

    Gestion d’un flux OCI Streaming

  • Puis-je modifier le nombre de partitions plus tard ?

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

  • Puis-je changer la durabilité de mon sujet ?

    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.

  • Comment surveiller les opérations et les performances de mon flux OCI Streaming ?

    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.

    Sécurité et chiffrement

  • Comment gérer et contrôler l’accès à mon 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ù ».

  • Comment s’authentifier lors de l’émission ou de l’utilisation de données provenant d’OCI Streaming ?

    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.

  • Lorsque j’utilise OCI Streaming, mes données sont-elles sécurisées ?

    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.

  • Puis-je chiffrer mes données ?

    Vous possédez les données que vous émettez, vous pouvez les chiffrer avant de les envoyer à OSS.

  • Pouvez-vous me guider tout au long du cycle de vie du chiffrement de mes données à partir du moment où je les envoie vers un flux OCI Streaming jusqu’à leur récupération ?

    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.

  • Quel algorithme de chiffrement est utilisé pour le chiffrement OCI Streaming ?

    OCI Streaming utilise l’algorithme AES-GCM 128 pour le chiffrement.

    Surveillance

  • Où puis-je surveiller mon flux ?

    Le streaming est entièrement intégré aux Services de surveillance OCI. La description des indicateurs clés de Streaming est disponible ici.

  • Quel indicateurs clés le service Streaming émet-il ?

    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.

  • Quelles statistiques sont disponibles dans la surveillance du service Streaming ?

    Chaque indicateur clé disponible dans la Console fournit les statistiques suivantes :

    • Taux, Somme et Moyenne
    • Min, Max et Nombre
    • P50, P90, P95, P99 et P99.9

    Ces statistiques offrent quatre intervalles de temps

    • Auto
    • 1 minute
    • 5 minutes
    • 1 heure
  • Pour quel indicateurs clés dois-je définir des alarmes ?

    Pour les producteurs, envisagez de définir des alarmes sur les indicateurs clés suivants :

    • Put Messages Latency:network issues.
    • Put Messages Total Throughput:
      • Une augmentation importante du débit total pourrait indiquer que la limite de 1 Mo/s par partition sera atteinte et que cet événement déclenchera le mécanisme de limitation.
      • Une diminution importante pourrait signifier que le producteur client a un problème ou est sur le point de s'arrêter.
    • Put Messages Throttle Records: Il est important d'être averti lorsque les messages sont limités.
    • Put Messages Failure: Il est important d'être averti si les messages Put commencent à échouer afin que l'équipe Ops puisse commencer à enquêter sur les raisons.

    Pour les consommateurs, envisagez de définir les mêmes alarmes en fonction des indicateurs clés suivant :

    • Get Messages Latency
    • Get Messages Total Throughpu
    • Get Messages Throttled Requests
    • Get Messages Failure
  • Que dois-je faire lorsque je reçois une alarme ?

    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.

  • Comment puis-je savoir si mon flux est sain ?

    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 :

    • Put Messages Latency est faible.
    • Put Messages Total Throughput est proche de 1 Mo/s par partition.
    • Put Messages Throttled Records est proche de 0.
    • Put Messages Failure est proche de 0.
    • Get Messages Latency est faible.
    • Get Messages Total Throughput est proche de 2 Mo/s par partition.
    • Get Messages Throttled Requests est proche de 0.
    • Get Messages Failure est proche de 0.

    Types d'erreur et significations

  • Où puis-je trouver la liste des erreurs API ?

    Les détails sur les erreurs API se trouvent dans la documentation.

  • Qu'est-ce qu'une défaillance partielle ?

    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.

  • Pourquoi est-ce que j'obtiens l'erreur « Vous dépassez le nombre de partitions autorisées » ?

    Veuillez contacter le service Oracle Streaming pour augmenter la limite de votre location.

    Tarification et facturation

  • Quel est le prix d'OCI Streaming ?

    OCI Streaming utilise une tarification à l’utilisation simple. Aucuns frais à avancer ni montant minimum, vous ne payez que les ressources que vous utilisez.

    • Prix des demandes GET/PUT (Gigaoctets de données transférées)

    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)

    • Dans ce scénario, la quantité totale de données produites par jour = 500 * 4 * 24 * 60 * 60 ko = 172,8 Go
    • Quantité totale de données récupérées = deux fois celle du produit = 2*172,8 Go = 345,6 Go
    • Prix demande PUT/jour = $172.8 * $xx= $A
    • Prix demande GET/jour = $345.6 * $xx = $B
    • Coût de stockage des données = $172,8*24*7*$yy = $C
    • Facture totale/jour = $(A + B + C)

    Facultatif :

    • la conservation prolongée des données présente un coût facultatif, calculé en fonction du nombre de jours de conservation supplémentaires au-delà de la période par défaut de 24 heures (gigaoctets de stockage par heure).
  • Existe-t-il un niveau d’OCI Streaming gratuit ?

    OCI Streaming ne possède pas de niveau gratuit.