Wie Key-Value Sets speichern?
Hallo,
ich schreibe Werte aus einer C++ Anwendung, gespeichert als std::map<string, T> in eine Datei.
Dabei will ich folgendes:
- Die Datei soll menschen-lesbar sein
- Es sollen mehrere Sets von Key-Value Paaren gespeichert werden, z.B. eins pro Run.
- Die Paar varieren pro Set. CSV scheidet deshalb aus, da es es für die gesamte Datei das gleiche Datenformat annimmt (wenn man die erste Zeile als Header, für die Keys verwendet)
- Eingelesen werden soll es mit Python um dann z.B. mit numpy weiterverarbeitet werden.
Wie würde nun ein geeignetes Datenformat ausschauen, was ich dann auch problemlos mit Python einlesen kann?
CSV mit Trennlinie?
A;B;C AValue;BValue;CValue ===== A;D;Y AVal,DVal,YVal ===== ...
Viele Grüße, Florian
Json!?
On Wednesday, 28 September, 2016 12:09 AM, Florian Lindner wrote:
Hallo,
ich schreibe Werte aus einer C++ Anwendung, gespeichert als std::map<string, T> in eine Datei.
Dabei will ich folgendes:
Die Datei soll menschen-lesbar sein
Es sollen mehrere Sets von Key-Value Paaren gespeichert werden, z.B. eins pro Run.
Die Paar varieren pro Set. CSV scheidet deshalb aus, da es es für die gesamte Datei das gleiche Datenformat annimmt
(wenn man die erste Zeile als Header, für die Keys verwendet)
- Eingelesen werden soll es mit Python um dann z.B. mit numpy weiterverarbeitet werden.
Wie würde nun ein geeignetes Datenformat ausschauen, was ich dann auch problemlos mit Python einlesen kann?
CSV mit Trennlinie?
A;B;C AValue;BValue;CValue ===== A;D;Y AVal,DVal,YVal ===== ...
Viele Grüße, Florian _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
JSON!
Regards Andreas Jung ----- Sorry for being brief - sent from a mobile device.
Am 28.09.2016 um 01:03 schrieb Achim Domma domma@procoders.net:
Json!?
On Wednesday, 28 September, 2016 12:09 AM, Florian Lindner wrote: Hallo,
ich schreibe Werte aus einer C++ Anwendung, gespeichert als std::map<string, T> in eine Datei.
Dabei will ich folgendes:
Die Datei soll menschen-lesbar sein
Es sollen mehrere Sets von Key-Value Paaren gespeichert werden, z.B. eins pro Run.
Die Paar varieren pro Set. CSV scheidet deshalb aus, da es es für die gesamte Datei das gleiche Datenformat annimmt
(wenn man die erste Zeile als Header, für die Keys verwendet)
- Eingelesen werden soll es mit Python um dann z.B. mit numpy weiterverarbeitet werden.
Wie würde nun ein geeignetes Datenformat ausschauen, was ich dann auch problemlos mit Python einlesen kann?
CSV mit Trennlinie?
A;B;C AValue;BValue;CValue ===== A;D;Y AVal,DVal,YVal ===== ...
Viele Grüße, Florian _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
On 2016-09-28 01:03, Achim Domma wrote:
Json!?
Wenn ich das richtig sehe, hätte JSON den Nachteil, dass man am Ende immer eine geschweifte Klammer hat, die beim inkrementellen Anfügen stört.
Mir fällt noch YAML ein.
https://en.wikipedia.org/wiki/Yaml http://pyyaml.org/
Viele Grüße Stefan
Jein. Json enthält keine Zeilenumbrüche, d.h. du kannst einen "Record" pro Zeile als Json codieren und so problemlos inkrementell schreiben.
Grüße, Achim
On Wednesday, 28 September, 2016 06:47 AM, Stefan Schwarzer wrote:
On 2016-09-28 01:03, Achim Domma wrote:
Json!?
Wenn ich das richtig sehe, hätte JSON den Nachteil, dass man am Ende immer eine geschweifte Klammer hat, die beim inkrementellen Anfügen stört.
Mir fällt noch YAML ein.
https://en.wikipedia.org/wiki/Yaml http://pyyaml.org/
Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
On 2016-09-28 09:02, Achim Domma wrote:
Jein. Json enthält keine Zeilenumbrüche, d.h. du kannst einen "Record" pro Zeile als Json codieren und so problemlos inkrementell schreiben.
Ich meinte: Falls du eine JSON-Datei schreibst und später noch neue Datensätze anhängen willst, reicht es nicht, die Datei einfach zum Anhängen zu öffnen. In dem Fall stört die geschweifte Klammer am Ende, die alle Datensätze einschließt. Die müsste quasi hinter den neuen letzten Datensatz wandern.
Viele Grüße Stefan
Korrekt. Außerdem ist das Format für mehrere JSON-Dokumente in einer Datei nicht offiziell standardisiert.
On 29.09.2016 08:36, Stefan Schwarzer wrote:
On 2016-09-28 09:02, Achim Domma wrote:
Jein. Json enthält keine Zeilenumbrüche, d.h. du kannst einen "Record" pro Zeile als Json codieren und so problemlos inkrementell schreiben.
Ich meinte: Falls du eine JSON-Datei schreibst und später noch neue Datensätze anhängen willst, reicht es nicht, die Datei einfach zum Anhängen zu öffnen. In dem Fall stört die geschweifte Klammer am Ende, die alle Datensätze einschließt. Die müsste quasi hinter den neuen letzten Datensatz wandern.
Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Am 28.09.2016 um 06:47 schrieb Stefan Schwarzer sschwarzer@sschwarzer.net:
Wenn ich das richtig sehe, hätte JSON den Nachteil, dass man am Ende immer eine geschweifte Klammer hat, die beim inkrementellen Anfügen stört.
Aus dem Grund wurden Formate wie JSrec entwickelt, das ich persönlich auch gern benutze. Man muss nur über die einzelnen Sätze selbst iterieren. Siehe:
https://www.huyng.com/posts/json-streaming-record-data-format
Gruß,
Dinu
-- Sent on the move. Von unterwegs gesendet.
Ich kann auch nur YAML aus den folgenden Gründen empfehlen:
- inkrementelles Schreiben - Standardisierung von Datum und Zeitstempeln - menschenlesbar(er im Vergleich zu JSON) - JSON ist ein Subset von YAML - unterstützt Dokumente per Streaming
Wir setzen YAML auch produktiv erfolgreich ein, von daher kann es sein, dass ich voreingenommen bin. :)
Sven
On 28.09.2016 06:47, Stefan Schwarzer wrote:
On 2016-09-28 01:03, Achim Domma wrote:
Json!?
Wenn ich das richtig sehe, hätte JSON den Nachteil, dass man am Ende immer eine geschweifte Klammer hat, die beim inkrementellen Anfügen stört.
Mir fällt noch YAML ein.
https://en.wikipedia.org/wiki/Yaml http://pyyaml.org/
Viele Grüße Stefan _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Servus Florian!
Am 28.09.2016 um 00:09 schrieb Florian Lindner:
Dabei will ich folgendes:
Die Datei soll menschen-lesbar sein
Eingelesen werden soll es mit Python um dann z.B. mit numpy weiterverarbeitet werden.
Wie würde nun ein geeignetes Datenformat ausschauen, was ich dann auch problemlos mit Python einlesen kann?
Ich frage mich, was Du mit dem Ganzen eigentlich bezweckst.
Du willst aus C++ in ein menschenlesbares Datenformat schreiben um es dann zu Parsen um es dann mit Numpy zu verarbeiten? Das erscheinen mir gleich zwei Widersprüche zu sein: Wenn Du numpy brauchst sind es viele Daten. Wenn Du viele Daten hast, will die sich ein Mensch nicht mehr anschauen. Und Du willst keinen Parser dafür bauen, weil der a) langsam sein wird und b) Du dir wirklich sicher sein musst, dass er richtig funktioniert. Was bei vielen Daten nicht ganz einfach zu überprüfen ist.
Dein Daten sind irregulär, also keine rechteckige Matrix. Daher ist Numpy sowieso nicht gut geeignet diese Daten direkt zu verarbeiten. Warum willst Du also Dinge, die sich unterscheiden in einer Datei aneinander hängen, um sie später für die Verarbeitung in Numpy wieder auseinander zu pfriemeln.
Wenn Du an Deiner "Alles in einen File"-Strategie festhält, wirst Du beim Einlesen sowieso eine Art von Dispatching machen müssen um die (sofern ich verstanden habe homogenen) Daten der einzelnen Runs wieder aus Deinem File zu extrahieren.
Wir verarbeiten für einen großen KFZ-Hersteller CAN-Bus-Daten. Das sind Signale die je nach Datenquelle anders kodiert sind. Also z.B. "Blinker Hinten Rechts" hat nur ein paar Zustands-Bits. Dagegen ist die Drehzahl, das Drehmoment und der Öldruck, des Motors ein Fließkomma-Wert. Alle diese Daten kommen als ein großer Datenstrom an. Das Problem ist also dem Deinigen evtl. ähnlich gelagert. Jede da draußen mit CAN-Daten beschäftigte Firma baut sich, wie Du es auch vor hast, ein eigenes Datenformat, um mit den Daten umzugehen.
Wir wollten nicht den gleichen Fehler machen und haben ein standardisiertes Datenformat genommen. Wir dispatchen die CAN-Daten nach der Datenquelle jeweils in eine Tabelle eines HDF5-Files. Es gibt also eine Tabelle für den "Blinker hinten rechts" und eine andere Tabelle für die Motordaten. Jede dieser HDF5-Tabellen hat dabei eine andere Struktur. HDF5 ist ein sehr flexibles selbst dokumentierendes, standardisiertes, komprimiertes, binäres, plattformunabhägiges Datenformat welches mit zwei Python-Befehlen eine Tabelle in einen numpy Array lesen/schreiben kann [1]. Ein HDF5-File ist aufgebaut wie ein Dateisystem mit Ordnern in denen Tabellen (und beliebige andere Dinge wie z.B. Grafiken) liegen können. Noch dazu kann mit mehr als C-Geschwindigkeit in gigantisch großen Datenbeständen (größer als der verfügbare RAM) aus Python heraus gesucht und gefiltert werden.
HDF5 ist erstmal nicht menschenlesbar - was meiner Meinung nach auch in den seltensten Fällen nötig oder wünschenswert ist. Aber es gibt mit hdf5dump und hdfview [2] plattformunabhängige Werkzeuge um HDF5-Files konfortablel zu betrachten oder in menschenlesbare Form zu bringen. Die Python Charting-Software VEUSZ [3] kann HDF5-Files direkt einlesen und verarbeiten, wie auch alle anderen größeren Charting-Programme Import-Filter für HDF5 anbieten. Ich habe mit Aesir [4] einen QT-Python-HDF5-Viewer programmiert der deutlich schneller als HDFView ist. Auch haben wir Datenklassen für Plone programmiert, um direkt im Browser durch HDF5-Files zu navigieren und deren Tabellen als Web-Tabellen und Charts darzustellen zu können [5]. Das ist der große Vorteil eines gut dokumentierten und standardisierten Datenformats, es ist eine gute Basis um selber darum ein Ökosystem zu entwickeln.
Ich hoffe Du erzählst uns ein bisschen mehr über Dein Projekt, dann können wir Dir sicher bessere Ratschläge geben als JSON, YAML, welche beide mit Numpy nicht so recht zusammengehen.
Beste Grüße
Volker
[1] http://www.pytables.org/ [2] https://support.hdfgroup.org/products/java/hdfview/ [3] http://home.gna.org/veusz/ [4] Noch nicht released. Kann bei Interesse aber gerne das Teil "as is" mal auf github schieben. [5] Erste Prototypen.
Hallo,
wenn die Daten unterschiedlich sind, kann es auch sinnvoll sein, SQLite als Persistenz-Format einzusetzen. Dann kannst Du Dir bequem für jeden Record-Typen eine eigene Tabelle schreiben und später beim Einlesen die Daten selektieren.
VG, Achim.
Am 28.09.2016 um 22:58 schrieb Dr. Volker Jaenisch volker.jaenisch@inqbus.de:
Servus Florian!
Am 28.09.2016 um 00:09 schrieb Florian Lindner:
Dabei will ich folgendes:
Die Datei soll menschen-lesbar sein
Eingelesen werden soll es mit Python um dann z.B. mit numpy weiterverarbeitet werden.
Wie würde nun ein geeignetes Datenformat ausschauen, was ich dann auch problemlos mit Python einlesen kann?
Ich frage mich, was Du mit dem Ganzen eigentlich bezweckst.
Du willst aus C++ in ein menschenlesbares Datenformat schreiben um es dann zu Parsen um es dann mit Numpy zu verarbeiten? Das erscheinen mir gleich zwei Widersprüche zu sein: Wenn Du numpy brauchst sind es viele Daten. Wenn Du viele Daten hast, will die sich ein Mensch nicht mehr anschauen. Und Du willst keinen Parser dafür bauen, weil der a) langsam sein wird und b) Du dir wirklich sicher sein musst, dass er richtig funktioniert. Was bei vielen Daten nicht ganz einfach zu überprüfen ist.
Dein Daten sind irregulär, also keine rechteckige Matrix. Daher ist Numpy sowieso nicht gut geeignet diese Daten direkt zu verarbeiten. Warum willst Du also Dinge, die sich unterscheiden in einer Datei aneinander hängen, um sie später für die Verarbeitung in Numpy wieder auseinander zu pfriemeln.
Wenn Du an Deiner "Alles in einen File"-Strategie festhält, wirst Du beim Einlesen sowieso eine Art von Dispatching machen müssen um die (sofern ich verstanden habe homogenen) Daten der einzelnen Runs wieder aus Deinem File zu extrahieren.
Wir verarbeiten für einen großen KFZ-Hersteller CAN-Bus-Daten. Das sind Signale die je nach Datenquelle anders kodiert sind. Also z.B. "Blinker Hinten Rechts" hat nur ein paar Zustands-Bits. Dagegen ist die Drehzahl, das Drehmoment und der Öldruck, des Motors ein Fließkomma-Wert. Alle diese Daten kommen als ein großer Datenstrom an. Das Problem ist also dem Deinigen evtl. ähnlich gelagert. Jede da draußen mit CAN-Daten beschäftigte Firma baut sich, wie Du es auch vor hast, ein eigenes Datenformat, um mit den Daten umzugehen.
Wir wollten nicht den gleichen Fehler machen und haben ein standardisiertes Datenformat genommen. Wir dispatchen die CAN-Daten nach der Datenquelle jeweils in eine Tabelle eines HDF5-Files. Es gibt also eine Tabelle für den "Blinker hinten rechts" und eine andere Tabelle für die Motordaten. Jede dieser HDF5-Tabellen hat dabei eine andere Struktur. HDF5 ist ein sehr flexibles selbst dokumentierendes, standardisiertes, komprimiertes, binäres, plattformunabhägiges Datenformat welches mit zwei Python-Befehlen eine Tabelle in einen numpy Array lesen/schreiben kann [1]. Ein HDF5-File ist aufgebaut wie ein Dateisystem mit Ordnern in denen Tabellen (und beliebige andere Dinge wie z.B. Grafiken) liegen können. Noch dazu kann mit mehr als C-Geschwindigkeit in gigantisch großen Datenbeständen (größer als der verfügbare RAM) aus Python heraus gesucht und gefiltert werden.
HDF5 ist erstmal nicht menschenlesbar - was meiner Meinung nach auch in den seltensten Fällen nötig oder wünschenswert ist. Aber es gibt mit hdf5dump und hdfview [2] plattformunabhängige Werkzeuge um HDF5-Files konfortablel zu betrachten oder in menschenlesbare Form zu bringen. Die Python Charting-Software VEUSZ [3] kann HDF5-Files direkt einlesen und verarbeiten, wie auch alle anderen größeren Charting-Programme Import-Filter für HDF5 anbieten. Ich habe mit Aesir [4] einen QT-Python-HDF5-Viewer programmiert der deutlich schneller als HDFView ist. Auch haben wir Datenklassen für Plone programmiert, um direkt im Browser durch HDF5-Files zu navigieren und deren Tabellen als Web-Tabellen und Charts darzustellen zu können [5]. Das ist der große Vorteil eines gut dokumentierten und standardisierten Datenformats, es ist eine gute Basis um selber darum ein Ökosystem zu entwickeln.
Ich hoffe Du erzählst uns ein bisschen mehr über Dein Projekt, dann können wir Dir sicher bessere Ratschläge geben als JSON, YAML, welche beide mit Numpy nicht so recht zusammengehen.
Beste Grüße
Volker
[1] http://www.pytables.org/ [2] https://support.hdfgroup.org/products/java/hdfview/ [3] http://home.gna.org/veusz/ [4] Noch nicht released. Kann bei Interesse aber gerne das Teil "as is" mal auf github schieben. [5] Erste Prototypen.
--
inqbus Scientific Computing Dr. Volker Jaenisch Richard-Strauss-Straße 1 +49(08861) 690 474 0 86956 Schongau-West http://www.inqbus.de =========================================================
python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
-- Achim Herwig achim.herwig@wodca.de 80997 München, Germany, +49 176 802 393 58
Achim Herwig schrieb am 29.09.2016 um 08:24:
wenn die Daten unterschiedlich sind, kann es auch sinnvoll sein, SQLite als Persistenz-Format einzusetzen. Dann kannst Du Dir bequem für jeden Record-Typen eine eigene Tabelle schreiben und später beim Einlesen die Daten selektieren.
Na ja, wenn es schon eine Datenbank sein soll für den initial beschriebenen Anwendungsfall, Key-Value-Paare zu speichern (und das ist definitiv keine schlechte Idee, war sogar mein erster Gedanke), dann würde ich nicht den SQL-Hammer rausholen, sondern eine der dbm-Datenbanken, die Python seit Urzeiten mitliefert.
https://docs.python.org/3/library/dbm.html
Die machen nämlich genau das: Daten per Schlüssel referenzieren und effizient zugreifbar machen.
Stefan
Servus Achim!
Am 29.09.2016 um 08:24 schrieb Achim Herwig:
wenn die Daten unterschiedlich sind, kann es auch sinnvoll sein, SQLite als Persistenz-Format einzusetzen. Dann kannst Du Dir bequem für jeden Record-Typen eine eigene Tabelle schreiben und später beim Einlesen die Daten selektieren.
Durchaus. Allerdings ist SQLite sowohl von der Performance her als auch von der numpy-Anbindung deutlich schlechter als HDF5.
Beste Grüße
Volker
participants (9)
-
Achim Domma -
Achim Herwig -
Andreas Jung -
Dinu Gherman -
Dr. Volker Jaenisch -
Florian Lindner -
Stefan Behnel -
Stefan Schwarzer -
Sven R. Kunze