Hi. Ich bastele grade wieder an der Webseite. Ich möchte jetzt einen Bildupload realisieren. Ich könnte die Bilder als BLOB in einer Datenbank speichern - oder ich könnte eine Filebase realisieren und aus der Datenbank nur referenzieren. Bei BLOB wird die Datenbank sehr groß, dafür sind die Bilder gleich da wo sie hingehören. Bei einer Filebase mit Referenzierung liegen die Bildateien einfach so im Filesystem, wobei pro Datenbankeintrag ein eigenes Unterverzeichnis erstellt werden muss. Eine große Datenbank mit BLobs ist aufwändiger zu sichern. Bei der Lösung mit der Filebase ist die zu sichernde Datenbank sehr viel kleiner. Die Filebase selbst muss jedoch parallel mitgesichert werden. Da die Bilder sich jedoch nicht oft ändern, kann man das leicht bewerkstelligen. es müssen nur neue Einträge / geänderte Einträge gesichert werden. Was würdet ihr machen?
Schau dir doch mal an, wie es die gängigen CMS Systeme machen, z.B. Joomla bzw. das Gallerymodul dafür, JoomGallery. Die werden sich schon gut überlegt haben warum sie es so machen, wie sie es tun. Gruß Markus
Nachtrag: Mir ist gerade eingefallen, daß unsere Vereinsseite mit Joomla gemacht ist und habe mal nachgesehen. Die Bilder, die man hochlädt werden als Dateien abgelegt.
Hat auch meist den Grund, weil solange man nicht die volle Kontrolle über den DB Server hat es häufig gewisse Größenlimits für eine DB gibt. Vorteil in der Filelösung ist mmn das man sie nicht aus der DB lesen MUß und sie z.B. auch in einem public Verzeichnis ablegen kann und der Webserver die dann einfach ausliefern kann ohne das immer zwangsweise eine DB Abfrage nötig ist.
Ich würde es größenabhängig machen. Wenn es extrem viele kleine Dateien sind, dann in die DB. Weil viele Dateien im Filesystem sich schlechter schlechter machen als eine große Datenbank. Wenn die Dateien größer sind, dann im Filesystem ablegen. Das hat Vorteile bei der Sicherung weil man nur Dateien sichern braucht die sich geändert haben. Und zu große Datenbanken lassen sich schlechter/langsamer sichern.
Hi. Also die Bilde sind zwischen ein paar KB und ein paar MB groß. Ein Album kann, jenachdem, wie gut man die Vorauswahl trifft, entweder nur ein paar Bilder groß sein, aber auch mal auf 100+ anwachsen, wenn man einfach relatv unsortiert hochläd. Jedes Bild wird vom Webserver automatisch auf 3 verschiedene Auflösungen umskaliert. Thumbnail, LowRes, HighRes. Die Quelldateien sind nicht öffentlich zugänglich. Man könnte jetzt folgenden Weg machen: Thumbnails in der DB und die anderen Bilder direkt im Dateisystem ablegen. Wenn man die großen Bilder auch noch in der DB speichert, würde die wirklich sehr groß werden. Man könnte aber auch alles direkt ablegen, und in der DB nur Links speichern, die dann im IMG Tag an den Browser ausgeliefert werden, Der Browser holt die Bilder dann direkt aus dem Filesystem.
Progger schrieb: > Der Browser holt die Bilder dann direkt aus dem Filesystem. keine gute Idee, damit kannst du nicht sicherstellen wer welches Bild sehen darf. Es darf keinen Direkten zugriff auf die Bilder geben, die Bilder dürfen nur von einem CGI/Perl/PHP script ausgeliefert werden!
Nun, was genau sollen denn die Bilder in der Datenbank? Da haben sie effektiv nichts verloren. Das führt bestenfalls zu riesigen Dumps bzw. Dateiengrößen, die dann (je nach Betriebssystem) schlimmstenfalls mal am Dateisystem scheitern. Nicht unbedingt am Server-Dateisystem, aber du musst ja irgendwie auch mal Backups anlegen. Gezielt komprimieren kannst du garnicht mehr, je nach Datenbank fragmentiert die Sache auch noch. Natürlich gehören die Bilddateien dann nicht in ein öffentliches Verzeichnis -- ich würde sie in jedem Fall noch per Skript ausliefern. Im einfachsten Fall macht das Skript nichts anderes, als die Bilddatei 1:1 abzuliefern (fpassthru() in PHP...), andernfalls hast du volle Kontrolle, kannst ggf. skalieren oder Deeplinks verhindern. Viele kleine Dateien machen einem aktuellen Dateisystem auch kein Problem. Zumindest aktuelle Unix-Dateisystem skalieren ziemlich gut.
Sven P. schrieb: > Viele kleine Dateien machen einem aktuellen Dateisystem auch kein > Problem. Zumindest aktuelle Unix-Dateisystem skalieren ziemlich gut. dann kopiere mal 100.000 Dateien mit 5kbyte oder 1 Datei mit 500Mbyte. Es gibt für beide Lösungen Gründe dafür und dagegen.
Was bei richtig vielen Dateien im Dateisystem hilft se auf Unterverzeichnisse zu verteilen,da wenn zuviele Dateien in einem Verzeichnis sind die Indexzugriffe irgendwann langsamer werden.
Peter II schrieb: > Sven P. schrieb: >> Viele kleine Dateien machen einem aktuellen Dateisystem auch kein >> Problem. Zumindest aktuelle Unix-Dateisystem skalieren ziemlich gut. > > dann kopiere mal 100.000 Dateien mit 5kbyte oder 1 Datei mit 500Mbyte. Ich weiß nicht, bereitet dir das ein Problem? Mir nicht. Ok, wenn man das mit dem Windows-Explorer erledigt, bereitet auch mir das ein Problem. Ich entwickle zur Zeit ein C++-Projekt unter Linux und Windows und synchronisiere den Projektstamm mit einem USB-Stick. Wenn ich die 300 Quelldateien mit dem Explorer (Win7) auf den Stick kopiere, dauert das 15mal länger als wenn ich denselben Projektstamm mit Linux oder MacOS draufkopiere. Chipsatztreiber usw. sind auf Win7 übrigens installiert. Und bevor ich 100.000 Dateien über Netz kopiere, verpacke ich die sinnigerweise in einen Tarball oder sowas. Das spart Overhead.
> Ich weiß nicht, bereitet dir das ein Problem? Mir nicht. Probleme nicht, aber zeit. Selbst rsync wird bei vielen Dateien sehr langsam. > Ok, wenn man das mit dem Windows-Explorer erledigt, bereitet auch mir > das ein Problem. Backup mache ich selten mit dem Explorer aber da sind 10.000 dateien eigentlich kein Problem - man kann auch alles mit strg+A makieren, mann muss nicht jede Datei einzeln anklicken! > Ich entwickle zur Zeit ein C++-Projekt unter Linux und > Windows und synchronisiere den Projektstamm mit einem USB-Stick. du must aber zeit haben. Für sotwas verwendet man eine ein Quellcode verwaltungsystem und checkt sie auf dem jeweiligen System einfach aus - per Netzwerk! > Und bevor ich 100.000 Dateien über Netz kopiere, verpacke ich die > sinnigerweise in einen Tarball oder sowas. Das spart Overhead. ist aber sehr umständlich für eine Sync zwischen 2 Servern, da ist mir rsync doch lieber.
Peter II schrieb: >> Ich weiß nicht, bereitet dir das ein Problem? Mir nicht. > > Probleme nicht, aber zeit. Selbst rsync wird bei vielen Dateien sehr > langsam. Darum vorher einen Tarball daraus machen. Das spart den Overhead für die einzelnen Dateintransfers. >> Ok, wenn man das mit dem Windows-Explorer erledigt, bereitet auch mir >> das ein Problem. > Backup mache ich selten mit dem Explorer aber da sind 10.000 dateien > eigentlich kein Problem - man kann auch alles mit strg+A makieren, mann > muss nicht jede Datei einzeln anklicken! Der Kopiervorgang selbst ist aber immernoch um Faktor 15 langsamer (unter den Unixoiden ist der sync beim Aushängen mitgerechnet!). Ich weiß ja auch nicht, wieso, aber es ist reproduzierbar. >> Ich entwickle zur Zeit ein C++-Projekt unter Linux und >> Windows und synchronisiere den Projektstamm mit einem USB-Stick. > du must aber zeit haben. > Für sotwas verwendet man eine ein Quellcode verwaltungsystem und checkt > sie auf dem jeweiligen System einfach aus - per Netzwerk! Das ist aber vom Arbeitgeber nicht gewünscht. Ja ich weiß, Gottes Wege sind manchmal unergründlich. >> Und bevor ich 100.000 Dateien über Netz kopiere, verpacke ich die >> sinnigerweise in einen Tarball oder sowas. Das spart Overhead. > ist aber sehr umständlich für eine Sync zwischen 2 Servern, da ist mir > rsync doch lieber. In der Regel darf man ja davon ausgehen, dass zwischen zwei Synchronisationen auch nicht alle 100.000 Dateien verändert haben und neu übertragen werden müssen.
Sven P. (haku) schrieb: > Wenn > ich die 300 Quelldateien mit dem Explorer (Win7) auf den Stick kopiere, > dauert das 15mal länger als wenn ich denselben Projektstamm mit Linux > oder MacOS draufkopiere. Schnell und schnell ist aber nicht das gleiche. Mach dir mal den Spass (zur Vergleichbarkeit) und kopiere das komplette Eagle-Verzeichnis v11.0 in ein Unterverzeichnis auf dem USB-Stick (so ein eagle ist schnell installiert). Das sind über 600 Dateien und rund 100 MB. Bei mir dauert das unter Windows mit dem FreeCommander rund 1 Min 12 Sek. (per Hand gestoppt, nicht sehr genau). Dann schließt sich der Kopierdialog und der Stick ist fertig. Dann gerade mal Parted Magic gebootet, die Lw gemountet, zwei Fenster geöffnet, mit der Maus das eagle Verz. auf den Stick gezogen und .. rasend schnell kopiert, d.h. fertig binnen Sekunden .. .. aber nur scheinbar, denn mein USB-Stick zeigt an, dass der noch genüsslich im Kopiervorgang verweilt. Beim Zugriff blinkt der nämlich und erst wenn er in Ruhe ist, geht er über in ein auf- und abschwellendes LED-leuchten. Die Zeit die er unter Parted Magic für den gleichen Kopiervorgang braucht ist rund 1 Minute 13 Sek., also so ziemlich exakt die gleiche Zeit wie unter Windows.
agp schrieb: > Die Zeit die er unter Parted Magic für den gleichen Kopiervorgang > braucht ist rund 1 Minute 13 Sek., also so ziemlich exakt die gleiche > Zeit wie unter Windows. Deshalb schrieb ich explizit dazu, dass ich z.B. bei Linux die Zeit mit einrechne, die nach dem umount noch verstreicht. Eben genau das, was du da beschreibst. Und genau darum verwundert mich die Sache ja umso mehr.
Sven P. schrieb: > agp schrieb: >> Die Zeit die er unter Parted Magic für den gleichen Kopiervorgang >> braucht ist rund 1 Minute 13 Sek., also so ziemlich exakt die gleiche >> Zeit wie unter Windows. > Deshalb schrieb ich explizit dazu, dass ich z.B. bei Linux die Zeit mit > einrechne, die nach dem umount noch verstreicht. Eben genau das, was du > da beschreibst. > Und genau darum verwundert mich die Sache ja umso mehr. So wieder zurück in W7. Kannst ja mal probieren wieviel Zeit es bei dir braucht das komplette eagle 5.11 Verz. (sind bei mir 676 Dateien) auf den Stick zu schieben, dann können wir vergleichen. ;) eagle ist schnell installiert/deinstalliert.
Sag ich dir übermorgen, dann bin ich wieder im Betrieb. Hier zu Hause kommt mir kein Windows auf die Platte :-) Für die Eagle-Linux-Installation: Kopieren dauert 1:29 auf mein Handy über USB2.0, löschen dauert 3 Sekunden. Interessanterweise dauert das Löschen unter Windows knapp solange, wie das Kopieren. Also löschen, so mit Umschalttaste, nicht in den Papierkorb schieben!
Sven P. (haku) schrieb: > Für die Eagle-Linux-Installation: > Kopieren dauert 1:29 auf mein Handy über USB2.0, löschen dauert 3 > Sekunden. Interessanterweise dauert das Löschen unter Windows knapp > solange, wie das Kopieren. Also löschen, so mit Umschalttaste, nicht > in den Papierkorb schieben! Ich hatte Interesse halber nochmal Parted Magic gebootet. Der Löschvorgang (wieder den Stick beobachtet + Stoppuhr) vom eagle-Verzeichnis geht mit rund 10 Sekunden unter Linux sehr schnell. Unter Windows 7 dauert der gleiche Vorgang (im reinen Explorer, gleiche Zeit im Freecommander) rund 22 Sekunden (Umschalttaste gedrückt, also ebenfalls komplett gelöscht) und damit deutlich länger. Geht aber noch wie ich finde. Mit abgeschaltetem AntiVir ist er beim kopieren noch ein paar Sekunden schneller, aber im Prinzip kaum der Rede wert.
Man kann nicht direkt linux mit Windows vergleichen. Bei Windows ist der cache für USB-Sticks abgeschaltet - damit man ihn einfach so abziehen kann. Das wirkt sich natürlich negitiv auf die Leistungs aus. Bei Linux ist der Cache meines wissens immer eingeschaltet und man muss ein umout machen.
Peter II schrieb: > Progger schrieb: >> Der Browser holt die Bilder dann direkt aus dem Filesystem. > keine gute Idee, damit kannst du nicht sicherstellen wer welches Bild > sehen darf. > Es darf keinen Direkten zugriff auf die Bilder geben, die Bilder dürfen > nur von einem CGI/Perl/PHP script ausgeliefert werden! Quasi alle Webserver unterstützten Zugriffsrechte. In der Regel über eine .htaccess-Datei. Die kann man auch automatisch generieren. Plus, bei der typischen Qualität der CGI/Perl/PHP Programmierer, kann es passieren, dass der Nutzer das Skript dazu bringen kann, andere Dateien, aus anderen Verzeichnissen auszuliefern.
Christian Berger schrieb: > Quasi alle Webserver unterstützten Zugriffsrechte. In der Regel über > eine .htaccess-Datei. Die kann man auch automatisch generieren. wie soll das denn sinnvoll gehen wenn die benutzer in einer DB stehen? Die meisten Portale nutzen eine interne Anmeldung, damit weiss der Webserver überhaupt nicht welcher Benutzer eingeloggt ist. Dann braucht der Webserver ja auch noch schreibrechte auf die .htaccess Datei - also ich habe noch nie eine solche lösung in der Praxis gesehen und finde sie auch unsinnig. > Plus, bei der typischen Qualität der CGI/Perl/PHP Programmierer, kann es > passieren, dass der Nutzer das Skript dazu bringen kann, andere Dateien, > aus anderen Verzeichnissen auszuliefern. kann eigentlich überhaupt nicht passieren wenn dem script nur eine ID übergeben wird und der Rest aus dem DB kommt. (klar könnte jetzt noch jemand die DB manipulieren aber dann ist es eh zu spät)
Peter II (Gast) schrieb: > Man kann nicht direkt linux mit Windows vergleichen. Bei Windows ist der > cache für USB-Sticks abgeschaltet - damit man ihn einfach so abziehen > kann. Das wirkt sich natürlich negitiv auf die Leistungs aus. Bei Linux > ist der Cache meines wissens immer eingeschaltet und man muss ein umout > machen. Der einzige Unterschied der sich bei mir gezeigt hat ist dass der Kopiervorgang unter Linux dem Anwender sehr viel schneller als beendet suggeriert wird. Trotzdem verbringt Linux ungefähr die gleiche Zeit (wie unter W7) um die Daten aus dem Cache auf den Stick zu schreiben. Das Leeren des Caches wird auch ohne umount sofort ausgelöst (mit einem direkten umount nach dem kopieren muss er halt warten bis der Cache geleert ist, bevor das System den Stick ausbindet).
Kleiner Nachtrag, der Stick ist bei mir default für schnelles Entfernen in der Entfernungsrichtlinie eingestellt. Man kann auch auf "Bessere Leistung" stellen, was dann den Schreibcache unter Windows 7 aktiviert. Habe ich aber nicht gemacht.
Peter II schrieb: > Man kann nicht direkt linux mit Windows vergleichen. Bei Windows ist der > cache für USB-Sticks abgeschaltet - damit man ihn einfach so abziehen > kann. Das wirkt sich natürlich negitiv auf die Leistungs aus. Bei Linux > ist der Cache meines wissens immer eingeschaltet und man muss ein umout > machen. Ich wiederhole es für dich gerne ein drittes Mal: Unter Linux habe ich die Zeit für den sync beim umount mit eingerechnet.
Peter II schrieb: > Christian Berger schrieb: >> Quasi alle Webserver unterstützten Zugriffsrechte. In der Regel über >> eine .htaccess-Datei. Die kann man auch automatisch generieren. > wie soll das denn sinnvoll gehen wenn die benutzer in einer DB stehen? > Die meisten Portale nutzen eine interne Anmeldung, damit weiss der > Webserver überhaupt nicht welcher Benutzer eingeloggt ist. Dann braucht > der Webserver ja auch noch schreibrechte auf die .htaccess Datei - also > ich habe noch nie eine solche lösung in der Praxis gesehen und finde sie > auch unsinnig. Dann hast du bisher aber gut weggeschaut. Für den Apache gibt es auch Authentifizierungs-Module, die ihren Kontenbestand in einer Datenbank ablegen. >> Plus, bei der typischen Qualität der CGI/Perl/PHP Programmierer, kann es >> passieren, dass der Nutzer das Skript dazu bringen kann, andere Dateien, >> aus anderen Verzeichnissen auszuliefern. > kann eigentlich überhaupt nicht passieren wenn dem script nur eine ID > übergeben wird und der Rest aus dem DB kommt. (klar könnte jetzt noch > jemand die DB manipulieren aber dann ist es eh zu spät) Ja, kann überhaupt nicht passieren. Wenn hätte könnte -- schau dich doch mal um nach SQL-Injection, etwa bei großen PHP-Projekten...
So, ich habs jetzt mit Filebase gemacht. Für die Bildbeschreibung usw habe ich eine XML Datei genommen. Ich liefere das Bild via PHP aus, um Deep Linking zu unterbinden. Ein Direktzugriff auf das passwortgeschützte Verzeihnis ist auch möglich. Der Verzeichnispfad ist im Script fest einprogrammiert. Es wird nur die Bildnummer akzeptiert, die auf den Dateinamen umgesetzt wird. So dass das ausliefern von nicht vorgesehenen Dateien unmöglich sein sollte.
Sven P. schrieb: >> Man kann nicht direkt linux mit Windows vergleichen. Bei Windows ist der >> cache für USB-Sticks abgeschaltet - damit man ihn einfach so abziehen >> kann. Das wirkt sich natürlich negitiv auf die Leistungs aus. Bei Linux >> ist der Cache meines wissens immer eingeschaltet und man muss ein umout >> machen. > Ich wiederhole es für dich gerne ein drittes Mal: Unter Linux habe ich > die Zeit für den sync beim umount mit eingerechnet. Du kannst es auch noch ein 4.Mal wiederholen aber das ändert an den Tatsachen nichts. Wenn der Cache abgeschaltet ist, dann erfolgt jeder Zugriff auf die FAT (ich gehe jetzt mal davon aus das auf dem USB-Stick ein FAT-System ist) einzeln. Weil der Zugriff immer Blockweise erfolgt wird der gleiche Block mehrfach angefasst. Durch einen Cache wird am ende nur einmal dieser BLock weggeschrieben. In diesem Fall sind also mit Cache weniger zugriffe notwendig. Sven P. schrieb: >>> Plus, bei der typischen Qualität der CGI/Perl/PHP Programmierer, kann es > >>> passieren, dass der Nutzer das Skript dazu bringen kann, andere Dateien, > >>> aus anderen Verzeichnissen auszuliefern. > >> kann eigentlich überhaupt nicht passieren wenn dem script nur eine ID > >> übergeben wird und der Rest aus dem DB kommt. (klar könnte jetzt noch > >> jemand die DB manipulieren aber dann ist es eh zu spät) > Ja, kann überhaupt nicht passieren. Wenn hätte könnte -- schau dich doch > mal um nach SQL-Injection, etwa bei großen PHP-Projekten... wer es bis heute noch nicht Begriffen hat wie Prepeared Statemens funktionieren dem ist eh nicht mehr zu helfen.
Ok, dann spielst du darauf an, dass der Schreibvorgang ins Flash des USB-Stick nur Blockweise geht, ja? Falls dem so ist, kann man Windows irgendwie dazu überreden, zu cachen? Und ja, es haben noch ziemlich viele nicht begriffen, dass es Prepared Statements gibt. Das schließt blöderweise die meisten PHP-Projekte mit nennenswerter Verbreitung mit ein...
Sven P. schrieb: > Ok, dann spielst du darauf an, dass der Schreibvorgang ins Flash des > USB-Stick nur Blockweise geht, ja? ja, Dabei gibt es auch noch 2 Blöcke einmal die vom Flash und dann das kleinste was das BS adressieren kann (meist 512byte). > Falls dem so ist, kann man Windows irgendwie dazu überreden, zu cachen? ich hatte es mal getestet, in den eigenschaften vom Datenträger kann man einstellen das es für hohe Leistung optimiert werden soll, nicht für das schnelle entfernen. Merkwürdigerweise hatte das bei mir keine Auswirkung auf die Geschwindigkeit. Hatte jetzt nicht weiter gesucht ob es noch irgenwo anders eine Einstellung dafür gibt. Das es aber nicht am Explorer oder generell Windows liegt kann man sehr einfach rausfinden. Wenn ich den EAGLE ordner auf der Festplatte kopiere dauert es nur 3 Sekunden, beim stick aber über 7minuten.
Sven P. (haku) schrieb: > Falls dem so ist, kann man Windows irgendwie dazu überreden, zu cachen? lies Beitrag "Re: BLOB oder Filebase?" lässt sich im Geräte-Manager umstellen (Laufwerke / Richtlinien). Dann muss der Stick allerdings immer manuell ausgebunden werden bevor man ihn herauszieht.
Peter II (Gast) achrieb: > Das es aber nicht am Explorer oder generell Windows liegt kann man sehr > einfach rausfinden. Wenn ich den EAGLE ordner auf der Festplatte kopiere > dauert es nur 3 Sekunden, beim stick aber über 7minuten. Komischer Vergleich. Also ein USB 2.0-Stick ist nun mal keine schnelle SATA-II Festplatte. Außerdem ist der Festplattencache grundsätzlich aktiviert.
agp schrieb: > Komischer Vergleich. Also ein USB 2.0-Stick ist nun mal keine schnelle > SATA-II Festplatte. Außerdem ist der Festplattencache grundsätzlich USB-Sticks können auch 10mbyte/s schreiben, Festplatten 150mbyte/s. Die zugriffszeit bei stick ist sogar besser der von festplatten. Damit lässt sich ein unterschied von 1:140 nicht erklären.
Peter II (Gast) schrieb: > USB-Sticks können auch 10mbyte/s schreiben, Festplatten 150mbyte/s. Deswegen sind Festplatten auch deutlic schneller. > Die > zugriffszeit bei stick ist sogar besser der von festplatten. Welche Zugriffszeizen denn? Für welchen Zugriff? Für welche Filegröße? > Damit lässt sich ein unterschied von 1:140 nicht erklären. Der existiert doch auch gar nicht, wenn man mal genau hinschaut. Linux schreibt genau so schnell Daten auf einen USB 2.0 FAT-32 Stick wie Windows. Da gibt es keinen Unterschied.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.