Index über 3,5 Mio Dokumente

[0xse]

Hi, wir haben eine DB die is 15 GB groß und beinhaltet 3.500.000 Dokumente. Es gibt eine Webansicht in unserem Kundenbereich. Jetzt ist das Problem, dass stündlich einige tausend Datensätze in die Datenbank importiert werden. Also wird auch jedes mal der Index aktualisiert. Dafür braucht der Server schon länger als eine halbe Stunde. Gibt es da eine Möglichkeit das zu beschleunigen, möglichst ohne auf ein anderes DB System umzusteigen?

[Thomas Schulte]

Voll krass fetten Server hinstellen ....

[Thomas Schulte]

Auf 7.0.2 umsteigen. Da ist der Server um einiges schneller geworden. Oder die Datenbank kleiner machen. 3.5 Mio Dokumente sind ein wenig viel für eine Anwendung unter R5.

[0xse]

Voll krass fetten Server hinstellen ....

Dual Xeon 2,8 GHz, 8 GB RAM, 360 GB 320er SCSI, ... eigentlich ist der schon hübsch schnell.

Notes 7... ein weiterer Applikationsserver ist geplant. Aber von der GL noch nicht bewillig :/ Naja, spätestens wenn die Kunden meckern, kommt er

Gibt es denn unter 5 noch irgendwelche Schräubchen an denen sich drehen läßt?

[Glombi]

Muss denn der Index immer aktuell gehalten werden?
Falls nicht, kann man den Index einmal nachts aktualisieren lassen (per Ansichtseigenschaften).

Andreas

[0xse]

Jup. In der DB werden abgewiesene Spam Mails erfasst. Wenn der Kunde jetzt sehen möchte ob eine Mail, die er erwartet, abgewiesen wurde, sollte die DB schon aktuell sein. Wir hatten zeitweise eine serverseitige Index Aktualisierung konfiguriert, über einen Agenten. Die Ansicht war auf Aktualisierung manuell gestellt. Allerdings wurde die Ansicht vom Agenten nicht inkrementell sondern immer komplett aktualisiert, weiß der Deubel warum... war jedenfalls nicht tragbar das die DB jede zweite halbe Stunde nicht erreichbar war. Im Moment wird sie relativ regelmäßg von Hand via aufrufen inkrementell aktualisiert.

Bzw sie werden: Es gibt drei Ansichten die für die Darstellung der Daten im Web benötigt werden.

[Thomas Schulte]

Wie lange verweilen die Daten denn in der Datenbank?
Wenn es geht würde ich das aufteilen. Eine Newest Spam Mails und eine Archived Spam Mails.

[0xse]

Ein halbes Jahr, wie es gesetzlich vorgeschrieben ist. Im Moment sind 3 Monate und 10 Tage drin, aber es werden immer mehr Tage, bis sie bei 183 angekommen sind. Alle Dokumente die älter als 183 Tage sind, werden automatisch gelöscht.

Da kommt noch ein weiteres Problem, das die DB Größe normalerweise um einiges über dem liegt, was die DB eigentlich an Platz braucht. Durch das tägliche einfügen und löschen. Allerdings haben wir das bisher mit einem compact der alle paar Wochen am Wochenende läuft gut überstanden.

Das mit dem Archiv ist aber wirklich eine gute Idee. Werde das mal weiterreichen Danke

[MartinG]

  Ein halbes Jahr, wie es gesetzlich vorgeschrieben ist.   

Wo steht denn gesetzlich geschrieben, das man SPAMs ein halbes Jahr aufbewahren muss? Das habt Ihr vermutlich mit Euren Kunden so definiert?

[0xse]

Ich weiß es nicht genau. Vermutung: Kunde von unseren Kunden sagt er hat xyz dann und dann eine Mail geschickt, und Empfänger sagt, dass die nie angekommen ist. So, wo ist die Mail wenn die vor Gericht gehen? Dann könne wir sagen: Wurde abgewiesen aus Grund abc an dem und dem Datum

Alternativ: Wenn der Kunde einen Spamfilter bezahlt und dann sagt, wir filtern gar keinen Spam. Somit können wir das Erbringen unserer Dienstleistung belegen.



Anm: Mit C wär das nicht passiert.