Erfahrungen mit MicroStream ?

[Ernesto95]

Moin !

Jemand hier schon Erfahrungen mit MicroStream zum speichern von Daten gemacht ?

Home

EclipseStore is a breakthrough Java-native persistence layer built for cloud-native microservices and serverless systems. EclipseStore is also great for big monoliths and runs on Android mobile, edge, and embedded devices.

microstream.one

Auf den ersten Blick deutlich einfacher zu handeln als die hauseigene Java Serialisierung, herkömmliche SQL-Datenbanken oder Persistenz-Frameworks wie Hibernate.
Den einzigen Nachteil den ich auf Anhieb sehe ist das es nur in einer SingleUser-Umgebung funktioniert.

Habe es aber bis dato nur ein bisschen getestet, aber noch nie produktiv eingesetzt. Daher wollte ich mal hier nach ebentuellen Erfahrungswerten fragen.

Grüße

 

[Oneixee5]

Ich habe es mal kurz überflogen. Es werden keine Daten in einem RDBMS gespeichert. Dahinter ist eine Graphen DB auf Basis von Java, designt für MicroServices und Serveless. Das ist ein ganz anderes Einsatzgebiet und lässt sich nicht mit einer SQL-DB vergleichen. Ich schätze eine Projektleitung wird nicht unbedingt begeistert sein, die Daten einer Anwendung so abzulegen. Da diese dann in einem System ohne Zugang für herkömmliche RDBMS liegen. Das erschwert die Weiterwendung und Administration. Es gibt aber bestimmt Einsatzgebiete, für die diese Art der Ablage gut geeignet ist. Ich könnte mir das z.B.: für Metadaten vorstellen.

 

[yfons123]

wenn du schwere SQL Abfragen hast kannst du diese als Stored Procedure in deiner Datenbank ablegen .. dann kann der DB Admin diese optimieren, der DB admin kann dann optimieren wie er will hauptsache es kommt immer das erwartete zurück

möchte mal wissen wie da dann der vergleich ist wenn du in jpa mit stored procedures arbeitest und nicht mit hingeknallten strings

Calling Stored Procedures from Spring Data JPA Repositories | Baeldung

Learn how to call stored procedures from Spring Data JPA Repositories

www.baeldung.com

du hast halt dann den vorteil dass du einen SQL Admin hast der dir das optimiert und du musst dich nicht darum kümmern


und eine graph db ist ja wieder was ganz anderes als sql db

 

[Oneixee5]

wenn du schwere SQL Abfragen hast kannst du diese als Stored Procedure in deiner Datenbank ablegen .. dann kann der DB Admin diese optimieren, der DB admin kann dann optimieren wie er will hauptsache es kommt immer das erwartete zurück

möchte mal wissen wie da dann der vergleich ist wenn du in jpa mit stored procedures arbeitest und nicht mit hingeknallten strings

Calling Stored Procedures from Spring Data JPA Repositories | Baeldung

Learn how to call stored procedures from Spring Data JPA Repositories

www.baeldung.com

du hast halt dann den vorteil dass du einen SQL Admin hast der dir das optimiert und du musst dich nicht darum kümmern


und eine graph db ist ja wieder was ganz anderes als sql db

Ich würde mich schämen wenn ein Admin meine Abfragen optimieren müsste. 😂 Dafür gibt es Logging, Zeitmessung, Ausführungspläne und Indizes, https://use-the-index-luke.com/

Aber es geht ja hier gerade darum SQL, JPA, Cache, weiteren Aufwand usw. zu vermeiden und direkt mit Java-Mitteln auf die Daten zuzugreifen ohne optimieren zu müssen. Das ist ein guter Ansatz. Das Problem welches ich sehe, aus Sicht der Entscheidungsträger, dass die Daten in einem Java-System "gefangen" sind, welches nur wenigen Spezialisten zugänglich ist. Es ist leider eine weit verbreitet Unsitte, dass Fachabteilungen Daten direkt mit SQL oder Excel aus DB's abgreifen wollen.

 

[yfons123]

Ich würde mich schämen wenn ein Admin meine Abfragen optimieren müsste. 😂 Dafür gibt es Logging, Zeitmessung, Ausführungspläne und Indizes, https://use-the-index-luke.com/

du gehst von einem Hohen Standard aus... warst noch nicht in einem "Historisch gewachsenen Umfeld"... wenn da was entwickelt wird am vor tag ist das schon als "Historisch" anzusehen

Da muss man gezielt dem Fachbereich rechte für selects entziehen... die hauen da schon mal knaller raus

 

[Ernesto95]

Danke für eure Kommentare.

Ja, bei größeren (verteilten) Projekten sehe ich da durchaus Probleme. Wie z.B. dem nicht möglichen parralelen Zugriff in einer Mehrbenutzer Umgebung oder die von Oneixee5 genannte Tatsache das die Daten in JAVA "gefangen sind".

Ich sehe hier den Anwendungszweck eher in isolierten 1-User Umgebungen, wo ein externer Zugriff auf die Daten nicht vorgesehen ist. Und das sowohl im Anwendungs- als auch im Gaming Bereich. Warum soll man sich da die Mühe machen die ganzen Daten aus der objektorientierten Umgebung in eine relationelle Datenbank zu mappen, wenn man doch ganz einfach mit wenigen Zeilen Code den kompletten Objektgraph speichern kann ? Und dies im Fall der Verwendung von Microstream ohne die Abhängigkeiten von der Java internen Serialisierung wo jede zu speichernde Klasse das Interface Serializable implementieren muss.

 

[yfons123]

warum sollte es schwer sein in eine db sachen rein zu kriegen?

wenn ich eine einzel user db will kann ich auch einfach eine sqlite db hernehmen

 

[Ernesto95]

warum sollte es schwer sein in eine db sachen rein zu kriegen?

wenn ich eine einzel user db will kann ich auch einfach eine sqlite db hernehmen

Nun, schwer ist es nicht, aber der Zeitaufwand für das ORM steigt parralel zur Größe der zu mappenden Objekte.

Dagegen ist die eine Zeile Code bei Microstream zum speichern eines beliebig großen Objekts doch ein sehr überschaubarer Aufwand.

storageManager.store(root.myObjects);

 

[yfons123]

ORM ist nicht das Allheilmittel

Du kannst auch in die sqlite db stored Procedures nutzen um in java aif 1e Zeile zu kommen

ausserdem ist java eine der miserabelsten Sprachen für extrem kurzen Code.. nach dieser Beurteilung wäre python oder powershell das beste aber das ist ja auch nicht der fall

 

[KonradN]

Nun, schwer ist es nicht, aber der Zeitaufwand für das ORM steigt parralel zur Größe der zu mappenden Objekte.

Was ist denn da genau für ein großer Aufwand? Man muss ggf. Kenntnisse haben und diese muss man erst einmal aufbauen. Aber ansonsten ist es unproblematisch.

Man schreibt in den Entity Klassen in erster Linie paar Annotations und das war es dann schon.

Oder habe ich jetzt im Thread etwas verpasst?

ausserdem ist java eine der miserabelsten Sprachen für extrem kurzen Code.. nach dieser Beurteilung wäre python oder powershell das beste aber das ist ja auch nicht der fall

Also wenn es um eine Programmiersprache geht, dann würde mir NIE eine Scriptsprache wie Powershell in den Sinn kommen. Und Zielsetzung extrem kurzer Code ist in meinen Augen auch schon etwas seltsam. Das klingt direkt nach Optimierung an einer Stelle, die wenig Sinn macht.

Klar, man will kein Boilerplate Code - aber da gibt es nun auch viele Lösungen und Ideen in Java. Es mag dann paar Argumente geben a.la. null Handling und so (das hört man vor allem von Kotlin Freunden), aber die, die das so toll und wichtig halten, haben nach meiner Erfahrung nie mit den null Annotations gearbeitet, die dann Spotbugs prüfen würde. So toll und wichtig ist das dann also vor dem Wechsel nicht gewesen

 

[yfons123]

Also wenn es um eine Programmiersprache geht, dann würde mir NIE eine Scriptsprache wie Powershell in den Sinn kommen. Und Zielsetzung extrem kurzer Code ist in meinen Augen auch schon etwas seltsam. Das klingt direkt nach Optimierung an einer Stelle, die wenig Sinn macht.

es war ein beispiel dafür dass "die kürze des codes" nicht viel darüber aussagt ob etwas gut ist oder nicht

java war noch nie bekannt für seine "würze in der kürze" aber das muss ja auch nicht der fall sein

 

[Ernesto95]

Was ist denn da genau für ein großer Aufwand? Man muss ggf. Kenntnisse haben und diese muss man erst einmal aufbauen. Aber ansonsten ist es unproblematisch.

Man schreibt in den Entity Klassen in erster Linie paar Annotations und das war es dann schon.

Naja, je nachdem wie groß die Klassen sind können es auch schnell mal ein paar "viele" Annotations werden. Und gerade für jemanden der es nicht beruflich macht sondern sich wie ich in der Freizeit mit dem Programmieren beschäftigt (und demnach auch immer mal wieder ein paar Wochen Pause hat), ist das mit dem Wissensaufbau nicht immer so trivial. Da ist es durchaus von Vorteil wenn man sich auf eine Sache (Java) konzentrieren kann.

Habe hier noch einen interessanten und recht aktuellen Blog Beitrag zu dem Thema gefunden, für diejenigen die etwas mehr ins Detail gehen möchten.

Microstream – das Ende der O/R-Mapper?

Microstream ist ein Persistenz-Framework, das mit Objektgraphen arbeitet. Kann Microstream O/R-Mapper und andere Persistenz-Frameworks ablösen? Beispiel-Applikation und Hinweise zur Nutzung von Microstream.

blog.codecentric.de

Grüße

 

[LimDul]

Danke, ist ein interessanter Artikel. Ich glaube das es Anwendungszwecke gibt, wo das gegenüber jpa deutliche Vorteile gibt. Aber ein Ersatz ist es bei den Einschränkungen definitiv nicht. Aber durchaus ein interessantes Framework