politik-bei-uns / daemon

Daemon zum Abruf und zur Verarbeitung von Daten via OParl-API.

Der "Politik bei uns"-Daemon ist ein Unix-Daemon, welcher von einer Reihe an OParl-Endpunkten Daten downloaded und weiterverarbeitet.

daemon's Issues

CI

Hi! I think that in order for people less familiar with this project to contribute with greater confidence, it would be awesome to have basic CI for this.

See for example #3 - if the container was built and started with a few basic checks in CI then that would give me better confidence that I didn't mess up :)

Intelligenteres Syncen: mehr im RAM halten

Bislang basiert der Daemon massiv auf MongoDB Upserts. Das ist zwar jeweils immer nur ein Request / Objekt, aber bedingt durch die vielen Objekt-Verknüpfungen sind das trotzdem extrem viele Requests, so dass bei einem Full Update extrem viele Requests auf die MongoDB gemacht werden. Es wäre vermutlich intelligenter, pro Stadt einfach einen Zusammenhang ID -> modified aller Objekte in den RAM zu laden und dann gegen den RAM zu checken, ob sich etwas verändert hat. Das würde insbesondere bei den verlinkten Objekten eine deutliche Beschleunigung ergeben.

Konkret: aktuell mache ich zich schreibende Requests im Beispiel von Organization: https://oparl.org/spezifikation/online-ansicht/#entity-organization , u.a. für jede Membership (was nur eine ID ist, die dann da abgespeichert wird), ebenso wie für Location. Hätte man ID + modified im RAM, so könnte man die Existenz von Membership und das Änderungsdatum von Location schlicht testen und nur dann abspeichern, wenn es überhaupt ein neues Objekt ist / eine Änderung gab.

Pro Kommune sind die ID -> modified Zuordnungen auch begrenzt: wenn man annimmt, dass eine URL bis zu 128 Zeichen lang ist, dann macht das 128 Byte * 500.000 Dokumente (was weit über der größten Kummune aktuell ist) = 64 MB RAM-Verbrauch. Mit gespeicherten Datetimes in einem riesigen Dict sind das in einem Realtest 227 MB VSZ und 156 MB RSS, was bei maximal 8 auf einem 8-Kern-System gleichzeitigen Prozessen eine Maximalauslastung von unter 2 GB ausmacht. Wenn dadurch wirklich nennenswert Datenbanklast eingespart werden kann, ist dies für einen Server mit 32 oder sogar 64 GB RAM ein Klacks.

ElasticSearch Updates mit Modified

Es sollten immer nur neue Dokumente aktualisiert werden, nicht alle.

Intelligentere Sitemaps

Aktuell müssen XML-Sitemaps bei jeder Änderung neu generiert werden. Das liegt u.a. an der blöden Beschränkung von 50k Einträgen / XML Sitemap. Da MongoDB auch keine hochzählende ID hat, ist es auch schwierig, da immer einen sauberen Cut zu finden und so nur Teile zu aktualisieren. Es bräuchte also einen hübschen Weg, wie man das besser macht.

sha512

Momentan wird nur sha1Checksum ausgegeben, nicht aber die bessere sha512.

Kleinteiligere Queue nach Download

Aktuell ist ein Queue-Eintag "Synce eine Stadt" oder "Generiere ElasticSearch einer Stadt". Das macht beim Downloaden selbst schon Sinn, weil die Anzahl Requests gegen einen Server eh limitiert werden muss, danach macht es aber weniger Sinn und ist oft unpraktisch, weil dann im Folge-Queue-Eintrag oft Infos fehlen. Es wäre also eine Überlegung wert, den großen Download in einer Queue zu belassen und dann im Anschluss eine rabbitmq Celery Queue zu machen, die dann kleinteilig Aufträge übernimmt (wie zum Beispiel: "mache Thumbnail für dieses eine File" oder "ES-Indexiere dieses eine Dokument").

Schöneres Syncen: Code aufhübschen

Den Code vom Sync-Client könnte man wirklich hübscher machen:

https://github.com/politik-bei-uns/daemon/blob/master/oparlsync/oparl_download/OparlDownload.py

Eine der fiesesten Dinge ist dabei diese riesige sehr abstrakte Loop. Eine der größten Gemeinheiten dort ist, dass sich document_type_obj zur Laufzeit von einem String zu einem Objekt ändert (uäh!), was von Mongoengine reinkommt und viel Spaß beim Debuggen gibt. Aber auch so: das ließe sich sicherlich aufhübschen, indem man das in mehr Codefragmente aufteilt.

Es ist auch eine Überlegung wert, manchmal nicht gar so abstrakt zu agieren. Diese extrem abstrakte Darstellung mit "alles definiert sich über das MongoEngine Datenmodell" hatte ich damals gewählt, weil wir nicht wussten, wie stabil und zuverlässig die OParl-Relationen auf nahezu alle Gegebenheiten passen. Da nun aber klar ist, wie gut OParl zur Realität passt, könnte man auch überlegen, das Abstraktionslevel zu senken, wenn das zu besser zu wartendem Code führt.