[Webdesign360]

Hallo zusammen,
Mache mir gerade ein wenig Gedanken über eine Datenbank Struktur. Spezielles Interesse liegt bei der Leistunbgsfähigkeit einer DB oder eher einem Datenbank Server.

Inhalte sind ca 120'000 Einträge die Tabelle hat insgesamt 60 Spalten mit Einträgen, ca. 15 Spalten werden in der Übersicht pro Eintrag abgefragt, es werden immer zwischen 10 und 100 Einträge in der Übersicht angezeigt, dabei soll die Homepage für bis ca .40'000 User pro Tag ausgelegt sein.

Die Gesamtübersicht dieser Einträge fragt dann alle 60 Spalten ab und stellt diese da. Es geht hierbei um ein Portal mit Ferienwohnungen, es werden also Texte, Bilder und Icons angezeigt die vom Webserver geladen werden.

Das gesamte Portal soll so ausgelegt sein, das es echt Mehrsprachig ist.

Die Leistungsfähigkeit der DB und Webserver sollen erweiterbar sein, so das Beispielsweise auch 250'000 Einträge verwaltet werden können und 100'000 Usern am Tag die Homepage besuchen.

Da ich selber bislang nur kleine Projekte durchgeführt habe, interessiert es mich ob jemand von euch schon mal Erfahrungen gesammelt hat und wie eine Datenbank Struktur aussehen könnte. Ich selber habe da eine bestimmte Idee weis allerdings im Moment nicht ob diese wirklich gut und ausreichend ist.

Also Bin gespannt dazu von euch Vorschläge zu sehen.

[robo47]

Ohne eine wirkliche Info über die Struktur, wie/wo welche Daten gebraucht werden etc, kann man da schlecht sagen was man besser machen kann, z.b. ob man das ganze weiter normalisieren sollte, etc. Ein Datenbankdesign mit nur einer Tabelle und 60 Spalten lässt allerdings meistens vermuten, dass man das noch etwas besser normalisieren kann.

Bei der Größenordnung denke ich allerdings auch, dass nicht nur die Struktur der Tabellen eine wichtige Rolle spielt, sondern sehr viel von der Konfiguration des Servers, php und mysql optimiert, zusätzliche Dinge wie ein Bytecode-Cache für PHP (APC, eAccellerator, Zend Optimizer ... etc), aktivierter QueryCache für PHP, ein CacheSystem im RAM des Servers (z.b. über APC oder Memcache), Verteilung der daten auf 2 oder mehr Platten (eine Betriebsystem, eine mysql-daten, eine für htdocs.
Unter Umständen kann es sich hier auch lohnen statische Inhalte (Bilder, CSS, Downloads) über einen 2ten Webserver [ich mein damit nicht nen 2ten Server in form von Hardware!] (lighttpd, nginx oder was ähnliches) laufen zu lassen.

Bei 40.000 Usern (und mal "nur" 10 MB / User und sowas ist mit Bildern, bißchen rumklicken und suchen schnell verbraten) kommt man da schon auf beachtliche 400 GB Traffic / Tag. Damit ist eine 100Mbit Karte im Server schon zu mehr als 40% ausgelastet (Theorhetisch bekommt man max~ 1 TB / Tag über 100 Mbit in 24 Stunden) wenn man das mal auf 24 Stunden verteilt. Da man aber die Peaks tagsüber hat, wären 100Mbit da wohl schon überlastet.

Der Server sollte also nach möglichkeit mit mehr als 100mbit angebunden sein oder man verteilt das ganze auf 2+ Server [bzw. plant eben schon in das Applikationsdesign ein, dass es verteilbar ist] (einer statischen Kram, einer die Generierung der Seiten)

Zum Thema Skalierbarkeit (Webseiten allgemein, PHP, Apache, Mysql und co) finden sich übrigends bei
http://www.slideshare.net/search/sli...rch]Slideshare einige gute (zumeißt englische) Präsentation (unter anderem wie solche Sachen bei Flickr, Yahoo, Facebook, Digg und ein paar anderen größeren Seiten gestaltet sind).

[ads]

Hallo,

das Topic ist zwar schon etwas älter, aber was solls ...


Eine Tabelle mit 60 Spalten hört sich schon mal nicht gut an. In der Regel ist dies ein Zeichen für fehlende Normalisierung und das nehmen relationale Datenbanken sehr übel.


Zur Mehrsprachigkeit: konsequentes Normalisieren dürfte dir an dieser Stelle weiterhelfen. Jedes Element, jede Beschreibung ect. liegt dabei nur als Referenz vor und bei den referenzierten Elementen steht dann der mehrsprachig vorhandene Text.


Zur Skalierbarkeit verweise ich mal auf das, was robo47 schon gesagt hat. Allerdings möchte ich so eine komplexe Struktur schon gar nicht mehr in einer MySQL Datenbank abbilden ... dafür gibt es besseres.

[MrNiceGuy]

Ich würde nicht unbedingt sagen, dass es Besseres gibt. Die Praxis hat gezeigt, dass MySQL ohne Probleme mit riesigen Datenbanken (mehrere GiB) arbeiten kann. Wichtig ist der richtige Einsatz von Indizes.

Auch wenn MySQL im Ansatz eine freie Datenbank ist und es professionellere Datenbanken zu kaufen gibt, heißt das aber noch lange nicht, dass man mit MySQL nicht zufrieden sein kann. Die Möglichkeiten dieses DB-Systems sind jedenfalls mehr als ausreichend.

Allerdings würde ich nicht unbedingt davon ausgehen, dass 60 Spalten schlechte Normalisierung bedeuten. Es kann durchaus Fälle geben, in denen gerade durch die Normalisierung (nicht mehr als eine Information pro Spalte) größere Tabellen bei herauskommen. Wenn diese Daten dann 1:1 miteinander verknüpft sind und alle stetig gebraucht werden (z.B. bei Statistiken), kann es durchaus mal sein, dass eine sehr große Tabelle entsteht, bei der eine Separation in mehrere Tabellen mit einer 1:1-Beziehung sich eher nachteilig auf die Performance auswirkt.

Das aber nur nebenbei, im Normalfall wird deine Vermutung wohl dennoch hinkommen ;)

[ads]

Zitat von MrNiceGuy

Die Praxis hat gezeigt, dass MySQL ohne Probleme mit riesigen Datenbanken (mehrere GiB) arbeiten kann.

Dann haben wir beide unterschiedliche Praxiserfahrungen.
Ich habe oft genug MySQL-Datenbanken gesehen, bei denen z. B. nach einem Absturz umfangreiche Prüfmassnahmen angesagt waren oder bei denen auch InnoDB keine Datensicherheit garantieren konnte. Schön, wer ein aktuelles Backup hatte ...

Wichtig ist der richtige Einsatz von Indizes.

Richtig. Und wo sind funktionale Indizes, partielle Indizes, Indizes auf anderen Festplatten (Performance)?

Allerdings würde ich nicht unbedingt davon ausgehen, dass 60 Spalten schlechte Normalisierung bedeuten.

Darum habe ich "in der Regel" geschrieben. Ich kenne auch Fälle, wo 60 Spalten - oder mehr - Sinn machen. Aber dann weiß der Programmierer schon, was er tut.

[mepeisen]

Das einzige, was an anderen Datenbanken besser ist, ist die Skalierbarkeit, denn irgendwann gibt die Hardware einfach nicht mehr Performance her, also muss man beispielsweise auf einer IBM Blackbox oder auf einem Cluster die Datenbank betreiben.

Das wird immer von den Betriebskosten teurer als alles, was der Hausgebrauch kennt, daher wird das im normalen Bereich keiner ernsthaft untersuchen. ABER: Es gibt auch Cluster-Varianten der MySQL. Wie die dann skalieren, dazu fehlt mir jegliche Erfahrung. Und bisher hatte ich trotz richtig großer Datenmengen nie ernsthafte Probleme mit MySQL.

Einen wirklichen Unterschied gibt es nicht, denn wenn man an die Grenzen der Performance anstößt, dann muss man sich mit der Arbeitsweise der Datenbank auseinandersetzen. Es gibt dann einfach SQLs, die eine Datenbank richtig ungeschickt handhabt und dann 50 Minuten braucht und die die andere Datenbank in wenigen Millisekunden abarbeitet. Trotz Indices, trotz Tuning. Da kann ich euch Geschichten zu erzählen, wie wir DB/2-Selects teilweise völlig absurd formuliert haben, nur damit es genau die Indices nimmt, die es nehmen soll.

Das zweite Problem ist nur bedingt ein Performance-Problem: Analyse und Performance-Analyse. Dazu braucht es extrem Know-How. Bei uns gibt es beispielsweise hervorrangendes KnowHow im DB/2-Bereich. Bei anderen Datenbanken (Oracle, MySQL) muss das erst mühsam aufgebaut werden, bis man im Betrieb einen Mehrwert erzielt und bei Performance-Problemen an den richtigen Stellschrauben dreht.

Das Fazit ist einfach: Wer tiefer in das performance-Thema einsteigen will, der sollte sich einen Leitspruch setzen: "Vergleiche sind Humbug".
Kein Select ist wie der andere, keine Datenbank wie die andere, kein Tag wie der andere ;)


Achja: Wer innoDB bei kritischen Anwendungen einsetzt, ist selbst schuld ;)

[ads]

Zitat von mepeisen

Achja: Wer innoDB bei kritischen Anwendungen einsetzt, ist selbst schuld

Nicht das ich MySQL mag, aber was nimmst du dann?

[mepeisen]

Zitat von ads

Nicht das ich MySQL mag, aber was nimmst du dann?

Zum beispiel jenes: http://www.redbooks.ibm.com/abstracts/sg247705.html

Das ist sogar das schöne an MySQL: Man kann sich die Engine aussuchen und mittlerweile finden sich einige, je nach persönlichen Bedürfnissen ;)

Zudem kommt mit 6.0 (bzw. wenn die Herren Diven wieder miteinander spielen wollen)
http://dev.mysql.com/doc/refman/6.0/en/se-maria.html
http://dev.mysql.com/doc/refman/6.0/en/se-falcon.html

Die können sich ja eventuell bewähren, je nach Einsatzgebiet.

[ads]

Zitat von mepeisen

Zum beispiel jenes: http://www.redbooks.ibm.com/abstracts/sg247705.html

Tschuldigung, da kann ich gleich DB2 nehmen.

Wenn ich mir Gedanken um 2 Datenbanken machen muss - wähle ich eine und zwar die bessere. Ansonsten brauche ich jemanden, der sich mit MySQL auskennt und jemanden, der Ahnung von DB2 hat. Das sind doppelte Kosten.

Das ist sogar das schöne an MySQL: Man kann sich die Engine aussuchen und mittlerweile finden sich einige, je nach persönlichen Bedürfnissen

Wenn denn alle Storage Engines auch alle notwendigen Features unterstützen würden ...
- Volltextsuche geht nicht mit Transaktionen
- Transaktionen funktionieren nicht mit schneller MyISAM Engine
- Geodaten gehen auch nur mit begrenztem Umfang

Zudem kommt mit 6.0 (bzw. wenn die Herren Diven wieder miteinander spielen wollen)

Das sind aber alles Engines, für die es noch keine Anwendungserfahrungen gibt. Schon 5.1 wurde als verfrühtes Release betrachtet, hoffen wir, dass 6.0 nicht ein ähnliches Schicksal wiederfährt. Und bis (große oder groß werdende) Applikationen auf die neuen Storage Engines wechseln oder diese nutzen, vergehen auch noch mal einige Monate. Erst dann zeigt sich, wie brauchbar die neuen Engines sind oder ob da noch nachgearbeitet werden muss.


Ach ja:
http://blog.redfin.com/devblog/2007/...s_smarter.html

[mepeisen]

Maria wurde für 6.0 angekündigt, gibt es aber seit etwa eineinhalb Jahren in einer stabilen Version auf einem 5.1 Fork. Es gibt auch einige Labors, die damit positive Erfahrungen gemacht haben.
Ansonsten hast du aber Recht. Sicherlich sind einige Sachen bei MySQL noch zu jung, um sie vernünftig einschätzen zu können, ohne sie selbst ausprobiert zu haben.

[MrNiceGuy]

@ads: natürlich ließe sich über dieses Thema streiten, das will ich garnicht in Frage stellen :)

Allerdings weiß ich nicht, wie andere Datenbank-Systeme es schaffen sollen bei einem richtigen Crash ihre Daten sicher zu behalten, ich denke, dass es da auch bei anderen Systemen durchaus zu Schaden kommen kann, schließlich ist ein Absturz kein berechneter Stop des Systems und kann IMMER Inkonsistenzen verursachen, deren Auswirkung nicht immer automatisch behoben werden kann!?

Wie dem auch sei, jeder muss selber wissen, welche DB er einsetzt, allerdings haben wohl die Wenigsten eine andere Möglichkeit, als auf MySQL zu setzen, es sei denn es befindet sich ein Root-Server im Fuhrpark :)

[ads]

Zitat von MrNiceGuy

Allerdings weiß ich nicht, wie andere Datenbank-Systeme es schaffen sollen bei einem richtigen Crash ihre Daten sicher zu behalten,

Unabhängig von der verwendeten Software:
Aufgabe einer Datenbank ist es, die eingegebenen Daten sicher aufzuheben. In dem Moment, in dem die Anwendung - oder der Benutzer - die Daten geschrieben hat, möchte er die auch sicher verwahrt und gegen Abstürze gesichert wissen.

Das ist zumindest das, was ich von einer Datenbank erwarte und was alle modernen Datenbanksysteme auch durch die Bank leisten.

ich denke, dass es da auch bei anderen Systemen durchaus zu Schaden kommen kann, schließlich ist ein Absturz kein berechneter Stop des Systems und kann IMMER Inkonsistenzen verursachen, deren Auswirkung nicht immer automatisch behoben werden kann!?

Falsch gedacht.
Allerdings betreiben Datenbanken (MySQL nur bei einigen Tabellentypen) einen beträchtlichen Aufwand, um Datenkonsistenz sicherzustellen und kaputte Dateien zu vermeiden.

Im Prinzip funktioniert das so:
Zuerst wird die anstehende Änderung in eine Logdatei geschrieben. Sobald diese Datei sicher auf der Festplatte angekommen ist, wird die eigentliche Datenänderung durchgeführt. Stürzt das System beim Schreiben der Logdatei ab, sind die Daten immer noch in Ordnung. Stürzt das System beim Ändern der Daten ab, kann der vorherige Zustand aus dem Log wiederhergestellt werden.

Was sich hier so einfach anhört, beinhaltet allerdings noch einiges an Mehrarbeit. Außerdem kann man sehen, dass es nicht mit einer einzelnen Schreiboperation getan ist sondern es finden immer Schreibvorgänge nacheinander statt - das kostet natürlich Zeit und kann nie so schnell sein wie ein einzelner Schreibvorgang allein. Im Gegenzug ist die Datenkonsistenz auch nach einem Absturz jederzeit gewährleistet.

allerdings haben wohl die Wenigsten eine andere Möglichkeit, als auf MySQL zu setzen, es sei denn es befindet sich ein Root-Server im Fuhrpark

Leider ...

[MrNiceGuy]

Mag auch sein, dass das so ist. Mein Verständnis von Datenbanken deckt sich ja auch mit deinem. Ich meinte nur, dass es auch für andere Datenbanksysteme sicher Situationen gibt, bei denen auch diese hoffnungslos der Hardware Tribut zollen, ob sie das nun wollen oder nicht. Abstürze können so viele Gründe und Ursachen haben, das kann kaum alles durch ausschließlich gute Programmierung und Überlegung beim Datenbank-System abgedeckt werden!? Meiner Meinung nach vermindern andere, bessere Datenbanksysteme dahingehend lediglich die Wahrscheinlichkeit einer Dateninkonsistenz, gänzlich sicher ist aber wohl keines.

[ads]

Zitat von MrNiceGuy

Meiner Meinung nach vermindern andere, bessere Datenbanksysteme dahingehend lediglich die Wahrscheinlichkeit einer Dateninkonsistenz, gänzlich sicher ist aber wohl keines.

Jetzt muss ich mal nachfragen: wie kommst du zu dieser Überlegung? Bzw. welcher Fall fällt dir ein, wo Daten nach einem Crash inkonsistent sind?
Das würde mich ernsthaft interessieren, da ich so etwas von einer Datenbank nicht erwarte.


Kleine Einschränkung: eine kaputte Festplatte mit defekten Sektoren sorgt z. B. für einen Datenverlust, den die Datenbank aber nicht zu verantworten hat. Für so etwas setzt man ein RAID ein und hat regelmäßige Backups.

[MrNiceGuy]

Ich hatte mal das Problem, dass eine Stromschwankung zur kurzzeitigen Unterbrechung der Stromzufuhr im Server geführt hat, wodurch bestimmte Daten defekt waren. Dies betraf jedoch nicht nur die Datenbank, sondern auch Teile des Betriebssystems. Ebenso sorgt natürlich auch defekte Hardware gerne mal dafür, dass bestimmte Daten nicht korrekt verarbeitet werden (defekter RAM, kaputte Festplatten, etc.). Dass man dem mit RAIDs etc. entgegenwirken kann ist mir durchaus klar, aber es gibt keine 100% Sicherheit. Die Stromschwankung hätte man im Übrigen durch eine USV abfangen können, ja. Aber: Irgendwo ist mein Budget dann doch begrenzt und wer ahnt denn, dass die Bauarbeiter auf der Straße vor dem Haus mit dem Bagger die Stromleitung küssen *rolleyes*

Letztendlich will ich eigentlich nur damit sagen, dass es kein perfektes System gibt. Irgendwas kann IMMER passieren. Und gerade in der EDV halte ich mitlerweile nichts mehr für ausgeschlossen, da kommen die wildestens Dinge vor. Nichtsdestotrotz bin ich bisher immer gute mit MySQL gefahren und werde es auch weiterhin verwenden. Bisher hatte ich allerdings auch noch nicht das Bedürfnis nach Funktionen der größeren DB-Systeme, vielleicht arbeite ich einfach in einem zu kleinen Eckchen des Universums!? :)

EDIT: Im Übrigen ist ein RAID auch keine Lebensversicherung. Wenn man Pech hat und der Controller schmiert ab oder es sind innerhalb kürzester Zeit gleich mehrere Festplatten betroffen... Wie gesagt, es ging mir lediglich um die Aussage, dass kein System perfekt ist.

[ads]

Das stimmt allerdings. Gegen kaputte Hardware kann die Datenbank nichts machen und wenn das Betriebssystem auch beeinträchtigt ist, hast du noch größere Probleme.

Nichtsdestotrotz betreiben Datenbanken einen großen Aufwand, bei reinen Softwareproblemen (Crash, Stromausfall, ...) jederzeit die Datenkonsistenz sicherzustellen. Eine Datenbank die das nicht schafft und Daten verliert, verdient diesen Namen nicht.

[mepeisen]

Es ist auch ein Unterschied zwischen totaler Datenkonsistenz und einem leicht wiederherstellbarem Datenzustand. Fast alle Datenbanksysteme, die ich kenne, beschränken sich auf zweiteres. Für alle Systeme gibt es Situationen, wo die Daten erst einmal augenscheinlich zerstört sind, wo jedoch nach einem Wiederanlauf die Daten wieder rekonstruiert werden.

Und Hardware-Crashs geht man am besten mit Hardware-Redundanz (Raid-Systemen, Clustern) aus dem Weg. Auch weniger etwas für den Hausgebrauch.