nicht angemeldet
Anscheinend ein Größenproblem mit serialize
Hi,
ich mache eine Datenbankabfrage und lasse mir das Ergebnis dann anzeigen. Nun möchte ich das Ergebis nachträglich nach verschiedenen Kriterien sortieren lassen. Da ich keine Lust habe die gesamt Abfrage nochmal durchzuführen hab ich mir gedacht, dass ich ja den Array mit den Resultaten der Abfrage mit serialize verpacken kann, dann noch ein base64_encode drüber und das ganze dann in einen longblob in die Datenbank.
Bei meinen ersten Tests mit wenigen Datensätzen hat das auch wunderbar geklappt, auch wenn meine Einträge in die Datenbank schon recht groß waren (ca. 500 kb pro Eintrag).
Nun will ich meine Abfrage über die gesamte Tabelle laufen lassen, die ca. 500000 Einträge hat und dementsprechend auch mehr Treffer liefert.
Dabei ist mir aufgefallen, dass serialize anscheinend ein Problem mit größeren Datenmengen hat.
Wieviel verkraftet serialize oder könnte bei mir da ein anderes Problem schuld sein ??
Danke
ff
-
Hello,
serialize hat bestimmt kein Problem:
http://forum.de.selfhtml.org/archiv/2004/5/82138/
Aber wozu base64?
mysql_escape_string() wäre richtig, wenn es eine MySQL-DB ist!
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau -
Moin!
ich mache eine Datenbankabfrage und lasse mir das Ergebnis dann anzeigen. Nun möchte ich das Ergebis nachträglich nach verschiedenen Kriterien sortieren lassen. Da ich keine Lust habe die gesamt Abfrage nochmal durchzuführen hab ich mir gedacht, dass ich ja den Array mit den Resultaten der Abfrage mit serialize verpacken kann, dann noch ein base64_encode drüber und das ganze dann in einen longblob in die Datenbank.
Hm, nochmal langsam zum Mitlesen: Weil es dir aus irgendwelchen Gründen nicht behagt, einmal
SELECT felder FROM tabelle WHERE xyz
zu machen und erneut
SELECT felder FROM tabelle WHERE xyz ORDER BY sortier
nachzuschieben, hast du dir überlegt, dass es vielleicht sinnvoller ist, stattdessen
INSERT INTO blobtabelle (blobfeld) VALUES ('ganzlangerserializestring')
SELECT blobfeld FROM blobtabelle WHERE blobid
DELETE FROM blobtabelle WHERE blobid
anzuwenden.Du ersetzt also einen SQL-Ausdruck durch mindesten drei SQL-Ausdrücke, welche darüber hinaus auch noch schreibend auf die Datenbank (bzw. die Blobtabelle) zugreifen - eine Operation, die immer verhältnismäßig langsam ist, weil man dazu die Tabelle (zumindest aber die betroffenen Spalten) exklusiv für Lesezugriffe sperren muß.
Performancemäßig gewinnst du auch nichts, weil die zu übertragende Datenmenge grob geschätzt gleich ist - wahrscheinlich aber eher mehr, wenn du mit serialize arbeitest.
Dabei ist mir aufgefallen, dass serialize anscheinend ein Problem mit größeren Datenmengen hat.
Sicher, dass serialize() der Grund ist? Oder könnte auch die Anbindung der Datenbank oder die zur Verfügung gestellte Spalte das Problem sein?
- Sven Rautenberg
-
Du ersetzt also einen SQL-Ausdruck durch mindesten drei SQL-Ausdrücke, welche darüber hinaus auch noch schreibend auf die Datenbank (bzw. die Blobtabelle) zugreifen - eine Operation, die immer verhältnismäßig langsam ist, weil man dazu die Tabelle (zumindest aber die betroffenen Spalten) exklusiv für Lesezugriffe sperren muß.
Performancemäßig gewinnst du auch nichts, weil die zu übertragende Datenmenge grob geschätzt gleich ist - wahrscheinlich aber eher mehr, wenn du mit serialize arbeitest.
Das Problem hierbei ist nicht die zu übertragende Datenmenge sondern ehr die Abfrage, die sehr komplex ist und zudem über viele Datensätze geht. Es geht dabei um eine Statistik.
Wenn ich also die Abfrage mache dauert das ganze dann ca. eine Minute bis mein Ergebnis kommt. Wenn ich das nun noch sortieren will dauert es ja wieder eine Minute bis das sortierte Ergebnis kommt.
Ich sortiere ja außerdem nicht mit Hilfe von ORDER bei der Abfrage direkt sondern nachdem ich meine Werte habe innerhalb von verschiedenen Arrays, die aus meiner Abfrage erzeugt werden mit Hilfe von Multisort.Deswegen wollte ich halt die nochmalige Abfrage vermeiden.
Sicher, dass serialize() der Grund ist? Oder könnte auch die Anbindung der Datenbank oder die zur Verfügung gestellte Spalte das Problem sein?
Es sollte an serialize liegen, da mir halt aufgefallen ist, dass bei kleineren Datenmengen (ca. 1000 Treffer mit jeweils 5 Werten) keine Probleme auftreten, bei größeren (ab 5000 Treffer mit jeweils 5 Werten) er dann aber das serialize nich mehr macht.
Ich hab dann halt ein Array mit 5000 Arrays drin, die jeweils auch wieder 5 Werte haben.mfg
ff-
Hello,
Es sollte an serialize liegen, da mir halt aufgefallen ist, dass bei kleineren Datenmengen (ca. 1000 Treffer mit jeweils 5 Werten) keine Probleme auftreten, bei größeren (ab 5000 Treffer mit jeweils 5 Werten) er dann aber das serialize nich mehr macht.
Ich garantiere Dir, dass es bis zu einer Datenmenge von ca. 1/4 des verfügbaren Scriptspeichers nicht an serialize() líegt. Den nis und ich haben nicht 119 Seiten Thread mit Content erzeugt und uns dabei nur die ... geschaukelt!
Es liegt aber mit 99,9% Wahrscheinlichkeit an der fejhlenden Escpae-Funktion!
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau -
Moin!
Wenn ich also die Abfrage mache dauert das ganze dann ca. eine Minute bis mein Ergebnis kommt. Wenn ich das nun noch sortieren will dauert es ja wieder eine Minute bis das sortierte Ergebnis kommt.
Deswegen wollte ich halt die nochmalige Abfrage vermeiden.
Dann benutze Sessions. Die sind exakt für den von dir vorgesehenen Zweck erdacht worden - außerdem mußt du dann das gesamte Handling des Speicherns etc. nicht mehr selbst erfinden, es ist einfach schon da.
- Sven Rautenberg
-
-
Hello,
na im Wesentlichen erstetz er doch eine unsichere dynamische Abfrage durch die Speicherung eines Snapshots...
Harzliche Grüße aus http://www.annerschbarrich.de
Tom
--
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
-