XML - Speichercheck

[Alice]

So...

Ich habe das ganze nun mit nur einem Query gelöst. ABER: Nun braucht das Skript leider wieder über 120 MB pro Lauf... weil halt die Tabelle groß ist.

Die Tabelle schaut so aus:

|Spalte1|Spalte2|Spalte3|Spalte4|

Ich brauche pro Lauf ca. 15 Datensätze. Dabei durchsuche ich "Spalte1".

Jemand ne Idee wie ich mit einem Query "Spalte1" durchsuchen kann, ohne die ganze Tabelle zu laden?

 

[sheel]

Standardfrage: Hast du einen passenden Index?

 

[Bratkartoffel]

Vielleicht hast Du recht, aber das eine Skript verbraucht das 28 Fache wie das andere... Wenn das Skript nur 500 mal auf Tag aufgerufen wird ist das ein 14000er Facher unterschied . Das wären 59500 MB (mehr Verbrauch) am Tag.

Hi,

na das ist aber eine schöne Milchmädchen Rechnung Natürlich ist das alles andere als optimal wenn ein Script so viel Speicher braucht. Aber wenn das Script durch ist, wird der Speicher wieder freigegeben und kann für den nächsten Lauf wiederverwendet werden.

Bin mir nicht mehr ganz sicher, aber die Wiederverwendung von Speicher und das cachen von compilten PHP-Scripten ist auch für deine Rechnung relevant, vorallem für die Laufzeit. Konkrete, vergleichbare Ergebnisse bekommst du nur wenn du den Server zwischendurch neustartest.

Grüsse,
BK

 

[Alice]

@Bratkartoffel

Ich bin nie davon ausgegangen das mein Test einer Wissenschaftlichen Überprüfung standhält, aber als guter "Wegweiser" wird das schon reichen. Ob nun ein Skript 3 MB oder 125 MB braucht, könnte auf dauer auf einem Webhosting Server zu einem Problem werden, wenn meine Skripte andere Kunden "beeinträchtigen". Daher schau ich auch gerne mal nach, ob das Teil für einen reelen Betrieb geeignet ist. Weiter gehe ich davon aus, dass man Primär immer versuchen sollte zu optimieren.

Mangels wissen muss ich - jetzt - davon ausgehen, dass eine XML-Datei mit einer "einfachen Verschachtelung" und viel Inhalt komplett geladen wird, während eine XML-Datei mit komplexer Verschachtelung nicht komplett geladen wird. In meinem Fall liegen da halt ~ 120 MB dazwischen. Das kann man eigentlich sogar mit dem Taschenrechner ausrechnen, denn die XML-Datei ist knapp 120 MB groß. PHP-Speicherverbrauch + XML-Speicherverbrauch = ~ 120 MB.

Da ich nun "praktisch" nicht weiss, wie eine XML-Datei auf mehrere Anfragen auf einmal (mehrere Clienten) "reagiert" (z.B. Ladezeit) bin ich vorerst auf MySQL umgestiegen. Ist schnell und schont den Speicher. Ich bin zwar nicht sehr glücklich damit, aber eine Alternative fällt mir nicht ein.

@sheel

?

 

[sheel]

Hast du einen passenden Index?

@sheel
?

Also vermutlich nicht
Wenn deine Tabelle tab heißt, was gibt folgendes aus:

SHOW TABLE STATUS FROM tab;

und

SHOW COLUMNS FROM tab;

Außerdem:
Welche der ausgegebenen Spalten ist die "Spalte1", die durchsucht wird?

Was ist da drin? (weil ich im Vergleich mit der XML-Datei oben etwas den Zusammenhang verloren habe)

Wird nur so gesucht, dass die ganzen Werte vergleichen werden, oder werden auch Textteile etc. gesucht?
Oder, falls es Zahlen sind, von-bis-Sachen im Select? Oder...

 

[Alice]

Also die Querys sehen so aus:

"SELECT * FROM `Kaffee` WHERE `Kaffee_ID` = 'Gold'"
"SELECT * FROM `Kaffee` WHERE `Kaffee_ID` = 'Platin'"
"SELECT * FROM `Kaffee` WHERE `Kaffee_ID` = 'Bronze'"
"SELECT * FROM `Kaffee` WHERE `Kaffee_ID` = 'Silber'"

Die "Kaffee ID'S" sind natürlich alle einmalig.

 

[Alice]

@sheel

Vielleicht habe ich mich etwas unglücklich ausgedrückt. Ich durchsuche immer die selbe Tabelle in einer Datenbank.

Beispiel:

Kaffee_ID || Kaffee_SD || Kaffee_PD || Kaffee_UI
==============================
0101_01 || 0101_02 || 0101_03 || 0101_04
0202_01 || 0202_02 || 0202_03 || 0202_04
0303_01 || 0303_02 || 0303_03 || 0303_04

 

[sheel]

Kannst du bitte trotzdem die Sachen von oben beantworten, und ohne Platzhalter?

 

[Alice]

Da steht (SHOW TABLE STATUS FROM Kaffee):

#1044 - Access denied for user 'XXXXXXXX'@'%' to database 'Kaffee'

Das andere (SHOW COLUMNS FROM Kaffee)

Field Type Null Key Default Extra
Kaffee_ID varchar(128) NO
Kaffee_SD varchar(128) NO
Kaffee_PD varchar(128) NO
Kaffee_UI longblob NO NULL

 

[Bratkartoffel]

Hi,

da Kaffe_ID anscheinend dein Primärschlüssel ist (du verwendest den als Bedingung für deine Selects und er ist Unique) würde ich da der Datenbank auch mal einen Index drauf legen lassen:

ALTER TABLE Kaffee
ADD PRIMARY KEY (Kaffee_ID)

Das sollte die Suche je nach Grösse der Tabelle um einiges schneller machen.

Grüsse,
BK