User DatenbankEN ..

time2flirt · 21.08.2009

Hallo Leute,

ich habe folgende überlegung und zwar da wir sehr viel user erwarten bei einem projekt wär es so gedacht das wir mittels php und mysql eine "replikation" im erweitesten sinne reproduzieren.

Es stehen gesamt 5 verschiedene mysql Server in DE und USA zur verfügung.

Soll nun folgendes heißen:
- User meldet sich an landet in authdb (passwort,nick,mail,handynummer)
Diese Datenbank "autdb" wir immer zum login , passwort vergessen benutzt, dort liegen ALLE Registierten daten wie oben geschrieben.

Nun sollte es so weitergehen:
udb1,udb2,udb3 und udb4 sind eigene mysql server - jeder dieser Server z.b udb1 hat eine ID limitations von z.b 1 - 3000 - dieses Limit heißt also nun wenn sich ein user anmeldet bekommt er eine ID mit der er auch am auth server abgefragt wird.

Gestaltet dieser user mit der beispiel id 2390 so landet er auf udb1 wo alle seine daten gespeichert sind - da diese datenbank zuständig ist für diesen user - auch werden empfangene und gepostete fotos von diesem user in der userdb1 abgelegt.

Wenn aber nun ein user 3001 hat landet er schon in udb2 und alle seine bekommenen gästebuch einträge als auch seine empfangenen nachrichten.

Hoffe ihr wisst was ich meine =)

greeZ

Duddle · 21.08.2009

AW: User DatenbankEN ..

Kurze "hör nicht zwingend auf mich"-Erklärung: Folgendes beruht nur auf Instinkt und ersten Ideen, nicht theoretischem oder praktischem Wissen mit einem wie von dir beschriebenen System.

Mein erster Kritikpunkt wäre, dass dieses System ab 12k Benutzern (um mal bei den beispielhaften Zahlen zu bleiben) komplizierter zu implementieren wird. Oder willst du aller 3k Benutzer einen neuen Server hinstellen? Wenn nicht, wie willst du es richtig aufteilen? Ist 3k die richtige Grenze, 4k oder doch nur 2k pro Server?

Zweitens: was passiert, wenn einer der Server ausfällt? Dann können plötzlich 3k Nutzer nicht mehr das System benutzen. Klar, es gibt Failback- / Ausweichserver, aber dann verdoppelt sich sofort die Anzahl der benötigten Server, Anschlüsse usw.

Drittens: das soll sicherlich eine relationale Datenbank werden und es wird sicher Beziehungen zwischen den Entitäten geben. Diese Beziehungen sind aber sehr viel schwieriger einzuhalten wenn die Bezugsdaten (im Beispiel die benutzerbezogenen Daten) auf X Server verteilt sind. Dadurch wirst du, besonders bei komplexeren JOINs, schätzungsweise einiges an Performance verlieren. Ausserdem muss dann auch dein Datenbanksystem diese Teilung unterstützen und ich vermute solch ein größeres Feature hat nicht jedes DBMS.

Das sind nur erste Gedanken, die für mich deinen Ansatz schon sehr fragwürdig erscheinen lassen. Sehr gern lasse ich mich aber von erfahreneren Leuten mit ein paar Links oder Hands-On-Erfahrung vom Gegenteil überzeugen.
Mein absolut aus der Luft gegriffener Vorschlag wären daher zwei replizierte DB-Server (die jeweils ein Hot-Standby haben) und entweder per Load-Balancing oder ortsbezogen ausgewählt werden. Dann haben alle Server die gleichen Daten (lies: Relationen bleiben erhalten), ausfallende Server werden abgefangen und es skaliert besser (mehr Benutzer = mehr RAM einbauen).

Insofern: falls du dir unsicher ob deines Entwurfs bist, und deine Frage legt das nah, solltest du dir echtes Fachwissen anlesen oder es dir einkaufen. Wenn dein Projekt wirklich so groß wird wie du es erwartest ist ein DB-Experte sicher im Budget drin.

Duddle

time2flirt · 21.08.2009

AW: User DatenbankEN ..

Hallo,

die aufteilung ist "on the fly" entstanden - sinnfreie werte kommt eben je nach Hadware drauf an wie viel reingeht bzw. das Limit der mysql Datenbank erschöpft ist.

-> Replicationen alles schön und gut, nur ich habe nicht vor 1 Datenbank zu benutzen sondern die connects so zu schreiben das jeder user einen "heimatort" in der datenbank hat - sachen von user ID 333 kommen eben wie oben geschrieben da rein - anmeldedaten liegen jedoch auf der authdb.

Die frage ist ob man nicht via index sagen kann wähle bei 1-5000 udb2.host.com an - oder eben mittels php.

Es geht darum: Wenn z.b die user db2 schwimen "offline" geht warum auch immer - so sind eben sagen wir mal beispiel "sinnfreie zahlen" 4.000 Profile nicht erreichbar und eben nicht alle. Das ist der sinn der sache.

stroyer · 23.08.2009

AW: User DatenbankEN ..

Wenn zum Beispiel ein User aus der DB 1 einen Gästebuch bei einem User aus DB 2 hinterlässt (wird in DB 2 gespeichert), dann müssen beim Abfragen zwei DBs abgefragt werden, die womöglich weit von einander entfernt sind. => längere Ladezeiten als nötig.
Wenn würde ich nicht die ersten 3000 user in db1 usw machen sondern immer die user aufteilen und neue accounts dorthin geben, wo am wenigsten user eigetragen sind.

Duddle · 23.08.2009

AW: User DatenbankEN ..

stroyer schrieb:
sondern immer die user aufteilen und neue accounts dorthin geben, wo am wenigsten user eigetragen sind.

Dann musst du bei jeder Benutzeraktion alle Server anfragen um erstmal herauszufinden, wo dieser Nutzer gerade eingetragen ist. Das mag bei zwei Servern gehn, wird aber unschön - und vorallendingen unnötig - bei zwanzig Servern.

Duddle

stroyer · 23.08.2009

AW: User DatenbankEN ..

time2flirt schrieb:
- User meldet sich an landet in authdb (passwort,nick,mail,handynummer)
Diese Datenbank "autdb" wir immer zum login , passwort vergessen benutzt, dort liegen ALLE Registierten daten wie oben geschrieben.

Nicht wenn man den Speicherort dorthin ablegt.
"Füllstand" der einzelnen Server kann man dort auch cachen.

time2flirt · 23.08.2009

AW: User DatenbankEN ..

hallo,

nach ein paar stunden funkstille bin ich wieder hier =)

hat es eigentlich erfasst..

Ziel ist es user datenbank systematisch bei der registrierung in diverse "datenbanken" einzutragen.

- Authserver = generelle userdaten
- usdbX = aktionen server wo gb , profil vom user gespeichert sind

Meine Idee wäre folgende nur ob das sinvoll bezüglich realisation ist..

User meldet sich an ein sql befehl geht an die 1 db und schreibt die useranmeldung rein .. erst wenn sich der user aktiviert wird auf der entfernten datebank (udb1-udb4) ein user angelegt "sein profil" ab nun an sagt die ID der "authdb" wo auch die userdaten enthalten sind welche ID für ihn zuständig ist also welcher server.
Da die Server verschiedene IDS "userprofile & aktionen" tragen eh wie im ersten post geschrieben.

Thema cachen - die datenbankserver sind meist alle "intern" also stehen im selben raum können aber auch extern ausgelagert werden.

Realisation?
Eine art read script das chekkt ist die id vom user X wenn ja frage db server 2 ab.

stroyer · 23.08.2009

AW: User DatenbankEN ..

Oder einfach ein eigenes Feld anlegen mit dem Speicherort.

time2flirt · 24.08.2009

AW: User DatenbankEN ..

Wie geht das denn? Hättest du da einige infos für mich?
Nur vergiss nicht gerade und ungerade user IDS -> andere db

lostboi · 25.08.2009

AW: User DatenbankEN ..

Ohne tiefer in die Diskussion mit einsteigen zu wollen fallen mir hier 2 Dinge auf.

1) Bist Du bei einem so großen Projekt wirklich an MySQL gebunden? Wenn nein, warum guckst Du Dir nicht mal andere DBMS an, die ggf. Deine Anforderungen besser erfüllen können?
2) Hast Du Dir mal die Möglichkeit des Clustering in MySQL ab Version 5 angesehen? Wobei sich hier (berechtigter Weise) auch wieder die Frage der Performance stellt, wenn nicht alle Hosts im gleichen RZ stehen oder räumlich zu weit von einander entfernt sind.

Just my 2 Cent.
LostBoi

stroyer · 25.08.2009

AW: User DatenbankEN ..

time2flirt schrieb:
Wie geht das denn? Hättest du da einige infos für mich?
Nur vergiss nicht gerade und ungerade user IDS -> andere db

Ich habe gemeint, dass du den User nicht in Abhängikeit von seiner ID irgendwohin speicherst sondern dass du neue User immer in die Datenbank speicherst, die am wenigsten Einträge hat.
Wenn zum Beispiel während dem Betrieb eine neue DB hinzukommt, kannst du den statischen Code vergessen.
Meine Alternatvie wäre, dass diese aufgefüllt wird, bis alle DBs wieder im Gleichstand sind.

time2flirt · 25.08.2009

AW: User DatenbankEN ..

hey,

es ist eben das problem das server gewisse gerade ungerade user auffangen server1 = gerade user ids server2 wiederum ungerade brechen die server nun warum auch immer ab bzw. gehen down is ned alles weg.

Wär aber denk ich mit deiner kombination machbar oder irr ich mich?

Edit: Nur nach irgend einem chema muss ich den user speichern und nicht nach lust und laune = Sinn = wenn eine db down geht nicht die ganzen user unregistriert sind sondern nur ein teil nicht erreichbar ist.

Bin gerne aber auch für andere sinvolle möglichkeiten zu haben =)

stroyer · 25.08.2009

AW: User DatenbankEN ..

Ich meinte, dass es zwar zum Teil nach Lust und Laune verteilt wird aber in der auth DB abgespiechert wird, wo der User liegt.
Wenn die DB down geht funktioniert so wie so nichts mehr, da die Zuordnung username->id nicht geht.

time2flirt · 26.08.2009

AW: User DatenbankEN ..

stroyer schrieb:
Ich meinte, dass es zwar zum Teil nach Lust und Laune verteilt wird aber in der auth DB abgespiechert wird, wo der User liegt.
Wenn die DB down geht funktioniert so wie so nichts mehr, da die Zuordnung username->id nicht geht.

Würde ich nicht sagen wenn db down dann id zuordnung down - daher meinte ich wie wäre es mit einem php file das beim login chekkt welche ID -> wenn id bereich 2 -> lese aus connection2 aus , PHP ordner das zu und verbindet NICHT MYSQL.

Somit finde ich die aussage "Wenn die db down is is eh alles weg" unsinnig, denn wenn php vorher die ids chekkt passiert eben nichts.

Auser ein mysql error wenn db -> down.

stroyer · 26.08.2009

AW: User DatenbankEN ..

Du meldest dich aber eher nicht mit User ID und Passwort an.
Und wenn die Zuordnung Username->User ID streikt, ist der Speicherort auch schon egal.

time2flirt · 26.08.2009

AW: User DatenbankEN ..

hi,

schau es geht darum in der authdb (server0) sind username passwort drinen - db1 und db2 sollen userprofile je nach gerader oder ungerader user ID von der authdb speichern.

Klar kann ich die authdb noch erweitern ist ja kein thema mir gehts nur generell darum was muss ich tun um mittels php und mysql diese "aufteilung" zu erhalten.

Ein kumpel meinte "helper" tabellen wie folgt:
server 1
- user tabelle | id, user, pw .....
- helper tabelle | id, user -dies ist immer identsich mit allen anderen servern
server 2
- user tabelle | id, user, pw .....
- helper tabelle | id, user -dies ist immer identsich mit allen anderen servern

Kannst du dir drunter was vorstellen?

r3nt5ch3r · 04.09.2009

AW: User DatenbankEN ..

Sowas macht man bestimmt nicht auf PHP-Ebene... -> MySQL :: MySQL Cluster

time2flirt · 04.09.2009

AW: User DatenbankEN ..

hoi,

wenn mans aber auf php ebene lösen muss

??

saila · 04.09.2009

AW: User DatenbankEN ..

Hi,

also ich habe mal das ganze Thema im groben durchgelesen.

Zwischendurch kam die Frage auf, ob es mysql sein muss. Naja, hier bleibt vorerst ein Argument prinzipiell stehen - warum bieten alle Provider mysql an?! Und diese verwalten mal ganz nebenbei mehrere Datenbanken für mehrere Domains per MySql-Cluster. Das dazu.

Zum eigentlichen Thema:
Mir fehlt bei dem Grundthema ein einigermassen nachvollziehbares Konzept. Mal so in den Raum geschmissen - ja da haben wir dies und das mal überlegt und die Daten des User hier und jene Daten da und man höre - gerade ID's in jene DB und ungerade in eine andere DB. Das ganze noch begrenzt auf 3k/DB.

Also eine mysql-DB schaft locker 3000k. Wie die Verteilung dann erfolgt, wo welche Daten abgelegt werden ist eine zweite Frage.

Abgesehen davon, dass man z.B. Server hier in Europa für User aus Europa zur Verfügung stellt und diese per Sprache in die jeweilige DB verteilt und User aus Übersee in DB's aus Übersee setzt dürfe wohl mehr als eine logische Konsequenz zur Verteilung der User sein. Insbesondere wird dadurch auch das Thema eines Serverausfall bzgl. der auth-Tabelle vermieden, da diese dann in jeder DB zu jedem zugehörigen Kontinent immer noch erreichbar ist.

Und wenn man schon dabei ist, deratrig geplante Datenmengen zu händeln - dann setzt man im Grunde je Land einen Server und der zugehörigen Datenbank auf.

Was das Thema Helper-Tables betrifft - viel Ahnung dürfte der Kumpel nicht gerade aufweisen, da Helper-Tables die Performance von etwas bis mächtig mindern/bremsen werden. Also lässt man Helper-Tables völlig weg - ausgenommen man kann es nicht vermeiden. Nur bei Themen wie Gästebuch oder dergelichen, man benötigt für derartige Tabellen keine HT's.

Für den Administrativen-Bereich, kann man dann immer noch einen Server aufsetzen, welcher alle Userdaten beinhaltet. Allerdings - ich schmunzel schon etwas - wer solch ein Projekt umsetzen möchte hat auch den entsprechenden finaziellen als auch fachlichen Background. Somit dürfte das Thema hier kein Thema sein.

Wenn sich das Thema lediglich um 3k User dreht oder von mir auch um 200 - 1000k, reicht ein Server zumindest für Europa völlig aus bzgl. der DB-Frage und somit ist die Verteilungsfrage auch schon geklärt.

Frage zum Eingangsbeitrag und dessen Verfasser: Warst du da Betrunken oder war die Tastatur zu weit entfernt?

time2flirt · 05.09.2009

AW: User DatenbankEN ..

hoi,

warum sollte ich betrunken sein oder die tastatur zu weit entfernt ? *kopfkratz*

Dein "Konzept" klingt realistisch , jedoch geht es dennoch darum eine "lasten" verteilung von den user ids zu erzeugen -> fällt ein id bereich weg ist nicht die ganze community ohne user nickpages =))

Denk mal daran =))