update troubleshoot

README.md

@@ -6,50 +6,22 @@ Dieses Repo beinhaltet den Code und die Datasets zur Masterarbeit "..." von Sven
 # Troubleshooting
 
 ## Gleiche Datenmenge in DB bekommen
-persistence true
-persistence_location /mosquitto/data
-
 Publisher Script angepasst. Es gibt im Publisher die Möglichkeit die Anzahl an Zeilen pro Datei zu bestimmen.
 Für alle auf z.B. 5000. Führt dazu, dass an jeden Subscriber die gleiche Anzahl an Zeilen gesendet wird.
 
 Bei einfachem Stoppen nach einer Minute sind unterschiedliche viele Daten in den DBs.
+-> Grund ist, dass wenn der Publisher fertig mit Übertragung ist, dass der SUbscriber die Connection zum Broker löscht
+-> Fix durch keepalive im Connect zum Broker von XYZ (4) Stunden.
+-> führte bei 100000 eingefügten Zeilen in Postgres dazu, dass keine Daten fehlen.
 
-Nutzen für Kontrolle der Queries
-
-
-docker build -t lab.it.hs-hannover.de:4567/cwy-p8d-u1/ma_code/pub_cdm "./infrastructure/streaming/clients/pub" 
-match (n) return count(n)
-
-select count(*) from node_list
-Bei 500 veröffentlichten Daten in der DB enthalten:
-PG = 500
-Neo4j = 500
-ONgDB = 500
-Memgraph = 500
+### Das Problem das ich unterschiedlich viele Daten in den DBs hatte lag: 
+1. an der Größe der Message Queue. Die war zu gering und dadurch wurden Nachrichten gedroppt. Ist mir erst aufgefallen, als ich die Ergebnisse mal in Excel gegenüber gestellt habe und das Diff ermittelt habe. Es gab tatäschlich Lücken zwischen dem Cadets Datensatz und dem was eingefügt wurde. Das Log vom Broker war der erste Anhaltspunkt wo man mal früher hatte reingucken müssen.
+-> Jetzt ist die Queue so lange wie der Datensatz selbst... sollte für meine kleinen Versuche reichen. Bei 100.000 Nachrichten wird jedenfalls nichts mehr gedroppt und der RAM vom Broker war etwa 250 MB von 9 GB. Der gesamte Datensatz sind knapp 40.000.000 Zeilen/Nachrichten. Da ich eh nur ein Experiment erstmal für zwei Stunden laufen lasse müsste das reichen.
 
-Bei 1000 veröffentlichten Daten in der DB enthalten (mit wartezeit...):
-PG = 1000
-Neo4j = 1000
-ONgDB = 1000
-Memgraph = 1000
+2. die Subscriber haben sich vom Broker disconnected, weil ich keine "keep-alive" Zeit eingerichtet habe, wenn der Publisher nicht mehr sendet. Da der Publisher so viel früher fertig war, kam es dazu, das sich die Subscriber ebenfalls disconnecten (weil keine neuen Nachrichten durch Publisher bekommen), obwohl noch Nachrichten zu inserten sind.
+-> keepalive Zeit ist nun 4 Stunden... also Open End um die Experimente durchlaufen zu lassen
 
-Bei 5000 veröffentlichten Daten in der DB enthalten:
-PG = 1590
-Neo4j = 1487
-ONgDB = 1487
-Memgraph = 1840
-
-zweiter Versuch 5000:
-PG = 1822
-Neo4j = 1684
-ONgDB = 1684
-Memgraph = 2179
-
-Wieso werden keine Knoten mehr eingefügt, sobald der Publisher aufhört?
--> Ist nicht der Fall... das einfügen dauert nur länger.... Die ersten 1000 kommen an
--> Bei 5000 jedoch nicht mehr
-
-Weil pro Batch nicht alles verarbeitet wird?
-Prüfe ende des zweiten Batches
+3. fehlten in Postgres noch Kanten. Hab die nicht eingefügt, wodurch die Pfad Query nicht funktionieren konnte. Jetzt bekomme ich auch für die Pfad-Query ein Ergebnis in Postgres bzw das gleiche Ergebnis wie in den GraphDB.
 
 Wie groß ist der Diff zwischen der Zeit, wenn alle Daten in DB?
+