Verwaltung großer Datenmengen (binär) in PHP/MSSQL

Aufgabenstellung
Ich brauche in einer PHP (5.2.6, IIS 6) Applikation eine große Menge an Daten in Form eines 2D-Arrays. Diese Daten kommen aus einzelnen Files in welchen diese Daten in binärer Form abgespeichert sind.

Die Frage ist nun, wie ich die Daten in einer Datenbank (MSSQL Express 2005) abspeichern kann, so dass der Zugriff auf große Mengen (mit bis zu mehreren Millionen Einträgen im 2D-Array) dieser Daten einerseits möglichst schnell erfolgt, andererseits aber die Datenbank nicht nach kurzer Zeit an ihre Grenzen stößt.

Iststand
Momentan speichere ich die Daten eines jeden Einzelfiles als eigene Zeile pro File in der DB, wobei ein Feld die binären Nutzdaten Base64-codiert enthält. PHP holt diese Daten ab und "entpackt" die Daten in 2D-Array-Form.

Problem
Bechmarks haben folgendes ergeben: Das Holen der Daten eines durchschnittlichen Files dauert 126ms, wobei 124,9ms lang entpackt wird. Da nun durchaus mehrere 100-1000 "Files" gelesen werden müssen, dauert alleine das Holen der Daten mehrere Sekunden bis Minuten, was wir dem User nicht antun wollen.

Lösungsansätze
Eine Alternative wäre das Entpacken der Daten beim Eintragen in die DB, wobei man um die n x m -Struktur zu wahren zwei Tabellen gebraucht werden - die eine bekommt für jedes neue File n Einträge (erste Dimension) mit Verweis auf die File-id, die zweite n x m Einträge mit Verweis auf die entsprechende id in der ersten Tabelle. Das Problem hierbei ist, dass mir ganz schnell die IDs ausgehen werden fürchte ich, denn: Ein (durchschnittliches) File hat 15x1000 Einträge und ich habe meherere 100-1000 Files täglich in die DB einzupflegen.

Die zweite Alternative ist das Entpacken beim Eintragen in die DB, aber speichern in einem 2D-Array, das mit serialize() bearbeitet wurde. Hier entstehen durch serialize() natürlich enorm große Datenmengen. Weiters hat diese Variante schon große Probleme mit der DB gemacht, und ich kenne die Performance von unserialize() nicht.

Andere Möglichkeiten die mir einfallen sind: Auslagern der entsprechenden Operationen in ein C-Programm (schneller?) und Stored Procedures auf der DB (keine Ahnung ob die wirklich was bringen würden).


Habt ihr Erfahrung mit solchen Anwendungen? Wie würdet ihr dieses Problem lösen? Ich wäre für jeden Input und jeden Tipp sehr dankbar

Den Gedanken hatte ich auch schon

Das Problem des Konvertierens von Binär- zu "Nutz"-Daten bleibt bestehen. Auch wenn ich die Daten als "Klartext" mit serialize() oder einem eigenen Format speichere, bleibt das Problem des Umwandelns bestehen.

Zitat von Uncle****a

das beste wäre wohl ein gscheites schema zu machen und die files richtig in die datenbank einzutragen so das du direkt drauf selektieren kannst. so wirst du die files komplett los und hast die performance.

Zitat von jives

Eine Alternative wäre das Entpacken der Daten beim Eintragen in die DB, wobei man um die n x m -Struktur zu wahren zwei Tabellen gebraucht werden - die eine bekommt für jedes neue File n Einträge (erste Dimension) mit Verweis auf die File-id, die zweite n x m Einträge mit Verweis auf die entsprechende id in der ersten Tabelle. Das Problem hierbei ist, dass mir ganz schnell die IDs ausgehen werden fürchte ich, denn: Ein (durchschnittliches) File hat 15x1000 Einträge und ich habe meherere 100-1000 Files täglich in die DB einzupflegen.

Das ist das, was mir dazu eingefallen ist. Meinst du sowas? Wenn ja, was sagst du dann zu dem von mir angesprochenen Problem? Oder macht man das dann anders?

Edit:
Man könnte auch immer eine neue Tabelle mit einem eindeutigen, generierten Namen für jedes File anlegen und die Files einfach in Tabellenform ohne id oder ähnlichem schreiben. Ich weiß aber nicht, ob man sowas wirklich machen soll/kann? Das werden dann ja unzählige Tabellen.
Dafür könne das Selektieren mehrerer Datensätze dann vielleicht mit JOINs durchgeführt werden...

In 99% der Fälle brauche ich das ganze Array bzw. mehrere komplette Spalten daraus.

In welcher Form meinst du soll ich die Daten ablegen?
Aber wenn ich die Daten als BLOB 1:1 im Dateisystem ablege, muss ichs in PHP ja erst entpacken - das ist genau die Operation, die jetzt Probleme macht.
Ich könnte probieren die Daten mit serialize() abzuspeichern, wobei die Operationen viel Speicher fressen und vermutlich nicht ausreichend perfomant sind.

Habe ich hier einen Denkfehler? Müsste ich nicht eigentlich die Daten auf jeden Fall in der DB verwalten, um ausreichende Performance gewährleisten zu können?

Meinst du mit aufteilen so wie von mir vorgeschlagen (eigene Tabelle pro File/zwei neue Tabellen für alle Files)?

Ich hab mir Muehe beim Lesen der Aufgabenstellung gegeben, aber mein geistiges Auge schafft es einfach noch nicht, das Szenario vor sich aufleben zu lassen

Ist es so, dass du
... N Files hast, die N Arrays repraesentieren
... jedes dieser N Arrays aus x*y Elementen besteht
... du jedes dieser Arrays in eine Tabelle einer SQL-DB schreiben willst, um dort auf Rows und Cols Zugriff nehmen zu koennen

oder habe ich da was falsch verstanden? (Es faellt mir mit dieser Anime-MMORPG-Gedudelmusik im Hintergrund hier grade etwas schwer, mich zu konzentrieren, sorry )

Wenn dich in diesen Arrays immer nur bestimmte Zeilen interessieren, dann waere es vielleicht performanter, diese alle in eine Verzeichnisstruktur zu speichern (es ist generell besser fuer die Performance, nicht ein Directory mit tausenden Files vollzumuellen; ziemlich unabhaengig vom FS. Deshalb solltest du deinen Index, ueber den die einzelnen Files/Arrays adressiert werden, auf Verzeichnis- und Dateinamen aufteilen: DATA/1/7/901.bin statt DATA/17901.bin zum Beispiel), und die einzelnen Files jeweils von einer BDB (Berkeley Database) verwalten lassen. Da kannst du deinen wie auch immer serialisierten Inhalt der Rows (Google Protocol Buffers waeren hier vielleicht eine nuetzliche Sache, wenn PHPs internes serialize() suckt (was ich mal annehme)?) mit deren Row-Nummer als Index ablegen, und wohl auch entsprechend schnell rausholen.

Vielen Dank an COLO und that für die (wie immer ) hervorragenden Inputs

@ COLO
An sowas hab ich noch gar nicht gedacht (wär auch nie darauf gekommen). Das scheint eine sehr gute Methode zu sein, die wir uns sicher genau anschauen werden.

@ that
Doch die Reihenfolge ist enorm wichtig. Ich hätte fast vergessen, dass es nicht reicht die Daten in der richtigen Reihenfolge in die DB zu schreiben. Stimmt ja leider nicht, weil ich die ja irgendwie zurück bekommen kann beim Lesen. Ich führe dann wohl am besten eine 64bit-ID mit, nach der ich sortieren kann. Die sollte auch für die nächsten tausend Jahre funktionieren

#1: Um ehrlich zu sein: Weil das Know-How für .NET nicht vorhanden ist
#2: Graphische Darstellung in Form von Diagrammen, die nach Benutzereingaben generiert werden.
#3: Weil zu den Daten ein Haufen Metadaten gehört, die alle mit einander verknüpft sind. Nachdem die Daten in der DB sind, werden unter Umständen die zugehörigen Metadaten verändert.