Cet article décrit une amélioration significative apportée dans la version 2025.2 à la manière dont InterSystems IRIS traite les statistiques de table, un élément crucial pour le traitement SQL IRIS. Nous commencerons par un bref rappel sur ce que sont les statistiques de table, comment elles sont utilisées et pourquoi cette amélioration était nécessaire. Nous nous intéresserons ensuite en détail à la nouvelle infrastructure de collecte et d'enregistrement des statistiques de table, puis nous examinerons ce que ce changement signifie en pratique pour vos applications. Nous terminerons par quelques remarques supplémentaires sur les modèles rendus possibles par le nouveau modèle et nous attendons avec impatience les étapes suivantes de cette première livraison.

Je n'utilise pas SQL, pourquoi suis-je ici? – C'est une question existentielle pertinente  , mais cet article peut néanmoins contenir des informations précieuses pour vous. Certaines fonctionnalités avancées d'IRIS, notamment Interopérabilité, utilisent IRIS SQL en arrière-plan, et certains changements de comportement peuvent vous inciter à activer une nouvelle tâche de maintenance. Reportez-vous à la section "Collecte automatique des statistiques des tables" ci-dessous.

Statistiques de table 101

SQL signifie Structured Query Language (langage de requête structuré). SQL est un langage dans lequel vous exprimez ce que vous voulez (la requête), plutôt que comment vous le voulez (le code permettant d'obtenir le résultat de la requête). C'est au moteur de requête d'une base de données qu'il revient d'examiner toutes les options et de choisir le plan vraisemblablement optimal pour récupérer le résultat que vous demandez. Pour déterminer le meilleur plan, l'optimiseur de requêtes a essentiellement besoin de deux choses: des informations sur la structure de votre table, telles que l'emplacement de stockage de vos données et les index disponibles, et des informations sur les données de la table elle-même: les statistiques de table. Ces statistiques de table couvrent des informations telles que la taille estimée de la table et la sélectivité de chaque champ, qui exprime la proportion moyenne de la table correspondant à une valeur de champ particulière. Ces informations sont essentielles pour prendre les bonnes décisions concernant les plans de requête. Supposons que vous deviez trouver le nombre d'utilisateurs féminins dans un code postal particulier et que vous puissiez choisir entre partir d'un index sur le sexe ou sur le code postal. La sélectivité de l'index sur le sexe sera d'environ 50 %, tandis que celle sur le code postal pourra être aussi faible que 1 % ou moins, ce qui signifie que vous filtrerez beaucoup plus rapidement l'ensemble des lignes à rechercher en partant de ce dernier. 

Si la structure des tables fait naturellement partie de votre application et peut être intégrée au code de celle-ci, ce n'est pas nécessairement le cas des statistiques de table. Si l'exemple précédent est tiré d'une petite application librairie, il est probable que les valeurs de sélectivité des champs soient valables pour toutes les librairies dans lesquelles l'application est déployée, mais s'il s'agit d'un système de dossiers médicaux électroniques, la sélectivité du champ sexe sera différente entre une maternité et un cabinet médical généraliste, et le nombre de codes postaux (et donc leur sélectivité) dépendra de la taille de la zone couverte par l'hôpital. Il est évident que vous souhaitez que vos statistiques, et donc vos plans de requête, soient basés sur les données réelles de l'environnement dans lequel l'application est déployée.

Statistiques de table dans IRIS - avant 2025.2

Sur IRIS, les statistiques de table ont toujours été stockées dans la définition d'une classe. Cela présente plusieurs inconvénients

• Comme décrit précédemment, les distributions de données peuvent varier considérablement entre les environnements dans lesquels vous déployez votre application. Ceci n'est pas seulement vrai pour la taille estimée des tables et la sélectivité, mais encore plus pour d'autres types de statistiques plus avancées telles que les informations sur les valeurs aberrantes et les histogrammes.
• Lorsque vous déployez une version mise à jour de votre application, vous souhaitez généralement conserver toutes les statistiques existantes, en supposant qu'elles sont basées sur les données réelles de cet environnement. Cela s'avère plus délicat lorsqu'elles sont stockées en tant que partie intégrante du code, car vous ne souhaitez évidemment pas déployer accidentellement les statistiques de table de votre environnement de développement ou de test sur le système d'un utilisateur.
• Lorsque le code d'application est déployé sous la forme d'une base de données en lecture seule ou lorsqu'il fait partie d'une bibliothèque système IRIS (comme les messages d'interopérabilité), il n'existe aucun moyen efficace de mettre à jour les statistiques de ces tables.

Consultez également cet article précédent qui fournit davantage de détails à ce sujet. Voici certaines raisons qui nous ont poussés à repenser la gestion des statistiques de table dans IRIS. La nouvelle infrastructure est désormais incluse dans InterSystems IRIS 2025.2.

Quel est le changement?

Statistiques collectées vs statistiques fixes

Comme décrit dans les exemples précédents, le stockage des statistiques dans le code de l'application n'a de sens que dans des environnements très spécifiques et contrôlés. Dans la plupart des cas, il est préférable de conserver les statistiques avec les données à partir desquelles elles ont été collectées, plutôt que de les fixer dans le code. C'est donc ce que nous faisons dans le nouveau modèle. Nous faisons la distinction entre les statistiques collectées qui sont toujours basées sur des données réelles et stockées dans l'index d'extension (une variable globale contenant d'autres détails au format registre sur les données de votre table, également appelées extensions), et les statistiques fixes qui sont codées en dur dans la définition de classe par le développeur de l'application et peuvent être basées sur des données réelles ou sur des hypothèses raisonnables. Comme vous pouvez le deviner, les statistiques fixes correspondent au modèle antérieur à la version 2025.2 pour la gestion des statistiques de table. 

Utilisez la nouvelle commande COLLECT STATISTICS FOR TABLE t   (qui est 100 % synonyme de la commande existante TUNE TABLE , (qui est 100 % synonyme de la commande existante TUNE TABLE, et qui sert simplement à normaliser la terminologie) pour remplir un nouvel ensemble de statistiques basé sur les données actuelles de votre table. Les statistiques de table sont très petites, nous n'écrasons donc pas les statistiques précédentes, mais stockons plutôt un nouvel ensemble et conservons les anciennes statistiques à des fins d'information jusqu'à ce qu'elles répondent aux critères de purge par défaut ou soient explicitement purgées. Si vous souhaitez passer au modèle fixe, vous pouvez enregistrer les statistiques collectées dans la définition de classe à l'aide de ALTER TABLE t FIX STATISTICS. Cela peut faire partie de la procédure de package de votre application, si vous êtes certain que ces statistiques correspondent à votre environnement cible et que vous préférez le modèle statique.

Par défaut, les statistiques fixes prévalent sur les statistiques collectées. Cela garantit la rétrocompatibilité et signifie qu'en tant que développeur, c'est toujours vous qui avez le dernier mot. En fait, si vous avez des statistiques fixes, même pour un seul champ, les statistiques collectées seront ignorées et nous reviendrons à des estimations sûres basées sur le type de données du champ pour tous les champs qui n'ont pas de statistiques fixes. Si vous souhaitez tester les statistiques collectées sans supprimer vos statistiques fixes, vous pouvez inclure l'indication %NOFIXEDSTATS hint dans la clause FROM de votre texte de requête (par table) afin d'obtenir le plan de requête basé uniquement sur les statistiques collectées, ou utiliser ALTER TABLE t SET RUNTIME IGNOREFIXEDSTATS = TRUE pour définir ce comportement au niveau de la table. 

Collecte automatique des statistiques de table

L'introduction des statistiques collectées résout déjà bon nombre des inconvénients liés au packagage et au déploiement mentionnés dans l'introduction. Cependant, elle ne résout pas vraiment l'un des problèmes les plus courants rencontrés par les utilisateurs: le manque de statistiques à jour . Comme décrit dans l'introduction, des statistiques précises sont essentielles pour obtenir les meilleurs plans de requête pour votre distribution de données spécifique. Si vous ne vous êtes jamais soucié de les collecter, l'optimiseur utilisera des valeurs par défaut approximatives basées sur le type de données de vos champs, mais celles-ci sont peu susceptibles de tenir compte correctement des spécificités de votre application dans tous les cas. À partir de la version 2021.2, IRIS collectera automatiquement les statistiques pour les tables qui n'en ont pas et qui sont éligibles à une technique d'échantillonnage rapide au moment de la requête, mais cela ne se produira qu'une seule fois, et peut-être à un moment où votre table n'aura pas encore été remplie avec des données représentatives. Mais même lorsque les statistiques ont été collectées à un moment opportun, les distributions de données évoluent avec le temps (notamment les histogrammes) et nous constatons très souvent que les utilisateurs obtiennent des plans de requête sous-optimaux simplement parce qu'ils sont basés sur des statistiques obsolètes.

Avec la version 2025.2, nous introduisons une nouvelle tâche système qui s'exécute pendant une fenêtre de maintenance de nuit et qui, pour chaque espace de noms, prend en compte toutes les tables qui n'ont aucune statistique, pour lesquelles les statistiques les plus récentes ont été invalidées (par exemple après avoir modifié la définition de stockage de la table et recompilé) ou pour lesquelles au moins 25 % des données de la table ont changé depuis la dernière collecte de statistiques (environ, ceci est mesuré sur la base du ROWCOUNT combiné pour les opérations DML sur cette table). Les statistiques sont ensuite collectées pour ces tables une par une, ou jusqu'à ce que la durée maximale de la tâche de maintenance (configurable) soit atteinte. D'autres options de configuration permettent de choisir de prendre en compte les tables avec des statistiques fixes (ON par défaut), les tables mappées vers un stockage distant (OFF par défaut) et les tables qui ne sont pas éligibles pour une technique d'échantillonnage rapide (OFF par défaut). Si nécessaire, vous pouvez marquer des tables individuelles à l'aide d'un paramètre de classe SKIPAUTOMATICSTATSCOLLECTION  (ou d'un indicateur d'exécution équivalent) afin qu'elles soient ignorées par cette tâche système (notez que ce nouvel indicateur affecte également le comportement AutoTune préexistant).

Dans la version 2025.2, cette tâche système est désactivée par défaut, car nous souhaitons évaluer avec les utilisateurs l'impact de cette fonctionnalité sur les modèles d'E/S des systèmes réels. Nous encourageons les utilisateurs à activer la tâche système et à nous communiquer leur expérience en matière de charge système afin que nous puissions procéder aux ajustements nécessaires avant de l'activer par défaut dans une version ultérieure. À ce moment-là, nous prévoyons de supprimer le fonctionnement précédent d' AutoTune qui pouvait se déclencher pendant le traitement des requêtes.

La collecte manuelle des statistiques de table est bien sûr toujours prise en charge, et l'exécution de COLLECT STATISTICS après des chargements ou des purges de données importants reste une bonne pratique.

Qu'est-ce que cela signifie pour votre application?

Nous avons pris soin de concevoir le nouveau modèle afin que les applications SQL mises à niveau vers IRIS 2025.2 ne subissent aucun changement. Les statistiques préexistantes seront désormais traitées comme des statistiques fixes, qui auront priorité sur toutes les statistiques collectées automatiquement en arrière-plan. Nous conseillons aux utilisateurs qui passent au nouveau modèle de tenir compte des trois recommandations suivantes:

Suppression des statistiques fixes après la mise à niveau

Si votre application ou, en fait, n'importe quelle table avait des statistiques avant la mise à niveau (ce qui serait le cas pour toutes les tables si vous avez suivi les meilleures pratiques), envisagez de les supprimer purement et simplement. Après la mise à niveau, elles seront considérées comme des statistiques fixes et auront priorité sur toutes les statistiques que vous collecterez explicitement (peut-être via des scripts personnalisés appelant TUNE TABLE) ou implicitement. Les statistiques fixes des tables peuvent être supprimées à l'aide d'une nouvelle commande ALTER TABLE t DROP FIXED STATISTICS ou de la commande équivalente ALTER SCHEMA s DROP FIXED STATISTICS. Vous pouvez utiliser l'indication %NOFIXEDSTATS pour vérifier à l'avance l'impact sur les requêtes individuelles, selon vos préférences.

On ne conservera les statistiques fixes que si l'on estime que les statistiques prédéfinies doivent rester inchangées pour maintenir les plans de requête actuels et qu'aucune modification de la distribution des données n'est prévue.

Prise en compte des statistiques pour les classes système

Il convient de noter que le nouveau modèle de statistiques collectées s'applique aux tables dont la définition réside dans une base de données en lecture seule, y compris les tables système IRIS telles que  Ens.MessageHeader. Pour ces tables, les statistiques de table étaient auparavant peu pratiques, voire impossibles à maintenir, mais elles deviendront désormais pertinentes et, lorsque vous aurez activé la tâche du système de collecte, elles seront maintenues automatiquement. Lorsque vous utilisez des productions d'interopérabilité ou d'autres éléments de l'infrastructure IRIS pouvant impliquer SQL en arrière-plan, nous vous recommandons de surveiller les performances des opérations de recherche et autres opérations similaires après la mise à niveau, et de collecter les statistiques manuellement ou d'activer la tâche système. 

Lors de l'utilisation de la recherche de messages, nous avons constaté des améliorations significatives des performances des requêtes après l'adoption du nouveau modèle, car celui-ci pouvait désormais utiliser une sélectivité et d'autres statistiques beaucoup plus réalistes, alors qu'auparavant, il s'appuyait sur des valeurs par défaut approximatives. Nous avons donc supprimé les statistiques fixes fournies avec ces tables système.

Soyez vigilant lors de l'importation et de l'exportation entre différentes versions

Lorsque vous exportez des définitions de table avec l'indicateur /exportselectivity=1 (par défaut), les statistiques sont incluses dans un nouveau format qui prend en charge à la fois les statistiques fixes et les statistiques les plus récentes collectées collected mais qui est incompatible avec les versions antérieures. Pour prendre en charge l'importation dans des instances IRIS exécutant des versions antérieures, utilisez /exportversion=2025.1 ou /exportselectivity=0 selon le cas. Veuillez noter que les statistiques collectées et exportées à l'aide de ce format seront toujours importées en tant que statistiques collectées et ne deviendront pas fixes de manière silencieuse parce qu'elles ont été incluses dans le fichier de définition de classe export . Compte tenu de ces nuances, vous pouvez revoir votre stratégie de contrôle de source afin de vous assurer que les informations correctes sont suivies pour votre modèle de déploiement. Notez également l'indicateur symétrique /importselectivity qui peut être utilisé lors de l'importation de définitions de classe. 

Les méthodes Import() et Export() de la classe $SYSTEM.SQL.Stats.Table ont également été étendues avec un argument de type supplémentaire afin de différencier correctement les deux types de statistiques. Pour plus d'informations, consultez la référence de classe .

Travaux futurs

Cette version comprend toute l'infrastructure nécessaire pour tirer parti du nouveau modèle. Outre quelques améliorations mineures visant à faciliter l'utilisation, nous prévoyons les deux mises à jour suivantes dans une prochaine version (probablement 2025.3)

Activation de la tâche de collecte automatique

Comme indiqué précédemment, nous avons introduit une nouvelle tâche système pour la collecte automatique des statistiques des tables pendant une fenêtre de traitement par lots de nuit, mais nous l'avons désactivée afin d'éviter toute charge E/S inattendue après la mise à niveau. Dans une prochaine version, nous l'activerons par défaut, si elle n'est pas déjà activée par l'utilisateur à ce moment-là.

Taille d'échantillon plus intelligente

Nous avons remarqué que notre algorithme d'échantillonnage rapide par blocs pouvait dans certains cas surestimer la sélectivité des champs hautement sélectifs dans les grandes tables, ce qui signifie que l'optimiseur pouvait ne pas utiliser les index correspondants alors que cela aurait été optimal. Nous mettons en place un algorithme qui affinera de manière dynamique la taille de l'échantillon si nous détectons trop de variabilité entre les échantillonnages. Ce changement n'a pratiquement aucun impact sur la modification globale de l'infrastructure décrite plus haut dans cet article.

Partagez votre expérience

Cela fait longtemps que nous attendions avec impatience le déploiement de cette modification, et nous sommes ravis qu'elle soit désormais incluse dans IRIS 2025.2. Nous avons pris soin de tester cette modification dans de nombreuses configurations différentes et nous sommes convaincus que la nouvelle infrastructure est robuste, mais nous sommes conscients que les modifications peuvent affecter des pratiques de déploiement hautement personnalisées, notamment le mappage des espaces de noms et le packagage du code. Nous vous invitons donc à nous faire part de vos commentaires et espérons que la nouvelle infrastructure vous facilitera la vie.

Bonjour,

Nous lançons un programme d'accès anticipé pour une nouvelle fonctionnalité de partitionnement de table. Cette fonctionnalité aidera les clients IRIS à gérer des tables très volumineuses et à répartir les données de ligne et les index associés entre les bases de données et les niveaux de stockage. Le partitionnement de table est au cœur de la gestion des données relationnelles d'IRIS. Nous souhaitons donc nous assurer de la réussite de nos projets en collaborant avec quelques clients impliqués, capables de nous faire part de leurs commentaires sur les livrables initiaux et de les peaufiner si nécessaire.

Si vous travaillez avec de très grands ensembles de données relationnelles, recherchez une efficacité opérationnelle accrue et êtes prêt à tester cette nouvelle fonctionnalité, inscrivez-vous sur https://www.intersystems.com/early-access-program/. Vous recevrez un e-mail de bienvenue vous redirigeant vers le portail d'évaluation, où vous trouverez une licence de développement temporaire, des kits et des images de conteneurs récents contenant la nouvelle fonctionnalité, ainsi qu'un tutoriel pour vous aider à démarrer.

Nous sommes ravis de continuer à déployer de nouvelles fonctionnalités dans InterSystems IRIS Cloud SQLInterSystems IRIS Cloud SQL, telles que la nouvelle capacité de recherche vectorielle Vector Search qui a été lancée pour la première fois avec InterSystems IRIS 2024.1. Le service Cloud SQL est un service en nuage qui offre précisément ce qui suit: l'accès SQL dans le cloud. Cela signifie que vous utiliserez des technologies de pilote standard telles que JDBC, ODBC et DB-API pour vous connecter à ce service et accéder à vos données. La documentation décrit en détail comment configurer les paramètres importants au niveau du pilote, mais ne présente pas les outils tiers spécifiques car, comme vous pouvez l'imaginer, il en existe un nombre infini.

Dans cet article, nous allons compléter cette documentation de référence avec des étapes plus détaillées pour un outil de visualisation de données tiers populaire que plusieurs de nos clients utilisent pour accéder aux données basées sur IRIS : Microsoft Power BI.

Étape 0: Création de votre déploiement

Tout d'abord, connectez-vous au portail des services Cloud Services Portal et créez un déploiement Cloud SQL. Il vous ne faut qu'une chose: cochez la case permettant d'activer les connexions externes. À part cela, tous les paramètres par défaut devraient fonctionner correctement.

Étape 1: Téléchargement du certificat

Afin de se connecter en toute sécurité, nous utiliserons des certificats pour crypter tout ce qui est envoyé sur le réseau. Vous pouvez télécharger le certificat à partir de la page des détails du déploiement en cliquant sur le bouton "Get X.509 certificate" (Obtenir un certificat X.509):

Nous devrons nous référer à ce certificat plus tard, il faudra donc l'enregistrer dans un répertoire approprié. Par exemple, j'utilise C:\Users\bdeboe\odbc\.

Étape 2: Création du fichier SSLDefs.ini

Pour savoir quels certificats et paramètres de cryptage utiliser, le pilote ODBC d'InterSystems recherche un fichier SSLDefs.ini, que nous allons créer ensuite. Par défaut, il recherche ce fichier dans  C:\Program Files (x86)\Common Files\InterSystems\IRIS, mais vous pouvez modifier cet emplacement à l'aide de la variable d'environnement ISC_SSLconfigurationsISC_SSLconfigurations. Pour conserver tous mes paramètres de configuration ensemble, j'ai défini cette variable à C:\Users\bdeboe\odbc\, le répertoire où j'ai également sauvegardé mon certificat.

Le fichier SSLDefs.ini doit contenir deux éléments pour qu'ODBC sache comment se connecter : une configuration de serveur et une configuration SSL. La configuration du serveur déclare simplement le nom de la configuration SSL à utiliser pour une combinaison particulière de nom d'hôte et de port, et la configuration SSL contient tous les détails nécessaires à l'établissement de la connexion cryptée. Il est donc facile de réutiliser une seule configuration SSL pour plusieurs serveurs. Voici le contenu de mon fichier SSLDefs.ini:

[My CloudSQL Server]
Address=k8s-da0bcd5e-a1b3a0c7-545df92ec8-2e44304cebef1543.elb.us-east-1.amazonaws.com
Port=443
SSLConfig=SampleSSLConfig
[SampleSSLConfig]
CAFile=
CertFile=C:\Users\bdeboe\odbc\certificateSQLaaS.pem
KeyFile=
Password=
KeyType=2
Protocols=28
CipherList=ALL:!aNULL:!eNULL:!EXP:!SSLv2
VerifyPeer=0
VerifyDepth=9

La première section contient la configuration du serveur auquel vous pouvez donner un nom de votre choix. Vous devrez modifier l'adresse pour qu'elle corresponde au nom d'hôte de votre déploiement Cloud SQL, qui peut être obtenu à partir de la page des détails du déploiement où vous avez téléchargé le certificat.

La deuxième section contient la configuration SSL, dont le nom doit correspondre à ce que vous avez spécifié pour SSLConfig dans la section de configuration du serveur. La valeurCertFile doit évidemment correspondre à l'endroit où vous avez sauvegardé votre certificat.

Pour plus de détails sur les autres paramètres, veuillez vous référer à la documentation complète sur les paramètres TLS.

Étape 3: Création du DSN de type ODBC

Power BI, comme la plupart des outils basés sur ODBC, fonctionne avec un DSN (Data Source Name), que vous enregistrez à l'aide d'un utilitaire Windows. Il suffit de cliquer sur l'icône Start (Démarrer) de Windows et de taper "ODBC", puis de cliquer sur "ODBC Data Sources (64 bit)" (Sources de données ODBC (64 bit)). Choisissez l'onglet "System DSN" (DSN du système) pour enregistrer une connexion à notre déploiement Cloud SQL. Si vous avez des installations locales d'InterSystems IRIS (j'en ai une douzaine à tout moment 😉), vous verrez que le programme d'installation a créé des entrées DSN par défaut pour:

Cliquez sur "Add..." (Ajouter...) pour créer un nouveau DSN, en choisissant un nom et en renseignant l'hôte, le port et l'espace de noms. J'enregistre habituellement mon nom d'utilisateur et mon mot de passe dans le DSN pour toute instance non productive (et nous en aurons besoin pour tester la connexion dans quelques instants), mais vous pouvez laisser ces champs vides et fournir ces informations d'identification plus tard. Le champ Nom du serveur SSL/TLS est quelque peu superflu (nous y travaillerons!).

 Ensuite, cliquez sur "Test Connection" (Tester la connexion) pour vérifier que tout fonctionne comme prévu. Vous devriez obtenir un message "Connectivity test completed successfully!" (Test de connectivité terminé avec succès). Si ce n'est pas le cas, vérifiez les étapes ci-dessus ou reportez-vous au Guide de dépannage. Un message d'erreur particulier peut vous laisser perplexe (en tout cas, il m'a laissé perplexe !): "No SSL config found in the registry or in ssldefs.ini" (Aucune configuration SSL trouvée dans le registre ou dans ssldefs.ini). Cette erreur signifie que le pilote ODBC n'a pas trouvé de correspondance pour votre combinaison nom d'hôte/port dans le fichier SSLDefs.ini. Comme votre nom d'hôte change à chaque fois que vous créez un nouveau déploiement, vous devrez mettre à jour ou ajouter les configurations de serveur pour chacun d'entre eux.

Étape 4: Connexion à partir de Power BI

Il est maintenant temps d'utiliser notre DSN ODBC pour extraire des données dans Power BI. Après avoir ouvert l'application, sélectionnez la commande "Get Data" (Obtenir des données) ou "Get data from other sources" (Obtenir des données à partir d'autres sources), et choisissez l'option ODBC:

Ensuite, choisissez le DSN que vous venez de créer dans la liste:

Dans l'écran suivant, vous pouvez indiquer votre nom d'utilisateur et votre mot de passe. Aucune propriété des informations d'identification supplémentaire n'est requise.

 Et c'est tout! Vous pouvez maintenant sélectionner les tables que vous souhaitez inclure dans vos rapports Power BI:

Comme vous l'avez probablement remarqué, toutes les étapes de cet article, à l'exception de la dernière, sont universelles pour la configuration ODBC, ce qui devrait vous permettre d'utiliser la plupart des outils basés sur ODBC. J'espère que cet article vous a permis d'avancer, et n'hésitez pas à ajouter vos propres trucs et astuces, ou à partager vos expériences sur la connexion à Cloud SQL. Notez également qu'il n'y a pratiquement rien ici, à part l'étape 0, qui soit spécifique à Cloud SQL, donc vous pouvez utiliser les mêmes étapes pour vous connecter à n'importe quelle instance IRIS qui nécessite des connexions cryptées.

InterSystems a le plaisir d'annoncer la disponibilité générale d'InterSystems IRIS Cloud SQL et d'InterSystems IRIS Cloud IntegratedML, deux services fondamentaux pour le développement de solutions cloud natives optimisées par les performances et la fiabilité éprouvées de classe entreprise de la technologie InterSystems IRIS.

Nous avons récemment publié un nouveau livre blanc sur l'utilisation de nœuds de reporting (« membres miroir de reporting asynchrone ») dans un environnement miroir. De plus en plus de clients considèrent ce mécanisme comme un moyen simple et rapide de configurer une copie de leurs données de production qui reste à jour, tout en pouvant être utilisée pour des requêtes analytiques ou des charges de travail de reporting lourdes sans impact sur le système source. Lisez le livre blanc ici.

Comme toujours, nous sommes curieux de connaître vos propres commentaires sur la manière dont vous avez utilisé cette option de mise en miroir dans votre organisation et si vous avez des idées sur la façon dont nous pouvons la rendre encore plus productive.

InterSystems IRIS Cloud SQL est un service cloud entièrement géré qui apporte la puissance des capacités de base de données relationnelles d'InterSystems IRIS utilisées par des milliers d'entreprises clientes à un large public de développeurs d'applications et de professionnels des données. InterSystems IRIS Cloud IntegratedML est une option de cette base de données en tant que service qui offre un accès facile à de puissantes capacités d'apprentissage automatique automatisé sous une forme SQL native, via un ensemble de commandes SQL simples qui peuvent facilement être intégrées dans le code d'application pour augmenter avec des modèles ML qui s'exécutent près des données.

Aujourd'hui, nous annonçons le programme d'accès pour les développeurs pour ces deux offres. Les développeurs d'applications peuvent désormais s'inscrire eux-mêmes au service, créer des déploiements et commencer à créer des applications composables et des services de données intelligents, l'approvisionnement, la configuration et l'administration étant entièrement pris en charge par le service.

La semaine dernière, lors du Global Summit, nous avons annoncé notre nouvelle fonctionnalité Foreign Tables, qui a été introduite en tant que fonctionnalité expérimentale avec la version 2023.1 plus tôt cette année. Nous vous invitons maintenant à rejoindre le Programme d'accès anticipé pour les tables étrangères et à tester cette nouvelle fonctionnalité, afin que vous puissiez nous faire savoir si elle répond à vos besoins et quelles fonctionnalités nous devrions ensuite prioriser.