MicroStream est une librairie JavaLangage de développement très populaire ! permettant de créer et utiliser des bases de données dites "in-memory".
Le principe est simple, la base de données est chargée dans la mémoire vive de l'application au chargement, ce qui permet d'avoir une vitesse de récupération de données décuplée.
Grâce à ce principe, on peut développer des applications ultra rapides, peu gourmandes en CPU et donc en coût.
En Java, tout est objet. A contrario, les base de données ont chacune leur propre structure de données, qui sont incompatibles avec les objets Java.
Par conséquence, une traduction est nécessaire (mapping), ce qui signifie que toutes les données doivent être converties à un moment.
Le processus de conversion amène une énorme perte de performances : environ 90% du temps total d'une requête est dédié à la conversion.
En plus du temps perdu, cela représente également une consommation de CPU, et donc des coûts d'infrastructure.
MicroStream a été pensé dans le but d'enlever cette conversion, et d'avoir le même modèle de données stocké, et manipulé.
L'idée est de sauvegarder directement les objets Java dans la source de données, et de récupérer ces objets lors du lancement de l'application, afin de pouvoir les manipuler.
S'il y a insertion ou mise à jour des données, les données en mémoire sont automatiquement synchronisées avec la source.
Enfin, la source peut être différents types de stockages, que ce soit une base de données SQLLangage permettant de communiquer avec une base de données., NoSQL, ou un système de fichier classique.
En fonction de son utilisation, on peut le voir comme plus gros avantage, ou le pire inconvénient !
En effet, avec MicroStream, il existe un objet dit root, qui est l'objet qui sera persisté. De la structure de cet objet découle donc tout votre modèle de données.
Cela demande donc une rigueur toute particulière, mais apporte une plus grande souplesse. Vous pourrez à n'importe quel moment ajouter ou supprimer un champ dans vos objets, sans avoir à passer de requête.
Du fait de sa récupération directe en mémoire, les opérations de lectures sur vos données sont beaucoup plus rapides que sur une base de donnée classique.
MicroStream affiche une lecture jusqu'à 1000x plus rapide.
De plus, cela permet de travailler directement avec des objets Java, et donc de pouvoir utiliser les outils que nous met à disposition Java (stream, map, list...). Cela peut également permettre de manipuler ses données sans avoir forcément de connaissance en SQL.
De son côté, l'écriture asynchrone est l'un des gros points faibles de MicroStream. À l'heure où cet article est écrit, les données sont synchronisées avec le stockage à chaque mise à jour ou insertion.
De ce fait, on voit rapidement les limites si on veut avoir beaucoup d'écritures de façon asynchrone, l'application sera beaucoup plus lente qu'avec une BDD classique.
D'un autre côté, si vous avez besoin d'update beaucoup de données d'un seul coup, de manière synchrone, Microstream ne sera pas un problème et le gèrera très bien.
Alors qu'avec une base de données SQL classique, on peut facilement se connecter à une base pour y lire le contenu, ou même le modifier, Microstream ne permet pas ça.
Les données qui sont stockées sont complétement illisibles, et ne permettent donc pas d'être manipulées en dehors d'une utilisation avec Microstream. Cela peut rendre le debugging en production compliqué. ![[Pasted image 20221122170513.png]]
Microstream étant encore à ses débuts, peu de documentation existe, et la communauté n'est pas très active.
Cela peut devenir compliqué si vous avez des besoins précis, ou des problèmes spécifiques.
Mise à part sur le site officiel, très peu de littérature est disponible sur internet.
MicroStream n'est pas adapté à tous les types d'applications, mais s'il est utilisé dans le bon contexte avec une bonne utilisation, vos performances vont s'envoler et les coûts se réduire.
Toute application pouvant avoir plusieurs instances connectées à la même source de données ne pourra pas utiliser MicroStream.
En effet, la synchronisation ne se fait que vers la source, et pas depuis celle-ci. Ce qui fait que si une donnée est modifiée dans la source par une instance, ce changement ne sera pas répercuté sur toutes les autres.
Une APIUne API est un programme permettant à deux applications distinctes de communiquer entre elles et d’échanger des données. type RESTREST (REpresentational State Transfer) est un style d'architecture logicielle qui fonctionne sous un certain nombre de contraintes. pourrait poser des problèmes avec MicroStream. La possibilité de ne pas pouvoir gérer le nombre d'écritures faites sur les données de manière asynchrone peut ralentir significativement votre application, l'écriture étant le point faible de cette solution.
Cependant, une API composée uniquement de lecture, pourrait grandement profiter de l'utilisation de MicroStream, la lecture asynchrone ne posant aucun problème à ce dernier.
MicroStream peut être une solution qui pourra révolutionner vos accès données dans votre application, mais une forte phase d'études doit être menée avant de partir sur ce choix.
La solution possède beaucoup d'avantages mais autant d'inconvénients, ce qui fait qu'elle n'est pas pertinente dans tous les cas d'usage, et peut même devenir un vrai problème.
Vous avez un projet et vous vous posez des questions sur MicroStream ? Le mieux c'est d'en parler avec un expert ! Contactez-nous par ici !
Comment gérer le lazy loading des blob en HIBERNATE
Dans cet article, nous allons plonger dans le monde d'Hibernate 6, en commençant par reprendre les bases d’Hibernate et ses principaux concepts. Nous explorerons ensuite les nouveautés et les améliorations apportées par Hibernate 6.
Découvrez la planche #73 !