[erledigt] Python: Daten effizient in Dateien und/oder RAM ohne Datenbank halten

[buhtz]

Ich denke gerade darüber nach, wie ich effizient und insbesondere ressourcensparend Daten in meiner Anwendung halten kann.

Es geht um 100 bis 200 Newsfeeds. Deren Meta-Daten sind in einer JSON-Datenstruktur vorhanden, die in einer Datei persistent gespeichert sind und bei Anwendungsstart ins RAM geholt werden und dort auch verbleiben.

Der Knackpunkt sind nun die Einzeleinträge (nenne ich jetzt mal "Nachrichten") je Feed. Mit enstprechender Nutzungszeit des Newsreaders kommen da schnell mehrere 1000 "Nachrichten" je Newsfeed zusammen. Wann ich diese Daten brauche, kann ich nicht voraussehen, weil ich nicht weiß, welche Feeds der Nutzer anklicken wird.

1. Eine echte Dantenbank drunter legen, die solche Dinge für mich "lösen" würde, möchte ich nicht.
2. Ich könnte je Feed eine eigenen Daten mit den Einzelnachrichten (auch im JSON-Format) anlegen. Die wird dann bei Bedarf geöffnet und ins RAM gelesen.
3. Ich könnte alle diese Dateien (100-200) Stück bei Programmstart schon mal öffnen, aber noch nicht lesen. Das spart RAM. Würde es die Zugriffszeit verbessern?
4. Alle Dateien und deren Daten (ca 200 x 2000 Feeds) bei Programmstart öffnen und ins RAM holen... Klingt nach overhead.
5. Ich könnte auch ein bisschen jonglieren: Je Newsfeed, ungelesene "Nachrichten" in eine Dateie, die gelesenen der letzten drei Monate in eine zweite Datei und den noch älteren Rest in eine Dritte. Komplex. Ob das durch den Benefit aufgewogen wird?

Mhm... Was meint ihr?

[shoening]

Hi,

im Sinne von „premature optimization is the root of all evil.“ würde ich erst mal in etwa Deine 2. Lösung implementieren (1 Verzeichnis pro Feed und pro Nachricht eine Datei) implementieren.

Wenn das dann zu langsam ist, legst Du um Deine Methode/Funktion einen Proxy, der z.B. einen LRU-Cache implementiert.
Einen LRU-Cache gibt es fertig in der Python Standard Bibliothek „functools“ - Batteries incuded .

Damit trennst Du dann ganz natürlich Deine eigentliche Funktionalität von dem „Optimierungscode“ und kannst beides auch unabhängig voneinander testen.

Ciao
Stefan

[Meillo]

Ich moechte hier auch gerne meine Gedanken zur Optimierung einbringen, die ich in einem Vortrag zusammengestellt habe: http://marmaro.de/docs/chaosseminar/on-performance/

Im Videomitschnitt ab 0:36:50 betrachte ich genau diese Situation, ueber die du hier nachdenkst, bei rss2email. Das solltest du dir anschauen und darueber nachdenken, bevor du unbewusst in das gleiche Problemmuster verfaellst.

[inne]

1. Eine echte Dantenbank drunter legen, die solche Dinge für mich "lösen" würde, möchte ich nicht. Das wäre mir zu aufgebläht für den Anwendungsfall und würde Abhängigkeiten zu weiteren Paketen (z.B. sqlalchemy und sqlite) schaffen.

Deine Datenbank wie sqlite wirst du brauchen – weil alles andere ungut ist.

[ChronoBoost]

Zumindest sqlite ist doch schon in jeder python Distribution enthalten und ein import sqlite3 sollte den Quellcode weniger aufblähen als die ganze Funktionalität selbst zu implementieren (Sortieren, Transaktionen, Joins usw.). Die Konfiguration könntest Du ja in den json Dateien belassen, so dass sie mit dem Texteditor einfacher geändert werden können.

[Milbret]

Klingt wegen JSON weniger nach einer Relationalen DB wie Sqlite und mehr einer Dokumenten DB.
Diese speichern dann JSON Strukturen und bieten auch die Möglichkeiten zu entsprechenden Abfragen mit eigenem Syntax.
Dürfte hier aber auch mit Sqlite gehen, musst dann eben deine JSON Objekte auf die Tabellen mappen.
Je nach Umfang der Struktur hast du dann einige Tabellen und mit der Zeit auch entsprechend große DBs.

Martin

[buhtz]

Datenbank ist keine Option und möchte ich an dieser Stelle auch nicht diskutieren. Habe (ausnahemsweise) in diesem Bereich ausreichend Erfahrung, um das beurteilen zu können. Eine Datenbank (auch so simple wie sqlite) wäre overkill - aus verschiedenen Gründen.

Zumindest sqlite ist doch schon in jeder python Distribution enthalten und ein import sqlite3 sollte den Quellcode weniger aufblähen als die ganze Funktionalität selbst zu implementieren (Sortieren, Transaktionen, Joins usw.).

Diese "Funktionalität" ist meinem Szenario nicht notwendig.

[novalix]

Was ist eine Datenbank?
Ein RDBMS - auch ein leichtgewichtiges wie SQLite - verursacht in Deinem Szenario mit Sicherheit einen fehleranfälligen Mehraufwand in der Programmierung, da Du die Struktur der JSON-Objekte auf ein relationales Schema mappen müsstest.
Dafür kann man wie @Milbret schon anführte gerne NoSQL-Systeme verwenden (Mongo, RethinkDB, etc.)
Die sind aber meistens selbst nicht unfett und für potentiell größere Datenmengen und -operationen ausgelegt.
Dann gäbe es da auch noch Key-Value-Stores à la redis oder memcached.
https://db-engines.com/de/ranking/key-value+store

[Meillo]

Stellen wir uns doch mal ganz dumm, denn in den meisten Faellen ist Brute Force der beste Ansatz ... jedenfalls bis man sich sicher ist, dass es nicht der Fall ist und dann ueberarbeitet man die Anwendung iterativ.

Also 200 Feeds, die du in einer Datei ablegst. Dann fuer jeden Feed eine eigene Datei in der die 2000 Eintraege abgelegt werden. Damit hast du 201 Dateien.

Die Feeddatei liest du beim Programmstart ein (notwendigerweise). Die anderen Dateien liest du dann ein wenn du sie brauchst.

Das Einlesen einer Datei ist fuer dein Nutzungsszenario sehr sicher ausreichend schnell, weil so ein Feedreader ja nicht oefter als sagen wir mal alle 10 Minuten die Feeds abruft.

Was den Arbeitsspeicherbedarf angeht, so kommt es darauf an, wieviel Datenmenge das je Feed tatsaechlich sind. Das kannst du ausrechnen. Je nachdem wie gross der Wert ist, musst dein Programm zwischendurch mal wieder Feeddaten freigeben oder nicht.


Ich sehe nicht ganz wo das Problem eigentlich liegt. Im Eingangspost schreibst du, dass der Knackpunkt sei, dass du nicht weisst wann die Feeddaten gebraucht werden ... aber du schreibst implizit auch, dass es dann sein wird, wenn der User auf den jeweiligen Feed klickt. Dann lade sie doch einfach in dem Moment. Wenn ich auf der Kommandozeile eine 2000-Zeilen-Datei sortiere (was Einlesen in den Speicher und noch verschiedene Rechnerei beinhaltet und damit in etwa dem entspricht was du machen musst) dann dauert das 0,05s -- das ist fuer den User unmerklich.

Ich schlage vor, dass du dir nicht so viele Gedanken machst, sondern einfach anfaengst und spaeter nacharbeitest, falls noetig.

[bluestar]

Im Zeiten wo wir bei RAM-Größen im GB-Bereich leben, würde ich mir da auch keine all zu großen Gedanken über den Speicherbedarf machen.

Einfach mal loslegen wäre auch mein Ansatz...

[buhtz]

Also 200 Feeds, die du in einer Datei ablegst. Dann fuer jeden Feed eine eigene Datei in der die 2000 Eintraege abgelegt werden. Damit hast du 201 Dateien.
...Ich schlage vor, dass du dir nicht so viele Gedanken machst, sondern einfach anfaengst und spaeter nacharbeitest, falls noetig.

Genauso hab ichs gemacht und komme bisher gut damit zurecht.

Eine JSON Datei für die Feeds.
Je Feed eine weitere JSON Datei mit den Feed-Beiträgen. Hier muss ich mir ab einigen 1000 Einträgen mal Gedanken um die Archivierung und das Verwerfen machen.

[Meillo]

[uname]

Schau dir mal Berkley DB an, die unter anderen von SquidGuard zur Verwaltung und Echtzeitdurchsuchen von Millionen Backlisteinträge verwendet wird. Für Python schau hier. Scheinbar wurde die Lizenz geändert. Da musst du evtl. etwas aufpassen.