BLOB oder Filebase?

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.

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.

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.