Graphe d'objets en mémoire pour remplacer la DB ?

[Jérémie Bresson]

Bonjour,

Je viens de regarder cette vidéo du VoxxedLu à propos de EclipseStore, version open-source du projet MicroStream:

https://www.youtube.com/watch?v=rCUgHVLwo4k

Je découvre cette idée de se passer de base de données (pas de DB relationnelle et pas de NoSQL).

Si je comprends bien: tout repose sur le fait de pouvoir sérialiser et déserialiser des graphs d'objets Java directement sur disque (ou dans un bucket de type S3).

Du coup les DB-queries sont remplacées par de la manipulation de Stream java.
Mais quand même dans les DB relationnelles, il y a des notions d'index, de foreign keys, de query… 

J'aurais bien aimé voir un peu de code pour comprendre comment ça marche. Mais la présentation est plus orientée "marketing"

J'aurais aussi bien aimé comprendre le cas d'usage. Le speaker est dithyrambique pour remplacer toute les db et services annexes associés (type pod ElasticSearch).

Il parle de lazy loading et du cas où les données ne tiennent plus en mémoire. Il évoque également les changements de classes avec la gestion de mapper pour aller vers les nouveaux types lorsque les objects sont désérialisés.
Mais j'ai du mal à comprendre si ça peut vraiment marcher dans la vraie vie (en prod).

Je me pose vraiment des questions autour de la viabilité/pérennité de cette approche…
En tout cas tout le projet est en train de devenir open-source https://eclipsestore.io/ avec une volonté de standardiser…

Bref, avez vous un avis?

[Remi Forax]

From: "'Jérémie Bresson' via lescastcodeurs" <lescast...@googlegroups.com>
To: "lescastcodeurs" <lescast...@googlegroups.com>
Sent: Thursday, July 13, 2023 3:22:07 PM
Subject: [LCC] Graphe d'objets en mémoire pour remplacer la DB ?

Bonjour,

Je viens de regarder cette vidéo du VoxxedLu à propos de EclipseStore, version open-source du projet MicroStream:

https://www.youtube.com/watch?v=rCUgHVLwo4k

Je découvre cette idée de se passer de base de données (pas de DB relationnelle et pas de NoSQL).

Si je comprends bien: tout repose sur le fait de pouvoir sérialiser et déserialiser des graphs d'objets Java directement sur disque (ou dans un bucket de type S3).

Du coup les DB-queries sont remplacées par de la manipulation de Stream java.
Mais quand même dans les DB relationnelles, il y a des notions d'index, de foreign keys, de query… 

J'aurais bien aimé voir un peu de code pour comprendre comment ça marche. Mais la présentation est plus orientée "marketing"

J'aurais aussi bien aimé comprendre le cas d'usage. Le speaker est dithyrambique pour remplacer toute les db et services annexes associés (type pod ElasticSearch).

C'est du Cloud Price Based Development, le prix d'une BDD "manager" dans le cloud est cher, et S3 c'est vraiment pas chère en comparaison, donc la question est comment developper une API simple qui utilise S3 comme une BDD.

Si ton appli utilises pas des micro-services ou si ton appli a besoin de "scaler" et tu trouves normal de payer pour ce service, tu correspond pas vraiment à la cible.

Il parle de lazy loading et du cas où les données ne tiennent plus en mémoire. Il évoque également les changements de classes avec la gestion de mapper pour aller vers les nouveaux types lorsque les objects sont désérialisés.
Mais j'ai du mal à comprendre si ça peut vraiment marcher dans la vraie vie (en prod).

Le format des données que tu as stocké à un moment correspond plus à ton code qui a évolué, donc il te faut une fonction qui sait passer de la version v1 à la v12 qui est ta version courante,

souvent c'est fait en indiquant une fonction qui va de v(n) à v(n +1) juste pour une donnée et à l'exécution tu composes les fonctions.

Je me pose vraiment des questions autour de la viabilité/pérennité de cette approche…
En tout cas tout le projet est en train de devenir open-source https://eclipsestore.io/ avec une volonté de standardiser…

C'est une M1, en langage Eclipse cela veut dire béta 1, donc c'est un peu tôt pour ce genre de questions.

Et la fondation Eclipse permet d'avoir des standards qui sont écrit que par une boite ...

Bref, avez vous un avis?

Rémi

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/45c93d89-7f11-44a4-aba1-3a469b5c1ad1n%40googlegroups.com.