Das Notes Forum

Domino 9 und frühere Versionen => ND8: Entwicklung => Thema gestartet von: m3 am 21.09.09 - 14:22:05

Titel: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: m3 am 21.09.09 - 14:22:05
Liebe Guruinen und Gurus,

bei uns ist derzeit eine Anwendung in Planung, die Dokumente über min. 10 Jahre aufheben soll. Nach derzeitigen Schätzungen werden nach diesen 10 Jahren etwa 1.120.000 Dokumente in der Datenbank sein.

Reader/Author Felder wird es (vermutlich) keine geben. Es hängen an diesen Dokumenten auch Anhänge dran, die wir aber in weitere, jährliche Datenbanken auslagern, um die zentrale DB klein zu halten.

Ist das noch eine Dokumentenmenge, mit der Notes in brauchbarer Zeit (Views, ...) umgehen kann (können sollte) oder sollte ich mir doch überlegen, die > 1 Mio. Dokumente auf mehrere Datenbanken aufzuteilen?

Vielen Dank schon im Voraus für Euer Feedback.
Titel: Re: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: WernerMo am 21.09.09 - 14:41:46
Hallo Martin,

wie ist das mit den 10 Jahren zu verstehen, gelten die ab jetzt oder für die letzten 10 Jahre.

Zum Verständnis,
mit jeder neuen Version hat Notes (bisher) auch mehr Dokumente verkraftet.

Meine größte DB hat z.Zt. 400.000 Dokumente und ist 30GB groß (noch ohne DAOS) unter V8
bei V6 mit den damaligen Servern wäre das nicht gegangen aber jetzt ist es sehr performant.
Ich glaube dass es mit 8.5  (und DAOS) wieder besser wird, und mit V  9 noch besser und wer weis, was Du dann in 10 Jahren hast (Ich bin dann schon in Pension).

Gruß Werner
---edit---
PS: hatte vergessen zu schreiben über 200 views in der o.g. Datenbank....
Titel: Re: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: BigWim am 21.09.09 - 16:04:57
Hallo Martin,

wir haben eine Datenbank gekauft, die in Produktion ebenfalls mit über 1 Mio Dokumente arbeitete.

Ich war auch sehr erstaunt und auf mein Nachfragen hin, sagte man mir, dass sehr von der Anzahl der Items abhinge und von der Indexierung. Ich hoffe, dass sind Stichworte mit denen Du mehr anfangen kannst als ich. Aktuell sind wir alledings erst bei knapp 400.000 Dokumente (und keine Probleme).

Mein Admin sagte mir noch, dass es ein Unterschied ist, ob die Datenbank täglich benutzt wird oder unregelmäßig.

Markus

Server & Client 8.0.2
Titel: Re: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: koehlerbv am 21.09.09 - 16:24:06
Markus hat sicherlich schon die ganz wichtigen Punkte genannt, und mit den stetigen Verbesserungen der Domino-Versionen (immer mehr Funktionen bei gleichzeitiger Performance-Steigerung und weniger RAM-Anforderungen etc.) kann ich auch Werner aus eigener Erfahrung nur zustimmen.

Der casus cnactus sind Eure Randbedingungen: Was sind das für Dokumente, und was soll mit denen passieren? Wie sollen sie visualisiert werden (Ansichten, Reports, Queries etc.)?

Wenn es aber irgendwie denkbar / möglich erscheint, diese Dokumentenmenge auf mehrere DBs zu verteilen: Ich würde das machen. Dafür spricht etliches. Vermutlich ...

More input - more output.

Bernhard
Titel: Re: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: atbits am 21.09.09 - 16:25:14
Hallo,

1 Mio. ist sicher kein Problem allein von der Anzahl her.

Wir haben einen Kunden der hat 2,5 Mio. Dokumente in einer DB auf nem 6.5er Server.
Das geht auch (ab 7 gehts aber deutlich besser)

Allerdings: Achtung mit den Ansichts-Indices, die werden echt heftig groß, bei der o.g. Anwendung schlucken Sie rund 25 GB, das sind fast 2/3 der Gesamt-Größe.

Aber wenn ihr da nur wenige schlanke Ansichten reinmacht ist es denke ich kein Problem.
Ach ja: Schaltet auf jeden Fall die "Ungelesen Markierung" aus.

Große Anhänge würde ich auch vermeiden.

Ein schneller Zugriff ist auf die Daten halt meist nicht wirklich möglich (langsame Ansichten).

Grüße David
Titel: Re: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: WernerMo am 21.09.09 - 16:44:27
Hallo,

Danke an David:
Ach ja: Schaltet auf jeden Fall die "Ungelesen Markierung" aus.
das hatte ich vergessen, das haben wir schon unter V6 gemacht und das hat eine Menge gebracht.

Gruß Werner
Titel: Re: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: m3 am 12.10.09 - 18:29:44
Danke für den ganzen Input. Es ist immer wieder eine Freude, was hier an gutem Input kommt.

Es geht dabei um Dokumente mit 10-20 Feldern (Items), wobei die "großen" Brocken, also die RTFs mit den Anhängen für jedes Jahr in eine eigene Datenbank ausgelagert werden. Die Dokumente selber sind also eher klein.

Die Dokumente selber will ich eigentlich nicht in jährliche Datenbanken auslagern, da über alle Dokumente und alle Jahre gesucht werden soll (daher auch die Frage).

Wir würden mit 0 Dokumenten starten und rechnen derzeit mit 1,2 Mio. Dokumenten in der DB im Jahre 2020.

Die Anzahl der Views (und Sortierungen) sollte sich ebenfalls im 1-2stelligen Bereich abspielen, "Angst" habe ich nur bezüglich der Kategorisierungen und ev. der Readerfelder, falls wir sie doch brauchen.

Im Prinzip soll mit den Dokumenten nicht viel passieren - suchen und Anzeigen halt, also nix "Aufregendes".


Falls sich aus dem eben von mir geschriebenen noch was "Neues" ergibt freue ich mich über Rückmeldungen. Ansonsten nochmals vielen Dank für den Input.
Titel: Re: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: atbits am 12.10.09 - 18:54:03
Hallo,

sofern möglich unbedingt auf Reader-Felder verzichten, die sind Gift für die View-Performance.

Benötigt jede View alle Dokumente?

Evtl. jedes Jahr eine neue View für dieses eine Jahr per Agent zufühen?

Grüße David
Titel: Re: Sizing/Anzahl Dokumente in einer DB/View
Beitrag von: m3 am 12.10.09 - 23:50:04
David, ja das mit den Readerfeldern ist besch... Ich hoffe ja immer noch, dass ich ohne auskommen. Na mal sehen, im zweifesfall kann man ja noch immer die Tricks aus Notes from Support: Reader Names fields can impact performance (http://www.ibm.com/developerworks/lotus/library/ls-reader_names_performance_impacts/) benutzen, um zu retten, was zu retten geht.

Um die Views werde ich nicht herumkommen. Aber ich konnte die Dokumente in Folder werfen, das wäre noch eine Option. Hmmm. Mal drüber nachdenken.