mehrere Datenbanken

[Frank Tuscherer]

Hi zusammen,

mir geht es mal um etwas prinzipielles. Und zwar um das Thema mehrere CMS in einer Datenbank. Es ist logisch das es klappt. Sobald man die Prefixe der Tabellen ändert kann ich in einer Datenbank mehrere CMS laufen lassen. Theoretisch auch keine dumme Idee, weil ich so eigentlich auch von CMS 1 auf CMS 2 zugreifen kann (das man dafür Programmierkenntnisse braucht - logisch).

Zuhause auf meinem eigenen PC habe ich nun 3 Wordpress in einer Datenbank installiert. Natürlich kann ich zuhause keinen Betrieb nachstellen, wie ihn ein Rechenzentrum hat, wo z.B. 50 Leute gleichzeitig auf meine Seite zugreifen (ok, vermutlich werden es in der Realität eher unter 5 sein).

Nehmen wir an, ich bin bei einem Wald- und Wiesenprovider. Da hat man ja mittlerweile auch keine Begrenzung wie früher der Datenbank mehr. Eine Datenbank kann da ja lockere hunderte von MB umfassen. Entsprechend kann man ja auch mehrere CMS in einer Datenbank laufen lassen.

Vom Prinzip her dürfte es ja auch zu keinem Performance Verlust führen oder? Wenn eine Seite z.B. gleichzeitig 100 Besucher drauf hat und da läuft eine Datenbank und ich habe 3 CMS in einer Datenbank und habe 3 x 5 Besucher, dürfte der Datenbankzugriff ja nicht langsamer sein, nur weil ich mehrere CMS in einer Datenbank nutze oder?

[Christian Kruse]

Moin Frank,

[… mehrere Anwendungen in einer Datenbank …]
Vom Prinzip her dürfte es ja auch zu keinem Performance Verlust führen oder?

Diese Frage laesst sich nicht so einfach beantworten: das ist stark abhaengig vom Datenbanksystem. Theoretisch ist es durchaus moeglich, dass die Anzahl der Tabellen ein Kriterium fuer die Performance ist. Es ist sogar wahrscheinlich, denn es muessen ja auch die Statistiken und Metadaten usw fuer die Tabellen gepflegt werden. In PostgreSQL ist es z.B. definitiv relevant.

Die Frage ist nur: ab wann ist das relevant? 100 Tabellen sind z.B. problemlos handlebar fuer PostgreSQL, 2000 dagegen kosten merklich Performance. Das musst du fuer dein DBMS messen.

LG,
 CK

[Frank Tuscherer]

Moin Frank,

[… mehrere Anwendungen in einer Datenbank …]
Vom Prinzip her dürfte es ja auch zu keinem Performance Verlust führen oder?

Diese Frage laesst sich nicht so einfach beantworten: das ist stark abhaengig vom Datenbanksystem.

Alle Provider (behaupte ich jetzt mal so) bieten ja mysql Datenbanken an. Aber wie jetzt die mysql Datenbank dort konfiguriert ist, weiß ich natürlich nicht als Endkunde. Nur verstehe ich eines nicht. Unbegrenzt Traffic haben heute alle. Massenhaft Speicher und bei den Datenbanken wird gegeizt. Dabei dürfte doch theoretisch dem Datenbanksystem nicht so schnell die Puste ausgehen. Naja ok vielleicht auch nur Marketing, so das man zum besseren Paket greift.

Klar, meine Frage war auch theoretisch. Zu erst einmal ist mir schon klar, das ich erst mal eine Seite haben müßte, die entsprechend Zugriffe generiert bevor man sich an Seite zwei macht. Aber es ging um das theoretische.

[Der Martin]

Hallo Frank,

Alle Provider (behaupte ich jetzt mal so) bieten ja mysql Datenbanken an.

nicht alle, und erst recht nicht in allen Hosting-Paketen. Es gibt bei sehr vielen Providern günstige Einsteiger-Tarife, die keine Datenbank enthalten; es gibt sogar immer noch Hosting-Angebote ohne Perl und PHP.

Und dann ist die Nutzung von Datenbanken oft nach Tarif gestaffelt. Beispielsweise bietet $provider das günstige Basis-Paket mit 1GB Speicherplatz, PHP5, bis zu 100 Mailadressen, aber ohne DB. Dann das Allround-Paket, da ist dann neben ein paar anderen Schmankerln mySQL mit _einer_ Datenbank inclusive, und erst im Premium-Paket darf man bis zu zehn mySQL-Datenbanken nutzen - und einen Haufen anderes Zeug, das man nicht gebraucht hätte.

Eine solche Tarifstruktur kann also noch ein Grund sein, alles in _eine_ DB zu stecken.

Aber wie jetzt die mysql Datenbank dort konfiguriert ist, weiß ich natürlich nicht als Endkunde. Nur verstehe ich eines nicht. Unbegrenzt Traffic haben heute alle.

Alle? Wohl eher nicht. Aber sehr viele.

Massenhaft Speicher und bei den Datenbanken wird gegeizt. Dabei dürfte doch theoretisch dem Datenbanksystem nicht so schnell die Puste ausgehen. Naja ok vielleicht auch nur Marketing, so das man zum besseren Paket greift.

Das ist die einzige Erklärung, die ich auch anzubieten hätte. Einen technischen Grund sehe ich jedenfalls nicht.

Ciao,
 Martin

[Kay]

Unbegrenzt Traffic haben heute alle.

Das ist ein Irrtum. Diese ganzen 0815 Angeboten sind sehr wohl limitiert.
Durch die Netzwerkkarte oder die UpLink-Verbindung. Diese Bandbreite teilen sich auch noch die anderen Kunden die auf den selben Abschnitt mitlaufen.

Diese Aussage mit dem "unbegrenzten Traffic" ist Werbemüll.

[Der Martin]

Hallo,

Unbegrenzt Traffic haben heute alle.
Das ist ein Irrtum. Diese ganzen 0815 Angeboten sind sehr wohl limitiert.
Durch die Netzwerkkarte oder die UpLink-Verbindung. Diese Bandbreite teilen sich auch noch die anderen Kunden die auf den selben Abschnitt mitlaufen.

beachte: Bandbreite != Traffic

Was du beschreibst, ist die Bandbreite der Netzanbindung, also die Geschwindigkeit. Die ist selbstverständlich von der Hardware des Servers, von der Anbindung im Rechenzentrum und von der Zahl der Hosting-Kunden abhängig, die sich eine Maschine bzw. ein Netzwerksegment teilen.

Unter Traffic versteht man aber die übertragene Datenmenge z.B. pro Monat.

Diese Aussage mit dem "unbegrenzten Traffic" ist Werbemüll.

Natürlich gibt es physikalische Grenzen; der theoretisch mögliche monatliche Traffic ist natürlich durch die Bandbreite limitiert. Aber selbst wenn die nutzbare Bandbreite der Anbindung nur 10Mbit/s wäre, ist das rund 1MB/s, also 86GB pro Tag, also rund 2.5TB pro Monat. Angebote mit limitiertem Traffic liegen aber meist bei 10..50GB/Monat. Da liegen also locker noch zwei Zehnerpotenzen dazwischen.

"Unbegrenzt Traffic" bedeutet, dass die Datenmenge nicht künstlich begrenzt wird bzw. dass nicht beim Erreichen oder Überschreiten einer Grenze zusätzliche Kosten entstehen. Werbemüll ist diese Aussage keineswegs.

Ciao,
 Martin

[TSO]

"Unbegrenzt Traffic" bedeutet, dass die Datenmenge nicht künstlich begrenzt wird bzw. dass nicht beim Erreichen oder Überschreiten einer Grenze zusätzliche Kosten entstehen. Werbemüll ist diese Aussage keineswegs.

Wobei ich sehr viele Provider gesehen habe, die mit einer „Fair-Use Flat“ werben.
Anders gesagt also: Grundsätzlich gibt es kein festes Limit, aber wenn es dem Provider irgendwann zu viel werden sollte, dann kann er einschreiten.
Problem ist natürlich, dass man bei sowas nicht wirklich weiß, wo nun eigentlich die Grenze liegt, ab der es dem Provider zu viel wird.

[1UnitedPower]

Meine Herren!

Und zwar um das Thema mehrere CMS in einer Datenbank. Es ist logisch das es klappt. Sobald man die Prefixe der Tabellen ändert kann ich in einer Datenbank mehrere CMS laufen lassen. Theoretisch auch keine dumme Idee, weil ich so eigentlich auch von CMS 1 auf CMS 2 zugreifen kann (das man dafür Programmierkenntnisse braucht - logisch).

An deiner Stelle würde ich das lassen und pro Installation eine eigene Datenbank erstellen. Das macht zum Beispiel die Arbeit mit Backups und der datenbankeigenen Rechtverwaltung einfacher.

Wenn du die CMS' untereinander kommunizieren lassen möchtest, wird die Programmierarbeit auch nicht wesentlich komplizierter, dadurch dass man zwei Datenbank-Verbindungen benötigt.

[Christian Kruse]

Moin 1UnitedPower,

Wenn du die CMS' untereinander kommunizieren lassen möchtest, wird die Programmierarbeit auch nicht wesentlich komplizierter, dadurch dass man zwei Datenbank-Verbindungen benötigt.

Doch, natürlich. Allein schon, dass JOINs wegfallen, macht es komplizierter.

LG,
 CK

[1UnitedPower]

Meine Herren!

Wenn du die CMS' untereinander kommunizieren lassen möchtest, wird die Programmierarbeit auch nicht wesentlich komplizierter, dadurch dass man zwei Datenbank-Verbindungen benötigt.

Doch, natürlich. Allein schon, dass JOINs wegfallen, macht es komplizierter.

Stimmt, an diesen Fall habe ich nicht gedacht. Eine einzige Verbindung hat doch ihre Vorteile, die Datenbanken ließen sich trotzdem separat halten: http://stackoverflow.com/questions/1565993/oracle-database-link-mysql-equivalent

[Sven Rautenberg]

Moin!

Nehmen wir an, ich bin bei einem Wald- und Wiesenprovider. Da hat man ja mittlerweile auch keine Begrenzung wie früher der Datenbank mehr. Eine Datenbank kann da ja lockere hunderte von MB umfassen. Entsprechend kann man ja auch mehrere CMS in einer Datenbank laufen lassen.

Vom Prinzip her dürfte es ja auch zu keinem Performance Verlust führen oder? Wenn eine Seite z.B. gleichzeitig 100 Besucher drauf hat und da läuft eine Datenbank und ich habe 3 CMS in einer Datenbank und habe 3 x 5 Besucher, dürfte der Datenbankzugriff ja nicht langsamer sein, nur weil ich mehrere CMS in einer Datenbank nutze oder?

Ich kann nur über MySQL reden.

Als allererstes aber: Zumindest mit MySQL gibt mindestens vier Ebenen der Aufteilung. Die höchste Ebene ist "der Datenbankserver". Auf dieser Ebene ist selbsterklärend, dass eine Trennung der Speicherorte für zwei Projekte auf zwei unterschiedliche Maschinen auf der einen Seite sofort doppelte Performance bringt (jedes Projekt hat einen Server exklusiv), auf der anderen Seite aber das projektübergreifende Zugreifen auf die Daten schwieriger macht (wie andernorts schon erwähnt: JOINs gehen nicht, zumindest nicht auf Serverseite).

Wenn allerdings nur ein Server im Spiel ist, ist in MySQL kein Unterschied mehr in den darunterliegenden Schichten: Das, was man als "Datenbank" bezeichnet, ist nur ein logisch abgegrenzter Bereich, eine Sammlung von Tabellen, genauso wie eine Tabelle nur eine Sammlung von Spalten ist.

Es macht auf Zugriffsebene keinen Unterschied, ob ich die Tabellen eines Projekts mit Tabellenprefix in derselben Datenbank ablege, oder in eine andere Datenbank. Sofern innerhalb von MySQL keine einschränkenden Zugriffsrechte eingetragen sind (dieser Teil der Datenbankfähigkeiten fällt immer unter den Tisch, weil alle Welt immer nur mit "dem einen DB-User" auf die DB zugreift - dabei kann man sehr feingranular einstellen, welcher User was genau darf), ist es egal, ob zwei Tabellen in derselben Datenbank liegen, oder nicht. JOINs zumindest gehen.

Jetzt bleibt nur noch die Frage der Performance. MySQL bietet genau zwei praxisrelevante Storage-Engines an: MyISAM und InnoDB. MyISAM möchte man eigentlich nicht mehr verwenden, weil bei Schreibzugriffen auf eine Tabelle die gesamte Tabelle für Lesezugriffe gesperrt wird (bei InnoDB wird nur der zu ändernde Datensatz gesperrt). Das sorgt bei hoher Auslastung und wechselseitigen Schreib- und Lesezugriffen für enorme Wartezeiten des einzelnen Zugriffs. Außerdem kann MyISAM keine Transaktionen. Wenn man sich die technische Realisierung des DB-Speicherns ansieht, wird man feststellen, dass MySQL in seinem Datenverzeichnis pro Datenbank einfach ein neues Verzeichnis anlegt und pro Tabelle darin einen Satz von drei Dateien.

Eine Mischung von Tabellen zweier Projekte in derselben Datenbank hat also zur Folge, dass mehr Dateien in einem Verzeichnis liegen. Umgekehrt würde der Zugriff auf Dateien in zwei Verzeichnissen erfolgen. Diese technische Realisierung sieht auf den ersten Blick nicht so aus, als ob sie irgendeinen Performanceeinfluss hat. (Außer natürlich, man legt die zwei Verzeichnisse durch Mounten auf zwei unabhängige Festplatten - das erhöht den I/O-Durchsatz pro Datenbank. Genausogut kann man aber auch RAID-0 einsetzen, das erhöht den Durchsatz auch dann, wenn nur eine Datenbank benutzt wird, auf's doppelte.)

Nutzt man InnoDB, landen alle Daten in wenigen, großen Dateien, die von der InnoDB-Storage-Engine verwaltet werden - egal in welcher Datenbank die Tabelle liegt. Auf technischem Level ist hier also kein Unterschied zu merken.

Bleiben als intransparenter Einflussfaktor nur noch die in dem DB-Server selbst anfallenden Verwaltungsaufgaben. Es könnte ja beispielsweise sein, dass das "Öffnen" einer Datenbank bzw. das fortwährende Wechseln zwischen zwei Datenbanken viel mehr Performance kostet, als wenn die Tabellen alle in einer Datenbank liegen. Dafür kenne ich aber keine Hinweise. "Die Datenbank" ist eher eine Verwaltungsstruktur für den User oder Admin, auf technischer Ebene sind alles nur Tabellen. Darauf deutet ja auch Christians Hinweis mit Postgres hin, dass die Anzahl der Tabellen ein relevanter Faktor sind, denn für jede Tabelle hat der DB-Server Verwaltungsinformationen bereitzuhalten, mindestens mal das Wissen, dass die Tabelle existiert.

Wie immer bei einer Performance-Frage am Ende der Hinweis: Ohne Messwerte für den konkreten Anwendungsfall sind alle Aussagen Makulatur.

Wenn du in der Situation steckst, dass du zwei Projekte hast, die einfach so laufen und schnell genug sind, und dich fragst, wie du die auf dem Datenbankserver organisieren sollst: Organisiere sie so, dass du das Leben einfach hast.

Wenn du hingegen mit den Projekten an einer Leistungsgrenze steckst und dich fragst, ob das Verschieben von zwei Datenbanken in eine (oder umgekehrt das Trennen in zwei) mehr Performance bringt: Nein, die Auswirkungen sind mit Sicherheit so marginal, dass sich der Aufwand nicht lohnt. Was sich an der Stelle viel mehr lohnt: Analysieren, wo das Problem steckt. Datenbankabfragen sind oftmals nur deswegen langsam, weil sie nicht optimal programmiert wurden, bzw. weil notwendige Indices nicht definiert wurden.

Wenn alle Abfragen und Indices optimal sind, und es trotzdem zu wenig Power gibt, ist die Lösung vermutlich eher ein Trennen auf zwei Datenbankserver (womit als Konsequenz auch die Trennung in zwei Datenbanken einhergeht).

Befürchtest du, dass eines deiner Projekte irgendwann auf diese Weise abgespalten werden muss, wäre es allein aus organisatorischen Gründen ratsam, schon heute alle Tabellen in einer eigenständigen Datenbank zu haben. Diese komplette Datenbank könnte man dann bei Bedarf auf einen anderen Server schieben und relativ problemlos sofort nutzen.

Haben zwei Projekte jedoch aus Versehen einzelne gemeinsam genutzte Tabellen entwickelt, wäre die Trennung schwieriger.

- Sven Rautenberg

[Auge]

Hallo

Wenn du hingegen mit den Projekten an einer Leistungsgrenze steckst und dich fragst, ob das Verschieben von zwei Datenbanken in eine (oder umgekehrt das Trennen in zwei) mehr Performance bringt: Nein, die Auswirkungen sind mit Sicherheit so marginal, dass sich der Aufwand nicht lohnt. Was sich an der Stelle viel mehr lohnt: Analysieren, wo das Problem steckt. Datenbankabfragen sind oftmals nur deswegen langsam, weil sie nicht optimal programmiert wurden, bzw. weil notwendige Indices nicht definiert wurden.

Wenn alle Abfragen und Indices optimal sind, und es trotzdem zu wenig Power gibt, ist die Lösung vermutlich eher ein Trennen auf zwei Datenbankserver (womit als Konsequenz auch die Trennung in zwei Datenbanken einhergeht).

… oder, falls man darauf Zugriff hat, die Nutzung von Replikation oder besser Clustern auf mehreren physikalischen Maschinen. Das ist dann aber der letzte Schritt nach dem Ausschöpfen aller Optimierungsmöglichkeiten.

Tschö, Auge

[Christian Kruse]

Moin Auge,

… oder, falls man darauf Zugriff hat, die Nutzung von Replikation oder besser Clustern auf mehreren physikalischen Maschinen. Das ist dann aber der letzte Schritt nach dem Ausschöpfen aller Optimierungsmöglichkeiten.

Wobei das wiederum einen ganzen Rattenschwanz anderer Probleme nach sich zieht, besonders bei Multi-Master-Replikation.

LG,
 CK

[Auge]

Hallo

… oder, falls man darauf Zugriff hat, die Nutzung von Replikation oder besser Clustern auf mehreren physikalischen Maschinen. Das ist dann aber der letzte Schritt nach dem Ausschöpfen aller Optimierungsmöglichkeiten.

Wobei das wiederum einen ganzen Rattenschwanz anderer Probleme nach sich zieht, besonders bei Multi-Master-Replikation.

Die Fallstricke kann ich, ehrlich gesagt, nicht beurteilen. In meiner Firma wird leise und nicht gerade intensiv über die Replikation eines MS-SQL-Servers nachgedacht. Bisher kenne ich das Konzept auch nur daher und auch nur theoretisch.

Da es das bei MySQL auch gibt, wollte ich auf die Existenz dieser Features hingewiesen haben. Für das hiesige Publikum wird der bewusste Zugriff darauf sowieso eher selten möglich sein. Selbst wenn der eine oder andere Hoster seine Datenbankserver repliziert, wird man als Kunde eher selten davon Kenntnis erlangen. Relevant ist das eher in einem eigenen Severpark bzw. Rechenzentrum.

Aber wie Sven schon sagte, erst mal das Optimierungspotential der eigenen Programmierung ausschöpfen. Darauf hat man schließlich ungehinderten Zugriff.

Tschö, Auge

[Christian Kruse]

Moin Auge,

sorry fürs Denglisch, ich bin heute völlig im Arsch und es fällt mir schwer, die deutschen Begriffe zu finden.

… oder, falls man darauf Zugriff hat, die Nutzung von Replikation oder besser Clustern auf mehreren physikalischen Maschinen. Das ist dann aber der letzte Schritt nach dem Ausschöpfen aller Optimierungsmöglichkeiten.

Wobei das wiederum einen ganzen Rattenschwanz anderer Probleme nach sich zieht, besonders bei Multi-Master-Replikation.

Die Fallstricke kann ich, ehrlich gesagt, nicht beurteilen. In meiner Firma wird leise und nicht gerade intensiv über die Replikation eines MS-SQL-Servers nachgedacht. Bisher kenne ich das Konzept auch nur daher und auch nur theoretisch.

Nun, die allgemeinen Fallstricke bei Replikation sind halt so Sachen wie replication lag (asynchron), lange response times (synchron), disappearing nodes, halt die üblichen Probleme, die bei Netzwerk-Kommunikation auftreten können. Bei Multi-Master kommen dann noch andere fiese Probleme dazu: conflicts (z.B. INSERTs auf dem gleichen pk, oder UPDATEs auf der gleichen row, DELETE vs UPDATE, etc, pp), diverging nodes, DDL conflicts, semantic conflicts, Probleme durch Trigger, etc, pp.

Und das sind alles Probleme, die das DBMS nicht für einen lösen kann, das muss der application developer tun.

Da es das bei MySQL auch gibt, wollte ich auf die Existenz dieser Features hingewiesen haben. Für das hiesige Publikum wird der bewusste Zugriff darauf sowieso eher selten möglich sein.

Das ist vermutlich richtig, ja.

LG,
 CK