Dimensionierung einer Datenbank

[barnti]

Hallo zusammen,

heute habe ich mal eine Frage zur Dimensionierung einer Datenbank für meine Anwendung.

Die Datenbank wird aus weniger als 10 Tabellen bestehen. Die Datenmenge setzt sich wie folgt zusammen:

Haupttabelle: Initiale Datenbasis 5 Mio Einträge ca. 150 MB, Tendenz + 5000 pro Tag,
Unregemäßiger (vierteljährlich) Dateiimport ca 5 - 10 Mio Datensätze ca 250 MB
Täglicher Fileimport 5 Mio Datensätze, 120 MB

Insgesamt wird die DB in Zukunft alle 50 Mio Records enthalten wobei ein Datensatz aus max. 10 Feldern besteht.

Zur Performance lässt sich folgendes sagen:

Es wird jeden Tag ein File mit 5 Mio Records importiert und in eine temporäre Tabelle geschrieben.
Es wird jeden Tag ein Abgleich mit einer weiteren DB gemacht (ca 30 000 Datensärte) und in eine temporäre Tabelle geschrieben.

Diese beiden Tabellen werden über PL/SQL mit der Hauptabelle konsolidiert, was meiner Meinung nach eine höhere Rechenleistung erfordert. Zusätzlich wird es weitere PL/SQL Routinen geben, die ähnliche Anforderungen haben. Die Anwendung wird nur von wenigen Usern benutzt (<20). Diese fragen über eine Webanwendung Datensätze in der DB ab und können einzelne Records hinzufügen.

Wie lassen sich die Anforderungen an die Datenbank bezüglich Hauptspeicher/Arbeitsspeicher, etc. beschreiben? Leider kenne ich die zu benennenden Parameter nicht. Kann jemand helfen und mir ein paar Tips geben?

[Jelly]

50 Mio. Datensätze sind schon einige, aber nicht so viele dass, als dass ein ausgewachsenes DBMS wie Oracle das nicht bewältigen könnte. Die Performance hängt natürlich stark von der Komplexität deiner Select Abfragen. Aber prinzipiell gibt es ein paar Punkte, auf die du achten sollst:

• Indiziere gescheit, will heissen, alle Felder über die du ein where-Kriterium in deinen Abfragen legst oder mit anderen Tabellen joinst, da benötigst du einen Index. Auch kombinierte Indizes könnesn interessant sein, je nach Abfrage. Vielleicht legst du uns mal eine Beispiel Abfrage vor, dann kann man mehr dazu sagen
• Schau zu, dass der DB Server für Oracle mindestens soviel Speicher zur Verfügung stellt, so dass alle deine Indizes in den Speicher passen. Dashalb ist es auch unter anderem wichtig, jetzt nicht auf alle Spalten einfach mal ein Index draufzuknallen, denn das kann deine Performance wieder drastig in den Keller treiben
• Bei deinen Abfragen, sorge dafür, dass du nicht hunderttausende Datensätze zu deinen Clients schaufeln musst. Zum Einen geht das ebenfalls stark auf die Performance, sowohl von Oracle als auch netzwerktechnisch, und zum Anderen machen solche Ergebnismengen beim Client prinzipiell sowieso keinen Sinn weil nicht mehr handlebar

Dies sind einfach mal ein paar Anhaltspunkte. Aber prinzipiell sollten 50 Mio. Datensätze kein Problem für Oracle sein.

[barnti]

Hallo Jelly,

danke für Deine schnelle Antwort. Das hilft mir schon mal ein Bisschen weiter.


>> mindestens soviel Speicher zur Verfügung stellt, so dass alle deine Indizes in den Speicher passen
Gibt es eine Möglichkeit das genauer zu beschreiben?

>>Komplexität deiner Select Abfragen.
Das was die Performance beeinträchtigen wird sind die PL/SQL-Abfragen bei dem die Datensätze konsolidiert werden(3 TAbellen werde zu einer zusammengefasst). Auch hier brauche ich eine Aussage zu Speicheranforderungen (Buffer cache, etc).

Ich brauche so etwas eine Aussage:

500 GB Fetsplatte, 2GB Arbeitsspeicher, etc. Nur aus der Sicht von DB-Anforderungen. Das muss auch nicht ganz genau stimmen, ich brauche die Parameter und deren ungefähre Dimension.

[Bernhard Geyer]

Zitat von barnti:

>> mindestens soviel Speicher zur Verfügung stellt, so dass alle deine Indizes in den Speicher passen
Gibt es eine Möglichkeit das genauer zu beschreiben?

Du mußt "einfach" den Speicherbedarf der entsprechenden Datenbankfelds * Anzahl der Datensätze nehmen + Overhead
Grob gesagt:

Integer = 4 Byte
(var)char = Bytes der Maximalen Größe

z.B. Index = 2 Integer + varchar(20) = 28 "Rohbytes" pro Datensatz
1 Mio Datensätze -> 28 MByte "Mindestverbrauch" des Index, Mit allem Overhead würde ich 50 MB ansetzen.

Zitat von barnti:

Ich brauche so etwas eine Aussage:
500 GB Fetsplatte, 2GB Arbeitsspeicher, etc. Nur aus der Sicht von DB-Anforderungen. Das muss auch nicht ganz genau stimmen, ich brauche die Parameter und deren ungefähre Dimension.

Entsprechend Ebenfalls aufgrund der Anzahl der Fehlder + Feldgröße * Erwartete Anzahl der Datensätze *2 (grob für DB-Overhead).

Für eine Datenbank solltest du am besten ein entsprechendes RAID-Syste, verwenden und wenn es das Budget zuläßt die Logfiles auf ein anders RAID verlagern. Bei aktuellen HW-Preisen würde ich gleich (wenn eine Neuanschaffung ansteht) gleich ein 64-Bit-System mit 8/16 GB RAM und entsprechen 1-4 TB HD-RAID nehmen. Du solltest mit der erwarteten Endgröße nach 5 Jahren rechnen um keinen teure Migration auf Neusystem nötig zu machen.

[barnti]

Hi,

jo, das sind schon mal Richtwerte mit denen ich einen Anhaltspunkt habe.

Danke!

[Jelly]

Mit Bernhard's Hardwarebeschreibung solltest du prinzipiell erst einmal sicher liegen, auch wenn es jetzt sogar etwas oversized ist.. Aber das DB-Volumen wächst ja, und das sollte man unbedingt berücksichtigen.

Wenn dir Performance schlecht wird totzt guter Hardware, dann gehts an Feilen der SQL Abfragen. Da ist dann meist noch sehr viel rauszuholen.