Datenbank Design und Backup Ablauf

**piratos** · 11.07.2009, 15:35

Unter Mysql ist jede Datenbank nur ein neues Verzeichnis .

Jede Tabelle besteht normal mindestens aus 3 Einzelteilen .frm, MYD und MYI.

Ob eine Aufteilung auf mehrere DB's schneller oder einfach günstiger ist, das ist die große Frage.

Da müsste man schon zig tausende von Datensätzen haben um überhaupt mal ein Test zu machen der sinnvoll wäre.

Ich glaube es nicht denn im Prinzip macht eine Suche über einen index nur 2 bis 4 Schritte aus und das bei mehreren Millionen Datensätzen.

Ich kann mir eher vorstellen, das eine Verteilung auf mehrere DB's mehr Zeit kosten wird, aber das wäre schon mal interessant das festzustellen.

Meine dickste Tabelle hat 1,833,136 Einträge, da war ein Test nur bei der Verteilung auf mehrere Tabellen (also nicht DB) negativ verlaufen, hat Zeitverluste gebracht, kann bei einer Aufteilung über mehrere DB's nicht besser sein.

**Lennie** · 11.07.2009, 17:01

Das system weiß welche Datenbank anzusprechen, d.h. es muss nur eine Datenbank/Tabelle nach dem Datensatz durchsuchen, die dann deutlich weniger Datensätze enthält.

Meine Frage nur, ob ca. 50-? Datenbanken den Server nicht solangsam machen würden, dass es günstiger ist einfach eine deutlich größere anzahl an datensätzen zu durchsuchen, dafür aber den server nur mit einer datenbank und auch nur verbindungen zu dieser datenbank zu belasten.

**piratos** · 11.07.2009, 19:07

Also eine normale Myisam benötigt über einen Index nur 2 bis 4 Schritte normal um einen Datensatz zu finden, da spielt die Größe der Tabelle keine Geige, da reden wir über nicht mehr messbare Mikrosekunden.

Verteile ich das über mehrere DB's reden wir zunächst über deutlich messbaren Zeitaufwand um die Connections zu checken bzw. zu bilden.

Darüber muss man reden wenn eine DB vom Fassungsvermögen aus allen Nähten platzt.

Wieviel zig Millionen Datensätze hast du denn ?

**piratos** · 11.07.2009, 19:20

Mal ein Beispiel:

Meine CMS benötigt

SQL Queries:10 Gesamtzeit:0.044099998474121 Sekunden

um über einen ausgewählten Ort

die eine Postleitzahl aus über 1,8 Mio. gespeicherten über Land und Ortsnamen zu finden
und um alle Hotels im Rahmen einer Umkreissuche mit einem Radius von 50 km aus einer Anzahl von 2700 gespeicherten zu ermitteln

und um die komplette Seite darzustellen.

Die meisten haben irgendwelche nicht zutreffende Vorstellungen über die Leistungsfähigkeit von Mysql.

Deswegen meine Frage mit welchen Mengengerüsten da gearbeitet wird.

**Lennie** · 11.07.2009, 19:49

Es wird sich vielleicht erst einmal auch nur bis an die 2 Millionen Datensätze handeln, die allerdings aus deutlich mehr als ein paar zahlenspalten bestehen (25% volltext).

Damit hätte sich die schnelligkeitsfrage erklärt, überlege jetzt eben noch über die möglichkeiten des Back ups bei einer Datenbank!

**piratos** · 11.07.2009, 20:00

die allerdings aus deutlich mehr als ein paar zahlenspalten bestehen

Das ist vollkommen wurscht, da Mysql den Index abklappert und nicht die Inhalte durchwühlt.

Backup DB:
Ich gehe mal davon aus das du eine DB Klasse verwendest, wenn sie gut ist bietet sie dir da etwas an (die ich verwende kann das).

**PHP-Desaster** · 11.07.2009, 20:09

Ich würde, wenn es ein gemeinsames System ist, eine einzelne Datenbank verwenden. Alles andere halte ich für Käse und verkompliziert das ganze nur. Wenn du dir Sorgen um die Geschwindigkeit von Queries machst, entsprechend mit EXPLAIN ungeschickte Queries erkennen und optimieren bzw. weitere Indizes erzeugen.

Backups am besten und einfachsten direkt mit mysqldump über einen Cronjob erzeugen, zusammen-tar-en und auf den Backupserver schaufeln, z.B. per SFTP.

**Lennie** · 11.07.2009, 22:13

Ich verwende meine eigene DB Klasse, die ich deshalb entsprechend erweitern muss.

Dass mit dem Dump habe ich mir auch schon irgendwie in der Art gedacht, allerdings ist es bei 2 Millionen datensätzen auch entsprechend groß, macht es deshalb sinn es aufzuteilen?

**TBT** · 11.07.2009, 23:22

du kannst da schon auf die Leistungsfähigkeit von MySQL setzen,
wenn deine DB ordentlich designd ist.

Unsere (in Firma) Hauptdatenbank hat aktuell 16.000.000 Datensätze, bei 1,3GB Größe.
Das interessiert MySQL nicht die Bohne

**onemorenerd** · 12.07.2009, 00:55

Dumps mit Blobs können tricky sein. Da lohnt es sich vorher mal zu überschlagen:
BLOB fasst bis zu 64 kB. Bei 2 Mio. Datensätzen sind das bis zu 124 GB. Worst Case.
Üblich ist ein Füllstand von rund 2 kB. Entspricht 1 Seite Text. Text kann locker um 75% komprimiert werden. Macht 1,2 GB. Average Case.

Na, wie viele BLOB-Spalten hast du? Wie/wohin willst du die Dumps schreiben?

Um die Datenmenge zu verringern könntest du in einer zusätzlichen Spalte den Zeitpunkt der letzten Änderung festhalten und nur die Datensätze sichern, die seit der letzten Sicherung verändert wurden.
Außerdem könntest du die BLOB-Spalten separat sichern. Getrennt von den sonstigen Spalten, um im Ernstfall das Backup schneller wieder einspielen zu können, und getrennt voneinander um die Dumps klein zu halten.

**piratos** · 12.07.2009, 14:04

Beim Backup mit PHP gibt es das Problem der max_execution_time, das sollte man nicht vergessen.

Wer allerdings solch gewaltige Mengen an Daten erwartet wird auch einen entsprechenden eigenen Server besitzen, denn der ist auf extreme Besucherzahl eingerichtet.

Da bieten sich die direkten Methoden von Mysql zum Backup an, die laufen extrem schneller durch als alles andere.

Was meine o.a. Konstellation betrifft PHP Backup 42 Sekunden, Mysql direktes Backup 3 Sekunden.

Datenbank Design und Backup Ablauf