Frage zu Datenbankaufbau.

[onemorenerd]

Heute nacht hat man aber was Besseres vor.

Wer in Größenordnungen wie Amazon oder ebay denkt, hat einen ganzen IT-Stab um sich herum und wird mit Sicherheit nicht in einem PHP-Forum solche Fragen stellen. Also bleiben wir mal in einem realistischen Rahmen:

a) Anfangs ist es eine zentrale, monolithische Applikation.
Updates können in einer parallelen DB eingespielt werden. Das kann ruhig sehr lange dauern. Die Applikation läuft unvermindert weiter mit der originalen DB.
Wenn das Update durch ist, werden die (zentral abgelegten) DB-Zugangsdaten geändert. Die Applikation war keine Sekunde offline.
Bei Code-Updates funktioniert es ähnlich. Parallele Installation und Änderung der Webserverkonfig.

b) Später kommt vielleicht Replikation und Balancing dazu.
Bei gewissen Änderungen an DB und/oder Applikation kann man wie bei a) verfahren. Die wenigen Updates, die sich nicht parallel einspielen lassen, werden Host für Host aufgezogen. Ist die Hälfte des Clusters mit Updates versorgt, wird umgeschaltet. Dann werden die restlichen Hosts aktualisiert und nach und nach wieder zugeschaltet. Die Applikation war zwischendurch also immer langsamer geworden und dann wieder schneller, war aber nie wirklich offline. (Wer den Leistungseinbruch vermeiden muß, vergrößert seinen Cluster vorrübergehend um 50%.)

c) Amazon, ebay, ... Träumerei!

[unset]

Original geschrieben von onemorenerd
Heute nacht hat man aber was Besseres vor.

Wer in Größenordnungen wie Amazon oder ebay denkt, hat einen ganzen IT-Stab um sich herum und wird mit Sicherheit nicht in einem PHP-Forum solche Fragen stellen. Also bleiben wir mal in einem realistischen Rahmen:

Zwischen einer kleinen Seite und Amazon/eBay existieren noch weitere Facetten. Ich arbeite in einem Unternehmen, dessen Datenaufkommen bei weitem das sprengt, was hier stets erwähnt wird (oder schon als "nicht mehr mit MySQL machbar" gehandlet wird).

Original geschrieben von onemorenerd
a) Anfangs ist es eine zentrale, monolithische Applikation.
Updates können in einer parallelen DB eingespielt werden. Das kann ruhig sehr lange dauern. Die Applikation läuft unvermindert weiter mit der originalen DB.
Wenn das Update durch ist, werden die (zentral abgelegten) DB-Zugangsdaten geändert. Die Applikation war keine Sekunde offline.
Bei Code-Updates funktioniert es ähnlich. Parallele Installation und Änderung der Webserverkonfig.

Unmöglich. Ich schreibe Software, die von mehreren Tausend Clients gleichzeitig genutzt wird, die Dateninkonsistenz selbst von wenigen Sekunden kann sich das Unternehmen nicht leisten. Vor allem wenn es Rechnungsrelevante Daten sind. Die Replikation der Datendifferenz ist auch nicht möglich, da somit wieder der Teilbereich des Systems ausgesperrt wird. Hier kommt man um kurzzeitiges dektivieren diverser Funktionalitäten nicht herum.

Edit: Übrigens würde es hier zu ID-Konflikten kommen. Viel mir eben auch noch ein.

Das ist im übrigen auch gängige Praxis. Unsere Kunden haben damit kein Problem - immerhin teilen wir ihnen solche Updates ja auch immer und mit genügend Vorlauf mit.

[goth]

Ich sag's ja ... es sind die sich zu wichtig nehmenden Trolle die 100% Verfügbarkeit verlangen ... jemand wirklich wichtig ist hat mehr Ahnung von der Materie ...

Im übrigen ... für Amazon und eBay hab' ich auch noch nicht gearbeitete ... aber für diverse DAX30er schon ... und selbst dort bleibt man realistisch. Und ... ja du hast Recht ... ich stelle hier auch keine Fragen ...

[onemorenerd]

Original geschrieben von unset
Ich arbeite in einem Unternehmen, dessen Datenaufkommen bei weitem das sprengt, was hier stets erwähnt wird

Interessant. Aber hier gehts um was anderes.

Ich schreibe Software, die von mehreren Tausend Clients gleichzeitig genutzt wird, die Dateninkonsistenz selbst von wenigen Sekunden kann sich das Unternehmen nicht leisten.

Wir wissen nicht genau, was der TO vor hat. Aber wie bereits erwähnt, läßt der gewählte Ort für seine Frage, dieses Forum, darauf schließen, dass sein Projekt in einer ganz anderen Liga spielt.
Wahrscheinlich eher in der Liga, in der auch ghostgambler denkt.

Ghostgambler meint, dass man beim DB-Design die seltenen DDL-Aktionen berücksichtigen sollte. Ich nicht; ACK@goth.
Ghostgambler argumentiert, dass man es muß, weil man sonst das SLA nicht halten kann. Unset erklärt wie man XXL-Projekte updated. Ich reiche das selbe für L und XL nach. Damit wollte ich das DDL-Argument entkräftigen, ohne auf unrealistische SLAs eingehen zu müssen.

Gibt es noch weitere Argumente für oder gegen Table Splitting?

[unset]

Original geschrieben von onemorenerd
Interessant. Aber hier gehts um was anderes.

Klar, ich wollte nur unterstreichen das hier gerne mal Käse erzählt wird.