Re: [otrs-de] Mysql 5.0 ARCHIVE storage engine für article_plain und article_attachment

[André Bauer]

Hallo.

Viel einfacher wäre es, du speicherst das Zeugs im Dateisystem.
Gab auch mal nen Generic Agent in der Mailingliste, der das Ganze
verschiebt...

-- 
Mit freundlichen Grüssen
André Bauer
System: Debian 3.1 / Apache 2.0.54 / MySQL 4.1.11 / OTRS 2.0.4

============================================

RH> Hallo, 

RH> unser OTRS wächst und wächst und wächst - kein Ende
RH> abzusehen. Inzwischen haben wir 1 GB an Daten und es werden immer
RH> mehr. 

RH> Da noch keine Archivierungslösung in Sicht ist und ich mir
RH> gerade MySQL 5.0 angeschaut habe kam mir die Idee die neue Stroage
RH> Engine von MySQL 5.0 ARCHIVE zu nutzen (des weiteren einfach
RH> ARCHIVE genannt) um die Datenbank etwas zu verkleinern.


RH> - Die Einschwänkungen der Storage Engine sind : 
RH> 1) ARCHIVE kann nur INSERT und SELECT
RH> 2) ARCHIVE unterstützt keine Indexe
RH> 3) ARCHIVE unterstützt bis MySQL 5.1 kein auto_increment

RH> Als Kandidaten für die Einsparung habe ich mir article_plain
RH> und article_attachment ausgesucht, da diese beide jeweils > 400 MB
RH> sind und damit die größten Tabellen bilden. Weiterhin vermute ich,
RH> dass in diesen Tabellen von OTRS keine Änderungen vorgenommen
RH> (???) und damit kommen wir mit SELECT und INSERT, welche von
RH> ARCHIVE unterstützt werden aus. 

RH> Ist dies richtig ? 

RH> Eine weitere Frage ist ebenfalls ob die fehlenden Indexe
RH> nicht extreme Performance Einbußen bringen ? Ich habe etwas
RH> getestet und herausgefunden dass Anfragen teilweise das 1000fache
RH> länger dauern. 

mysql>> select article_id, change_time, create_time from
mysql>> article_plain where change_time = '2006-07-27 23:26:06';
RH> +------------+---------------------+---------------------+
RH> | article_id | change_time         | create_time         |
RH> +------------+---------------------+---------------------+
RH> |       9839 | 2006-07-27 23:26:06 | 2006-07-27 23:26:06 |
RH> +------------+---------------------+---------------------+
RH> 1 row in set (18.59 sec)

mysql>> select article_id, change_time, create_time from
mysql>> article_plain where article_id=9839;
RH> +------------+---------------------+---------------------+
RH> | article_id | change_time         | create_time         |
RH> +------------+---------------------+---------------------+
RH> |       9839 | 2006-07-27 23:26:06 | 2006-07-27 23:26:06 |
RH> +------------+---------------------+---------------------+
RH> 1 row in set (0.01 sec)

RH> In diesem Beispiel ist "article_id" mit einem Index versehen, "create_time" jedoch nicht.

RH> Ist dieser (zugegeben einfache) Plausibilitätstest korrekt
RH> und wird sich dann die Performance im OTRS (OTRS sucht doch immer
RH> über article_id oder ?) extrem verschlechtern ? 

RH> Ich frage deshalb, weil wenn ich eine Volltextsuche im Feld
RH> "Text" über das Frontend durchführe dauert diese nur wenige
RH> Sekunden. Dieses müsste ja aber auch alle article_plain
RH> durchsuchen. Daher die Vermutung, dassmein einfacher Test
RH> vielleicht nicht repräsentativ ist.  

RH> Bevor ich das Ganze ausprobiere, wollte ich die Liste erst
RH> ein Mal fragen, ob hier Erfahrungen hierzu vorhanden sind.

RH> Danke, 
RH> Robert Heinzmann