Performance <> Grafiken auf Platte oder Datenbank speichern

[semtex]

Hallo Leute,
ich schreibe gerade an einem Programm für meine Flugvorbereitung.

Diesbezüglich habe ich eine Frage...

In diesem Programm sollen auch mehrere Grafiken für das Routing der Flugstrecke und dessen Berechnung hinterlegt werden.
Am Anfang jeder Berechnung werden über Jeppesen viele Charts und diverse Karten per HTTPS übermittelt und "sollen" local in eine Postgresql Datenbank angespeichert werden.
Einige Karten werden bearbeitet/gespeichert und sollen für weitere Aktionen zur Verfügung stehen.

Hier mal die Maße:

Anzahl : max. 1000
Format: PNG
Grösse je max. 150 KB
Maße je : 512*512px


Nun die eigentliche Frage, soll ich diese PNG´s direkt in der DB hinterlegen, sie besser Base64 decodieren, oder auf der Platte speichern und nur den Pfad zur Grafik in der DB speichern.

Danke für die zahlreichen Antworten..

[Kiffi]

soll ich diese PNG´s direkt in der DB hinterlegen, sie besser Base64 decodieren, oder auf der Platte speichern und nur den Pfad zur Grafik in der DB speichern.

Wenn es Dir um die reine Performance geht, letzteres.

Grüße ... Kiffi

[HeX0R]

Es sollte auch noch erwähnt werden, dass Binärdateien in einer PostreSQL-Datenbank doppelt so viel Speicher brauchen, wie sie groß sind.
Das hatte mich damals ziemlich verwundert, als ich damit zu tun hatte, das liegt am bytea Hex Format.
Daher habe ich mich damals für ein zip->base64->TEXT Feld entschieden.

Aber png-Dateien brauchst du eh nicht zippen, das bringt nix.

[semtex]

Danke für eure Antworten !

Ich habe gestern noch ein paar Routinen diesbezüglich geschrieben, aber irgendwie bin ich mit der ganzen Verabeitung der Binären Files noch nicht so ganz glücklich.
Enweder ich habe eine sehr grosse Datenbank, oder Festplatte, von den ewigen Schreib- und Lesezugriffen ganz zu schweigen.
Ich würde ja ab liebsten nur die geänderten Grafiken local speichern und mir die anderen bei Bedarf wieder per HTTPS holen.
Leider geht das nicht immer, das Programm sollte später auch im Cockpit auf meinem Tablet laufen.

[WPö]

Moin, Semtex!

Da noch nicht geschehen, von mir: Willkommen im Forum!

"Semtex" ist aber auch ein recht provokanter Name für einen Piloten. Haste keine Angst, daß der auffliegt?

Die Jeppesen-Karten sind nicht so viele - es gibt ja auch nur eine begrenzte Anzahl internationaler Flufhäfen auf diesem verwässerten Planeten. Die Karten sollten also mit 500MB-700MB Platz erschlagen sein - und den Platz hat doch schon jedes Android-Telefon. Sind die Karten nicht genau genug? Wozu die Änderungen?

Zu Deiner ersten Frage bekräftige ich den Rat, einzelne Dateien im Dateisystem zu behalten. Das ist am schnellsten kopiert, geschrieben, geladen. Am platzsparendsten ist es auch (außer Du willst Dir Arbeit auf den Tisch ziehen und eine transparente Kompression einbauen, die aber bei bereits komprimierten Bildern Humbug ist).

Gruß - WPö

[semtex]

@WPö auch ein "HALLO" an Dich und alle anderen Mitglieder dieser Community...

Mit den von Dir angegebenen 700MB wirst Du leider nicht ganz auskommen !
Der komplette Datensatz der Erde mit den von mir benötigten acht Zoomstufen, beträgt etwa 3 GB.
Es gib auch kleinere Kartensätze, allerdings kann ich mit diesen nichts anfangen, auch aus lizenztechnischen Gründen stehen mir diese nicht zur Verfügung.

Zum Thema bearbeiten der Karten, es sind natürlich alle benötigten Daten wie Airports, Lufträume für IFR/VFR in den Jeppesen Karten verzeichnet.
In meinem Programm soll aber nachtäglich die Flugroute laut Flugplan mit allen Wegpukten auf den Karten verzeichnet werden.
Ich habe aber das ganze Konzept nochmal überdacht, ich speichere nicht die geänderten Karten ab, sondern nur die jeweiligen Wegpunkte und Plotte sie dann über die benötigten Karten.
So das ich im Grunde jetzt keine Karten mehr abspeichern brauche, sondern nur noch die Wegpunkte und dessen Daten.
Ich dachte das es ein guter Ansatz sei die geänderten Karten abzuspeichern, leider war es ein Denckfehler von mir.
Das gleiche wird mit der tatsächlich geflogenen Route passieren, das Programm wird später im Flugprotokoll die GPS Daten mit der im Flugplan angegebenen Route vergleichen und beide Strecken in den Karten anzeigen.
Das ganze Briefing, sowie die Metar, eventuelle NOTAMs und die Charts, werde ich in PDF Dokumenten auslagern, genau so wie das entgültige und fertige Flugprotokoll.

Ich habe leider die nächsten Wochen nicht so viel Zeit für mein Projekt, da wir am Sonntag schon wieder in die USA fliegen und von (KFXE) eine umgebaute Grumman in den Persischen Golf fliegen.

[WPö]

Hallo, semtex!

Laß mich raten: Überführt wird eine Gulfstream II nach Persien, äh in den Iran. Die Gulfstreams sind die einzigen zivilen Flugzeuge von Grumman, die heute noch fliegen (oder ich müßte mich schon sehr täuschen).

Die 3GB an Flugkarten sind mir neu. Ok, mein Stand ist auch von der Jahrtausendwende. Wahrscheinlich hatte ich nur eine abgespeckte Version der Karten. Würdest Du mir eine Kopie der Daten zukommen lassen? Wäre sehr nett von Dir.

Die Routen sind tatsächlich besser separat zu speichern. Damit schnurrt der Speicherplatzverbrauch auf fast Null zusammen. Achte in diesem Fall darauf, geographische kartesische Koordinaten zu verwenden, damit die Daten portabel bleiben.

Guten Flug und denk bloß nicht zuviel an die vor ein paar Jahren verlorene Dakota!

Gruß - WPö