nicht angemeldet
PHP serialize und Textdatei als Datenbankersatz?
Guten Tag zusammen
Ich wollte mich kurz nach Eurer Meinung erkundigen. Ich arbeite seit langem mit MySQL habe jetzt aber einen Fall in welchem mir eine MySQL-Datenbank übertrieben und unpraktisch vorkommt. Als Alternative speichere ich jetzt einen serialized-String in eine Textdatei. Klappt bestens. Meine Frage lautet: Spricht etwas gegen diese Methode sofern der Einsatz in kleinem Rahmen erfolgt? Sicherheit? Geschwindigkeit?
Viele Grüsse, Phil
-
Moin,
Ich wollte mich kurz nach Eurer Meinung erkundigen. Ich arbeite seit langem mit MySQL habe jetzt aber einen Fall in welchem mir eine MySQL-Datenbank übertrieben und unpraktisch vorkommt.
Kommt dir das nur so vor oder hast du noch andere/weitere Gründe, die für die Alternative sprechen?
Hotti
-
Hallo Hotti
Danke für die Antwort. Als ich über deine Frage genauer nachdachte, ist mir etwas klar geworden. Es geht mir hauptsächlich darum, ein mehrdimensionales Array abzuspeichern. Anstatt den serialized String in eine Textdatei zu speichern, könnte ich diesen auch gleich in eine MySQL Datenbank schreiben. Somit vermeide ich das lästige Dateihandling!Jetzt fühle ich mich gerade ziemlich doof :) Danke!
-
Danke für die Antwort. Als ich über deine Frage genauer nachdachte, ist mir etwas klar geworden. Es geht mir hauptsächlich darum, ein mehrdimensionales Array abzuspeichern. Anstatt den serialized String in eine Textdatei zu speichern, könnte ich diesen auch gleich in eine MySQL Datenbank schreiben. Somit vermeide ich das lästige Dateihandling!
Mehrdimensionale Daten kannst du auch in einem XML-File ablegen.
-
Hai ;)
[..] Somit vermeide ich das lästige Dateihandling!
Ooch, gerade Arrays lassen sich in Dateien ganz hervorragend speichern ;)
Jetzt fühle ich mich gerade ziemlich doof :) Danke!
Was bin ich auch für ein fieser Typ heute ;-)
Mögliche Gründe zur Datei-Alternative:
- Overhead beim Verbinden mit dem DB-Server
- Ausfall der Verbindung
Verbesserungen:
zu 1) Der Prozess läuft schon, z.B. als FastCGI
zu 2) Die Datei-Alternative nicht als Alternative machen sondern als Fallback, wenn die Verbindung zur DB nicht zustande kommt.Obwohl: Dateihandling ist tatsächlich lästig. Plan B: Schreib ne Klasse für den Dateizugriff und greife in der Anwendung nur noch auf Methoden zurück. Schreibe eine Klasse für den DBzugriff und gib den Methoden dieselben Namen wie den Methoden in der Klasse für den Dateizugriff. Dann kannst Du die Klassen austauschen und die Anwendung arbeitet entweder mit DB oder mit File. Und wenn du das fertig hast, mache ein Benchmark ;-)
Hotti
-
Hi!
[..] Somit vermeide ich das lästige Dateihandling!
Ooch, gerade Arrays lassen sich in Dateien ganz hervorragend speichern ;)Jedes Art Daten lässt sich ganz hervorragend in Dateien speichern, wenn man sie vorher serialisiert. Was sollte bei PHP-Arrays, die ja keine Arrays im herkömmlichen Sinne sind, sondern komplex strukturierte Gebilde sein können, besonders gut geeignet sein?
Mögliche Gründe zur Datei-Alternative:
2) Ausfall der Verbindung
Verbesserungen:
zu 2) Die Datei-Alternative nicht als Alternative machen sondern als Fallback, wenn die Verbindung zur DB nicht zustande kommt.Ach, und wie synchronisieren sich die Daten zwischen beiden Systemen? Wenn man Ausfallsicherheit beim MySQL-Server haben will, ist die aufwandärmste Version eine Replikation zu einem zweiten Server. Das muss man nur konfigurieren und fertig ist.
zu 1) Der Prozess läuft schon, z.B. als FastCGI
Was ist daran besser? Dass der eine Prozess bereits auf der offenen Datei sitzt und andere Prozesse ausbremst, weil sie nun nicht parallel zugreifen können?
Lo!
-
Hello,
[..] Somit vermeide ich das lästige Dateihandling!
Ooch, gerade Arrays lassen sich in Dateien ganz hervorragend speichern ;)Jedes Art Daten lässt sich ganz hervorragend in Dateien speichern, wenn man sie vorher serialisiert. Was sollte bei PHP-Arrays, die ja keine Arrays im herkömmlichen Sinne sind, sondern komplex strukturierte Gebilde sein können, besonders gut geeignet sein?
Zur "hervorragenden Datenspeicherung" gehört für mich allerdings in der Hauptsache die ungehinderte Zugriffsmöglichkiet, also möglichst ein "Random Access".
Das ist bei allen seriellen Datenformaten nicht möglich.
Da Dateien in üblichen Dateisystemen aber eindimensional, also seriell organisiert werden (an der API geschaut), muss man sich wieder Mthoden ausdenken, wie man diese Eigenschaft durchbrechen kann, wenn man schnellen Zugriff bei gleichzeitig kleinem Hauptspeicherbedarf wünscht.
-
serielle Dateien
-
serielle Dateien mit fester Satzlänge aber varianter Feldlänge
-
Random Access-Dateien mit fester Satzlänge und fester Feldlänge
-
Baumstrukturen mit festem Seitenaufbau
-
...
usw.
Irgendwann ist man dann sowieso bei der Datenbank angekommen
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi!
Ooch, gerade Arrays lassen sich in Dateien ganz hervorragend speichern ;)
Jedes Art Daten lässt sich ganz hervorragend in Dateien speichern, wenn man sie vorher serialisiert. Was sollte bei PHP-Arrays, die ja keine Arrays im herkömmlichen Sinne sind, sondern komplex strukturierte Gebilde sein können, besonders gut geeignet sein?
Zur "hervorragenden Datenspeicherung" gehört für mich allerdings in der Hauptsache die ungehinderte Zugriffsmöglichkiet, also möglichst ein "Random Access".Ja, da stimme ich dir zu. Nur sind PHP-Arrays nicht dafür geschaffen, dass man sie einfach so in dieser Form ablegen kann. Das geht nur, wenn man sich strikt an ein paar Regeln hält: Die Struktur der Daten muss immer gleich sein, ebenso ihre Größe. Auch Strings dürfen die vorher festgelegte Länge nicht überschreiten. Und dann muss man sowas wie pack() verwenden, dem man aber nur einzelne Werte und keine Arrays übergeben kann. Mit call_user_func_array() bekommt man da was hin, aber schon bei zweidimensional aufgebauten Arrays hat man wieder das Nachsehen in Form einer selbst zu schreibenden Schleife, mit der man sich durch eine der beiden Dimensionen bewegen muss. "Ganz hervorragend" geht deutlich anders. Mit einem serialize() hat man die komplexeste und unregelmäßigste Struktur in einem Rutsch geschrieben. Nur wahlfreier Zugriff ist dann nicht möglich.
Lo!
-
hi,
Zur "hervorragenden Datenspeicherung" gehört für mich allerdings in der Hauptsache die ungehinderte Zugriffsmöglichkiet, also möglichst ein "Random Access".
Das ist bei allen seriellen Datenformaten nicht möglich.
Richtig, Tom, eine Sequenz wird sequentiell erzeugt und gelesen, das ist die Physik der Bytes. Auf der Physik kann jedoch eine Logik sitzen, die einen Quasi-Random-Access ermöglicht, nämlich über die vom Deserialize-Prozess gelieferte Datenstruktur.
Falls du ab und zu mal was mit Perl machst, in der letzten Ausgabe der $foo gibt es dazu einen Artikel von mir ;-)
Perl-Magazin ab Seite 34...
Es ist jedoch so, dass eine Sequenz, weil sie eben von a-z gelesen werden muss, komplett im Hauptspeicher liegt. Ich habe vor einiger Zeit ein Modul entwickelt, womit die Datenmenge auf ein Minimum beschränkt wird. Serialisiert wird eine Objektsammlung (in Perl: Hash of Hash). Deserialize liest nur die Namen der Objekt-Attribute und die Position in der Sequenz sowie den Offset. Erst wenn der Wert eines Attributes abgefragt werden soll, werden über Position und Offset die Bytes aus der Datei gelesen.
Je nachdem, wie die Objekte beschaffen sind, Beispiel: eine komplette Website mit 100 Einzelseiten belegt 2 MB in der Datei, im RAM liegen dann nur 200 kB. Der Quasi-Random-Access auf die Datei erfolgt in der Anwendung über die Datenstruktur.
Hotti
-
Hello,
Zur "hervorragenden Datenspeicherung" gehört für mich allerdings in der Hauptsache die ungehinderte Zugriffsmöglichkiet, also möglichst ein "Random Access".
Das ist bei allen seriellen Datenformaten nicht möglich.
Richtig, Tom, eine Sequenz wird sequentiell erzeugt und gelesen, das ist die Physik der Bytes.
Auf der Physik kann jedoch eine Logik sitzen, die einen Quasi-Random-Access ermöglicht, nämlich über die vom Deserialize-Prozess gelieferte Datenstruktur.
Ach *ächz*
"Random Access" zu emulieren ist ungefähr genauso, wie eine Erregung durch Viagra zu simulieren.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
moin Tom,
"Random Access" zu emulieren ist ungefähr genauso, wie eine Erregung durch Viagra zu simulieren.
Nein, ich werde mein neues Modul nicht Viagra nennen.
Schönen Sonntag ;)
Hotti
PS: Das neue Modul steht wie Ast. Es lädt alle HTML-Templates aus?
_einer_ Datei ;)API: Wahlweise über eine Methode oder eine gebundende Datenstruktur.
-
hello,
Auf der Physik kann jedoch eine Logik sitzen, die einen Quasi-Random-Access ermöglicht, nämlich über die vom Deserialize-Prozess gelieferte Datenstruktur.
Ach *ächz*
So, Tom! Du hasts mal wieder geschafft! Mein neues Modul für die Templates wird einen echten Random-Access bekommen und zwar auf Byte-Ebene, jawoll!
Ich bin grad dabei, den Algorithmus zu programmieren, es wird einen Adressblock am Anfang der Datei geben, wo Position und Offset der Inhalte weiter hinten stehen. Der wahlfreie Zugriff 'Lesen' geht dann so:
- Adressblock lesen, Ermitteln Position und Offset für die Daten (Definitionsliste für Platzhalter als Array und Template als Scalar)
- Zeiger positionieren und Daten lesen
Aber drei Dinge bleiben sequentiell: Create, Insert, Update.
Hotti
-
Hello,
So, Tom! Du hasts mal wieder geschafft! Mein neues Modul für die Templates wird einen echten Random-Access bekommen und zwar auf Byte-Ebene, jawoll!
Ich bin grad dabei, den Algorithmus zu programmieren, es wird einen Adressblock am Anfang der Datei geben, wo Position und Offset der Inhalte weiter hinten stehen. Der wahlfreie Zugriff 'Lesen' geht dann so:
- Adressblock lesen, Ermitteln Position und Offset für die Daten (Definitionsliste für Platzhalter als Array und Template als Scalar)
- Zeiger positionieren und Daten lesen
Aber drei Dinge bleiben sequentiell: Create, Insert, Update.
Wirklich gewonnen hast Du nur etwas, wenn zum Holen, Einfügen, Ändern oder Löschen der Daten nicht jedesmal die gesamte Datei gelesen werden kann.
Bei einer sequentiellen Datei kann man keine Daten holen, sondern nur suchen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
hi,
Wirklich gewonnen hast Du nur etwas, wenn zum Holen, Einfügen, Ändern oder Löschen der Daten nicht jedesmal die gesamte Datei gelesen werden kann.
Das schießen wir mal nicht alles über einen Haufen ;-)
Aufm Webserver, wo es schnell gehen muss, haste schon viel gewonnen, wenn nur das Lesen der Daten optimiert ist.
Bei einer sequentiellen Datei kann man keine Daten holen, sondern nur suchen.
Unabhängig davon, wie die Datei erzeugt wurde, ein wahlfreier Zugriff muss ja auch erstmal wissen, wohin er greift. Dafür gibt es einen Index und der muss in jedem Fall gelesen werden. Der Index ist freilich viel kürzer als die ganze Datei und kann entweder in der gleichen Datei oder ein einer weiteren Datei hinterlegt sein. Die Adressierung mache ich linear.
Du wirst auch bei einem Random-Access-Feature nicht umhin kommen, die Daten sequentiell zu lesen, sprich: Zeiger an Position x, lese y Bytes.
Der Kompromiss liegt wie immer zwischen CPU und RAM ;)
Hotti
-
-
-
-
-
-
-
Hi!
Ich arbeite seit langem mit MySQL habe jetzt aber einen Fall in welchem mir eine MySQL-Datenbank übertrieben und unpraktisch vorkommt. Als Alternative speichere ich jetzt einen serialized-String in eine Textdatei. Klappt bestens. Meine Frage lautet: Spricht etwas gegen diese Methode sofern der Einsatz in kleinem Rahmen erfolgt?
Grundsätzlich nicht. Zu Beachten ist, dass Datenbankhandling eine Vorbereitung erfordert (Connection aufbauen), das Dateihandling allerdings auch noch in Bezug auf konkurrierenden Zugriff berücksichtigt werden muss. Das DBMS hat das bereits eingebaut. Eine Alternative kann auch SQLite sein, das für Anwendungen konzipiert ist, wo ein DBMS überdimensioniert ist, das Dateihandling jedoch auch nicht glücklich macht.
Sicherheit? Geschwindigkeit?
Welche Sicherheit meinst du? Gegen Ausfälle, gegen unerlaubte Zugriffe, gegen was anderes? Geschwindigkeiten sind keine konstante Größe. Je nach Konstellation kann das eine oder das andere schneller oder langsamer sein.
Lo!
-
Hello Phil,
Ich wollte mich kurz nach Eurer Meinung erkundigen. Ich arbeite seit langem mit MySQL habe jetzt aber einen Fall in welchem mir eine MySQL-Datenbank übertrieben und unpraktisch vorkommt. Als Alternative speichere ich jetzt einen serialized-String in eine Textdatei. Klappt bestens. Meine Frage lautet: Spricht etwas gegen diese Methode sofern der Einsatz in kleinem Rahmen erfolgt? Sicherheit? Geschwindigkeit?
Wenn ein nur begrenztes Projekt mit wenig Daten gebaut werden soll, sind Flatfiles durchaus eine sinnvolle Alternative. Der Vorteil ist, dass die Sicherung des Projektes "in einem Rutsch" stattfinden kann. Es muss lediglich die Datenveränderung für einen Moment unterbunden werden und alle Dateien, die zur Domain gehören, in ein TAR-File kopiert werden (incl. Rechten). Dann kann das Projekt bereits wieder weiterlaufen. Beim Rücksichern muss nur das TAR-File entpackt werden, und es kann losgehen.
Dennis und ich haben hier mal ein paar Überlegungen zu Flatfile-Lösungen angestellt.
http://tutorial.riehle-web.com/scripts/index.php#flatboxDer Vorteil einer Datenbanklösung zeichnet sich dann ab, wenn der Datenbestand größer wird, die Verknüpungen zwischen den Daten komplexer werden, usw.
Da der Datenbankserver getrennt vom Request als Dienst läuft, muss nicht bei jedem Request der gesamte relevante Datenbestand geladen werden, sondern es müssen nur diejenigen Daten gesucht und geholt werden, die den Request befriedigen können.Außerdem muss nicht für jede Domain ein eigener Datenbankserver laufen.
Die Sicherheit ist diejenige, die man von einem Datenbankmanagementsystem erwarten kann.
Was jedoch bei beiden Systemen immer wieder gerne vergessen wird, ist der konkurrierende Betrieb im zustandslosen Bereich. Die Eigenheiten von HTTP/s werden nicht einmal mangelhaft berücksichtigt, sondern nur ungenügend. Immer, wenn mehrere Roundturns für das Hinzufügen, Verändern oder Löschen von Daten benötigt werden, muss dies entspechend berücksichtigt werden. Bei MySQL muss man dies noch selber im Datenmodell und in der API / Sessionverwaltung tun.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
Ich wollte mich kurz nach Eurer Meinung erkundigen. Ich arbeite seit langem mit MySQL habe jetzt aber einen Fall in welchem mir eine MySQL-Datenbank übertrieben und unpraktisch vorkommt. Als Alternative speichere ich jetzt einen serialized-String in eine Textdatei. Klappt bestens. Meine Frage lautet: Spricht etwas gegen diese Methode sofern der Einsatz in kleinem Rahmen erfolgt? Sicherheit? Geschwindigkeit?
den direkten zugriff auf die datei u.u. verhindern, nicht dass man bei example.com/testFolder/my_serialized_data.ser eine antwort bekommt.
ansonsten habe ich das eine zeit lang so gemacht. allerdings nicht in einer textdatei alles, sondern die datensätze fortlaufend nummeriert, so dass dann die datei 8023 zb. ein entsprechendes serialisiertes datenfile eben dieser id ist.
Gruß
jobo
-
Hi!
den direkten zugriff auf die datei u.u. verhindern, nicht dass man bei example.com/testFolder/my_serialized_data.ser eine antwort bekommt.
Am besten, indem man sie außerhalb des DocumentRoots lagert, wie alles, was nicht ausgeliefert werden soll. Ein Verbot ist nur die zweitbeste Lösung.
Lo!
-