IBSurgeon annonce la sortie de la version 1.6.2 de la technologie de streaming dans HQbird

IBSurgeon annonce la version 1.6.2 de la technologie de streaming dans HQbird

La version portugaise est ci-dessous.

Le streaming (également connu sous le nom de capture de données de changement) est un moyen de capturer les modifications dans la base de données sans requêtes SELECT et d’envoyer les données vers des destinations externes. HQbird inclut des plugins prêts à l’emploi pour envoyer les modifications vers Kafka, RabbitMQ, MongoDB ou de simples fichiers JSON. Le système de plugins est extensible - vous pouvez développer des plugins personnalisés pour d’autres cibles.

Comment cela fonctionne-t-il ?

HQbird Streaming lit le journal de réplication Firebird pour capturer les modifications de la base de données. Le système traite les transactions validées et convertit chaque modification d’enregistrement en un message séparé. Après configuration du plugin de streaming, il capture :

INSERT - toutes les valeurs de colonnes du nouvel enregistrement
UPDATE - clé primaire, toutes les colonnes des versions ancienne et nouvelle de l’enregistrement (y compris les BLOBs jusqu’à 10 Mo)
DELETE - clé primaire et toutes les anciennes valeurs de colonnes (y compris les BLOBs jusqu’à 10 Mo - configurable)

Vous pouvez configurer le streaming pour capturer les modifications de tables sélectionnées ou de toutes les tables de la base de données.

Le système conditionne chaque modification dans le format souhaité (message Kafka, message RabbitMQ, document MongoDB ou fichier JSON) et le livre.

Caractéristiques techniques :

Latence : généralement 30 secondes (configurable de 5 à 60 secondes)
Débit : testé jusqu’à 10 000 modifications d’enregistrements par seconde
Tampon : basé sur disque, survit aux redémarrages de HQbird
Aucune modification de base de données requise (fonctionne avec les bases de données Firebird 4.0+ existantes)

Pourquoi est-ce utile ?

Le streaming offre un moyen efficace de capturer les modifications. Il existe deux cas d’utilisation principaux : les notifications pilotées par événements et la réplication de données vers des systèmes externes.

Recevoir des notifications

Exemple : Système de rendez-vous médicaux

Lorsque le système crée ou modifie un rendez-vous patient, il doit notifier le médecin avec une notification push, envoyer un SMS au patient et mettre à jour Google Calendar.

L’approche traditionnelle nécessite des requêtes SELECT périodiques de chaque service - expéditeur de SMS, intégration Google et application. Cela crée plusieurs problèmes :

Tous les services ont besoin de connexions SQL à la base de données
Les requêtes fréquentes créent une charge inutile sur la base de données (un anti-modèle connu de Firebird)
Effort de développement supplémentaire pour créer et maintenir les requêtes SQL
Couplage étroit entre les services et la base de données

Avec le streaming, chaque modification dans la table APPOINTMENTS génère un message envoyé à Kafka. Tous les microservices s’abonnent à ces messages et reçoivent les notifications automatiquement. Cette approche :

Nécessite une seule connexion à la base de données
Élimine les requêtes d’interrogation
Réduit la charge de la base de données
Découple les services de la base de données
Livre les notifications en moins d’une minute

Réplication des modifications vers des systèmes externes

Exemple : Systèmes de business intelligence cloud

Si vous utilisez des systèmes de BI cloud comme Snowflake ou BigQuery, les exportations complètes régulières de données créent un fardeau financier. Exécuter des requêtes SQL pour exporter de grandes quantités de données puis les traiter via des pipelines ETL nécessite une bande passante et une puissance de traitement élevées. Cette approche laisse également vos données analytiques obsolètes de plusieurs heures ou jours.

Avec le streaming, vous envoyez uniquement les modifications réelles au système externe. Au lieu d’exporter des millions d’enregistrements quotidiennement, vous diffusez uniquement les milliers d’enregistrements qui ont réellement changé. Cette approche :

Réduit le transfert de données de 99 % ou plus
Met à jour les systèmes externes avec très peu de délai (généralement moins d’une minute)
Réduit considérablement les coûts de traitement cloud
Minimise les exigences de bande passante
Élimine l’impact sur les performances de la base de données

Licence

Le streaming est inclus dans les licences HQbird (par serveur, abonnement illimité et support entreprise). La fonctionnalité est fournie sur demande aux clients sous licence.

Support d’implémentation

IBSurgeon offre un support d’implémentation gratuit pour les solutions de streaming aux détenteurs de licence HQbird et aux clients de support technique jusqu’au 31 décembre 2025. Cela comprend :

Revue d’architecture pour votre cas d’utilisation
Assistance à la configuration des plugins
Recommandations d’optimisation des performances pour le streaming
Support de dépannage

Contactez-nous

Contactez IBSurgeon pour activer le streaming dans votre installation HQbird

IBSurgeon annonce la version 1.6.2 de la technologie de streaming dans HQbird

Le streaming (également connu sous le nom de capture de données de changement ou CDC) est un moyen de capturer les modifications dans la base de données sans requêtes SELECT et d’envoyer les données vers des destinations externes.

HQbird inclut des plugins prêts à l’emploi pour envoyer les modifications vers Kafka, RabbitMQ, MongoDB ou de simples fichiers JSON. Le système de plugins est extensible - vous pouvez développer des plugins personnalisés pour d’autres cibles.

Comment cela fonctionne-t-il ?

HQbird Streaming lit le journal de transactions Firebird pour capturer les modifications de la base de données. Le système traite les transactions validées et convertit chaque modification d’enregistrement en un message séparé.

Après configuration du plugin de streaming, il capture :

INSERT - toutes les valeurs de colonnes du nouvel enregistrement
UPDATE - clé primaire, toutes les colonnes des versions ancienne et nouvelle de l’enregistrement (y compris les BLOBs jusqu’à 10 Mo - configurable)
DELETE - clé primaire et toutes les anciennes valeurs de colonnes (y compris les BLOBs jusqu’à 10 Mo)