wohl ne ganz doofe Frage: gibt es eigentlich irgendwann Probleme mit der Nummerierung der IDs? So ist zB die höchste Kommentar-ID bald bei 800.000 angekommen (spam….). Oder läuft das bis zum Tag des Jüngsten Gerichts fröhlich weiter?
Neue Stellenangebote
Growth Marketing Manager:in – Social Media GOhiring GmbH in Homeoffice |
||
Social-Media-Manager, befristet für 2 Jahre (m/w/d) Deutsche Kreditbank AG (DKB) in Berlin |
||
Social Media Manager (m/w/d) Young ISO Media GmbH in München, Hybrid |
||
Social Media Manager:in (m/w/d) SCHULZ Systemtechnik GmbH in Visbek (zwischen Cloppenburg und Vechta) |
||
Social Media Manager (m/w/d) Pronova BKK in Leverkusen |
||
Social Media Manager (m/w/d) Finanzen HAPEKO Deutschland GmbH in Hamburg, Berlin, Frankfurt am Main, München, Köln |
||
(Senior) Social Media Manager (m/w/d) Rödl Rechtsanwälte Steuerberater Wirtschaftsprüfer Unternehmens- und IT-Berater in Nürnberg |
||
(Senior) Manager (w/m/d) Social Media B. Braun Melsungen AG in Melsungen |
Das verwendete INT-Feld dürfte 10 bis 12 Stellen haben. Da können noch ein paar Kommentare zusammenkommen.
Kritisch wird bestenfalls die Suche. Wenn es lahmarschig wird, solltest nachschauen, welche Indexes existieren und ggf. passende Indexes (manchmal über mehrere Felder) erzeugen. Die brauchen zwar Plattenplatz, bringen aber wirklich Speed.
Kommt ganz drauf an, auf welches Nummernformat die ID in MySQL eingestellt ist. Im Normalfall steht sie auf Integer, da kommst Du locker bis zwei Milliarden – für’s Erste also kein Grund zur Sorge 😉
Sofern ich jetzt nicht falsch liege, müsste das bis ID Nummer 18446744073709551615 ausreichen (ist ein Bigint).
@Mathias, nutze dieses DB-Plugin, das die Indices angeblich besser setzt als WP selbst
@Al, danke, das sollte reichen, in der Tat:))
Naja, je nach integer wert kann es von 1-100 (8 Bit) gehen bis 1 … 10^38 (128 bit)
http://de.wikipedia.org/wiki/Integer_%28Datentyp%29
würde ich sagen. Was mysql da benutzt weiß ich nicht
Bei meiner WordPress-Installation ist das ein BIGINT-Feld mit der Länge von 20 Bytes. Das macht insgesamt 2^8 (ein Byte) ^ 20 mögliche Zahlen, sprich: 7,3 * 10^47 positive Werte. Sollte also auch mit relativ hohem Spamaufkommen so ein bis zwei Monate reichen… 😉
jo, ist knapp, schauen wir mal
Keine Ahnung, wie WP die Indexes selbst handhabt und wie die mit Plugins zu verbessern sind. Mir ist schon vorgekommen, dass der Datenbanknutzer keine Rechte hatte, Indexes zu erzeugen (mea culpa). Da muss man dann halt irgendwann von Hand ran. Wenn manche Queries etwas träge sind, kannst Du ja mal das Slow-Query-Log vornehmen und die fiesesten Abfragen ermitteln:
http://techblog.tilllate.com/2006/12/23/optimierung-von-mysql-abfragen-der-slow-query-log/
Ich vermute aber einfach mal, dass der Autor des ungenannten Plugins nix wesentlich anderes gemacht hat…
BIGINT signed oder unsigned?
Signed gehts bis 9.223.372.036.854.775.807
unsigned gehts bis 18.446.744.073.709.551.615
meint zumindes die mysql-doku.
Also ich bezweifle dass bigint als type der ID verwendet wurde, sondern viel eher INT(10). Aber nicht irrefuehren lassen das heisst nicht dass 10 stellen zur verfuegung stehen denn ein INT ist 4 Byte gross:
Signed max: 2147483647
Unsigned max: 4294967295
Wieso es nicht 10 stellen sind entnimmt man am besten der Doku ( http://dev.mysql.com/doc/refman/4.1/en/numeric-types.html ) aber kannst beruhigt sein, selbst problogger.com hat das maximum noch nicht ueberschritten ^^
und die WP ID ist vom Typ BIGINT (unsigned) also kannst bis IDs bis 4.294.967.295 produzieren.
Bei dem Tempo in diesem Blog ist das aber sicher bald erreicht 😉
warum löschst du nicht die spam kommentare raus? wenn die den größten anteil an den kommentaren haben bringt das sicher auch etwas performace, gibt es auch plugins dazu – wenn du nicht direkt auf die DB willst
@ Robert
Die Kommentar-ID wird fortlaufend nummeriert, auch wenn der Kommentar 1 gelöscht wurde, bekommt der zweite die Nummer 2, usw. usf. 😉
@Gerhard: Bei unsigned BIGINT kann der Counter bis 18.446.744.073.709.551.615 gehen (siehe mein Kommentar weiter oben)!
Und ja, es handelt sich tatsächlich um ein unsigned BIGINT:
http://codex.wordpress.org/Database_Description#Table:_wp_comments
Dann werden wir jetzt so lange dämliche Kommentare ablassen, bis wir den Wraparound schaffen.
rofl:))
@robert, Akismet löscht ja die Einträge, wie aber Michael bereits gesagt hat, es wird die nächsthöhere ID genommen, nicht die nächste freie ID ab 1. Logisch, alles andere wäre bisserl aufwendig.
@ Maggi
Ich glaube selbst mit der laufenden Unterstützung der Spammer, schaffen wir das nicht mehr zu unseren Lebzeiten…
Aber wir können es probieren. 😀
@michael
weiß ich es ging mir einfach darum das man durch das löschen der spam einträge weniger datensätze hat und dadurch evtl. bessere performance
@robert
ich kann es leider gerade nicht prüfen aber bist du dir da 100% sicher? kann sein das ich mich irre aber ich dachte die bleiben trotzdem in den untiefen der DB
100%, da ich sonst knapp 1 Mio Datensätze hätte in der comments-table, so habe ich irgendwas über 50.000.
Huhu 🙂
Das mit den BIGINTs bei MySQL mag zwar stimmen, aber problematisch wird es bei der Frage wie WordPress in PHP mit den Integern umgeht.
Integer in PHP sind 32 bit signed. Also um die 2 Milliarden. Je nachdem, wie WordPress programmiert ist, kann es zu einem Überlauf kommen.
Bei bis zu 2.147.483.647 Kommentaren bist du aber auf der sicheren Seite 😉
Werden die Kommentare bei Akismet erst gespeichert und dann bei Spam wieder gelöscht? Da wäre Potenzial zur Optimierung.
@Seong, hey, hallo:)))) Wie gehts? Btw, danke für die Aufklärung, scheint ja noch genug Luft nach oben zu sein.
@Martin, ja, richtig, einfach deswegen, um false positives wieder rausnehmen zu können, werden die Spameinträge nicht sofort gelöscht.
@Robert: Wenn wir dazu übergehen uns über deine Kommentare zu unterhalten, dann reicht so ein 32 bit signed INT nicht aus… pfff… lächerlich 😀