Mysql 5.0 ARCHIVE storage engine für article_plain und article_attachment
Hallo,
unser OTRS wächst und wächst und wächst - kein Ende abzusehen. Inzwischen haben wir 1 GB an Daten und es werden immer mehr.
Da noch keine Archivierungslösung in Sicht ist und ich mir gerade MySQL 5.0 angeschaut habe kam mir die Idee die neue Stroage Engine von MySQL 5.0 ARCHIVE zu nutzen (des weiteren einfach ARCHIVE genannt) um die Datenbank etwas zu verkleinern.
- Die Einschwänkungen der Storage Engine sind : 1) ARCHIVE kann nur INSERT und SELECT 2) ARCHIVE unterstützt keine Indexe 3) ARCHIVE unterstützt bis MySQL 5.1 kein auto_increment
Als Kandidaten für die Einsparung habe ich mir article_plain und article_attachment ausgesucht, da diese beide jeweils > 400 MB sind und damit die größten Tabellen bilden. Weiterhin vermute ich, dass in diesen Tabellen von OTRS keine Änderungen vorgenommen (???) und damit kommen wir mit SELECT und INSERT, welche von ARCHIVE unterstützt werden aus.
Ist dies richtig ?
Eine weitere Frage ist ebenfalls ob die fehlenden Indexe nicht extreme Performance Einbußen bringen ? Ich habe etwas getestet und herausgefunden dass Anfragen teilweise das 1000fache länger dauern.
mysql> select article_id, change_time, create_time from article_plain where change_time = '2006-07-27 23:26:06'; +------------+---------------------+---------------------+ | article_id | change_time | create_time | +------------+---------------------+---------------------+ | 9839 | 2006-07-27 23:26:06 | 2006-07-27 23:26:06 | +------------+---------------------+---------------------+ 1 row in set (18.59 sec)
mysql> select article_id, change_time, create_time from article_plain where article_id=9839; +------------+---------------------+---------------------+ | article_id | change_time | create_time | +------------+---------------------+---------------------+ | 9839 | 2006-07-27 23:26:06 | 2006-07-27 23:26:06 | +------------+---------------------+---------------------+ 1 row in set (0.01 sec)
In diesem Beispiel ist "article_id" mit einem Index versehen, "create_time" jedoch nicht.
Ist dieser (zugegeben einfache) Plausibilitätstest korrekt und wird sich dann die Performance im OTRS (OTRS sucht doch immer über article_id oder ?) extrem verschlechtern ?
Ich frage deshalb, weil wenn ich eine Volltextsuche im Feld "Text" über das Frontend durchführe dauert diese nur wenige Sekunden. Dieses müsste ja aber auch alle article_plain durchsuchen. Daher die Vermutung, dassmein einfacher Test vielleicht nicht repräsentativ ist.
Bevor ich das Ganze ausprobiere, wollte ich die Liste erst ein Mal fragen, ob hier Erfahrungen hierzu vorhanden sind.
Danke, Robert Heinzmann
participants (3)
-
André Bauer
-
Dominic Priesmann
-
Robert Heinzmann