>>>>>>>
Bei Daten wie Bilder oder Isofiles schreibt nur einen Link in die DB und nicht das ganze File.
<<<<<<<

dann habe ich zumindest schon wieder zwei dinge zu sichern und zu verwalten
die DB
die files im filesystem

und bei jeder änderung -
neue festplatte mit anderem buchstaben
vielleicht andere maschine (win <--> lin ) aus "C:\eigene dateien\bilder" wird "/home/ich/bilder"

fängt das aktualisieren der links an

und genau das alles will ich ja vermeiden

>>>>>>>
Die MySql Datenbank wird ja sonst irre langsam.
<<<<<<<

was genau soll daran langsam werden ???

meine 'longblobs' liegen in einer eigenen table - und ob dort hineingegriffen wird entscheidet der benutzer
wenn er das bild mit 50 MB sehen und daher übers netz ziehen will, ja dann wirds ein wenig dauern,
aber ich sehe keinen unterschied, wenn das bild im filesystem des betriebssystems liegt ???

fritz
(-:fs)

lösung
 

A.2.8 Packet too large Error

When a MySQL client or the mysqld server gets a packet bigger than max_allowed_packet bytes, it issues a Packet too large error and closes the connection.

In MySQL 3.23 the biggest possible packet is 16M (due to limits in the client/server protocol). In MySQL 4.0.1 and up, this is only limited by the amount on memory you have on your server (up to a theoretical maximum of 2G).


vielleicht brauchts jemand ...


fritz
(-:fs)

@erdling

Ab ~ 2GB Inhalt wird MySql langsam.
Nicht das Downloaden eines z.B Bildes sondern die Abfrage und Suche.

Wenn du die Bilder im DokumentRoot von dem Webserver ablegst, bleibt der Pfad immer gleich, auch auf anderen Maschinen und Platten.

Mit einem Cron läßt sich das alles leicht sichern
cp /pfad/zu/denTabellen/* /backup/
cp /pfad/dokument/root/* /buckup/

Das Einzige das du beim übersiedeln anpassen mußt ist die IP in deinen Scripten oder der Domainname.

Sloter

jez wirds dechnisch - subbba
 

>>>>>>>>>>
Ab ~ 2GB Inhalt wird MySql langsam.
Nicht das Downloaden eines z.B Bildes sondern die Abfrage und Suche.
<<<<<<<<<<

ich glaub das kann man nicht so einfach sagen
wenn du von einer 'normalen' satzgröße ausgehst, wirds vielleicht schon tables mit 1 million records geben

da hat jede DB irgendwo eine grenze wo sie in die knie geht

extrembeispiel -
wenn ich 100 CD speichere dann sind das 6 GB
aber ich kann mir nicht vorstellen, daß die suche nach dem namen (indiziert natürlich) in hundert sätzen lange dauert

also die absolute DB größe ist _nicht alleine_ ausschlaggebend

------------------------------------

<<<<<<<<<<<<<
Wenn du die Bilder im DokumentRoot von dem Webserver ablegst, bleibt der Pfad immer gleich, auch auf anderen Maschinen und Platten.
>>>>>>>>>>>>>

das hab ich glaube ich nicht verstanden

wenn ich hart (absolut) einen pfad eintrage scheiterts doch schon an den 'verkehrten' strichen zwischen windows und unix maschinen ('\' != '/')

-------------------------------------

>>>>>>>>>>>>>
Das Einzige das du beim übersiedeln anpassen mußt ist die IP in deinen Scripten oder der Domainname.
<<<<<<<<<<<<<

das ist genau _eine_ stelle, dort wo der connect zur DB aufgebaut wird
wenn ich dort statt rechner_A den rechner_XY eintrage läuft das ganze auf einer anderen DB (aber dem selben webserver)

dort könnte ich auch 10 datenbanken connecten und 'round robin' cursor an die speicherlogik ausgeben, damit in 10 DBs eingetragen wird (die suche wird dann ETWAS erschwert - also ein konzept, welche DB was speichert braucht man schon) aber das ganze ist hoch skalierbar (bin ich jetzt bei 20 GB kritische mysql masse ???)


uff - genug getippt

fritz
(-:fs)

Re: jez wirds dechnisch - subbba
 

<ich glaub das kann man nicht so einfach sagen
<wenn du von einer 'normalen' satzgröße ausgehst, wirds vielleicht <schon tables mit 1 million records geben
Es ist auch nicht die Anzahl der Einträge ausschlaggebend sondern die Größe.

<da hat jede DB irgendwo eine grenze wo sie in die knie geht
Sicher, aber MySql geht lange vor Oracle & Co die Luft aus.

<wenn ich 100 CD speichere dann sind das 6 GB
<aber ich kann mir nicht vorstellen, daß die suche nach dem namen <
<(indiziert natürlich) in hundert sätzen lange dauert
Doch weil die gesammt Dateigröße zu groß für MySql wird.

<also die absolute DB größe ist _nicht alleine_ ausschlaggebend
Eh net, aber wenn sie zu Groß wird dann schon :D


<wenn ich hart (absolut) einen pfad eintrage scheiterts doch schon an <den 'verkehrten' strichen zwischen windows und unix maschinen ('\' !<= '/')
Nö nö, unser Freund Apache, kann einiges ausbügeln in der Url.


<skalierbar (bin ich jetzt bei 20 GB kritische mysql masse ???)
Auf wie viele DB und Server verteilt? Wenn du nur Links hättest, würdest wahrscheinlich mit einer DB auskommen die schlank und rank ist und einem fetten Fileserver :D


Sloter

nächste runde - gong ;;;-)))
 

>>>>>>>>>>>>>>>>
<also die absolute DB größe ist _nicht alleine_ ausschlaggebend
Eh net, aber wenn sie zu Groß wird dann schon
<<<<<<<<<<<<<<<<

hmmm, ein index sollte eigentlich ein eigenes file sein und daher von der größe der 'wirklichen' daten unabhängig - aber ich weiß nicht wirklich wie mysql das macht
das zweite ist der tatsächliche zugriff und da können große files schon probleme verursachen (swappen, ...)

da du offenbar mit dem ding schon längere praxis hast (od'r ?) -
kannst du - nur ungefähr - den zeitunterschied einer suche schätzen
bleiben wir bei dem beispiel mit 100 x CD = 60 GB:

einmal mit den daten in der DB
einmal mit den daten auf einem fileserver und nur link gespeichert

???

---------------------------------------

>>>>>>>>>>>>>
<wenn ich hart (absolut) einen pfad eintrage scheiterts doch schon an <den 'verkehrten' strichen zwischen windows und unix maschinen ('\' !<= '/')
Nö nö, unser Freund Apache, kann einiges ausbügeln in der Url.
<<<<<<<<<<<<

der _mir_ unbekannte indianer freund mag das schon können

mein mir mehr bekannter zope-freund ist ganz anders aufgebaut

da gibts kein herumstochern in verzeichnissen des betriebssystems -
sämtliche webobjekte liegen in einer internen objekt datenbank, welche sich im admin-fenster natülich auch als verzeichnisstruktur darstellt

und da die liebe zu diesem zope-freund noch einigermaßen jung ist habe ich zu der eingebauten objedatenbank wenig vertrauen und bin in eine SQL DB 'hinausgegangen'

====================================

grundsätzliches -

wenn du sagst apache gleicht das aus,
dann heißt das, daß die oberfläche ( = GUI = oberste schicht) einer 3-tier anwendung sich um _semantische_ dinge in der datenbank ( = unterste, dritte schicht) kümmert

das halte ich für sehr schlechtes design

da sind weder die drei schichten unabhängig voneinander -
noch ärger - eine ganze schicht ( = mittelschickt = business logic) wird übersprungen

das gefällt mir gar nicht gut - schlanke DB hin und fileserver her

--------------------

vielleicht hab ichs auch falsch verstanden, da ich den apachen nicht kenne

aber meine anforderung IST:

wenn es mir morgen einfällt eine andere als die WEB-oberfläche zu programmieren (vielleicht in java) dann habe ich mit der MITTELSCHICHT folgende kommunikation
1.) objekt lesen
2.) objekt speichern
3.) objekt suchen

wenn ich mich um mehr kümmern muß - vielleicht die art der speicherung der links auf dateien in der datenbank ('\' <---> '/') - dann habe ich was falsch gemacht (-O


fritz
(-:fs)

Re: nächste runde - gong ;;;-)))
 

<das zweite ist der tatsächliche zugriff und da können große files <schon probleme verursachen (swappen, ...)
Klar doch, sogar schon beim sortieren oder beim Überspielen wie du siehst
<da du offenbar mit dem ding schon längere praxis hast (od'r ?) -
Man tut was man(n) kann :rolleyes: . Wie lange machst du schon mit DB`s rum?

<kannst du - nur ungefähr - den zeitunterschied einer suche schätzen
<bleiben wir bei dem beispiel mit 100 x CD = 60 GB:
Leichte Milchmädchenrechnung.
Meine 100 CD Links mit Titel,Interpreter und kleine Geschichte sind keine 2 MB
Die wird er doch schneller als deine 60 GB durchackern?


<der _mir_ unbekannte indianer freund mag das schon können
mod_speling ist der unbekannte dritte oder auch der Neffe mod_rewrite mit seinem Bruder mod_alis :D

<mein mir mehr bekannter zope-freund ist ganz anders aufgebaut
Steuerst du Zope über Apache oder eigenständig?

<da gibts kein herumstochern in verzeichnissen des betriebssystems -
Nö die gucken nur in der DokumentRoot nach. Kann aber auch auf wunsch ausserhalb stattfinden.
Je nach belieben :tux:

<sämtliche webobjekte liegen in einer internen objekt datenbank, <welche sich im admin-fenster natülich auch als verzeichnisstruktur <darstellt
Muß ja quälend langsam sein das Ding......


<dann heißt das, daß die oberfläche ( = GUI = oberste schicht) einer <3-tier anwendung sich um _semantische_ dinge in der datenbank ( = <unterste, dritte schicht) kümmert
Der Apache bastelt sich nur eine richtige Url zusammen, da wird nicht direkt in der DB herumgepfuscht.

<das halte ich für sehr schlechtes design
<das gefällt mir gar nicht gut - schlanke DB hin und fileserver her
Haste falsch verstanden.........ist mächtig Leistungsfähigdie Kombination und unendlich Erweiterbar.


<wenn es mir morgen einfällt eine andere als die WEB-oberfläche zu <programmieren (vielleicht in java) dann habe ich mit der
Nimm PHP :D und es ist egal welche Sprache den Link aus der DB rausholt und darstellt.

<wenn ich mich um mehr kümmern muß - vielleicht die art der <speicherung der links auf dateien in der datenbank ('\' <---> '/') -
s.o = Module von/für Apache

<dann habe ich was falsch gemacht (-O
Nö, so kann man das nicht sagen...nur deine DB hat bald die Grenze erreicht und du darfst das Sparschwein für eine Oracle 8i schlachten wo ich noch lange einen auf Free und Easy mache :D

Sloter

jo moment
 

sitzt du mit drei seketärinnen vorm kistl

so schnell wie du schreibst kann ich ja nicht einmal lesen ;-)

fritz
(-:fs)

>>>>>>>>>>>>>>>>>
Wie lange machst du schon mit DB`s rum?
<<<<<<<<<<<<<<<<<

kommt sich drauf an was man unter DB versteht

wenn du auch dBase III plus gelten läßt -> lang :-)

-----------------------------------
>>>>>>>>>>>>>>
<kannst du - nur ungefähr - den zeitunterschied einer suche schätzen
<bleiben wir bei dem beispiel mit 100 x CD = 60 GB:
Leichte Milchmädchenrechnung.
Meine 100 CD Links mit Titel,Interpreter und kleine Geschichte sind keine 2 MB
Die wird er doch schneller als deine 60 GB durchackern?
<<<<<<<<<<<<<<

ähhh, keine ablenkungsmanöver ;-)
ich habe mir wirkliche zahlen erhofft

weil genau die 10 fache suchzeit -
also statt 3 milliskunden ewig lange 3 hunderstel sekunden -
ist genau wurscht

-------------------------------------

>>>>>>>>>>>>
<mein mir mehr bekannter zope-freund ist ganz anders aufgebaut
Steuerst du Zope über Apache oder eigenständig?
<<<<<<<<<<<<

eigenständig

-------------------------------------
<sämtliche webobjekte liegen in einer internen objekt datenbank, <welche sich im admin-fenster natülich auch als verzeichnisstruktur <darstellt
Muß ja quälend langsam sein das Ding......

eigentlich nicht

aber es gibt da noch eine sauschnelle eingebaute alternative
die ist deshalb so schnell, weil sie (die DB) _komplett_ in den speicher geladen wird <uff>
also hauptspeicher und DB-größe sollten in einer vernünftigen relation stehen ...

--------------------------------------

<dann heißt das, daß die oberfläche ( = GUI = oberste schicht) einer <3-tier anwendung sich um _semantische_ dinge in der datenbank ( = <unterste, dritte schicht) kümmert
Der Apache bastelt sich nur eine richtige Url zusammen, da wird nicht direkt in der DB herumgepfuscht.

ich könnte ja wenn mir fad ist die mittelschicht auch von apache aus steuern (es gibt ja ziemlich sicher ein mod_python oder wie das heißt)
wird das nächste projekt, wenn mir zope zu fad wird ...

--------------------------------------
>>>>>>>>>>>>>>>>>
<wenn es mir morgen einfällt eine andere als die WEB-oberfläche zu <programmieren (vielleicht in java) dann habe ich mit der
Nimm PHP und es ist egal welche Sprache den Link aus der DB rausholt und darstellt.
<<<<<<<<<<<<<<<<<

python ist mir sympatischer
und mit dem hab ichs gemacht

---------------------------------------

<wenn ich mich um mehr kümmern muß - vielleicht die art der <speicherung der links auf dateien in der datenbank ('\' <---> '/') -
s.o = Module von/für Apache

tja und was macht meine zukünftige java-oberfläche mit apache-modulen ???

---------------------------------------

<dann habe ich was falsch gemacht (-O
Nö, so kann man das nicht sagen...nur deine DB hat bald die Grenze erreicht und du darfst das Sparschwein für eine Oracle 8i schlachten wo ich noch lange einen auf Free und Easy mache

siehe skalierung -
ich werde 10 rechner a 100,- euro aufstellen
die haben dann ca. 512 kB x 10 = 5 GIG hauptspeicher
und ca. eine prozessorleistung von 500 MHz x 10 = 5 GHz

ziemliche gute kiste für 500 euro


grins


fritz
(-:fs)

<aber es gibt da noch eine sauschnelle eingebaute alternative
<die ist deshalb so schnell, weil sie (die DB) _komplett_ in den <speicher geladen wird <uff>
<also hauptspeicher und DB-größe sollten in einer vernünftigen <relation stehen ...
Mit dem Indianer könntest du komplette Abfragen in die Ram laden, nochmals etwas mehr performanz ;)



<wenn ich mich um mehr kümmern muß - vielleicht die art der <speicherung der links auf dateien in der datenbank ('\' <---> '/') -
<s.o = Module von/für Apache
<tja und was macht meine zukünftige java-oberfläche mit apache-<modulen ???
Die Frage sollte heißen, warum greift der Apache mit seinem Modul schon vorher ein und verändert die Url auf eine Datei die er hat.
IMHO kannst du mit Java auch Zeichen in der Url erstzen/austauschen.


siehe skalierung -
<ich werde 10 rechner a 100,- euro aufstellen
<die haben dann ca. 512 kB x 10 = 5 GIG hauptspeicher
<und ca. eine prozessorleistung von 500 MHz x 10 = 5 GHz
<ziemliche gute kiste für 500 euro
Das ist aber jetzt eine Milchmädchenrechnung :confused:
Besser wäre ein LoadBalancer dahinter 2 Webserver und dann noch 2 dicke DB-Server.
Keiner unter 1 GB Ram.

Meine kleine DB nur mit den Links würde wahrscheinlich sehr pasabel auf einem PII mit 256 Ram laufen :D



Sloter