Das deutsche Python-Forum

Hallo,

@__deets__:

Redis ist normalerweise nur in-memory,

Redis kennt doch zwei Arten der Datenpersistenz.

Für zeitbasierte Daten könnte man noch InfluxDB in den Raum werfen. Wobei die Anforderungen sicherlich auch problemlos mit PostgreSQL abbildbar sind.

Gruß, noisefloor

Das berührt nicht meine Antwort. WIE geschrieben wird, ist erstmal unerheblich. Es muss nur der gesamte KV Raum in den Speicher passen. Damit halt schnell nachgeschlagen werden kann. Anders als bei Postgres (oder auch afaik MongoDB), wo ggf halt nachgeladen wird.

Das zumindest ist mir so ergangen vor 3 Jahren oder so, und einen Weg das zu ändern abs damals nicht.

Nochmal geschaut: sowas geht https://redis.io/topics/lru-cache

Eine wirklich geeignete DB ist das aber denke ich trotzdem nicht. Redis ist gut im Speicher. Nicht in zb Indizes über Zeitstempel, so das man die Frage nach “Temperatur von bis” gut beantworten kann.

Flexible Abfragen sind halt immer noch am besten bei einer SQL-Datenbank möglich. Sofern man weiß, dass man nur eine ganz bestimmte Abfrage machen möchte, lassen sich die Daten im Falle von NoSQL vorab entsprechend strukturieren. Spielt hier aber alles keine Rolle, da ja laut TE nur PostgreSQL verwendet werden kann.

Ich denke übrigens, dass man sich über Performance oder Speicherverbrauch bei dieser relativ kleinen Datenmenge keine großartigen Gedanken machen muss. Klar wächst die Menge zunehmend, aber den RAM dürfte es so schnell nicht sprengen.

Hallo,

@__deets__ : das Redis hier nicht 1. Wahl ist sehe ich auch so.

Was bei so kleinen Datenmengen auch gehen würde: Daten in eine CSV-Datei schreiben und mittels Pandas auswerten.

Gruß, noisefloor

Was ich aber noch nicht verstanden habe bei der normalisierung von Datenbanken wie laufen die Tabellen neben einander? Also muss ich da dann immer 3 Tabellen abrufen um mir dann die Daten die ich haben will zusammen zubauen oder wie geht das ganze dann?

Das kommt auf die Art der Daten an und wie weit man ins Detail gehen möchte.

Eine Messstation bleibt wahrscheinlich längere Zeit bestehen und wird immer wieder referenziert. Hier könnte man im einfachsten Fall sich irgendein Kürzel oder Zahl als Kennung ausdenken. Eleganter wäre aber ein Eintrag in einer Extra-Tabelle mit automatisch angelegter ID, auf die man dann woanders Bezug nehmen kann. Dann lassen sich auch weitere Details wie Standort oder Aufstelldatum / Datum der Inbetriebnahme mit einpflegen.

Und eine weitere Tabelle braucht man dann für die eigentlichen Messungen. Was man da als Details eintragen kann, wurde ja schon besprochen. Jede Messung sollte natürlich auch wieder automatisch eine ID zugeteilt bekommen. Zum Beispiel können diese IDs benutzt werden, um zu dokumentieren, welche Messungen in welchem Monat / Woche / Tag durchgeführt wurden, ohne dass man jedes Mal die komplette Messung eintragen muss.

Das Prinzip lautet hier: Sparsamer Umgang mit Ressourcen (Speicher) durch Vermeidung von Redundanzen (Wiederholungen). Als weiterer Effekt werden damit Änderungen an den Daten an allen Stellen sichtbar, da überall auf den gleichen Datensatz verwiesen wird und nur dieser Datensatz angefasst wird. Die dazu passende Struktur und wieviele Tabellen du dafür anlegst, musst du dir schon passend zum Anwendungsfall selbst ermitteln.

Hypec hat geschrieben: Mittwoch 20. März 2019, 16:13 Also muss ich da dann immer 3 Tabellen abrufen um mir dann die Daten die ich haben will zusammen zubauen oder wie geht das ganze dann?

Na, das löst du halt beim Reporting auf. Der Leser interessiert sich ja weniger für die ID, sondern eher für den Namen oder Standort der Station. Das lässt sich dann passend einteilen, z.B. mittels GROUP BY.

Du musst halt, wie so oft bei der Programmierung, in Rollen denken: Eine Rolle ist die interne Datenhaltung, wo man IDs benutzt. Die andere Rolle ist die Aufbereitung für Anzeige beim Anwender. Dass dann mehrere Tabellen ins Spiel kommen, ist ganz normal.

Sorry das ich erst so spät antworte aber ich war mit anderen dingen beschäftigt. Ich habe jetzt meine Datenbank normalisiert. Mein Problem jetzt ist das ich momentan eine kostenlose Datenbank nütze die dafür allerdings auf 10.000 Reihen begrenzt ist. Wenn ich jetzt 3 Messstationen a 6 Werte habe sind das 432 Reihen am Tag und die Datenbank wäre nach 23 Tagen voll.
Was würde sich verändern wenn ich immer alle 6 Messwerte aus einer Messung in die selbe Reihe schreiben würde ?

Wie sieht Dein Datenbank-Design jetzt aus?

Wenn Du immer 6 Messwerte in einen Datensatz schreibst, ist die Datenbank nach 138 Tagen voll.

Eine auf 10.000 Datensätze beschränkte Datenbank ist für vieles nicht brauchbar – insbesondere nicht für regelmässig anfallende Messdaten.

Mein Datenbank Design sieht momentan so aus:

WERTTYP: id, name

MESSSTATIONEN: id, name,owner

MESSUNG: id, messstation_id, werttyp_id, timestamp, wert

Meine Überlegung wäre es jetzt MESSUNG so umzuformen:

MESSUNG: id, messstation_id, timestamp, wert1, wert2, wert3, wert4, wert5, wert6

Ja das stimmt das wären dann aber immerhin mehr als 4 Monate die ich auf die Daten zurückgreifen könnte.

Ich weiß allerdings will ich solange ich das ganze noch Entwickel möglichst meine Kosten gering halten.

Die Auswahl von DBMS ist gefühlt riesig. Wenn genau das System, das du einsezen willst, ein Feauture hat, das kein anderes bietet, dann musst du halt die Vollversion kaufen, damit es keine Beschränkung der Einträge in einer Tabelle gibt. Das Tabellendesign kaputtzufrickeln, nur damit es mit der Trial-Version läuft, wäre wenig zielführend.
Also: gibt es ein solches Feature? Falls nicht, setz halt ein, was es am Markt etabliert gibt: PostgreSQL, MariaDB/MySQL, sqlite3 wenn es lokal reich oder von mir aus auch so etwas wie Firebird.

Allerdings bin ich verwirrt: Das Thema heißt doch "Postgresql Tabellen" (sic!), da gibt es doch gar keine Beschränkung.

@sparrow: Ich habe das jetzt so interpretiert das er eine kontenlose PostgreSQL bei einem Anbieter verwendet, der aber Geld sehen will wenn man da mehr als 10.000 Datensätze drin speichern möchte.

Richtig ich nutze heroku.com da läuft eben auch meine Website mit der ich die Datenbank verbinde.

Dann schau doch mal, ob es nicht sinnvoller ist, statt Postgres sqlite zu verwenden.

Das Problem dabei ist das die Datenbank in einer Datei ist. Wenn ich dann meinen Server aktualisieren will also etwas im Code ändern möchte muss ich ja wieder den ganzen Ordner hochladen. Damit dann die Datenbank bestehen bleiben würde müsste ich erst die Datei Herunterladen in den Ordner ziehen und dann wieder mit Hochladen. Das wäre ein ziemlicher Aufwand.

Im Gegensatz zur Migration deiner Datenbank? Das geht doch genauso wenig automatisch, und sobald du da etwas nicht triviales machst ist ggf wegwerfen & neu aufsetzen eh die besser Idee. Außerdem musst du doch die SQLite überhaupt nicht transferieren. Welchen Nutzen haben denn die Daten von Lokal?

Ich glaube ich sollte mich ein bisschen besser erklären. Also meine Webanwendung in Flask läuft auf Heroku. Wenn ich da etwas im Code ändern will programmiere ich das ganze Lokal bei mir und muss dann den ganzen Ordner, mit den Dateien Python HTML usw., auf den Server hochladen wodurch die alte Version überschrieben wird.
Wenn ich es richtig verstanden habe ist SQLite eine Datenbank welche in einer Datei ist und diese Datei muss ja auch in dem Ordner sein den ich Hochlade. Wenn ich jetzt eine neue Version Hochlade dann wird meine alte SQLite Datenbank überschrieben und meine Messdaten sind weg.
Um das zu verhindern müsste ich also vor jeder neuen Version die ich mache die Datenbank mit den Messdaten vom Server Herunterladen in den Ordner kopieren und wieder mit Hochladen, damit nichts verloren geht.

Und bei den äquavilenten 10000 Zeilen deiner Postgres reden wir hier über wieviele Kilobyte? Bei angenommenen 100 Byte pro Zeile ein GANZES Megabyte. Da ist so ein DSL Anschluss schonmal SEKUNDEN mit beschäftigt ...

Mir geht es nicht um die Datengröße sondern um den Aufwand der dabei entsteht.