Microservices StrukturPlanung

Diskutiere Microservices StrukturPlanung im Application Tier Bereich.
S

Schuriko

Hab nochmal nachgeschaut sind inzwischen 57 Stunden. Er erweitert den Kurs ja in unregelmässigen Abständen.
 
mrBrown

mrBrown

Ja, JMS kommt vor, relativ weit hinten. (Mit "Building a Spring Boot Web-App" hat das allerdings nichts zu tun ;) )
 
S

Schuriko

Ja, JMS kommt vor, relativ weit hinten. (Mit "Building a Spring Boot Web-App" hat das allerdings nichts zu tun ;) )
Das Kapitel über JMS seperat ja, auf JMS geht er aber ab der Lektion 90 (von über 500) ein. Und wie ich in dem anderen Thread schon geschrieben habe ist der Titel: "Vom Anfänger zum Guru" leicht übertrieben. Aber für den ersten Einstieg bis Fortgeschrittenen ist der Kurs schon sehr gut.

Ansonsten geb ich dir Recht, Spring Boot hat mit JMS nichts zu tun, ich persönlich würde sogar soweit gehen, zu Behaupten es sind zwei unterschiedliche Paar Schuhe.

Er hatte aber geschrieben, er findet nichts zu Spring Boot.
 
Zuletzt bearbeitet:
NicoDeluxe

NicoDeluxe

Hab jetzt mal ActiveMQConnectionFactory.setUseAsyncSend(true) gesetzt aber das brauch mir immer noch zu lange 30 Messages pro Sekunde ca. Da muss doch mehr gehen o_O
 
NicoDeluxe

NicoDeluxe

Jetzt hab ich wie folgt gesendet:

Java:
 taskExecutor.execute(() -> {
   jmsTemplate.convertAndSend(JmsConfig.IMPORT_QUEUE, productImportDto);
});
Alle 40.000 Teile wurden in wenigen Sekunden (unter 5) an den Queue geschickt. Krass!
Aber irgendwie hat das nichts mit dem Pooling zu tun. In der Properties kann ich einstellen was ich will (oder auch eine Bean erstellen) ohne den TaskExector dümpelt es vor sich her.

Code:
spring.activemq.user=nico
spring.activemq.password=nico
spring.activemq.pool.enabled=true
spring.activemq.pool.max-connections=1000
spring.activemq.broker-url=tcp://localhost:61616
Hat noch jemand n Tipp wie der Pool korrekt genutzt wird?
 
NicoDeluxe

NicoDeluxe

Ums senden gehts mir grad.

Die folgenden Settings in der properties, bewirken dass 40k Teile in 6 min an den Broker geschickt werden. Das ist doch ein guter Schnitt find ich. Vorallem wenn ich bedenke, dass mehrere Services auf einem Server laufen. Wenn ich dann zig Threads sende hab ich Angst, dass der Server überlastet, der Server wo der Broker läuft muss das ja auch alles fressen können wenn da mehrere Services drauf ballern.

spring.jms.cache.enabled=true
spring.jms.cache.consumers=true
spring.activemq.broker-url=tcp://localhost:61616

Meinen Mac hab ich grad zum abstürzen gebracht mit 2000 Threads (TaskExecutor) :D
 
mrBrown

mrBrown

Auf Producer-Seite ist es unsinnig, das Senden in einen extra Task-Executor auszulagern, da kannst du einfach den aktuellen Thread für nutzen. (Außer, das Senden dauert wirklich extrem lange pro Nachricht, was aber eher nicht der Fall sein dürfte)
 
NicoDeluxe

NicoDeluxe

Hm kommt drauf an wie man schnell definiert, er hat so 30 pro Sek gemacht. Das ist gefühlt langsam. Mit dem og, caching gehts aber schneller (150 pro Sekunde), damit werd ich leben.

Beim Listener liegts auch so bei 100 pro sekunde wenn ich die message nur ausgebe. Das ist auch ok denk ich.

Aufm Server gehts dann bestimmt nochmal ein wenig flotter.
 
NicoDeluxe

NicoDeluxe

Nun überlege ich doch nochmal um, bezgl der Datenbank. MapDB ist nice, aber ich kann nicht einfach in die DB schauen was evtl kaputt ist etc.
Nun überlege ich doch auf eine DB zu gehen:

product_db
table_hersteller1
table_hersteller2
usw

Die Tabellen so simpel wie möglich:

sku
ekprice
tenant
name
beschreibung
stock
ean
mpn
usw

Das dumme daran ist dann natürlich, dass die Daten 100 fach vorkommen würden. (Wäre in mapdb auch ) Also Artikel 12345 wäre für 10 User, 10 mal in der Tabell. Evtl 10 x identisch, evtl auch 10 mal mit je verschiedenem Preis. Eigentlich müsste ich Datenbank "richtig" aufbauen sodass alle Werte die die anders sein können in eine eigene Tabelle stecken.

zb
table_price
id
tenant
ekPreis

Dann wäre das sauber, aber ist aufwändiger. Wenn ich das so mache, könnte ich auch gleich die Daten in die jeweilige tenante DB schreiben, was aber wiederrum bedeuten würde ich müsste die Logiken (Preis berechnen, Stati setzen usw) in den Hersteller Service einbauen. Wenn ich dann was ändere muss ich das bei jedem Hersteller.

Hier drehe ich mich irgendwie im Kreis.

Ich könnte auch einfach wie folgt vorgehen:

Erster Import legt ne Map an Map<sku,product> und speichert die lokal als Datei.
bei jedem weiteren Import wird die Datei geladen und die darin enthaltenen Produkte werden abgeglichen / ersetzt (update) ich bekomme Änderungen am Preis usw mit, welche ich dann an JMS senden kann.

Die Map würde dann (vermutlich?) im RAM liegen. Die größte derzeit hat 200mb, wenn ich die Daten so speichere als Map ist die Datei 20MB groß. Wenn ich sie lade bedeuted das, dass diese mit 20MB im RAM liegt oder wird das irgendwie "dynamsich" gehandhabt?
 
T

temi

Das dumme daran ist dann natürlich, dass die Daten 100 fach vorkommen würden. (Wäre in mapdb auch ) Also Artikel 12345 wäre für 10 User, 10 mal in der Tabell. Evtl 10 x identisch, evtl auch 10 mal mit je verschiedenem Preis.
Ist denn nur der Preis unterschiedlich, oder noch mehr? Man könnte ja eine Tabelle mit Artikelstammdaten haben und weitere Tabellen mit pro Kunde variablen Daten. Ungefähr folgende Tabellen:

Tabelle Kunden
Tabelle Artikelstammdaten
Tabelle Preise (mit FK_Kunde und FK_Artikel)
 
mrBrown

mrBrown

Das dumme daran ist dann natürlich, dass die Daten 100 fach vorkommen würden. (Wäre in mapdb auch ) Also Artikel 12345 wäre für 10 User, 10 mal in der Tabell. Evtl 10 x identisch, evtl auch 10 mal mit je verschiedenem Preis.
Welche Daten können denn vom Kunden abhängen, nur der Preis oder auch anderes?

Ich persönlich würde bei einer Tabelle bleiben, der Aufwand für Normalisierung (wenn es nicht sogar schon ausreichend normalisiert ist?) ist es in dem Fall wohl nicht wert.


Wenn ich das so mache, könnte ich auch gleich die Daten in die jeweilige tenante DB schreiben, was aber wiederrum bedeuten würde ich müsste die Logiken (Preis berechnen, Stati setzen usw) in den Hersteller Service einbauen. Wenn ich dann was ändere muss ich das bei jedem Hersteller.
Nur weil du einen Schritt weit gehst, musst du ja nicht gleich den Marathon laufen :)

Ich könnte auch einfach wie folgt vorgehen:

Erster Import legt ne Map an Map<sku,product> und speichert die lokal als Datei.
Das wäre wieder die „selber basteln“ Variante, stattdessen einfach die Datenbank nehmen dürfte sinnvoller sein (in Hinblick auf ACID etc), es muss ja keine Relationale Datenbank sein.
 
NicoDeluxe

NicoDeluxe

Die Daten können verschieden sein Bilderlinks können fehlen, Preise anders, Beschreibungen können abweichen.

Wenn wir den aktuellen Hersteller nehmen mit 40k Datensätzen, wären wir bei 100 Kunden bei 400k Einträgen in der Tabelle. Mit solchen Daten hab ich noch keine Erfahrung gemacht. Ist das viel? Keine Ahnung :D
 
mrBrown

mrBrown

Die Daten können verschieden sein Bilderlinks können fehlen, Preise anders, Beschreibungen können abweichen.
Dann dürften die Daten direkt schon in 4. (BC? 5.?) Normalform vorliegen.
Schlüsselkandidat ist (Artikel-Nr, Kunde), davon sind alle anderen abhängig.


Wenn wir den aktuellen Hersteller nehmen mit 40k Datensätzen, wären wir bei 100 Kunden bei 400k Einträgen in der Tabelle. Mit solchen Daten hab ich noch keine Erfahrung gemacht. Ist das viel? Keine Ahnung :D
400k Zeilen dürften kein Problem sein.
Überschlags einfach mal grob in Byte, wie viele Daten sind’s denn pro Artikel, irgendwas im unteren Kilobyte-Bereich? Und dann ist generell kaum Last auf der DB, keinerlei joins, nur einfach Insert/Update/Select mit Index.
 
NicoDeluxe

NicoDeluxe

Danke, ich teste das jetzt mal. Mal schauen was der db Server sagt. Dazu werde ich versuchen einen Interceptor einzubauen, der mir sagt welche werte sich geändert haben dann kann ich daraus gleich die Events feuern.

Ist doch richtig, dass Hibernate bei save() entweder updated oder neu anlegt, richtig? Geht das auch bei .saveAll() dann könnte ich gleich ne List speichern, spart vielleicht auch noch etwas Last?
Der Key müsste dann wie du sagst tenant und sku sein.
 
NicoDeluxe

NicoDeluxe

Jo das läuft. Lokale DB 40k Teile in 30 Sekunden mit save all und batch.
Allerdings gehts auf dem Liverserver mal wieder nicht so schnell. Da ist doch garantiert wieder irgenwas falsch konfiguriert :/
 
mrBrown

mrBrown

Jo das läuft. Lokale DB 40k Teile in 30 Sekunden mit save all und batch.
Allerdings gehts auf dem Liverserver mal wieder nicht so schnell. Da ist doch garantiert wieder irgenwas falsch konfiguriert :/
Datenbank und Service laufen auf unterschiedlichen Systemen und müssen übers Netzwerk kommunizieren? :)
 
NicoDeluxe

NicoDeluxe

Jap, aber auch nach 5 minuten kommt in der remote db nix an :( Die remote DB hat eine 1gbit Anbindung und ich hier 200.000 das muss doch flutschen oder?
 
NicoDeluxe

NicoDeluxe

Lese ich da unterschwellig heraus, dass ich die DB auf dem selben Server installieren soll? :D
 
Thema: 

Microservices StrukturPlanung

Passende Stellenanzeigen aus deiner Region:
Anzeige

Neue Themen

Anzeige

Anzeige
Oben