Frage zu Datenbankaufbau.

[nohfreak]

Moin Leute,

ich arbeite an einem Projekt, das relativ umfangreiche Datenbanken benötigt. Ich will das mal kurz in einigen Worten erläutern, ehe ich auf meine Frage komme.

Es gibt eine theorethisch unbegrenzte Zahl von Gruppen, die jeweils mindestens 1000 Datensätze ( Also Content, keine Account-Sachen ) speichern müssen. Tendenz ist aber eher steigend, also mehrere Tausend.

Nun müssen für JEDEN Benutzer Statistiken erstellt werden, in Verbindung mit den Datensätzen der Gruppen.

Die Frage ist nun ab wann es sich lohnt für jede Gruppe, oder gar für jeden User eine eigene Tabelle zu erstellen.

Ich meine, wenn ich die Datensätze aller Gruppen in eine Tabelle schreibe, dann sind da nachher mehrere 10.000 Datensätze drin, und das dürfte doch schon eine relativ große Performance-Belastung darstellen, da die User bei Benutzung der Seite ständig auf diese Tabelle zugreifen müssten. Oder ?

Dann die Statistiken,... Pro Gruppen-Datensatz hat jeder User nochmal einen Datensatz mit seinen STatistiken, d.h. pro User auch mehrere Tausend Datensätze. Eine Tabelle für alle User/Datensätze würde auch ziemlich überdimensionale Ausmaße annehmen.

Die eigentliche Frage ist nun wo denn die Grenze liegt. So Pi mal Daumen, ab wievielen Datensätzen lohnt es sich eine Tabelle in mehrere aufzusplitten, um optimale Performance zu gewährleisten?

Nachteil wäre dann wieder, wenn man alle Gruppen-Datensätze nach etwas durchsuchen möchte, dann muss man natürlich wieder auf alle Tabellen zugreifen.

Hat da jemand Erfahrungen ? Ich habe noch nie mit so etwas Großem zu tun gehabt und wollte mir gern vorher ein paar Tips holen, als dann direkt auf die Schnauze zu fallen und alles nochmal neu machen zu müssen.

Greetz,
Nohfreak

[Slava]

Es lohnt sich überhaupt nicht die Tabelle zu zerstückeln.
Wenn du die richtige Indexen gesetzt hast, dann dauert eine suche bei 10.000 datensetzen ein Bruchteil schneller als bei 1000.000.
Sonnst gibtes auch die möglichkeit die Tabelle Partitionieren um die Geschwindigkeit zu gewinnen http://dev.mysql.com/doc/refman/5.1/...titioning.html

[nohfreak]

Naja, jeder Datensatz hat dann halt ne eigenständige ID und würde dann mit einem Feld den jeweiligen Gruppen zugewiesen.

Bei den User-STatistiken zu den Objekten wär das dann halt genauso.

Macht das wirklich so wenig Unterschied, ob da 1k, 10k oder 100k drin sind ? Mir scheint ich unterschätze die Rechenleistung doch deutlich

Meine Überlegung war halt, dass wenn 100 User gleichzeitig auf ne 100k-Tabelle zugreifen die Performance schlechter is, als wenn jeder User ne eigene Tabelle hat mit 1k

[Slava]

ich habe schon mehr mals über diese Thema gesprochen.
bei Indexierter suche verwendet ein Datenbank eine binäre suche und braucht bei einer 10.000 datensatz Tabelle maximal 12 Zeiger-Bewegungen um der erster Datensatz zu finden.
Die suche nach den weiteren Datensätzen braucht nur maximal 2 Zeiger-Bewegungen.
In Vergleich zu einer 1000.000 datensatz Tabelle, die eigentlich 100-mal mehr datensätze hat, wird maximal 24 Zeiger-Bewegungen für erster Datensatz und maximal 2 für die folgende Datensätze gebraucht.

Also wenn du merkst liegt der Unterschied in 12 Zeiger-Bewegungen die wirklich keine Bedeutung für Performance als auch Speicherverbrauch haben.

[unset]

Original geschrieben von nohfreak
Meine Überlegung war halt, dass wenn 100 User gleichzeitig auf ne 100k-Tabelle zugreifen die Performance schlechter is, als wenn jeder User ne eigene Tabelle hat mit 1k

Gleichzeitig ist logisch schon mal gar nicht möglich. Die Zugriffe werden in Schlange gesetzt und abgearbeitet. Das geht allerdings so schnell, dass man als Mensch keine spürbare Wartezeit hat. Was anderes ist es bei Schreibzugriffen, da die Tabelle dafür erst gelockt wird und nachdem die Daten geschrieben werden wieder entlockt wird. Ich nehme allerdings an, dass das für deine Anwendung ebenfalls kein Problem sein wird, denn selbst bei täglich 5 Million Datensätzen kommt man noch mit bezahlbarer Hardware hin (allerdings stößt man dann auch laaaaaangsam an die Grenzen ).

[ghostgambler]

Es macht durchaus Sinn große Tabelle in kleine aufzuteilen.
Allein ein ALTER auf eine 500 MB Tabelle braucht auf einer 64Bit-Maschine mit 16 Gig Ram im laufenden Betrieb fast 20 Minuten und selbst bei null-sonstigem-Betrieb noch 5 Minuten.

Wenn ich mir vorstelle, dass das eine von dreißig Tabellen ist, aus denen das Teilprojekt besteht... wenn das alles in einer Tabelle wäre - na dann gute Nacht.

Das Partitioning in 5.1 ist zwar eine gute Idee, aber ich glaube das mit den ALTER-Befehl deckt das auch nicht besser ab (und abgesehen davon muss man halt erstmal 5.1 haben und die ist aktuell ja nicht mal stable).

[Slava]

ALTER ist kein Standardbefehl um mit DB zu arbeiten.
Wir sprechen eigentlich mehr über insert, update und select.
Bei einer riesiger Tabelle wird jede veränderung von Tabellenstruktur kritisch und braucht sehr viel zeit.
Also, man überlegt schon vorher, wie eine Tabellenstruktur aussehen muss und erst danach fühlt man das mit den werten.
Im fall, dass wir bei den Tabellen ziemlich oft die Update von 100000 Datensätzen brauchen, würde ich auch für die mehrere Tabellen aussagen.
sonnst, wenn man update auf einer Zeile macht oder select von übersichtbaren Datensätzen, dann sehe ich kein Sinn die Tabelle zu zerteilen.

[ghostgambler]

Im live-Betrieb eine einzige von 30 Tabellen für 20 Minuten offline zu nehmen, ist weniger schlimm, als ein komplettes Teilprojekt für eventuell Tage offline zu nehmen.

Mir auch egal, mach was du willst, ich stütze mich auf Erfahrung von mir und anderen Leuten, die deutlich Ahnung von MySQL haben:
http://www.mysqlperformanceblog.com/...gs-are-better/

[bla$ter]

Original geschrieben von Slava
ich habe schon mehr mals über diese Thema gesprochen.
bei Indexierter suche verwendet ein Datenbank eine binäre suche und braucht bei einer 10.000 datensatz Tabelle maximal 12 Zeiger-Bewegungen um der erster Datensatz zu finden.
Die suche nach den weiteren Datensätzen braucht nur maximal 2 Zeiger-Bewegungen.
In Vergleich zu einer 1000.000 datensatz Tabelle, die eigentlich 100-mal mehr datensätze hat, wird maximal 24 Zeiger-Bewegungen für erster Datensatz und maximal 2 für die folgende Datensätze gebraucht.

Also wenn du merkst liegt der Unterschied in 12 Zeiger-Bewegungen die wirklich keine Bedeutung für Performance als auch Speicherverbrauch haben.

Das kann man so nicht stehen lassen.
Neben B-Baumen gibt es in fast allen Datenbanken mehrere Indizierungsverfahren, die leicht über einiges schneller sein können als eine binäre Suche. Die Wahl des Indexes muss IMMER davon abhängen, welche Queries die Benutzer stellen bzw. wonach gesucht wird, sonst läufst du mit deiner Binären Suche schneller gegen die Wand als du gucken kannst.

[Slava]

bla$ter sorry es gibt immer wieder die Fälle, wo eine oder andere Technik versagt.
In jedem Fall die suche nach einem Zahl oder nach einen String mit like bringt bei normaler indexierung die Vorteile, die ich schon angesprochen habe. Ausserdem scheint es bei dem @nohfreak genau der Fall sei, da es um die Gruppen und dazu gehörige Datensätze handelt.
Ich würde doch vorschlagen alles in eine Tabelle zu schreiben, da die Möglichkeit die Tabelle zu zerstückeln bleibt weiterhin machbar.
Ab einer bestimmtem Anzahl von Tabellen, wird die Performance von DB auch schnell sinken, da die suche nach Tabelle selbst nimmt auch Performance in Anspruch.

die schnellere suchverfahren kenne ich nicht und würde mich freuen wenn du mir ein Algorithmus bzw ein Hinweis gibst wo ich das nachschlagen könnte.

[goth]

Fast jeder Such-Algorithmus wird unter Umständen suboptimal ... man spricht in diesem Falle von Degeneration oder degernerativem Verhalten eines Algorithmus (egal ob Suchen oder Sortieren). Allerdings ist das eher ein Problem für DB-Server-Entwickler.

Die Aufgabe des Programmierers ist es die beste Methode zu finden Daten zu speichern. Das Spliten von Tabellen (Entitäten) ist dieses indes jedenfalls nicht (weil dieses den Pradigmen eines relationalen Datenbankmodells wiederspricht).

Die beim orginären Problem benannten Datenmengen sollten im Normalfall kein Problem darstellen (vernünftige Indizierung vorausgesetz).

Wenn allerdings Datenmengen in solchen Größen (500GB und mehr) anfallen, ist die Frage welche Information ich speichern will und ob in diesem Falle eine Datenbank das richtige Mittel ist.

Große Datenmenge fallen im Normalfall z.B. durch Protokollierungen an. In solchen Fällen und wenn Daten nicht in alle möglichen Richtungen und häufig ausgewertet werden müssen, sollte man sich überlegen ob nicht vielleicht ein simples Logfile mit entsprechenden Auswertungstools sinnvoller ist.

Alternativ oder zusätzlich dazu läßt sich prüfen welche Informationen in Wirklichkeit gespeichert werden sollen oder welche Informaitonen in Wirklichkeit verwendet werden. Oft lassen sich so Informationen komprimieren und die erfassten Datenbestände können wieder reduziert werden.

Im Übrigen. Wenn ein ALTER TABLE für ein laufendes System ein Problem darstellt, liegt das Problem eigentlich nicht im ALTER TABLE sondern im Datenbank Entwurf. Ein ALTER TABLE ist eigentlich ein DDL-Befehl der also im Zuge der Entwicklung oder während UPDATE/UPGRADE Prozessen eine Rolle spielt nicht jedoch während des laufenden Betriebs einer Software. Da UPDATES/UPGRADES eigentlich sehr selten im laufenden Betrieb durchgeführt werden ist dieses eher zu vernachlässigen.

[ghostgambler]

Original geschrieben von goth
Im Übrigen. Wenn ein ALTER TABLE für ein laufendes System ein Problem darstellt, liegt das Problem eigentlich nicht im ALTER TABLE sondern im Datenbank Entwurf. Ein ALTER TABLE ist eigentlich ein DDL-Befehl der also im Zuge der Entwicklung oder während UPDATE/UPGRADE Prozessen eine Rolle spielt nicht jedoch während des laufenden Betriebs einer Software. Da UPDATES/UPGRADES eigentlich sehr selten im laufenden Betrieb durchgeführt werden ist dieses eher zu vernachlässigen.

Erklär das mal den Benutzern, die 24-Stunden-Erreichbarkeit wollen.
Da kann man für ein Update der Software die Website nicht mal eben für ein paar Stunden vom Netz nehmen... dann rennen die uns das Mail-Postfach und Forum ein.

[nohfreak]

Hui, da bin ich ja überwältigt, was ich da für Diskussionen losgetreten habe. Auf jeden Fall danke ich allen, die eine Antwort geschrieben haben.

Ich denke für mein Problem ist es dann schon ok alles in eine Tabelle zu stecken.

Denn im Prinzip sollen innerhalb einer Gruppen Objekte erstellt werden. Mit diesen Objekten können die Benutzer diverse Aktionen durchführen und die Ergibnisse davon sollen dann für jeden User und jedes benutzte Objekt immer in der DB gespeichert werden.

Ich benutze also im Regelfall nur SELECT, UPDATE und INSERT auf einzelne oder einige wenige Datensätze.

Also hau ich alles in eine Tabelle. Sollten irgendwie Probleme auftreten werde ich mich weider melden.

Danke nochmals.

[goth]

Original geschrieben von ghostgambler
Erklär das mal den Benutzern, die 24-Stunden-Erreichbarkeit wollen.
Da kann man für ein Update der Software die Website nicht mal eben für ein paar Stunden vom Netz nehmen... dann rennen die uns das Mail-Postfach und Forum ein.

Dann hast Du wenig Ahnung davon wie man UPGRADES einspielt ... ....

Im übrigen ist einem Kunden der kein vollkommener Vollidiot ist eine solche Problematik vollkommen klar ... selbst bei großen Systemen (Amazon, Bahn, Post, ...) kommt es durch Software Updates zu geplanten ausfällen. Meinstens sind's die Trolle die 100% Verfügbarkeit verlangen oder diese versprechen.

[unset]

Dort wo ich an solchen Änderungen beteiligt war bzw. sie selbst durchgeführt habe, wurden solche Updates allerdings immer partiell eingespielt. D.h. dass man nicht das "komplette System" offline nimmt, sondern nur die Teile, die Betroffen sind.

Will heißen, wenn ich eine Tabelle mit Adressdatensätzen ändere, so muss ich nicht das gesamte System ausschalten, sondern lediglich die Teilbereiche, die auf diese Tabelle zugreifen (schreibend wie lesend). Das minimiert den subjektiven Ausfall, und wenn man das zeitlich geschickt plaziert, merken lediglich eine Handvoll Benutzer etwas (Übrigens ist heute Nacht so ein geschickter Zeitpunkt ).