Erfahrung mit großen Datenmengen

[udo187]

Liebe Forumsmitglieder!

Was ist eure Erfahrung mit unzähligen Dokumenten (> 10 000 000) und daraus resultierenden großen Datenbanken?
Die Dokumente beinhalten nur Textfelder und keine Dateianhänge.


Interessieren würde mich:

- Anzahl Dokumente
- Datenbankgröße
- Ansichtsindizes (% der Datenbank)

-> Performance?


Hintergrund: Für Statistikzwecke sollten pro Kunde und für jeden Tag im Jahr ein Dokument erstellt werden (da sich Inhalte auf täglicher Basis ändern können), geplant ist die wöchentliche Ausführung des Agenten.

Das bedeutet (pro Ausführung):

1 Kunde = 365 Dokumente
bei 500 Kunden = 182 500 Dokumente

...und das Ganze 52x im Jahr: 9 490 000 Dokumente


Freue mich auf euer Feedback!

Gruß
Udo

[Erik Schwalb]

Wenn für jeden der 500 Kunden ein Dokument für jeden Tag im Jahr erstellt werden soll, dann sind das in Summe

365 x 500 = 182500 Dokumente pro Jahr


Ob der Agent dann täglich läuft und somit jeden Tag für jeden Kunden ein Dokument erzeugt (500 x 1 x 365 = 182500)

oder ob er wöchentlich läuft und somit jede Woche für jeden Kunden 7 Dokumente erzeugt (500 x 7 x 52 = 182000) macht im Endeffekt keinen großen Unterschied.

Wie dabei unterm Strich jedoch knapp 9,5 Millionen Dokumente pro Jahr entstehen sollen, erschließt sich mir noch nicht.

[Tannibal]

Mal als Größenvergleich, unsere größte DB hat 650gb mit 5 Mio. Dokumenten.
Bei den Ansichten muss man etwas aufpassen, z.B. sortierbar nur das Nötigste mit einer kleinen Auswahl an Dokumenten.

[CarstenH]

Test-DB (ND14, ODS 55) mit einer Maske (10 Felder) und einer View (4 Spalten, eine Sortierung) angelegt.

Mit einem Agenten (20-Zeiler) nacheinander 100, 1.000, 10.000, 100.000, 1.000.000 und zuletzt 10.000.000 Dokumente samt Inhalten erzeugt. Zwischendurch auch ein paar gelöscht.

Testergebnis
Dokumente: 10.111.000 (zzgl. ca. 150 Deletionstubs)
Größe DB (physisch): 5GB (4.994.105.344 Bytes ohne Index, da ausgelagert)
Größe des Viewindex: 2GB (2.001.334.272 Bytes eine View mit allen(!) Doks und 4 nicht sortierbaren Spalten, ausgelagert per NIFNSF)

Die Test-Dokumente haben je 10 (gefüllte) Felder, davon 2 x Date/Time, 4 x Text und 4 numerische Felder gemischt mit ganzen und Gleitkommawerten. Ca. 200-250 Bytes je Dokument.

Index (der einzigen View) komplett neu aufbauen braucht ca. 7 Minuten, reine Updates brauchen natürlich weniger, hab ich aber nicht gemessen.

Die Zeit zum Anlegen/Schreiben von Dokumenten war bis 10.000 kaum bis gar nicht messbar, erst bei 100.000 brauchte der Agent etwa 30-35s und für je 1 Mio brauchte das Script weitere 5-6 Minuten.

DB öffnen, Dok öffnen (oder ändern und speichern), Scrollen, Sprung zum ersten oder letzten Dokument (bei aktuellem Viewindex): alles unter 1s

Ich habe an diversen Stellen bei der DB natürlich Dinge abgeschaltet, die die Performance negativ beeinflussen, wie z.B. Unread Marks, Activitylogs oder automatische Viewupdates. Andere Dinge, wie z.B. Dok-Komprimierung, Translog oder NIFNSF habe ich dafür wieder bewusst eingeschaltet.

Auch nicht ganz unwichtig: der Server hierbei ist ein reines Testsystem (Win2k19), nichts besonders Performantes aber dafür auch keine Nutzer oder Hintergrundaktivitäten die bremsen.

Was mir bei deinem angefragten Szenario fehlt sind die Erwartungen, also was für wen und wie oft genau soll die DB eigentlich abliefern. Guckt da einmal im Jahr einer rein und exportiert die Statistik nach Excel oder wollen 500 Kunden täglich live ihre Statistiken per HTTP rausholen.
Die von dir geschilderten Schreibvorgänge sind für sich genommen kaum der Rede wert - siehe weiter oben, selbst bei über 1000 neuen Dokumenten schreiben war der Agent schneller fertig als ich Käsekuchen sagen könnte.

Viel interessanter ist das, was danach kommt, also das, was du NICHT gefragt hast

HTH, Carsten

[udo187]

Danke für die Antworten!

@Erik Schwalb
Der Agent läuft zwar wöchentlich, es wird aber für jeden Kunden und pro Tag ein Dokument erzeugt (500 x 365 x 52 =  9 490 000 Dokumente).

@CarstenH: DANKE für deine umfangreichen Tests!


Ein Prototyp der Datenbank läuft bereits, ca. 11 000 000 Dokumente und 230GB physische Größe, davon 78GB Viewindex (36%).
Der Indexaufbau bei Änderung einer Ansicht benötigt ca. 15-30 Minuten, was leider nicht praktikabel ist.
Daher werden die Ansichten bis auf ein erforderliches Minimum reduziert und die Daten werden per CSV-Datei exportiert.

Die exportierten Daten (genauer: Datenextrakte wie 1. Quartal) werden anschließend mit Excel und Pivot-Tabellen & Grafiken weiterverarbeitet,
was erstaunlich performant ist (trotz ca. 100 000 Datensätze pro Extrakt) - und jeder kann sich seine Pivot-Tabelle "on the fly" nach seinen Kriterien zusammenbauen (ohne dass unzählige Notes-Ansichten mit riesigen Indexe erstellt werden müssen).


Gruß
Udo

[Riccardo Virzi]

Zu den Ansichten: da der Agent einmal wöchentlich (ich vermute am Wochenende) läuft, können die Ansichten in der einen Datenbank mit einem Programmdokument aktualisiert werden (updall). Wenn das Programmdokument am Sonntag abend oder am Montag morgen läuft, ist der Ansichtsindex aktuell wenn die Benutzer darauf zugreifen.

Auch wenn die Anwender dann per CSV-Export damit arbeiten, muss der erste Anwender der exportiert dann nicht 30m warten bis der Index aktuell ist.

[Erik Schwalb]

...

@Erik Schwalb
Der Agent läuft zwar wöchentlich, es wird aber für jeden Kunden und pro Tag ein Dokument erzeugt (500 x 365 x 52 =  9 490 000 Dokumente).

...

Wenn der Agent das erste mal gelaufen ist, dann existieren danach doch für jeden Kunden bereits 365 Dokumente (also sprich für jeden Tag ein Dokument).
Warum erzeugt der Agent beim nächsten mal dann wieder für jeden Kunden 365 neue Dokumente?

Hier würde mich mal der use case genauer interessieren.


Die zweite Frage wäre:
Domino scheint hier ja "nur" der Datencontainer zu sein, während die Visualisierung und Auswertung anderswo (d.h. in Excel) erfolgt.
Warum schreibst Du die Daten aus Domino dann nicht gleich bei der Erzeugung in ein RDBMS oder transferierst sie mit HEI automatisch in ein anderes System, auf das die Endanwender dann leicht mit Excel zugreifen können? Dann kann man sich den Export nach CSV und den (vermutlich) manuellen Transfer der CSV Datei nach Excel sparen.

[MaVo]

Udo schon mal die Auswertung mit DQL durchgeführt ist. Viel performanter und flexibler als mit den klassischen View-Abfragen.

OpenNTF webinar September 2020: What's New with Domino Query Language with John Curtis from HCL
Video: https://youtu.be/tk4b0l4aKGY
Präsentation: https://www.slideshare.net/gacres99/openntf-webinar-series-dql-with-john-curtis-september-2020

OpenNTF webinar February 2022: What's new in 12.0.1 for Developers including the new QueryResultsProcessor
Video: https://youtu.be/NqhbKNAycUI
Präsentation: https://www.openntf.org/Public/presentations.nsf/0/2C172BE78C07F1A1862587EC0082F3F1/$FILE/OpenNTF-2022-Feb.pdf

Auch sollten man die Serverperformance nicht unbeachtet lassen

"Building a high performance Domino Server" von Stephan Wissel:
https://www.wissel.net/blog/2009/04/building-a-high-performance-domino-server.html