Als ich mich gestern daransetzte, ein Backup dieses Blogs zu machen, fiel ich fast vom Stuhl. Meine mySQL-Datenbank ist fast 13 MB groß!
Ich kenne mich mit so etwas zwar nicht sonderlich aus, jedoch fand sich im Netz schnell ein Vergleich, der mich ziemlich verzweifeln lies:
Auf dem BasicThinking Blog sind es insgesamt ~9 MByte bei
ca. 2.700 Postings und ~6.900 Kommentaren, die zusammen mit SpamKarma den Großteil der Tabellengesamtgröße ausmachen.
Hm, Der Eckpfeiler nimmt sich da doch etwas bescheidener aus, mit 226 Beiträgen und 194 Kommentaren. Nur datenbanktechnisch ist es schon ein dicker Hund!
Hat evtl. einer meiner Leser eine Ahnung, wie ich das wieder auf ein “gesundes” Maß zurückschrumpfen kann? Oder macht das eigentlich gar nichts aus, so lange der Server eine entsprechende Leistung hat? Denn irgendwie bin ich ziemlich verunsichert, ob die vermehrten mySQL-Timeouts und die daherrührende gelegentliche Unerreichbarkeit dieses Blogs nicht doch evtl. auf die Größe der Datenbank zurück zu führen sind.
schau Dir mal die einzelnen Tabellen mit der Bezeichnung wp_xy…. an (alle WP-Tabellen fangen deafultmäßig mit “wp_” an, es sei denn, Du hast bei der Installation in der wp-config.php was anderes vorgegeben)…
wie groß sind die einzelnen Tabellen?
Hi Ecki,
also ich glaub ja, dass ich dir auch nicht viel weiterhelfen kann…aber da ich mich auch mit Datenbanken beschhäftige und sowieso mehr Kommentare hinterlassen könnte, scheiß ich einfach mal ein bisschen klug
Ich denke auch, dass die Größe der DB bisschen heftig ist.
Es könnte daran liegen, dass die DB schlecht designed ist (z.B. Abhängigkeiten nicht richtig aufgelöst sind etc.). Jedoch denk ich mal, dass du ein “Standardprodukt” einsetzt, das die DB selbst angelegt hat bzw. vorgefertigte Scripts dabei waren. Folglich denke ich nicht, dass es daran liegt, da sich die Entwickler sicher Gedanke gemacht haben. Kannst ja trotzdem mal schauen, ob gleiche Felder (Spalten) in verschiedenen Tabellen vorkommen. Das würde dann heißen, dass gleiche Daten mehrfach gespeichert werden.
Außerdem könnte es sein, dass die DB im vorraus schon Speicher belegt (kenn ich so von Oracle). Also ich weiß nicht wie das mySql macht…in Oracle “sagt” man der DB beim Erstellen wieviel Speicher sichergestellt werden soll, reicht dann der angelegte Speicher nicht mehr holt sie sich eben wieder was (wieviel/wie/… ist konfigurierbar). D.h. die DB belegt auf der Platte z.B. 13 MB braucht aber nur x MB, der Rest ist einfach schon reserviert…sind die 13 MB dann irgendwann “verbraucht” reserviert sie sich wieder Speicher usw.
So das wars jetzt fürs erste…vielleicht kennt sich ja noch jmd. besser aus und kann meinen Beitrag verbessern/korrigieren/erweitern oder einfach für unfachlich/blöd/super/absoluten Schwachsinn erklären.
Naja dann viele Grüße,
dani
Hi Ecki,
hmm eigentlich ists nicht so tragsich und bei der Geschwindigkeit dürfte es nichtsausmachen wie groß sie ist, da du ja nicht die ganze db abfragst beim aufrufen der seite sondern nur die letzten x einträge.
Komisch ist es aber schon dass deine so groß bei der doch überschaulichen Anzahl von Einträgen ist. Hast du dir die Tabellen in deiner db schon mal angeschaut? Kommen vielleich einträge doppelt vor? Hmm einfach mal in die DB reingucken, sonst wüsst ich auch net woher die Größe kommen könnte
grüße
Germ
Entschuldigt die späte Antwort, ich kam leider erst jetzt dazu. Außerdem hat Askimet (mein Spamfilter) einzelne Kommentare als Spam definiert und so in der Moderationsschleife gehalten.
Ich habe mir die Datenbank jetzt einmal näher angesehen und schätze, dass es an FAlbum, meinem Gallerie-Plugin liegt. Ca. 70% des Inhalts der DB beginnt zumindest mit dem Präfix wp_falbum. Ich schätze einmal, dass es sich dabei um den Cache für die Bilder handelt, die ja ursprünglich auf flickr liegen.
So, mal schauen, ob ich daran etwas ändern kann. Falls nicht, fliegt Falbum wieder aus dem Sortiment
Ich habe gerade einmal den Bildercache geleert und plötzlich sind es nur noch 1,12 MB. Danach muss ich wohl noch genauer schauen.
Die Performance hat sich IMO dennoch nicht verbessert. Das liegt dann wohl doch am lahmen DB-Server von 1blu.