Architektur- und Performance-Frage

[Fraenk]

Hallo,

ich habe 2 Fragen zum Aufbau und Betrieb einer Datenbank.

Es geht um eine DB(mySQL) mit 2 Tabellen. Die erste Tabelle enthält ca. 200.000 - 500.000 Stammdaten, die 2 Tabelle ist relational verbunden. Darin kann es zu jedem Stammdatensatz bis zu 100 zugehörige, gleichartige Datensätze geben. Im schlimmsten Fall also 50.000.000 Datensätze. Jetzt die Frage: ist es da besser, zu jedem Stammdatensatz eine Tabelle zu erstellen? Dann würden im schlimmsten Fall 500.000 Tabellen existieren. Oder gibt es noch bessere Strategien?

Die DB wird online über Servlets abgefragt. Ein Service übergibt die Stammdaten an ein Ojekt. Ggf. werden die relationalen Daten, wenn erforderlich, an Unterobjekte übergeben. Der Service öffnet jedesmal die Verbindung zur Datenbank, holt die Daten, schließt die Verbindung und übergibt die Daten. Macht es Sinn, die Verbindung für jede Abfrage zu öffnen und danach wieder zu schließen? Oder die Verbindung nur einmal öffnen und dann offen lassen? Gibt es dabei irgendwelche Haken und Ösen?

Jetzt schon mal vielen Dank und einen schönen Sonntach noch!
Fraenk

[seth]

gudn tach Fraenk!

[nur zur ersten frage]
ich bin zwar auch nicht so der db-held, aber vermute, dass 500000 kleine tabellen doof sind und dass je nach dem wie deine tabellen geartet sind, die folgende zweite oder dritte moeglichkeit geeigneter sein koennten:

1. moeglichkeit (so wie ich deine erste idee verstanden habe)

tabelle1 sehe z.b. so aus:
|ID|X|Y|Z|
|0 |*|*|*|
|1 |*|*|*|
|2 |*|*|*|
#zeilen=5e6

(* stehe fuer irgendeinen eintrag)

tabelle2
|ID|Relation|A|
|0 |0       |*|
|1 |1       |*|
|2 |1       |*|
|3 |1       |*|
|4 |2       |*|
#zeilen=5e6

2. moeglichkeit

besser waere evtl. (je nach struktur) eine gemeinsame tabelle

tabelle_neu
|ID |X|Y|Z|A1|A2|A3|A4|...|A100|
|0  |*|*|*|* |- |- |- |...|-   |
|1  |*|*|*|* |* |* |- |...|-   |
|2  |*|*|*|* |- |- |- |...|-   |
#zeilen=5e6
#spalten entsprechend vergroessert

(- stehe fuer NULL)

was die geschwindigkeit betrifft, sind solche grossen tabellen afaik oft das schnellste, verbrauchen dafuer allerdings einen haufen platz.

ausserdem ist hier die struktur nicht mehr soo flexibel.

3. moeglichkeit

eine weitere moeglichkeit, die ebenfalls stark von der struktur der realen gegebenen zusammenhaenge abhaengt, ist eine hybridloesung, also sowas wie

tabelle1
|ID |X|Y|Z|A1|A2|A3|A4|...|A30|
|0  |*|*|*|* |- |- |- |...|-  |
|1  |*|*|*|* |* |* |- |...|-  |
|2  |*|*|*|* |- |- |- |...|-  |
#zeilen=5e6

tabelle2
|ID|Relation|A|
|0 |42      |*|
|1 |65      |*|
|2 |65      |*|
|3 |247     |*|
#zeilen=? (strukturabhaengig)

so, vielleicht koennte mir nun noch jemand von den db-helden sagen, ob das, was ich hier geschrieben habe, einigermassen ok oder voelliger bloedsinn ist. in der bierdatenbank verwenden wir jedenfalls bzgl. der bier-geschmackseigenschaften (von denen es X fest vorgegebene "standard-"eigenschaften gibt, aber darueber hinaus beliebig viele zusaetzliche) so eine hybride form, da es um ein vielfaches(!) schneller ist als die 1. moeglichkeit.

prost
seth

[Fraenk]

Tach Seth,

erstmal Danke für Deine Antwort!

Aber es ist genau mein Problem, dass ich auch irgendwie im Nebel rumstochere! Die DB erreicht eine kritrische Größe, bei der ich nicht mehr sicher bin, wie ich das noch handeln soll...

Ciao - Fraenk

[Ilja]

yo,

Aber es ist genau mein Problem, dass ich auch irgendwie im Nebel rumstochere! Die DB erreicht eine kritrische Größe, bei der ich nicht mehr sicher bin, wie ich das noch handeln soll...

dann wird es zeit, licht ins dunkle zu bringen. und dafür bietet jedes dbms tools an, zum beispiel ist immer der erste schritt, sich den ausführungsplan einer abfrage anzeigen zu lassen. daran kann man nämlich erkennen, wie das dbms die abfrage ausführt. oftmals bewirkt das folgende setzen von geeigneten indezies und den richtigen aufbau der abfrage wunder. die daten, welche du benutzt, sind von der menge her nicht so kritisch.

Ilja

[Fraenk]

Hi,

ich denke, dass das System hinreichend beschrieben wurde...
Und es bleibt die Frage: kann eine DB 50.000.000. Datensätze verkraften oder eher 500.000 Tabellen? Oder wie sieht die intelligente/alternative Lösung aus?

Fraenk

[Ilja]

yo,

ich denke, dass das System hinreichend beschrieben wurde...

nein, du hast das wichtigste nicht mit angegeben und das habe ich versucht, dir zu erklären. welche indezies sind gestzt und wie sieht abfrage aus, bzw. der ausführungsplan. das sind ganz elementare infos oder habe ich übersehen woe du sie beschrieben hast ?

Und es bleibt die Frage: kann eine DB 50.000.000. Datensätze verkraften oder eher 500.000 Tabellen?

grundsätzlich sind 500.000 tabellen schon mal aus dem gefühl heraus keine gute lösung, aber ganz so pauschal kann man das nicht beantworten, solange das dbms überhaupt eine solche menge verwalten kann. wenn man die abfrage mit zwei tabellen hinbekommt, und davon gehe ich mal aus, dann würde ich es bei zwei belassen.

btw. eine relation ist eine tabelle und keine beziehung.

Ilja

[Chris]

Hallo,

Und es bleibt die Frage: kann eine DB 50.000.000. Datensätze verkraften oder eher 500.000 Tabellen? Oder wie sieht die intelligente/alternative Lösung aus?

Gewinne ich nächsten Samstag im Lotto?

Du müsstest schon rauslassen, um welches DBMS es sich handelt. Es gibt welche, die stecken die Anzahl der Datensätze locker weg und es gibt bestimmt auch welche, die schaffen nur 65.000 (und ein paar) pro Tabelle...

Aber die Idee, alles auf einzelne Tabellen aufteilen zu können, ist ein Trugschluss, da diese auch verwaltet werden müssen.

Wenn jeder Detaildatensatz 4kByte hat, dann würde das 200GByte Nutzdaten ergeben, oder? Also muss auch die Hardware unter dem DBMS mitspielen und entsprechend viel Speicherkapazität adressieren können. Auf DOS 3.3 wirst Du das nicht hinbekommen ;-)

Und ein bisschen Hauptspeicher für die (schnelle) Verarbeitung von Indexen benötigst Du auch!

LG
Chris

[Fraenk]

Hi,

ah, jetzt wirds klarer! ;-)

Also, geplant ist der Einsatz von mySQL. Server: Linux/Apache/Tomcat(für Servlets).

Das mit den 500.000 Tabellen zu lösen erschien mir bis jetzt eben als einzige Alternative... Glücklich finde ich das ja auch nicht. Deshalb möchte ich ja gerne herausfinden, welche anderen Lösungsmöglichkeite es gibt!

Bin bestimmt nicht der erste, der vor dieser Aufgabenstellung steht ;-)

Grüße
Fraenk

[Ilja]

yo,

Das mit den 500.000 Tabellen zu lösen erschien mir bis jetzt eben als einzige Alternative... Glücklich finde ich das ja auch nicht. Deshalb möchte ich ja gerne herausfinden, welche anderen Lösungsmöglichkeite es gibt!

auch auf die gefahr hin mich zu wiederholen, sind den schon mal testweise die beiden tabellen erstellt worden und testdaten angegeben worden, um mal zu sehen, ob es überhaupt handlungsbedarf gibt, die beiden tabellen aufzuteilen und um zu sehen, wie der ausführungsplan aussieht ?

es scheint mir so zu sein, dass man sich gedanken um etwas macht, was vielleicht gar kein problem darstellt.

Ilja

[Frank (no reg)]

Hallo,

ich hab den Thread nicht so hundertprozentig mitverfolgt, das liegt
auch daran, dass du nicht wirklich ein stichhaltiges Argument
vorbringengen konntest, 500.000 Tabellen zu erzeugen, in denen,
von der Struktur her gesehen, dieselben Daten liegen.

Ohne aufgrund technischer Unvertrautheit wissen zu können, wie MySQL
Tabellendaten physikalisch speichert ... liegt das Problem am physikalischen
I/O? Am Ram-Verbrauch?

Wie sieht die Benutzung der 50M Datensätze aus? Würde die typische Abfrage
mit einer Partitionierung der Daten korrelieren?

Nenn mir doch einfach mal ein Kriterium für die Aufteilung in die 500k
verschiedenen Tabellen!

Wäre es nicht einfach mal sinnvoll über den Erwerb eines richtigen DBMS
nachzudenken? Wer 50 Mio Datensätze verwalten will tut das sicher nicht
als Hobby.

[Lulli]

Hi,

Es geht um eine DB(mySQL) mit 2 Tabellen. Die erste Tabelle enthält ca. 200.000 - 500.000 Stammdaten, die 2 Tabelle ist relational verbunden. Darin kann es zu jedem Stammdatensatz bis zu 100 zugehörige, gleichartige Datensätze geben. Im schlimmsten Fall also 50.000.000 Datensätze. Jetzt die Frage: ist es da besser, zu jedem Stammdatensatz eine Tabelle zu erstellen?

auf keinen Fall! Wenn ich Dich richtig verstehe, kannst Du mit [b]einer[/b] Tabelle auskommen.

Macht es Sinn, die Verbindung für jede Abfrage zu öffnen und danach wieder zu schließen? Oder die Verbindung nur einmal öffnen und dann offen lassen?

Wenn Du exakt einen Datenclient hast, darfst Du die Verbindung gerne offen lassen. Das Aufrechterhalten vieler Verbindungen dagegen bringt Pech.

Gruesse!
Lulli

[Fraenk]

...ist doch mal eine Aussage :-)

Danke