Ankündigung

Einklappen
Keine Ankündigung bisher.

Bilder speichern - Filesystem vs. Datenbank

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Bilder speichern - Filesystem vs. Datenbank

    Hallo,

    wie in der Überschrift bereits steht wollte ich eure Erfahrungen zum Thema "Bilder speichern - Filesystem vs. Datenbank".

    Arbeite an einem etwas größerem Projekt wo künftig großes Aufkommen an Bildern erwartet wird.

    Habe einige Bekannte die für Konzerne interne Portale in ASP.NET Webforms programmieren. Bei größeren Datenaufkommen neigen die eher dazu die Dateien wie PDFs in der Datenbank als BLOBs zu speichern. Vorteil - alles ist in der DB und somit an einer Stelle gespeichert, Datenintegrität ist immer gegeben. Nachteil von der Geschichte - megagroße DBs die besondere Vorgehensweise bei den Backups erfordern. Eine Datenbank mit vielen Gigabytes ist nicht mal eben abgespeichert und wiederhergestellt.

    Selber habe ich ebenfalls interne Portale entwickelt. Habe die Dateien im Filesystem abgespeichert. Vorteil - DBs sind nach Jahren schön klein, liegen im Megabyte-Bereich. Performant, relativ schnell wiederhergestellt bzw. transferiert. Filesystem liegt aber auch schon im Gigabyte-Bereich. Nachteil ist die Datenintegrität - Datenbank kann mit dem Filesystem auseinander laufen. Das hatte ich bisher noch nicht, denkbar wäre es aber schon.

    Vom BLOB-en habe ich persönlich bischer nicht viel gehalten. Doch wenn ich das Datenaufkommen von den anderen ansehe - die reden nicht mehr von SQL-Requests sondern von der Daten-Pipeline, also vom massiven Datenstrom. Es muss ja auch irgendwie gehen dort große Menge an Daten durzuschieben.

    Benötige möglichst performante Lösung um Kunden-Dateien hauptsächlich Bilder mit PHP und Apache2 (ev. NGINX) bereitzustellen. Kunden-Dateien (hauptsächlich Bilder) sind nicht geschäftsrelevant. Der Verlust der Dateien würde keine rechtlichen Probleme auslösen, des Datenbankinhalts schon.

    Hat jemand Erfahrung in dieser Richtung? Welche Lösung würdet Ihr vorschlagen.

  • #2
    Ich würde die Bilder an deiner Stelle getrennt von der Datenbank speichern und nur die Referenz auf die Bilder in der Datenbank speichern. Außer deine Datenbank unterstützt ausdrücklich das Speichern von Dateien, wie z.B. bei MongoDB mit GridFS. (GridFS — MongoDB Manual)

    Was am Anfang ggf. noch leicht zu bewerkstelligen ist in der Datenbank, wird spätestens dann zum Problem wenn die Datenbank größer wird, wie der Speicherplatz deines Servers. Dann wirst du nämlich eine Lösung brauchen mit Sharding zu arbeiten, was nicht ganz trival ist, gerade im MySQL Bereich..

    Kommentar


    • #3
      Kommt halt drauf an … ich speichere in nem Projekt die Bilder in verschiedenen Auflösungen, da die als srcset ausgegeben werden, von wegen Seitenaufbau, Ladezeiten etc. auch Site Ranking, da tu ich mir leichter die im Filesystem entsprechend abzulegen.

      Kommentar


      • #4
        Bei Dateisystem beachten, dass ein Ordnerzugriff im Bereich von 10000 Dateien langsam wird. Bei Datenbanken sind andere Aspekte zu beachten (Index, ...)

        Kommentar


        • #5
          Zitat von Porth
          Bei Dateisystem beachten, dass ein Ordnerzugriff im Bereich von 10000 Dateien langsam wird.
          Wenn man mit Caching arbeitet, dauert es nur einmal etwas länger. Und btw... ich kenne kein Onlineshopsystem, bei dem das nicht auf Verzeichnisebene passiert und die haben damit i.d.R. kein Zeitproblem.
          Competence-Center -> Enjoy the Informatrix
          PHProcks!Einsteiger freundliche TutorialsPreComposed Packages

          Kommentar


          • #6
            Zitat von Porthd Beitrag anzeigen
            Bei Dateisystem beachten, dass ein Ordnerzugriff im Bereich von 10000 Dateien langsam wird. Bei Datenbanken sind andere Aspekte zu beachten (Index, ...)
            echt ?
            gibt es da einen artikel drüber ?
            zu wo bilder speichern haben wir afaik einen (?) anderen thread.

            Kommentar


            • #7
              Zitat von tomBuilder Beitrag anzeigen

              echt ?
              gibt es da einen artikel drüber ?
              zu wo bilder speichern haben wir afaik einen (?) anderen thread.
              Die genaue Grenze kenne ich auch nicht, aber habe mal ein Server gehabt, welcher aufgrund eines Fehler im Script Cache Ordner von 0000-ZZZZ in jeder Kombination angelegt hat. (Also von 0 - Z, 00-ZZ, 000-ZZZ,0000-ZZZZ)
              Ein ls Aufruf in diesem Ordner hat die SSH Verbindung zum Absturz gebracht und ein Auflisten aller Dateien in einer Text-Datei hat eine 60-80 GB große Text Datei erzeugt.

              Die Dateien in den Ordner waren alle aufrufbar, aber sogar das Löschen dieses Ordners war mit einem einfachen rm nicht mehr möglich.
              Aber ob das jetzt eine "Grenze" des Dateisystems ist oder eher die standard Tools an Ihre Grenzen stoßen, vermag ich nicht zu sagen.

              Kommentar


              • #8
                Du machst ja sachen Zeichen32 ^^

                bist du sicher dass SSH tot war, oder hat das nur gerödelt wie wild .....

                wenn du an der grenze bist, wird keine datei mehr angelegt, auf dem ganzen fs.
                die grenzen sind allerdings bei unix schon immer recht hoch.
                doch irgendwann steigt allerdings auch der kernel aus .

                welches fs wie getuned man verwendet, das mag der verantwortliche entscheiden und was genau die neuen clusterfs können, ich hab keine ahnung.
                10k sollten keien grenze sein, könnte sein, dass in einer normalen installation von *nix, mehr dateien auf / liegen.

                Kommentar


                • #9
                  Hier mal einige Tipps:
                  • Speichere die BLOBs der Dateien nicht in einer Datenbank - egal welche DB das ist, selbst mit dem MSSQL FILESTREAM (https://docs.microsoft.com/en-us/sql...l-server-ver15) würde ich das nicht machen
                  • Lege die Dateien im Dateisystem ab und speichere dir zu den Dateien die wichtigsten Attribute in der Datenbank (Größe, Datum, Original-Name, Original-Erweiterung, Mimetype)
                  • Dateien nicht mit Original-Namen im Dateisystem abspeichern - indexiere sie lieber anhand der Datenbank-ID durch und vereinheitliche die Dateierweiterung, speichere den Original-Dateinamen in der Datenbank ab (z.B. aus MeinUrlaub.jpg wird 001.dat) - das verhindert Duplikate und Sonderzeichenprobleme im Dateisystem
                  • Lege am besten gleich mehrere Ebenen indexierter Unterverzeichnisse für die Dateien an, um zu viele Dateien auf einer Ebene zu verhindern (z.B. statt files/1.dat - files/10000000.dat nutze files/000/000/000/000/001.dat - files/999/999/999/999/999.dat, das lässt sich mit einem chunk_split, str_pad und mkdir_recursive sehr elegant lösen) - achte aber darauf, dass du so die Menge an speicherbaren Dateien nicht unnötig limitierst
                  • Einen (Keyed-)Hash der Datei gleich mit zu speichern, kann sinnvoll sein, wenn man Deduplizierung und oder Integritätsprüfung umsetzen will (z.B. das jemand nicht an den Dateien unbemerkt rumfummelt, ohne die Datenbank-Daten anzupassen oder eine Datei doppelt und dreifach hochgeladen wird)
                  • Falls du die Dateien im Dateisystem vor dem Speichern verschlüsseln willst, empfehle ich das PHP StreamInterface mit entweder Xchacha20 oder AES-GCM Verschlüsselung zusammen mit Sodium - teste aber bestenfalls auch die Kompatibilität mit anderen Programmiersprachen (z.B mit PHP verschlüsseln, mit Java wieder entschlüsseln), PHP ist da manchmal etwas eigen

                  Eine DB-Struktur könnte so aussehen:

                  = file_blobs =
                  id
                  relative_store_path
                  size
                  mimetype
                  hash

                  = files =
                  id
                  blob_id
                  original_name
                  original_ext
                  modified_date


                  Bei verschlüsselten Dateien müsstest du noch eine Schippe mehr draufpacken
                  Tutorials zum Thema Technik:
                  https://pilabor.com
                  https://www.fynder.de

                  Kommentar


                  • #10
                    Zitat von Zeichen32 Beitrag anzeigen

                    Die genaue Grenze kenne ich auch nicht, aber habe mal ein Server gehabt, welcher aufgrund eines Fehler im Script Cache Ordner von 0000-ZZZZ in jeder Kombination angelegt hat. (Also von 0 - Z, 00-ZZ, 000-ZZZ,0000-ZZZZ)
                    Ein ls Aufruf in diesem Ordner hat die SSH Verbindung zum Absturz gebracht und ein Auflisten aller Dateien in einer Text-Datei hat eine 60-80 GB große Text Datei erzeugt.

                    Die Dateien in den Ordner waren alle aufrufbar, aber sogar das Löschen dieses Ordners war mit einem einfachen rm nicht mehr möglich.
                    Aber ob das jetzt eine "Grenze" des Dateisystems ist oder eher die standard Tools an Ihre Grenzen stoßen, vermag ich nicht zu sagen.
                    EXT4 hat eine Begrenzung bei ca 64.000 Dateien. Da kommt du mit deinen 0-ZZZZ wahrscheinlich hin. Du kannst mehr Dateien oder Ordner in einen Ordner reinpacken. Dann kommt es aber eben dazu dass, du mit Filesystem ins Schleudern kommst. Dann kannst du auch mit SSH nichts mehr anrichten. Habe spaß halber auch schon getestet mit PHP-Script 100.000 Ordner auf EXT4 zu erstellen. Dann hatte ich auch ähnliche Effekte.

                    Kommentar


                    • #11
                      Mal eine andere Frage - Ebay hat einen Server für Image-Dateien ebayimg.com. Dort werden sämtliche Bilder gespeichert. Hat jemand Erfahrung mit solchen File-Servern?

                      Ich könnte mir vorstellen dass, man so etwas mit FTP macht und dann einfach aus DB-Einträgen verlinkt. Nur was macht man mit Datenmüll - Dateien deren Einträge in der DB nicht mehr existieren? Da müsste man eine Routine aufbauen die rückwärts testet. Wenn in den verschachtelten Ordnern Zehntausende Dateien liegen kann man kaum effizient das ganze periodisch rückwärts durchsuchen.

                      Hat jemand Erfahrung mit so etwas?

                      Kommentar


                      • #12
                        Also FTP ist ein prähistorisches Relikt, das heutzutage praktisch niemand mehr ernsthaft produktiv einsetzt. FTP hat so viele Nachteile und Unzulänglichkeiten, da weiß man gar nicht, wo man anfangen soll.

                        Um viele Dokumente zu speichern werden heutzutage Dokumentendatenbanken oder ein BLOB-Storage eingesetzt.

                        Kommentar


                        • #13
                          Zitat von hruendel Beitrag anzeigen

                          EXT4 hat eine Begrenzung bei ca 64.000 Dateien. Da kommt du mit deinen 0-ZZZZ wahrscheinlich hin. Du kannst mehr Dateien oder Ordner in einen Ordner reinpacken. Dann kommt es aber eben dazu dass, du mit Filesystem ins Schleudern kommst. Dann kannst du auch mit SSH nichts mehr anrichten. Habe spaß halber auch schon getestet mit PHP-Script 100.000 Ordner auf EXT4 zu erstellen. Dann hatte ich auch ähnliche Effekte.
                          wo steht das biite ?
                          ext4 hat eine begrenzung von 64 k unterverzeicnissen - was etwas anderes ist.

                          Kommentar


                          • #14
                            Zitat von hellbringer Beitrag anzeigen

                            Um viele Dokumente zu speichern werden heutzutage Dokumentendatenbanken oder ein BLOB-Storage eingesetzt.
                            da bin ich echt überfragt.

                            google.com/intl/de/photos/

                            dürfte wohl die state of the art lösung nutzen.
                            ob da irgendwelche limits von irgendwelchen uns bekannte technologien zum speichern gesprengt werden und welche tecdchnologie dahintersteckt konnte ich auf die schnelle nicht rausfinden.

                            Kommentar


                            • #15
                              Dafür hab ich immer ein Uploadverzeichnis wie "/2021/12/23/" + $filename verwendet, damit die Verzeichnisse nicht zu umfangreich werden. Diese Struktur erlaubt es auch z.B: per rsync Dateien einfach anhand eines Zeitbereichs zu synchronisieren oder bestimmte Jahrgänge auf einen anderen günstigeren Server zu verschieben. In der Datenbank einfach die komplette Url zur Datei speichern, dann ist es auch egal wo die liegen.

                              Kommentar

                              Lädt...
                              X