mySQL rödelt sich auf der HD tot

[lupusoft]

Moin,

ich habe mySQL 4.0.21 auf einem Dual G5/1.8GHz unter Panther 10.3.5 laufen. Die Datenbank ist von der Anzahl der Datensätze her gesehen nicht besonders gross (die grösste Tabelle hat ca. 12000 rows), allerdings gibt es eine Tabelle mit ca. 1500 Datensätzen, die in einem blob Feld gezippte Dateien zwischen 500k und 6MB enthalten. Bei anfänglich durchaus akzeptabler Geschwindigkeit (entweder direkte SQL Anfragen oder über PHP), bricht mir der mysqld mittlerweile ziemlich zusammen. Ich habe versucht, einige Pufferwerte hochzusetzen, aber letztendlich kommt er offensichtlich nicht mit der Grösse der Datensätze zurecht. Wenn ich mir das Verhältnis von gelesenen zu geschriebenen Dateien anschaue, dann liege ich derzeit bei 1.8 Terabyte (!!!) zu 12 Gigabyte. Für mich ein deutliches Zeichen, dass er zuviel über die Platte arbeitet. Wenn ich das richtig interpretiere, dann liegt es weniger am Swappen (394943 pageins und 787265 pageouts), als daran, dass er die nicht die kompletten Tabellen ins RAM bekommt. Insgesamt hat die Bank eine Grösse von ca. 1.3 GB, der Mac hat 1.2 GB RAM. Virtuell hat mysqld 1.06 GB Speicher, bei 100 bis 200 MB physikalischem RAM.
Was kann ich tun, um die Bank wieder flotter zu machen. Momentan ist es wirklich inakzeptabel; über das Webinterface dauert ein select query mittlerweile 1 bis 3 Minuten. Das kann es doch nicht sein, oder? mySQL sollte in der Lage sein Millionen von Datensätzen ohne Probleme zu handeln. Ist die MacOSX Implementation schlechter als bei anderen Platformen? Gibt es eigentlich eine Möglichkeit (oh, oh jetzt kommt die dumme Unix-Nichtwisser-Frage), bestimmten Programmen mehr physikalischen Speicher fest zuzuordnen. Da liegen über 800 MB RAM rum, die top als "inactive" markiert. Oder ist die einzige Chance, noch mehr RAM in den Rechner zu stopfen?

Danke für eure Vorschläge, Lupus

 

[wegus]

@Lupus:
Schlag mich ruhig, aber ich hab mal gelernt das man das so nicht machen soll! Zum aufbewahren von Dateien ( gezipped oder nicht) gibt es ein gutes DBMS ( das Filesystem). In die DB kommt allenfalls der Name und der Pfad dahin. Der Grund liegt einfach in Transaktionen und deren Logs, sowie Caches für Abfragen. Das DBMS muß hierzu ggf. mehrere Versionen eines BLOBs vorrätig halten. Damit killst Du jedes IDE-Plattensystem und erhältst genau den I/O von dem Du sprichst. Bei jedem JOIN, jedem GROUP,... werden zwischetabellen angelegt. Bei der BLOB-Größe in der Tat tödlich. Deshalb Dateien ins Dateisystem. Deren Verwaltung in die DB!

So habs ich mal gelernt, mag beizeiten vielleicht andere Lösungen geben, dann möge man mich eines Besseren belehren.

Gruß Karsten

 

[lupusoft]

Hallo Karsten,

@Lupus:
Schlag mich ruhig, ...

Nicht doch, du hast ja vollkommen recht, ABER ich mache das nicht wirklich freiwillig. Das Problem ist folgendes: der XAMP (oder wie sagt man bei OSX?) Server liegt in einer DMZ, die sowohl von aussen, als auch von dem Firmen-LAN wo ich gerade arbeite, nur über ein Portfenster von 9000 bis 9010 erreichbar ist. Das bedeutet u.a., dass ich keine Möglichkeit habe vom LAN aus über FileSharing an die Platte des Servers zu kommen, um die ZIP Dateien direkt auf den Server zu legen. Andersherum hat natürlich auch der XAMP-Server keinerlei Zugriff auf das LAN. Ich weiss, dass ich theoretisch über ssh und eine Port-Umleitung doch an den AFP-Server vom G5 drankommen würde, aber das setzt auf der LAN-Seite ebenfalls OSX (oder was anderes mit X drinne) voraus. Die Clients im LAN, die den Server füttern, müssen aber alle unter OS9 laufen(proprietäre SW, das alte Problem). Also habe ich einen OS9 mySQL Client geschrieben, der den mysqld direkt auf einem 9000er port kontaktiert und die Daten rüberschiebt. Das ist natürlich alles suboptimal (ganz zu schweigen davon, welche Hürden ich bei der Programmierung des OS9 Clients nehmen musste), aber ich habe momentan keine andere Möglichkeit (naja, ich könnte natürlich eine FW-Platte nehmen und hin und herstöpseln, aber das ist nicht machbar).

... In die DB kommt allenfalls der Name und der Pfad dahin. Der Grund liegt einfach in Transaktionen und deren Logs, sowie Caches für Abfragen. Das DBMS muß hierzu ggf. mehrere Versionen eines BLOBs vorrätig halten. Damit killst Du jedes IDE-Plattensystem und erhältst genau den I/O von dem Du sprichst.

Naja, einerseits beruhigend zu hören, dass das "normal" ist, dass mein G5 so langsam aber sicher abschmiert, aber andererseits gibt es doch die blobs, und die sind genau für den Zweck vorgesehen, dass man da "dicke Dinger" reinpackt. Wie laufen denn Banken, die grosse Bilderarchive oder ähnliches verwalten? Haben die alle RAIDs dranhängen, damit es flüssig bleibt?
Ich hab jedenfalls erstmal 2 zusätzliche Gigabyte RAM bestellt und hoffe, dass es damit besser geht. Hat sonst noch jemand Erfahrungen mit BLOB-Banken gemacht? Ich bin ein wenig unter Druck, weil der Server täglich von zig Kunden besucht wird, die ihre zip Files haben wollen...

Gruss, Lupus

 

[wegus]

Mit sowas kriegst Du auch einen G6 mit 8GHz klein. RAM hilft...um das Problem zu verschieben, nicht um es zu lösen. Dein Problem habe ich verstanden (und beneide Dich nicht ), ich kenne jedoch OS9 nicht (Macuser since 10/2004). Allerdings drängt sich mir eine ganz blöde Frage auf:

Upload/Download würde ich über FTP/HTP realisieren. Kann man nicht einen Webserver auf einen der Ports laufen lassen (Innen wie aussen) und dort via FTP über HTTP Dateien uploaden? Dann könntest Du die mit PHP in ein Filesystem sortieren und deren Pfade in mysql verwalten um dynamische Angebotsseiten für die Kunden zu erstellen. Das wäre mein Ansatz gewesen. Um Deinen BLOB-Harddiskstreßtest vernünftig zu realiseren, braucht es Plattensysteme. Am Besten Raidcontroller mit ordentlich RAM drauf und nem RAID 0 oder 10. Dann hast Du eine reelle Chance.

 

[lupusoft]

Moin,
puh, habe mir eine kleine Verschnaufspause verschafft, indem ich heute morgen die beiden Gig-Riegel eingebaut habe. Läuft jetzt wieder einigermassen akzeptabel, aber wie du schon sagst, wird es wohl nur eine Frage der Zeit sein..

... ich kenne jedoch OS9 nicht (Macuser since 10/2004).

Tja, und ich komme genau von der anderen Seite, sprich fühle mich ziemlich fit auf dem alten MacOS und programmiere halt auch semi-professionell dafür. So hat alles angefangen, ein paar Programme für die Firma, die den täglichen work-flow automatisieren: Ergebnisse analysieren, Bewertungen setzen, ein paar Kundendaten aus der FileMaker Bank ziehen, ein paar Dateien komprimieren, emails generieren, attachments reinhängen und abschicken. Alles "at the ease of a click" sozusagen. Das lief auch lange Zeit gut, bis die Auslieferungen der zips über email langsam ins Stocken geriet (Stichwort Spamfilter). Also musste ein Datenbanksystem für die passive "Auslieferung" der Kundendateien her, am besten gleich gepaart mit online-Bestellung etc. Naja, nach kurzem Zögern und ein paar Versuchen auf OS9 war klar, dass ich da nur mit OSX weiterkommen würde, wenn ich nicht jede Menge Räder neu erfinden wollte. Aber trotzdem muss es halt von den OS9 Rechnern im LAN aus mit ein paar Klicks funktionieren.

Upload/Download würde ich über FTP/HTP realisieren. Kann man nicht einen Webserver auf einen der Ports laufen lassen (Innen wie aussen) und dort via FTP über HTTP Dateien uploaden? Dann könntest Du die mit PHP in ein Filesystem sortieren und deren Pfade in mysql verwalten um dynamische Angebotsseiten für die Kunden zu erstellen.

OK, danke erstmal fürs Mitdenken. Was den zusätzlichen Webserver angeht, kann man das wohl mit virtuellen Hosts in Apache regeln, oder? Da hab ich mich aber noch nicht wirkich mit auseinandergesetzt. Aber der schwierigere Teil ist sicher das Sortieren mit PHP. Ich muss dazu sagen, dass ich nicht wirklich firm in PHP bin. Die jetzigen PHP-Seiten wurden von einem externen Fachmann erstellt (der übrigens witzigerweise Karsten heisst), halt mit HTML-templates und allen Schikanen. Da kann ich nicht wirklich mitreden, aber die PHP-Sortierungsgeschichte könnte ich ja auch wieder abgeben. Was mir mehr Kopfzerbrechen bereitet, ist die Frage, wie ich diesen Weg von den OS9 Rechnern aus beschreite. Wenn die Leute im Büro jetzt irgendwas "per Hand" machen müssen, gibts ne Meuterei. Also via Browser die Dateien hochladen fällt aus. Alternativ könnte ich natürlich einen handgestrickten http-client in meine Programme einbauen, aber da hab ich dann den ganzen http Protokoll Overhead drin. Also wird es wohl auf eine proprietäre Lösung hinauslaufen, sprich ein OSX Programm, das die zips entgegennimmt, in Ordner schiebt und den Pfad in die Bank schreibt. Das wird wieder Neuland für mich, selbst wenn es "nur" eine Carbon App wird.
Jedenfalls danke für deine Hilfe, Lupus

 

[wegus]

@Lupus:
Eije das klingt verzwickt. Aber keine Angst vor PHP! It's almost like C!
Vergiß einfach alle Variablen-Typen und geh von einem C-Interpreter ( zugegeben mit einigen Eigenheiten) aus. Ich benutze PHP fast als einzige Scriptsprache um meine LINUXe zu verwalten, alltägliche Abläufe per Cron zu erledigen...
Ist halt soviel lesbarer als Perl. Gut es ist nicht so schnell, aber wen störts bei derartigen Anwendungen. Den Internen und Externen Apache würd ich allein aus Sicherheitsgründen trennen. Zumal ja auch jeder auf eine andere Netzwerkkarte gebunden werden müßte...

SoSo, Dateiupload per Browser überfordert User. Ich wußte nicht das wir in der gleichen Firma arbeiten und hab hier auch noch keinen Mac gesehen

 

[norbi]

hab' zwar keine Ahnung von SQL, aber:
wieso lagerst Du die Suchfelder für die Blobs nicht in eine eigene Tabelle aus. Wird in dieser schlanken Tabelle ein DS gefunden, braucht nur noch das EINE Blob in der Blob-Tabelle geladen werden.

So isses gemeint:
Tabelle1 - zum Suchen:
- Index
- Dateiname
- Änderungsdatum
- Dateityp
- Dateigröße
- ...
Tabelle2 - mit den Blobs:
- Index Tabelle 1
- Blob

Ich selbst hatte das ganze mal (in "4D") so gelöst, daß ich die Tabelle mit den Blobs nochmal aufgeteilt hatte, auf eine weitere Tabelle mit etwa 100 k großen Blobs pro DS. Beim Import und Export wurde die Datei in Stücken von der HD geladen bzw. in Stücken auf die HD geschrieben. Selbst mit 10 MB-Dateien war das auf einem Centris 660 AV (25 Mhz!, 64 MB RAM) kein Problem - und flott.

No.

 

[lupusoft]

Gut es ist nicht so schnell, aber wen störts bei derartigen Anwendungen.

Höhö, da kann ich dich gleich weiterleiten an die Leute nebenan. Wenn mein Programm 6000 Adressdaten aus der internen FileMaker Bank nach dem gewünschten Kunden durchsucht, 40 neue Records in 3 verschiedenen Tabellen der mySQL Bank für den Auftrag anlegt, anschliessend automatisch eine email mit den Auftragsdaten in Eudora erzeugt und dafür satte 7 Sekunden braucht, gibt es schon nervöses Fingertrommeln auf der Maus. Soviel dazu...

Den Internen und Externen Apache würd ich allein aus Sicherheitsgründen trennen. Zumal ja auch jeder auf eine andere Netzwerkkarte gebunden werden müßte...

OK, hab dich falsch verstanden; ich dachte an einen weiteren httpd, der auf einem anderen Port der "externen" Karte läuft. In Gänsefüsschen, weil die Sache ja noch viel paranoider ist, als man sich (zumindest ich mir) vorstellen würde. Der Haus-Provider, an den wir gebunden sind, ist schon fast eine Behörde für Internetsicherheit. Vom Provider/Internet aus gesehen sitzt das das gesamte Gebäude mit einem dutzend Firmen hinter der ersten firewall, die eigentlich von aussen schon fast alles dicht macht. Von dieser ersten firewall geht es auf die zweite firewall, die hier in der Firma steht. Letzteres ist eine DOSe mit Suse und 3 Netzwerkkarten, eine "externe", eine fürs LAN (192.168.101.x) und die dritte für die DMZ (192.168.102.x). Das bedeutet, dass der G5 seine IP-Existenz quasi über reines port-mapping bezieht. Ich kann vom G5 aus ja nicht mal über irgendwelche ports nach "draussen" gehen, da alle anderen ports ausser 9000-9010 technisch gesehen zum LAN Interface gehören). Ironischerweise kann ich mir also nicht mal die Sicherheitsupdates von Apple runterladen. Diese Leute sind vollkommen phobisch und eine zweite Netzwerkkarte am G5, mit der ich wieder ins LAN gehe, wäre ja wieder die Umgehung der physikalischen Trennung. Ausserdem wäre das ja über Umwege auch das gleiche, als wenn ich die offenen ports direkt zu einem LAN-Rechner mappe. Da bekommt der Provider wieder Herzattacken und redet gleich von Haftungsausschluss und Schadensklagen in Millionenhöhe, die Dritten durch eingeschleuste Viren enstehen könnten, und da werden die Chefs natürlich weicheierig und wollen das auch nicht. Lustig ist auch, dass sie z.B. die Time-Server Abfragen der Macs blocken, weil das ja ein Sicherheitsrisiko darstellt. Und als ich den G5 Server dann in Betrieb genommen habe, hagelte es gleich Anrufe von erzürnten Kunden, die nicht auf die Seiten kamen. Da musste ich mich dann auch noch mit deren Sysadmins rumschlagen, damit die wiederum ihre firewalls für den rausgehenden port 9003 freischalten. Haha, manchmal weiss ich wirklich nicht, ob ich lachen oder weinen soll.
Naja, ich komm ins Schwätzen. Muss aufpassen, dass ich nicht selbst zum Sicherheitsrisiko werde

SoSo, Dateiupload per Browser überfordert User. Ich wußte nicht das wir in der gleichen Firma arbeiten und hab hier auch noch keinen Mac gesehen

Sei froh, dass ihr noch keine Macs habt, sonst erwarten die Leute bald, dass alles sprachgesteuert funktioniert

...wieso lagerst Du die Suchfelder für die Blobs nicht in eine eigene Tabelle aus. Wird in dieser schlanken Tabelle ein DS gefunden, braucht nur noch das EINE Blob in der Blob-Tabelle geladen werden.

Mmhja, darüber nachgedacht hab ich auch schon, könnte mir aber vorstellen, dass es nicht soviel bringt. Wenn ich mir die Tabelle mit zip-blobs anschaue, dann hab ich ca. 10 kleine Felder (varchar, int) mit Auftrags-spezifischen Sachen wie Datum Eingang/Ausgang, Kundennummer, mail-Adresse, ID (als primary key) etc. und halt das dicke binary blob Feld. Die kleinen Felder machen also kaum Raum aus. So wie ich es verstanden habe (und es ist nicht unwahrscheinlich, dass ich es nicht verstanden habe) läuft der Zugriff sowieso über die Index Tabellen, die MyISAM anlegt. Die Indices werden nicht dadurch kleiner, dass ich die blobs von den übrigen Daten trenne, im Gegenteil brauche ich einen weiteren Index. Die key index caches hab ich schon raufgesetzt, da kommt nix mehr an Geschwindigkeit. Es könnte was bringen bei Volltextsuchen, aber das passiert eigentlich nicht. Alle select und update queries beziehen sich auf ints, die gleichzeitig als key Werte benutzt werden (z.B. loggen sich die Kunden mit ihrer Kundennummer ein, die wiederum im primary key Feld stehen. Aufträge haben eine unique ID als prim. key und die Kundennummer als secondary key usw.). Wie nun aber InnoDB die Datensätze handelt, weiss ich natürlich nicht. Da lasse ich mich sehr gerne belehren, ob es was bringt, die zips in eine separate Tabelle zu verfrachten.

 

[wegus]

öhö, da kann ich dich gleich weiterleiten an die Leute nebenan. Wenn mein Programm 6000 Adressdaten aus der internen FileMaker Bank nach dem gewünschten Kunden durchsucht, 40 neue Records in 3 verschiedenen Tabellen der mySQL Bank für den Auftrag anlegt, anschliessend automatisch eine email mit den Auftragsdaten in Eudora erzeugt und dafür satte 7 Sekunden braucht, gibt es schon nervöses Fingertrommeln auf der Maus. Soviel dazu..

Hey wir arbeiten doch in der gleichen Firma! Aber im Ernst, so was geht in PHP ( und auch schneller als in 7 Sekunden) ohne Probleme. Ich meinte nur perl sei schneller bei administrativen Dingen ( String und Fileoperationen). Aus Gründen der Wart- uns Lesbarkeit nehm ich dafür auch nur noch PHP. Der Normalisierungsvorschlag von Norbi ist aufgrund der Speichergöße der Blobs wohl ohnehin ein Muß!

Was Deine Admins angeht so ists brav ( so ists auch bei uns!)! Außer nat. den Port für Zeitserver, das ist in der Tat etwas übertrieben...

 

[lupusoft]

Aber im Ernst, so was geht in PHP ( und auch schneller als in 7 Sekunden) ohne Probleme.

Nee, die Angaben waren für mein selbstgebasteltes Programm auf einen alten G3 mit OS 8.6, der übers Netz mit dem mysqld redet. Ich weiss gar nicht, ob es überhaupt ein PHP für Classic gibt, und wenn, dann nur "Künstlich" draufgesetzt.

Der Normalisierungsvorschlag von Norbi ist aufgrund der Speichergöße der Blobs wohl ohnehin ein Muß!

Öh, versteh ich nicht. Die Definition heisst doch Ein Relationstyp ist in der 1. Normalform, wenn alle Attribute maximal einen Wert haben. Das ist doch bei mir der Fall; jedes zip gehört zu genau einem Auftrag. Kannste das nochmal erläutern?

Was Deine Admins angeht so ists brav ( so ists auch bei uns!)! Außer nat. den Port für Zeitserver, das ist in der Tat etwas übertrieben...

Tja, da kann man natürlich endlos dikutieren, wo der Kompromiss zwischen Sicherheit und Nutzbarkeit des Systems ist. Wenn wir hier ne Horde Windoof Rechner rumstehen hätten, wäre ich ja einsichtig, aber bei den ganzen Klimmzügen, die ich unternehmen muss, um an meinen eigenen Server zu gelangen, würde ich sagen, es wäre weniger zeitintensiv, den Server nach jeder Hackerattacke neu einzurichten.

 

[wegus]

Kannste das nochmal erläutern?

Ich meine damit, daß Norbi Recht hat, weil über diese ( wenn auch übertriebene Aufsplittung) Operationen auf den Daten der Blobs möglich sind (Sortierung, Gruppierung) ohne dabei die Blobs mit anzufassen. Wer das will muß via JOIN erst die Tabelle mit den BLOBS explizit ansprechen ( prädestiniert dafür ggf. ein view). Ich bleibe aber bei meiner Kernaussage, daß das beste DBMS für Dateien ein Dateisystem ist.

würde ich sagen, es wäre weniger zeitintensiv, den Server nach jeder Hackerattacke neu einzurichten

Kann man sehen wie man will. Zu Zeiten von Sasser und Co. waren meine Kollegen (non EDV) auch nicht erbaut, daß sie weiterarbeiten mußten während andere Firmen Ihre Leute nach Hause geschickt haben da dort nichts mehr ging. Manchem ist es ergo wohl recht eine instabile EDV zu haben.

 

[lupusoft]

Ich bleibe aber bei meiner Kernaussage, daß das beste DBMS für Dateien ein Dateisystem ist.

Message ist rübergekommen, und ich werde mir eine Lösung ausdenken müssen, um die zips in Dateien zu packen.

Kann man sehen wie man will. Zu Zeiten von Sasser und Co. waren meine Kollegen (non EDV) auch nicht erbaut, daß sie weiterarbeiten mußten während andere Firmen Ihre Leute nach Hause geschickt haben da dort nichts mehr ging. Manchem ist es ergo wohl recht eine instabile EDV zu haben.

Hey, erkenne ich da eine gequälte Sysadmin Seele? Vollkommen ok wenn du versuchst euer System zu schützen. Aber wenn du es wirklich sicher machen willst, schneid alle Kabel durch. Was interessiert mich Sasser und Co? Wir haben hier ein Mac LAN, noch dazu eins mit OS 8.6 bis max 9.2.2. Da gibt es nix zu hacken, weil es keine Verzahnung von Serverdiensten mit dem OS gibt. Webstar (damals Hersteller eines Webservers für "klassisches" OS) hatte sogar öffentlich einen Contest mit hoher Belohnung ausgeschrieben für denjenigen, der es schaffen würde die Software auf irgendeine Weise zu kompromottieren (ausgenommen DOS Attacken). Das hat wohl selbst nach Jahren keiner geschafft. Und selbst wenn es irgendwelche buffer overflows oder weiss der Geier was gegeben hätte, ist die Mac Gemeinde einfach so verschwindend klein, dass keine Sau Mühe darin investiert, die Rechner lahmzulegen. Was sollen sie denn machen die ganzen Script-Kiddies, wenn sie auf einmal kein Windows mehr vor sich haben? Wie sollen die potentiellen Hacker denn weiterkommen im LAN, selbst wenn sie Zugriff auf einen Rechner bekommen? Da gibt es keine TCP/IP-basierten Dienste, keinen root, keine Privilegien. Wer weiss denn irgendwas von DDP-basierten AppleTalk über das die alten Rechner ihr FileSharing betreiben? Das letzte Mal, dass ich einen Virus auf einem Mac hatte, ist 18 Jahre her, und jetzt ist es schon eine Sensationsmeldung wert wenn ein vermeintlicher Trojaner für OSX auftaucht. Das ist doch das einzige, was mir altem Mac-User als Trost gegen Benchmarks- und Kompatibilitäts-Diskussionen blieb: ich hab mich totgelacht, wenn alle anderen in (begründete) Hysterie verfallen sind, weil wieder ein mail-Virus umging. Und wenn ich dann sage, gebt mir doch ein Beispiel, einen Wurm, ein Virus oder irgendwas, wo ein Mac unter OS 8/9 gehackt wurde, dann bekomme ich nur ein "darüber diskutieren wir nicht" zurück. Soviel Ignoranz treibt mich zur Weissglut.
Egal, soll ja nicht das Thema sein. Wäre auch schade, wenn wir uns darüber jetzt streiten würden. Ich bin ja dankbar, dass du mir bei meinen DB-Problemen weitergeholfen hast.
Gruss, Lupus

 

[wegus]

Hey, erkenne ich da eine gequälte Sysadmin Seele?

Gequält nein, der Rest stimmt!

Wäre auch schade, wenn wir uns darüber jetzt streiten würden.

Ich streite mich gerne! Aber wozu Du hast ja vollkommen Recht ( soweit ich das Überblicke - ich kenne nur OS X). OS X ist ein bezahlbares und kommerziell maintaintes BSD mit einer hervorragenden GUI zu einem Spotpreis! Das ist der Grund, warum ich mir so ein Ding gekauft hab. Für mich spielen die PM in der gleichen Liga wie Sun Sparc oder SGI-Irix Workstations ( was die UNIXe angeht). Mit WINtel darf man so was nicht vergleichen.

 

[norbi]

Also ich würde nicht sagen, daß mein Vorschlag was mit Normalisierung zu tun hat. Ganz im Gegenteil. Es ist eine Maßnahme zur Beschleunigung - entgegen Normalisierungs-Regeln. Aus Performance-Gründen ist es in diesem Fall aber "erlaubt" - denke ich.

No.

 

[wegus]

@norbi:
Ja, Normalisierung war der falsche Ausdruck! Sorry, schwacher Moment!
Gute datenbanken haben immer eine Ausnahme gegen die Regeln

 

[lupusoft]

Upload/Download würde ich über FTP/HTP realisieren. Kann man nicht einen Webserver auf einen der Ports laufen lassen (Innen wie aussen) und dort via FTP über HTTP Dateien uploaden? Dann könntest Du die mit PHP in ein Filesystem sortieren und deren Pfade in mysql verwalten um dynamische Angebotsseiten für die Kunden zu erstellen.

Moin,
bin nun also doch dabei, deinen Vorschlag über http aufzugreifen und dümpel ein wenig mit PHP rum. Unser externer PHP Experte hat grad zu viel um die Ohren, deshalb dachte ich mir, ich fang schon mal an und versuch was dabei zu lernen. Nun ja, bin gerade dabei kläglich zu scheitern...
Mein Plan: ein über .htaccess geschütztes PHP-Skript einer extra directory im Indianer Web-Ordner, das den upload der zips managed. Die Dateien landen zunächst im temp Ordner und sollen dann in einen Ordner auf einer zweiten internen Platte in eine nach Jahr, Monat, Tag aufgesplittete Verzeichnisstruktur übertragen werden. Der Pfad dahin kommt dann anstelle des Blob-Feldes in die mySQL Bank. Soweit die Theorie.
Die Authentifizierung hab ich soweit eingerichtet, und nach ein paar TCP-dumps bin ich auch hoffnungsvoll, dass ich die notwenigen http Header nachbasteln kann: method=POST, action='meinSkript.php' und enctype='multipart/form-data'. Die Form Felder sind dann <input type=hidden name='MAX_FILE_SIZE' value=200000000> und file: <input type=file name='userfile'>. Soviel von der Client/Browser Seite. Auf der Skript Seite fange ich den upload mit dem $_FILES array auf. Laut Beschreibung bekomme ich dann den Originalnamen der Datei in $_FILES['userfile']['name'], den Mime Typ in $_FILES['userfile']['type'], die Grösse der Datei in $_FILES['userfile']['size'], den temporären Pfad des uploads in $_FILES['userfile']['tmp_name'] und irgendwelche Fehler beim upload in $_FILES['userfile']['error']. Also hab ich mir sowas in meinSkript.php gebastelt:

<?php
$err = $_FILES['userfile']['error'];
if ($err = 0)
{
$uploadbase = '/Volumes/xxxx/ZipBase';
$filename = $_FILES['userfile']['name'];
if(strlen($filename)>6)
{
$uploaddir = $uploadbase.'/'.$yeardir.'/'.$monthdir.'/'.$daydir;
echo 'Der Pfad ist jetzt '.$uploaddir;
$uploadfile = $uploadbase.'/'.basename($filename);
if (($err == 0) && move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile))
{
echo 'Die Datei '.$filename.' ist angekommen und wurde in '.$uploadfile.' verschoben';
}
else
{
echo 'Die Datei '.$filename.' ist angekommen, aber das Verschieben aus '.$_FILES['userfile']['tmp_name'].' in '.$uploaddir.' ist gescheitert'."\n";
phpinfo();
}
}
else
{
# kein gueltiger Dateiname
$err = '-43';
echo 'Die Datei '.$filename.' hat einen falschen Dateinamen'.' Fehler '.$err;
}
}
else
{
echo 'Der upload hat nicht funktioniert: '.' Fehler '.$err;
}
?>

Das hat sogar funktioniert - anfangs. Dann musste ich allerdings feststellen, dass ich die Maximalgrössen für den upload in php.ini anpassen muss, damit die grösseren Dateien auch rüberkommen. Letzteres war allerdings in meiner Standard OSX Installation von PHP 4.3.2 gar da bzw. aktiviert. Da liegt ein php.ini.default in /etc rum, ein php.ini-recommended in /usr/local/php/lib/ und ein php.ini im selben Verzeichnis, das aber wohl nicht gelesen wird. Also hab ich das php.ini aus /usr/local/php/lib/ rüberkopiert nach /etc und den Werte für post_max_size raufgesetzt. Jetzt klappt es leider nicht mehr
Das PHP Log sagt PHP Notice: Undefined index: userfile in /Library/WebServer/Documents/yyyyy/meinSkript.php on line 2. Irgendwas entscheidendes an dem php.ini ist also anders als die default Werte. Tja meine Fragen sind also
a) Wo kommen die default Einstellungen ohne php.ini her? (werden die beim Kompilieren gesetzt?)
b) Was hindert PHP daran die Werte aus $_FILES auszulesen?
c) Wieso lass ich Idiot nicht die Finger von diesen Sachen?

Danke für eure Hinweise, Lupus

 

[wegus]

moin Lupus,
ich hab's gelesen! Ist aber so viel, da muß ich ein bißchen Zeit dazu haben. Ich schau mal bei Gelegenheit in ruhe hinein!

 

[lupusoft]

moin Lupus,
ich hab's gelesen! Ist aber so viel, da muß ich ein bißchen Zeit dazu haben. Ich schau mal bei Gelegenheit in ruhe hinein!

Moin Karsten,
ja sorry, bei der Menge kann einem gut die Lust vergehen. Die gute Nachricht ist aber, dass es jetzt wieder funktioniert. Um es möglichst nicht nachvollziehbar zu machen , habe ich gleichzeitig am Skript, der ini Datei und den User-Rechten rumgefruckelt, und jetzt kann ich die zips schon mal via Browser hochladen. Momentan versuche ich den http post programmatisch nachzuäffen. Melde mich bestimmt bald wieder hier.

Gruss, Lupus

 

[wegus]

sorry, bei der Menge kann einem gut die Lust vergehen

Nö das nicht, ich hatte nur bisher keine Zeit das auseinanderzutüddeln und ein bißchen reindenken muß man sich ja schon, wenns Sinn machen soll!

Momentan versuche ich den http post programmatisch nachzuäffen.

Wie meinen?

 

[lupusoft]

Wie meinen?

Will sagen, mein Programm soll Browser spielen, i.e. ich öffne eine TCP/IP Verbindung zum Server und schicke ihm in etwa folgendes:

POST /Verzeichnis/MeinSkript.php HTTP/1.1
Host: XXX.YYY.ZZZ.AAA
User-Agent: MeinProgramm
Accept: text/xml, text/html
Keep-Alive: 300
Connection: keep-alive
Authorization: Basic XXXirgendwascodiertesYYY
Referer: http://192.168.101.13/MeinProgramm
Content-Type: multipart/form-data; boundary=---------------------------17515310515627
Content-Length: 1708

Das wäre z.B. der http header für ein "POST" an das PHP-Skript auf dem Server. "Nachgeäfft" weil es mehr oder minder von einem TCP-Dump abgekupfert ist, den ich während eines "Gespräches" zwischen Netscape und
meinem Skript auf dem Server aufgenommen habe. Hinter den Header wird dann einfach der Inhalt der zip-Datei gehängt (soviel ich gesehen habe, wird da nix escaped), und am Ende folgt nochmal die im Header definierte Grenze, also:
[edit]schon der erste Fehler: der header geht nur bis content-length, die durch die boundaries abgetrennten Formulardaten kommen hinter dem ersten CR+LF Paar und werden selber auch wieder durch ein doppeltes CR+LF separiert.[/edit]

-----------------------------17515310515627
Content-Disposition: form-data; name="MAX_FILE_SIZE" 200000000
-----------------------------17515310515627
Content-Disposition: form-data; name="userfile"; filename="MeineDatei.zip"
Content-Type: application/zip
PK........vvF1...m............und so weiter, halt binär der Inhalt der zip Datei....
-----------------------------17515310515627--

Was mir noch nicht ganz klar ist: kann man sich was ausdenken für die "boundary"? Nach mehreren Versuchen mit verschiedenen Browsern, scheint sie mir willkürlich bezüglich Grösse und Inhalt zu sein. Zweite Frage: kann ich in die simulierten Formulardaten weitere Pseudo-Felder (type hidden oder wie auch immer) einbringen (um später die records in der mySQL Bank zu identifizieren, die den Pfad gesetzt bekommen müssen), ohne dass ich mir mein $_FILES array zerschiesse? Naja letzteres werd ich einfach ausprobieren...