Große Mengen an Datensätzen, Hilfe bei Datenbankstruktur?

[filament]

Hallo liebe Community,

ich möchte grob gesagt (ohne groß ins Detaill zu gehen) ein Projekt aufbauen, dass sich um Finanzen, Anbieter und Quoten dreht und deren tabellarische und grafische Auswertung.

Da ich leider lange nicht mehr selbst Seiten programmiert habe bzw. mich weiter informiert habe, würde ich gerne vorab mal einige Sachen geklärt haben, bevor ich was anfange und es später aufgrund von Problemen wieder umstrukturieren muss. Die Arbeit kann ich mir ja durch ein gutes Grundkonzept sparen.

Das Projekt läuft wie folgt ab:

Ich stelle eine Seite zur Verfügung, die kostenlos von jedem Besucher der sich registriert hat, genutzt werden kann. Der User hat dabei die Möglichkeit selbst Datensätze anzulegen. Um eine Zuordnung zu gewährleisten wollte ich also erst einmal eine Tabelle anlegen User. Diese Tabelle besteht aus id (auto_increment; unique), username, registrierungsdatum, werbefrei (eventuell später brauchbar). Über Registrierung und die damit verbundenen MySQL Querys möchte ich hier nicht reden, die kann ich dem manual selbst entnehmen, zumal ich nicht ganz so eingerostet bin

Die zweite Tabelle soll lauten: Einzahlungen; Bestehend aus: id, userid, betrag, anbieter, datum.
Die dritte Tabelle soll lauten: Auszahlungen; Bestehend aus: id, userid, betrag, anbieter, datum.
Die vierte Tabelle soll lauten: Gewinne; Bestehend aus: id, userid, betrag, anbieter, datum.
Die fünfte Tabelle soll lauten: Verluste; Bestehend aus: id, userid, betrag, anbieter, datum.

Vielleicht folgen noch weitere Tabellen, sollen aber gleichen Aufbau haben. Grund: Ich will mit nem JOIN die User Tabelle mit der jeweiligen anderen Tabelle verbinden.

Nun zum eigentlichen Problem:

Es kann sein, dass ein User am Tag um die 20 - 40 Datensätze anlegt. Gehen wir mal von 20 aus. Dann legt er im Jahr eventuell 20 x 365 Datensätze an. Das sind 7300. Wenn ich nun 500 registrierte User habe (was ja eigentlich nicht viel ist), dann habe ich also um die 3.500.000 Datensätze. Ich will die Datensätze jedes Users mittels ID sortieren und auch zusammenzählen, maximal jedoch auf 1 Jahr beschränkt (SUM, ORDER BY etc.). Alles was älter ist als 1 Jahr wird nachts um 3 durch nen Cronjob gelöscht.

Hält meine MySQL Datenbank solche Datenströme stand? Macht es hier vielleicht Sinn das Projekt gleich auf mehrere Datenbanken aufzubauen? (Gedanke: 200 - 500 User pro Datenbank, danach neue) Frage: Macht das Sinn auf dem gleichen Server? (Oder sinnvoller verschiedene Server dafür zu mieten? (Anfangs will ich natürlich nicht die riesen Kosten eingehen, bis das Projekt nicht etwas an Einnahmen durch Werbung etc. abwirft))

Wenn ja wie realisier ich solche mehrfachserver basierten Projekte? Sollte ich der performance halber Datenbankklassen nutzen? (ich glaub das hieß so?)

Nächster Punkt: Bin wie bereits geschrieben länger nicht tätig gewesen, gibt es irgendwelche technischen Neuerungen in PHP5?

Insgesamt in den Raum gefragt, eignet sich für solche Statistikprojekte mit Auswertungen MySQL überhaupt? Oder gibt es andere Datenbanksysteme die besser geeignet sind? Wenn ja welche? Hat jemand dazu Tutorials oder Einführungen? (Kenne mich nur mit MySQL aus, sonst noch nichts anderes gemacht bisher)

Hat vielleicht jemand Erfahrungen mit Projekten derartiger Größe?

Danke im Voraus an euch für die Mühe!
Gruß
Ronny

 

[CPoly]

Da du sehr viele Fragen hast, vor allem auch aus verschiedenen Bereichen, werfe ich mal einfach ein paar Sachen in den Raum.


Im Prinzip ist gegen deine Tabellen nichts einzuwenden. Wichtig ist Normalisierung (scheinst du ja zu tun). Ist zwar nicht immer förderlich für die Performance, aber vermeidet Redundanz/Datenmüll und erhöht die Erweiterbarkeit/Wartbarkeit/Lesbarkeit/Verständlichkeit.


MySQL ist prinzipiell dafür geeignet, wie viele andere Datenbanksysteme auch (Postgres, Oracle, MS SQL, etc.). Da gibt es dann wieder unendliche Diskussionen, was die eine besser kann als die andere, aber das musst du selbst entscheiden.
Wenn ich mir deine bisherigen Tabellen ansehe, dann gibt es keine komplexe Beziehungen (Du brauchst im Moment ja nie mehr als zwei Tabellen bei einem JOIN). Deshalb lohnt sich vielleicht auch ein Blick in Richtung nicht-relationaler Datenbanken. Z.B. bei einer Dokumenten orientierten Datenbank (etwa http://www.mongodb.org/ ) hättest du pro User ein Dokument, welches alle Einzahlungen, Auszahlungen etc. enthält. Das hängt aber ganz davon ab, was du sonst noch alles an Daten brauchst.


Wenn deine MySQL Installation tatsächlich mal zu groß und damit zu langsam wird, würde man je nach Anforderung eine Master-Master (schnellere writes und reads) oder eine Master-Slave (sehr schnelle reads) Replikation aufbauen (natürlich auch mit mehr als zwei Master oder Slave Servern möglich). Aber darüber kannst du dir Gedanken machen, wenn du mit einem größeren Server (vertikale Skalierung) nicht mehr aus kommst.


Bei großen Projekten spielt natürlich Caching eine wichtige Rolle. Anstatt bei jedem Seitenaufruf die Datenbank zu bemühen, obwohl sich die Daten gar nicht geändert haben, wird der Kram einfach im RAM gehalten. Dafür geeignet z.B. http://memcached.org/. Damit kannst du auch den RAM von mehreren Server zu einem gigantischen Speicher verbinden und sehr schnelle Zugriffe realisieren (Facebook hat damit 800 Server vernetzt, um insgesamt 28TB RAM über eine einzige Schnittstelle ansprechen zu können [stand September 2010]).


Zu PHP kann ich keine qualifizierten Aussagen treffen.

 

[filament]

Das heißt dann aber, dass ich selbst einen Server haben sollte? Sprich keinen vom Provider mit anderen Kunden geteilten Server? Oder ist das dort genauso möglich?

 

[CPoly]

Auf was genau beziehst du dich?

So lange du mit einem VServer auskommst, wo du dir mit anderen einen Server teilst, liegen die oben beschriebenen Sachen noch weit weit entfernt. Aber installieren kannst du da ja auch alles selbst (voller root Zugriff vorrausgesetzt).

Wenn du mit einem Root Server (> 8 GB RAM) nicht mehr auskommst, dann wirst du erst mal die Datenbank vom Webserver trennen. Und wenn dann eines von beiden wiederum an die Grenzen kommt, dann gehst du am einfachsten erst mal noch etwas höher, z.B. je einen Server mit 128GB oder mehr RAM. Und dann kannst du dir einen dritten Server mit Memcached hinstellen (oder auch erst mal Memcached auf dem Webserver installieren). Und wenn das alles nicht mehr reicht (Großen Webserver und Großer Datenbankserver und intelligentes Caching) wird es erst in irgendeiner Form interessant (Loadbalancing für mehrere Webserver, Master-Master/Master-Slave für Datenbank, Verteiltes Memcached).

Natürlich kann man die Reihenfolge auch etwas ändern, je nach dem wie man es braucht (Monitoring!). Es schadet nicht ziemlich früh zwei Webserver hinter einem Loadbalancer zu haben, falls einer ausfällt.


Aber im Prinzip sind das alles Luxusprobleme. Mach dir erst mal Gedanken wie du da hin kommst^^.

 

[filament]

Hallo,

danke erstmal für die Antworten, hatte ich oben vergessen zu sagen

Im Moment habe ich halt einen Webspace über all-inkl.com gebucht. Diesen hier: http://all-inkl.com/webhosting/privatplus/

Dort teile ich mir den Server mit 50 anderen Kunden. (Ich betreibe zurzeit nur einen Blog, da reicht das einfach völlig aus! Vor allem weils einfach auch viel günstiger ist.) Was der Server dort an RAM hat kann ich nicht mal sagen. Ich habe halt 10 GB Speicherplatz.

Nehmen wir mal an ich möchte das ganze in den nächsten Wochen / Monaten angehen. Wie gehe ich jetzt am besten vor. Bleibe ich auf dem Server bis ich bemerke, dass es Probleme gibt? Oder sichere ich mich im Voraus ab und wechsle den Server? (Wenn ja, welchen Server bzw. Tarif? Schließlich habe ich auch noch nie einen eigenen Server gemanaged?)

Meine Datenbankstruktur sollte ja keine Probleme geben sagtest du ja? Wie kann ich eventuell die Performance mittels der Abfrage noch steigern? Oh hab gerade noch mal geschaut, du sagtest wegen PHP kannst du nichts sagen.. Dann sollte vielleicht mal jemand anderes was dazu schreiben, der aus der Hinsicht Ahnung hat.

Ich habe halt vor etwas richtig großes aufzuziehen und möchte nicht, dass mir irgendwas zwischendurch Probleme bringt. Wie schnell geht denn ein Datenbankumzug, wenn ich hunderttausende Datensätze hätte? Kann das von heute auf morgen vollzogen werden, einfach mal so?

So lange du mit einem VServer auskommst, wo du dir mit anderen einen Server teilst, liegen die oben beschriebenen Sachen noch weit weit entfernt. Aber installieren kannst du da ja auch alles selbst (voller root Zugriff vorrausgesetzt).

Was genau meinst du damit, dass die Sachen noch weit weit entfernt liegen? Heißt das, dass ich mir einen Server besorgen sollte, auf dem ich alleiniger Kunde bin?

Im Prinzip ist gegen deine Tabellen nichts einzuwenden. Wichtig ist Normalisierung (scheinst du ja zu tun). Ist zwar nicht immer förderlich für die Performance, aber vermeidet Redundanz/Datenmüll und erhöht die Erweiterbarkeit/Wartbarkeit/Lesbarkeit/Verständlichkeit.

Kannst du mal kurz zur Verständlichkeit Normalisierung definieren? Danke.

Wie genau funktioniert dieses MongoDB? Ist das wie MySQL aufgebaut vom Prinzip? Kann ich da auch einfach via PHP mit den normalen Abfragen die Datensätze auslesen und einfügen. (Sodass ich einfach nur andere SELECT Abfragen etc. habe****?)

Wenn deine MySQL Installation tatsächlich mal zu groß und damit zu langsam wird, würde man je nach Anforderung eine Master-Master (schnellere writes und reads) oder eine Master-Slave (sehr schnelle reads) Replikation aufbauen (natürlich auch mit mehr als zwei Master oder Slave Servern möglich). Aber darüber kannst du dir Gedanken machen, wenn du mit einem größeren Server (vertikale Skalierung) nicht mehr aus kommst.

Das fällt bei mir ja flach oder was?

Danke im Voraus für Antworten

 

[CPoly]

Das wird hier langsam unübersichtlich, vielleicht solltest du einen extra Thread für deine PHP Fragen (http://www.tutorials.de/php/) und einen für die Server Fragen (http://www.tutorials.de/hosting-webserver/) erstellen. Dann können wir hier bei der Diskussion um die Datenbank bleiben.

Zu Normalisierung:
Das heißt einfach, dass du die Daten so weit zerlegst (in mehrere Tabellen), dass innerhalb der Tabellen keine Abhängigkeiten mehr bestehen. Schlecht wäre es z.B., wenn deine Einzahlungs-Tabelle so aussehen würde
id | username | registrierungsdatum | werbefrei | betrag | anbieter | datum
Mehr dazu: http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

Zu Umzug:
Ein Umzug der Datenbank sollte ohne weiteres an einem Tag machbar sein. Im Prinzip hängt es nur von der Menge der Daten ab (kb, mb, gb) und der Bandbreite zwischen beiden Servern. Dann kannst du alle Daten einfach umziehen. Je größer desto länger dauerts eben und desto komplizierter.

Zu MongoDB:
http://www.mongodb.org/display/DOCS/SQL+to+Mongo+Mapping+Chart
http://www.mongodb.org/display/DOCS/PHP+Language+Center

Zu "Schließlich habe ich auch noch nie einen eigenen Server gemanaged?":
Vielleicht solltest du dir dann eine alternative überlegen. Beispiel (deutsche Firma!): http://cloudcontrol.com/

Was genau meinst du damit, dass die Sachen noch weit weit entfernt liegen? Heißt das, dass ich mir einen Server besorgen sollte, auf dem ich alleiniger Kunde bin?

Wenn du sagst "Ich habe halt vor etwas richtig großes aufzuziehen", dann braucht man gar nicht drüber nachdenken, ob du dir mit 50 anderen einen Server teilen kannst. Das wird nicht funktionieren. Aber wenn du einfach loslegen willst, dann kannst du das natürlich machen. Aber du musst dir im klaren sein, dass wenn du ein paar mehr Besucher bekommst, du schnell umziehen musst. Aber das ist ja kein Problem. Fang doch einfach mal an und guck was passiert.