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 _______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.com/
