Re: Re: [pgsql-de-allgemein] Die Optimale Tabellenstruktur für Postgres 8.1-8.3 ?

On Sun, 11 May 2008 13:19:23 +0200 rudi(at)je-more(dot)de wrote:

> >> Mit der Normalform macht man seltenst Fehler.
> >>
> hmm, naja gibt andere DB's die nehmen einen die Normalform schon eher krum,

Das sind dann aber keine relationalen Datenbanken ... oder schimpfen
sich nur so.

> >> Das Tool der Wahl ist EXPLAIN ANALYSE, dazu das Loggen aller Statements,
> >> die l�nger als X ms Ausf�hrungszeit haben.

Dein Encoding hat irgendwo ein Problem ...

> Das Problemfeld sind hier die SELECTS und INSERTS die Konkurierend von
> verschiedenen
> Usern gleichzeitig ausgeführt werden. Aufgrund der Zeichenlänge im Feld
> "Messagebody (text)"
> dauert ein Insert/Select ewig lange und führt auf der WebApplikation
> Oberfläche zu langen Wartezeiten
> für dier User (Warnung: das momentane System läuft auf MySQL5 mit PHP4.x
> unter Linux).

PHP4 ist schon alt und ranzig, das Haltbarkeitsdatum ist abgelaufen.

Nicht alles, was auf MySQL irgendwie läuft, lässt sich 1:1 auf normale
relationale Datenbanken übertragen. Die Erfahrung lehrt jedoch, dass
dann eine (bislang fehlende) Normalisierung der Daten auf einmal Wunder
bewirkt. Gerade den Messagebody könnte man ggf. auslagern oder/und nur
einlesen, wenn er wirklich benötigt wird (beim Darstellen einer
Nachricht, nicht bei der Darstellung der Übersicht). Gleiches gilt
übrigens für die Applikation: ein "SELECT *" überträgt natürlich
Unmengen Daten, wobei man ggf. mit einem "SELECT id, sender, subject,
date" vollkommen ausreichen würde.

Da PostgreSQL durchgehend MVCC fährt, sollten sich schreibende (das
schliesst updatende Operationen aus) und lesende Operationen überhaupt
nicht stören. Das Problem ist also ev. etwas anders gelagert.

> Die Messagetable ist jetzt knapp 700 GBytes groß und wächst beständig
> weiter an. Wenn 10.000- 14.000
> USer täglich eingeloggt sind gibts schon mal 20 bis 30 Sek. für ein
> Insert und ca. 5 bis 20 Sek fürs
> Selects, je nach kokurierendem Userverhalten (sprich wie hoch die
> Hotspots nun mal gerade sind).

Ein INSERT sollte überhaupt keine Zeit kosten, weil die Datenbank -
zumindest PostgreSQL - dafür auf keine anderen Verbindungen warten muss.

> Die Tabelle Messages istzwar nicht groß und Komplex aber das Feld
> Messageboy ist eine riesige
> Datentonne wo ich nicht recht weiß wie ich auf Postgres Seite so
> gestalten soll das ich keine Bauchschmerzen
> mehr damit habe.

An sich sollte das kein Problem sein - bei Problemen kann man das
jedoch auslagern und bei Bedarf vernünftig joinen.

> In Zukunft soll die gesammt db so mit ca. 1 Terrabyte
> bis 1 Exobyte keine Probleme
> haben, so dass sich der Wechsel auf Postgres auch wirklich rechnet und
> nicht in ein paar Jahren die
> nächste DB Migration ins Haus steht.

Nun, die einzig sinnvolle Antwort an dieser Stelle: Testen.
Dann einen Datenbestand von 1 TB aufbauen und noch mal testen.
Danach den Datenbestand vergrößern und noch mal testen. Dabei tauchen
dann die Schwachstellen sowohl der gewählten Datenbank wie der
gewählten bzw. geschriebenen Applikation an allen Ecken und Enden auf
und man kann korrigierend eingreifen.

Es ist aber schon klar, dass zwischen 1 Terabyte und einem Exabyte 6
Zehnerpotenzen liegen?

Wenn man sich in Bereiche mit solchen Datenmengen begibt, fangen aber
ganz andere Probleme erst an. Wie z.B. stellt man ein Backup der
Datenbank her? Für all solche Fragen sollte man nicht als Neuling
anfangen sondern entweder selbst Wissen aufbauen (Schulungen
existieren, ich weiss da was) oder Wissen einkaufen. Alles andere führt
irgendwann zu Problemen, weil man Details übersieht, die sich hinterher
böse rächen.

Bis dann

--
Andreas 'ads' Scherbaum
German PostgreSQL User Group