Je vais vous montrer comment vous pouvez installer très rapidement sur votre ordinateur un cluster de nœuds InterSystems IRIS en sharding. Dans cet article, mon objectif n'est pas de parler du sharding en détail, ni de définir une architecture de déploiement pour un cas réel, mais de vous montrer comment vous pouvez rapidement installer sur votre machine un cluster d'instances d'IRIS en sharding avec lequel vous pouvez jouer et faire des tests. Si vous souhaitez en savoir plus sur le sharding dans IRIS, vous pouvez consulter la documentation en cliquant ici: clicking here.  

Disons dès le départ que la technologie de sharding d'IRIS va nous permettre de faire deux choses:

• Définir, charger et consulter des tables fragmentées ou des shards, dont les données seront réparties de manière transparente entre les nœuds du cluster
• Définir  des tables fédérées, qui offrent une vue globale et composite des données appartenant à des tables différentes et qui, physiquement, sont stockées sur différents nœuds distribués

Donc, comme je l'ai dit, nous laissons le sujet du jeu avec des shards ou des tableaux fédérés pour d'autres articles, et nous nous concentrons maintenant sur l'étape précédente, c'est-à-dire sur la mise en place du cluster de nœuds en sharding.

Dans un environnement conteneurisé, vous pouvez gérer l'heure de votre conteneur via la variable TZ ou via les répertoires /etc/timezone et /etc/localtime :

Le bon vieux temps

La classe %Library.DynamicObject existe dans IRIS depuis bien avant que IRIS ne devienne IRIS. Si vous l'utilisez depuis l'époque de Cache, vous souhaiterez peut-être vous familiariser avec certaines de ses modifications.

Dans Cache 2018, la méthode %Get n'avait qu'un seul argument. Il s'agissait de la clé permettant de récupérer les données dans le JSON. Ainsi, si votre objet JSON s'appelait myObj, cela ressemblerait à ceci:

Bonjour la communauté,

Nous avons quelque chose de passionnant pour vous : c'est l'heure du nouveau concours de vidéos de démonstration, et cette fois, c'est vous qui êtes juge !

📺 Demo Games pour les InterSystems Sales Engineers 📺

Pour ce concours, les Sales Engineers d'InterSystems du monde entier ont soumis de courtes vidéos de démonstration présentant des cas d'utilisation uniques, des solutions intelligentes et les puissantes fonctionnalités des technologies InterSystems.

À votre tour ! Nous ouvrons le vote à toute la communauté des développeurs. Votre expérience et votre point de vue de développeurs font de vous de parfaits experts.

Rubrique FAQ InterSystems

Les variables globales temporaires stockées dans les bases de données IRISTEMP/CACHETEMP sont utilisées lorsqu'un processus n'a pas besoin de stocker des données indéfiniment, mais requiert les performances élevées des variables globales. Les bases de données IRISTEMP/CACHETEMP ne sont pas journalisées ; leur utilisation ne crée donc pas de fichiers journaux.

Le système utilise les bases de données IRISTEMP/CACHETEMP pour le stockage temporaire et les utilisateurs peuvent y accéder à cette fin.

Chers membres de la Communauté,

Alors que l’année touche à sa fin, nous souhaitons vous adresser nos plus chaleureuses félicitations pour cette incroyable année de contributions, de partages et d’échanges.

Bonjour, chers collègues développeurs d'InterSystems IRIS !

On me demande souvent, notamment en ce qui concerne les bonus techniques que nous encourageons pour chaque concours Open Exchange, pourquoi nous donnons constamment des bonus pour les tests de qualité Docker, IPM et ObjectScript.

En fait, il est très facile de répondre à cette question.

Une qualité de service (QoS) est attribuée à tous les pods. Trois niveaux de priorité sont attribués aux pods d'un nœud. Ces niveaux sont les suivants :

1) Garanti : Priorité élevée

2) Évolutif : Priorité moyenne

3) Meilleur effort : Priorité faible

Il s'agit d'indiquer au kubelet quelles sont vos priorités sur un nœud donné si des ressources doivent être récupérées. Ce superbe GIF d'Anvesh Muppeda ci-dessous l'explique.

Si des ressources doivent être libérées, les pods avec une QoS « Meilleur effort » seront d'abord évincés, puis ceux avec une QoS « Évolutif », et enfin ceux avec une QoS garantie. L'idée est qu'en évinçant les pods de priorité inférieure, nous récupérerons suffisamment de ressources sur le nœud pour éviter d'avoir à évincer les pods avec une QoS garantie.

InterSystems recherche un Solution Architect pour accompagner sa croissance continue en Belgique, en se concentrant sur les engagements stratégiques dans le secteur public.

Présentation du poste :

En tant que Solution Architect, vous collaborerez avec les clients du secteur public afin de comprendre leurs besoins et de proposer des solutions techniques robustes et évolutives utilisant la technologie InterSystems. Vous jouerez un rôle clé dans la résolution des défis complexes liés à l'intégration, à l'analyse et à la conformité des données.

Lorsque nous créons un référentiel FHIR dans IRIS, nous avons un point de terminaison pour accéder à l'information, créer de nouvelles ressources, etc. Mais il y a certaines ressources dans FHIR que nous n'aurons probablement pas dans notre référentiel, par exemple, la ressource Binary (cette ressource renvoie des documents, comme des PDF par exemple).

Qui n'a jamais développé un bel exemple avec une image IRIS Docker et vu la génération de l'image échouer dans le Dockerfile parce que la licence sous laquelle l'image a été créée ne comportait pas certains privilèges ?

Dans mon cas, je déployais dans Docker une petite application utilisant le type de données Vector. Avec la version Community, ce n'est pas un problème, car elle inclut déjà la recherche et le stockage vectoriels. Cependant, lorsque j'ai remplacé l'image IRIS par une image IRIS classique (latest-cd), j'ai constaté que la compilation de l'image, y compris des classes générées, renvoyait l'erreur suivante :

Bonjour à tous,

L'équipe Certification d'InterSystems Learning Services développe actuellement deux nouveaux examens de certification HealthShare Unified Care Record. Nous sollicitons les commentaires de notre communauté afin de nous aider à évaluer et à définir leur contenu. Veuillez noter que ces examens remplaceront l'examen de spécialiste technique HealthShare Unified Care Record, que nous prévoyons de supprimer en janvier 2026. Les certifications obtenues dans cette technologie avant la suppression de l'examen resteront valables cinq ans à compter de la date d'obtention.