Mit Spring Boot wird das vermutlich weniger zu tun haben, sondern dein Problem vermute ich eher in deiner Vorgehensweise bei der Entwicklung. Du wirst ja kaum immer an allen Ecken gleichzeitig arbeiten. Wenn du eine UI entwickelst, dann ist es dieser z.B. egal, wo die Daten herkommen und den ganzen Rest der Anwendung brauchst du dann auch nicht. Wenn du also in kleinen Abständen "selbst immer mal gucken willst", wie das Ergebnis nun aussieht, dann betrachte also auch nur diesen kleinen Ausschnitt, an dem du gerade arbeitest. Für das große ganze gibt es dann Build-Server, automatisierte Tests usw. Da ist es dann auch egal, wenn so ein Build mal ne halbe Stunde dauert.
Auf der anderen Seite läuft vermutlich was schief, wenn gleich zu Beginn der Anwendung der gesamte Datenbestand ausgelesen werden muss. Was du da gebastelt hast, kann man aber nicht mal erraten, ohne einen Blick in deinen Anwendung geworfen zu haben.
Auf der anderen Seite läuft vermutlich was schief, wenn gleich zu Beginn der Anwendung der gesamte Datenbestand ausgelesen werden muss. Was du da gebastelt hast, kann man aber nicht mal erraten, ohne einen Blick in deinen Anwendung geworfen zu haben.
Ich denke, dass ist die Validierung von Entitys und Datenbank, das dürfte doch bei jedem Start passieren?
Allerdings klingt eine Anwendung, die 2000 Tabellen braucht nicht grad nach einer Anwendung, sondern nach ziemlich vielen, die einfach in ein Projekt gesteckt wurden...
Auf der anderen Seite läuft vermutlich was schief, wenn gleich zu Beginn der Anwendung der gesamte Datenbestand ausgelesen werden muss. Was du da gebastelt hast, kann man aber nicht mal erraten, ohne einen Blick in deinen Anwendung geworfen zu haben.
Ich hoffe, dass Spring-Boot etwas von Haus aus mitbringt. Die Persistenzschicht ist ja über die sogenannten "Repository-Interfaces" gekapselt...
Ich habe an so etwas gedacht wie Spring DEV-Tools, dem du dann sagen kannst schalte alle Prüfungen aus und starte dann die Anwendung schneller...
Ich versuche meine Frage noch einmal anders zu stellen:
Weiß jemand wie man die Startprozedur von Spring Boot mit Spring Data für die Entwicklung schneller machen kann?
Gibt es da irgendwelche Optionen an den man schrauben kann?
Speziell die beiden in 78.1 genannten Parameter solltest du, für so eine große Datenbank ersteinmal ausschalten und lieber mit einem inkrementellen Tool arbeiten, dass deine Datenbank mittels Änderungen erweitert. Da kann ich Liquitbase empfehlen, Änderungen an Tabellen werden als "Changelog" definiert und angewandt bei Start. Das lässt sich auch in Spring integrieren.
Wenn Spring erstmal für 2000 Tabellen Anfragen an die Datenbank schicken muss, um die zu überprüfen, das kann durchaus mal eine Weile dauern, zumindest würde ich das so erwarten.
Danke für die Hinweise.
Vielleicht stelle ich mich blöd an, aber die Zeit zum Hochfahren der Anwendung hat sich nicht geändert. Started ServletInitializer in 57.524 seconds (JVM running for 63.972)
Es dauert also ca. 60 Sekunden, bis die Anwendung gestartet ist.
Ich habe es mit folgenden Parametern in der application.properties ausprobiert. spring.jpa.properties.javax.persistence.validation.mode=none
spring.jpa.generate-ddl=false
Zu DatabaseInitialization:
Ich starte eine bestehende Datenbank. Das Datenbankschema ist also schon da...
Nur so eine Idee, die mir gerade in den Sinn kommt: Worauf startest du eigentlich die Anwendung? Linux? Windows?
Sie enthält ja sicher auch einen Tomcat/etc. Unter Linux muss (bzw. sollte man) man beim Start noch einen Parameter mitgeben:
Code:
-Djava.security.egd=file:/dev/./urandom
Das Problem ist, das eventuell nicht genug Entropy für die Initialisierung zur Verfügung steht, dann wartet man auf den Start der Anwendung (auch von kleinen Anwendungen) mitunter recht lang.
Spring an sich gehört auch nicht gerade zu den performantesten Frameworks...
Aber bei 2000 Tabellen hast du irgendwas falsch gemacht.
Entweder zu viel normalisiert oder du solltest deine Anwendung aufteilen.
z.B. wenn man es minimalitischer angeht mit Guice.
#edit: Vielleicht auch vert.x... Noch nie Probiert, aber wenigstens vom Anbieten der Daten her scheint es ja performant zu sein.
Dann muss man aber eben schauen, wie man die DB-Sache hinbekommt. Bei einer existierenden Struktur wie hier, würde ich wohl mal jOOQ ausprobieren. Steht auf meiner TODO-Liste, hatte bisher aber noch kein passendes Projekt.
z.B. wenn man es minimalitischer angeht mit Guice.
#edit: Vielleicht auch vert.x... Noch nie Probiert, aber wenigstens vom Anbieten der Daten her scheint es ja performant zu sein.
Dann muss man aber eben schauen, wie man die DB-Sache hinbekommt. Bei einer existierenden Struktur wie hier, würde ich wohl mal jOOQ ausprobieren. Steht auf meiner TODO-Liste, hatte bisher aber noch kein passendes Projekt.
Aber von denen ist ja auch keins wirklich vergleichbar mit dem Spring-Framework, da muss man ja schon alle 3 kombinieren, und das würde kaum an das ran kommen, was Spring Boot + Spring Data bietet...
Dann muss man aber eben schauen, wie man die DB-Sache hinbekommt. Bei einer existierenden Struktur wie hier, würde ich wohl mal jOOQ ausprobieren. Steht auf meiner TODO-Liste, hatte bisher aber noch kein passendes Projekt.
Kommt von der Einfachheit niemals an Spring Data ran (will es ja auch nicht). Als alternative sähe ich Apache DeltaSpike. Aber ich würde das Problem jetzt nicht auf die Spring Performance schieben.
Ich denke auch eher, dass es weniger an Spring liegt (trotz etwas langsamerer Startzeiten), sondern eher an Hibernate, wenn es das Model verifiziert (Modell-Klassen gegen DDL - auch wenn ich die Interna zu wenig kenne, was Hibernate da eigentlich macht).
Ich wollte ja nur Alternativen zeigen - auch wenn sie vielleicht etwas unzulänglich sein mögen. Wobei Vert.x sicher ein Ersatz für den Web-Teil sein könnte, aber mehr eben auch nicht.
Muss denn die Applikation alle Modelle beinhalten? Könnte man denn nicht mehr dem Mikroservice-Ansatz folgen und alles etwas nach "Themen" aufspalten?
Wenn man erstmal nur HTTP ausliefern will, ist Jersey oder Jetty oder Grizzly zu empfehlen.
Letzteres soll laut diesem Artikel sogar mit zu den schnellsten HTTP Server Libraries zählen.
An die Daten kommt man am schnellsten ohne Object Mapper, indem man direkte MySQL Queries schreibt und ausführt.
Dennoch würde ich eher Micro-Services verwenden, die nur das enthalten, was sie brauchen. Nicht alles. Und in dem Fall dieser DB würde vielleicht jOOQ sich anbieten - das kann die DB "scannen" und den Client generieren. Unter der Haube "native" Queries, kein ORM im Sinne vom Hibernate, sondern ein automatisches Konvertieren, das man sonst selbst und von Hand schreiben müsste.
Wenn man erstmal nur HTTP ausliefern will, ist Jersey oder Jetty oder Grizzly zu empfehlen.
Letzteres soll laut diesem Artikel sogar mit zu den schnellsten HTTP Server Libraries zählen.
An die Daten kommt man am schnellsten ohne Object Mapper, indem man direkte MySQL Queries schreibt und ausführt.
Spring Boot und andere Server sind i.d.R. kein Problem (jetty, undertow, …) - Grizzly kenn ich nicht.
Und auch jOOQ ist IMHO kein Problem. Also wahrscheinlich alles integrierbar.
