07.02.2012, 13:59
Während man bei einer loaklen Standalone noch mit einer guten alten Filedatenbank (Tatsächlich abgeleitet vom guten alten DBase) arbeiten kann, wird für "ernsthaftere" Installationen schon ein richtiger Datenbankserver benutzt. OpenSim ist hier für MySQL ausgelegt.
Die Geschichte von MySQL
Dieses Datenbanksystem hat eine interessante Karriere hinter sich, die so etwa vor 10 Jahren begann. Obwohl es von Anfang an ein OpenSource Produkt war, steckte ein Unternehmen, MySQL A.B., hinter der Entwicklung, die Hauptsächlich an Consulting zum Produkt verdienten. Wer bereits mit Datenbanksystemen arbeitete, konnte MySQL zu der Zeit noch nicht wirklich ernst nehmen, es war ein sehr rudimentäres System mit grossen Schwächen im bei komplexeren Abfragen, ohne grundlegende Funktionen wie gespeicherte Prozeduren oder Trigger.
Bei dem was es konnte, war es aber aus diesem Grund auch besonders schnell, und so setzte sich MySQL z.B. gegen das, ebenfalls als Opensource existierende, PostGreSQL durch, das wirklich ein sehr mächtiges, aber auch eher langsames und schwer zu bedienendes Datenbanksystem war.
Gerade Webentwickler liebten MySQL und es wurde mehr oder weniger die Standarddatenbank für alle Projekte auf Basis von PHP und die möglichkeit für Hoster, LAMP Server günstig aufzusetzen, da keine Lizenzkosten anfielen, hat die Kombination letztlich zum Standard für Webapplikationen gemacht.
In der Welt der kommerziellen Datenbankanbieter passierte in der Zwischenzeit so einiges. Oracle war lange Zeit der Marktführer, bis hin zu einem Punkt, wo sie "abhoben". Soll heissen, das Produkt wurde immer aufgeblähter, komplexer (es gibt alleine vier verschiedene Stellenbeschreibungen für die Menschen, die beruflich mit Oracle arbeiten) mit einer Abfragesprache, die sich wenig an die offiziellen Standards hielt und einer eigenen Programmiersprache. Vorteile gab es jedoch beim Thema Sicherheit und Skalierbarkeit, weshalb sie immer noch recht beliebt war in Bereichen wie Enterprise Resource Planning (komplexe Warenwirtschaftssysteme) wie zum Beispiel SAP (eine deutsche Firma aus Waldorff).
SAP mochte diese Abhängigkeit von einem Drittanbieter aber nicht so wirklich und man entwickelte ein eigenes Datenbanksystem, das sich an Oracle orientierte: SAPDB. Die meisten Kunden setzten aber weiterhin auf das, für sie bewährte, Oracle, und die Entwicklung einer Datenbanksoftware ist teuer, also kam die SAP AG auf die Idee, SAPDB als OpenSource freizugeben, um so den Pool freier Entwickler zu nutzen (es war ja eh nie ein Produkt, an dem sie direkt verdienten).
SAP versuchte allerdings, die Kontrolle in der Hand zu behalten und setzte das ganze auch nicht unter die GNU Lizenz.
Ähnlich wie bei Netscapes Mozilla ging die Rechnung nicht ganz auf, gerade auch deshalb, weil sich im OpenSource-Bereich MySQL so durchgesetzt hatte. Und jetzt passierte etwas interessantes, die SAP AG schenkte der MySQL A.B. die (mächtige) SAP DB komplett, und dieses Geschenk hat dafür gesorgt, das das MySQL Datenbanksystem tatsächlich mächtiger wurde, und sich zu einem wirklich ernstzunehmenden System entwickelte. Das ganze wurde dann noch dadurch getoppt, das Oracle selbst die geballte freie Konkurrenz, die sie auch nicht durch kostenlose Varianten ihres Produkts bekämpfen konnte, schlichtweg aufkauften. Gut für die Gründer von MySQL A.B. und gut für "professionelles" OpenSource, denn diese Erfolgsgeschichte zeigt, das man auch als Unternehmen grossen finanziellen Erfolg haben kann, wenn man OpenSource Software entwickelt.
Wo steht MySQL jetzt und was bedeutet das für OpenSim-Grid Betreiber?
Auch wenn OpenSim als solches nur wenige der mächtigeren Funktionen nutzt gibt es einen ganz wichtigen Aspekt, der dem Datenbankserver einiges Abverlangt: Skalierung.
Skalierung bedeutet, dass ein Datenbanksystem mit dem Wachstum einer Anwendung mithalten muss. Und wie schnell hier Grenzen erreicht werden, sehe ich schon an meinem, Zweiuser-Grid mit zwei Regionen, dass bei ca. 3000 Inventoryitems und ca 30000 prims schon etwa 1,5 GB auf der Festplatte verbucht.
Das Problem: Eigentlich kennt MySQL keine grossartigen, eingebauten Skalierungsoptionen. Um zu skalieren, muss es in der Lage sein, sich quasi über mehrere Rechner zu verteilen. So lange man mit einem Rechner arbeitet, sind diesem natürliche Grenzen gesetzt, man kann nur eine gewisse Anzahl an RAM und Festplatten verbauen.
Dennoch verwenden bekannte und datenlastige Webunternehmen wie Flickr, Youtube oder Facebook MySQL. Die Datenmengen würden jeden einzelnen Rechner sprengen. Wie machen die das?
Skalierungskonzepte für MySQL
Im kleineren Rahmen:
Solange die Datenbank noch auf einem Rechner Platz hat, sind folgende Dinge sehr vorteilhaft:
- Möglichst viel RAM
- viele einzelne, schnelle, Festplatten, auf die Tabellen als einzelne Dateien abgelegt werden. Auf keinen Fall mehrere Festplatten über ein RAID zu einer virtuellen verbinden!
Prozessorleistung kann man dabei eher vernachlässigen, alles, was mit Datendurchsatz zu tun hat dagegen, sollte so schnell wir möglich sein.
Bei OpenSim Grids lassen sich die Datenbanken für Robust.exe und OpenSim.exe trennen und auf zwei verschiedenen Rechnern betreiben.
und wenn das nicht mehr reicht?
Die grosse Skalierung:
1. Replication
Webanwendungen sind leselastig, Schreibzugriffe finden eher selten statt. Also lässt man mehrere Rechner laufen und verteilt die Abfragen gleichmässig auf die Rechner, ähnlich, wie es auch mit Webservern gemacht wird. Gibt es einen schreibenden Zugriff, muss dieser an alle Server weitergeleitet werden.
2. Sharding
Tabelleninhalte werden auf Kopien verteilt. Statt einen Server zu haben mit einer grossen Tabelle, hat man mehrere Server mit der Tabelle, aber jede hat nur einen Teil der Inhalte.
Der Nachteil bei beiden Varianten, die meist in Kombination eingesetzt werden, ist, dass MySQL das nicht von sich aus organisieren kann. Während allerdings Webseitenunternehmen, wie die Oben genannten, die vollständige Kontrolle über den Datenbankzugriff haben und den Datenbankzugriff in der entsprechenden Schicht organisieren können, haben OpenSim-Gridbetreiber diesen Luxus nicht.
Lösungskonzepte
Neugierig, wie ich bin, habe ich heute mal ein wenig Recherchiert, aber bislang nur einen Anbieter gefunden, der eine "Organisationssoftware" anbietet, bei der man so aufgeteilte Datenbanken praktisch benutzen kann, als wäre eine einzige Datenbankinstanz dahinter. Das Produkt heist: ScaleBase und ist recht teuer, es kostet eine jährliche Lizenzgebühr im vierstelligen Bereich. Dennoch ist es letztlich günstiger, als eigene Lösungen zu entwickeln. Facebook zum Beispiel jongliert mit mehr als 1800 MySQL Servern, da muss man sich nicht wundern, warum schon die Seite schon bei kleinen Änderungen so Fehleranfällig ist.
Fazit:
Wer anfängt ein Grid mit grossen Wachstumsaussichten aufzubauen, sollte beachten, dass hier eventuell ein grosser Kostenfaktor auf ihn zukommt, und es in der Preisgestaltung berücksichtigen. Wenn jemand andere, möglichst kostengünstigere Konzepte kennt, wäre ich sehr gespannt, hier davon zu lesen.
Und was mich auch sehr interessieren würde, wäre, welche Datenbank LindenLab für Second Life verwendet.
PS: Nach Dorenas Kritik den "Sim on a Stick" Teil korrigiert.
Die Geschichte von MySQL
Dieses Datenbanksystem hat eine interessante Karriere hinter sich, die so etwa vor 10 Jahren begann. Obwohl es von Anfang an ein OpenSource Produkt war, steckte ein Unternehmen, MySQL A.B., hinter der Entwicklung, die Hauptsächlich an Consulting zum Produkt verdienten. Wer bereits mit Datenbanksystemen arbeitete, konnte MySQL zu der Zeit noch nicht wirklich ernst nehmen, es war ein sehr rudimentäres System mit grossen Schwächen im bei komplexeren Abfragen, ohne grundlegende Funktionen wie gespeicherte Prozeduren oder Trigger.
Bei dem was es konnte, war es aber aus diesem Grund auch besonders schnell, und so setzte sich MySQL z.B. gegen das, ebenfalls als Opensource existierende, PostGreSQL durch, das wirklich ein sehr mächtiges, aber auch eher langsames und schwer zu bedienendes Datenbanksystem war.
Gerade Webentwickler liebten MySQL und es wurde mehr oder weniger die Standarddatenbank für alle Projekte auf Basis von PHP und die möglichkeit für Hoster, LAMP Server günstig aufzusetzen, da keine Lizenzkosten anfielen, hat die Kombination letztlich zum Standard für Webapplikationen gemacht.
In der Welt der kommerziellen Datenbankanbieter passierte in der Zwischenzeit so einiges. Oracle war lange Zeit der Marktführer, bis hin zu einem Punkt, wo sie "abhoben". Soll heissen, das Produkt wurde immer aufgeblähter, komplexer (es gibt alleine vier verschiedene Stellenbeschreibungen für die Menschen, die beruflich mit Oracle arbeiten) mit einer Abfragesprache, die sich wenig an die offiziellen Standards hielt und einer eigenen Programmiersprache. Vorteile gab es jedoch beim Thema Sicherheit und Skalierbarkeit, weshalb sie immer noch recht beliebt war in Bereichen wie Enterprise Resource Planning (komplexe Warenwirtschaftssysteme) wie zum Beispiel SAP (eine deutsche Firma aus Waldorff).
SAP mochte diese Abhängigkeit von einem Drittanbieter aber nicht so wirklich und man entwickelte ein eigenes Datenbanksystem, das sich an Oracle orientierte: SAPDB. Die meisten Kunden setzten aber weiterhin auf das, für sie bewährte, Oracle, und die Entwicklung einer Datenbanksoftware ist teuer, also kam die SAP AG auf die Idee, SAPDB als OpenSource freizugeben, um so den Pool freier Entwickler zu nutzen (es war ja eh nie ein Produkt, an dem sie direkt verdienten).
SAP versuchte allerdings, die Kontrolle in der Hand zu behalten und setzte das ganze auch nicht unter die GNU Lizenz.
Ähnlich wie bei Netscapes Mozilla ging die Rechnung nicht ganz auf, gerade auch deshalb, weil sich im OpenSource-Bereich MySQL so durchgesetzt hatte. Und jetzt passierte etwas interessantes, die SAP AG schenkte der MySQL A.B. die (mächtige) SAP DB komplett, und dieses Geschenk hat dafür gesorgt, das das MySQL Datenbanksystem tatsächlich mächtiger wurde, und sich zu einem wirklich ernstzunehmenden System entwickelte. Das ganze wurde dann noch dadurch getoppt, das Oracle selbst die geballte freie Konkurrenz, die sie auch nicht durch kostenlose Varianten ihres Produkts bekämpfen konnte, schlichtweg aufkauften. Gut für die Gründer von MySQL A.B. und gut für "professionelles" OpenSource, denn diese Erfolgsgeschichte zeigt, das man auch als Unternehmen grossen finanziellen Erfolg haben kann, wenn man OpenSource Software entwickelt.
Wo steht MySQL jetzt und was bedeutet das für OpenSim-Grid Betreiber?
Auch wenn OpenSim als solches nur wenige der mächtigeren Funktionen nutzt gibt es einen ganz wichtigen Aspekt, der dem Datenbankserver einiges Abverlangt: Skalierung.
Skalierung bedeutet, dass ein Datenbanksystem mit dem Wachstum einer Anwendung mithalten muss. Und wie schnell hier Grenzen erreicht werden, sehe ich schon an meinem, Zweiuser-Grid mit zwei Regionen, dass bei ca. 3000 Inventoryitems und ca 30000 prims schon etwa 1,5 GB auf der Festplatte verbucht.
Das Problem: Eigentlich kennt MySQL keine grossartigen, eingebauten Skalierungsoptionen. Um zu skalieren, muss es in der Lage sein, sich quasi über mehrere Rechner zu verteilen. So lange man mit einem Rechner arbeitet, sind diesem natürliche Grenzen gesetzt, man kann nur eine gewisse Anzahl an RAM und Festplatten verbauen.
Dennoch verwenden bekannte und datenlastige Webunternehmen wie Flickr, Youtube oder Facebook MySQL. Die Datenmengen würden jeden einzelnen Rechner sprengen. Wie machen die das?
Skalierungskonzepte für MySQL
Im kleineren Rahmen:
Solange die Datenbank noch auf einem Rechner Platz hat, sind folgende Dinge sehr vorteilhaft:
- Möglichst viel RAM
- viele einzelne, schnelle, Festplatten, auf die Tabellen als einzelne Dateien abgelegt werden. Auf keinen Fall mehrere Festplatten über ein RAID zu einer virtuellen verbinden!
Prozessorleistung kann man dabei eher vernachlässigen, alles, was mit Datendurchsatz zu tun hat dagegen, sollte so schnell wir möglich sein.
Bei OpenSim Grids lassen sich die Datenbanken für Robust.exe und OpenSim.exe trennen und auf zwei verschiedenen Rechnern betreiben.
und wenn das nicht mehr reicht?
Die grosse Skalierung:
1. Replication
Webanwendungen sind leselastig, Schreibzugriffe finden eher selten statt. Also lässt man mehrere Rechner laufen und verteilt die Abfragen gleichmässig auf die Rechner, ähnlich, wie es auch mit Webservern gemacht wird. Gibt es einen schreibenden Zugriff, muss dieser an alle Server weitergeleitet werden.
2. Sharding
Tabelleninhalte werden auf Kopien verteilt. Statt einen Server zu haben mit einer grossen Tabelle, hat man mehrere Server mit der Tabelle, aber jede hat nur einen Teil der Inhalte.
Der Nachteil bei beiden Varianten, die meist in Kombination eingesetzt werden, ist, dass MySQL das nicht von sich aus organisieren kann. Während allerdings Webseitenunternehmen, wie die Oben genannten, die vollständige Kontrolle über den Datenbankzugriff haben und den Datenbankzugriff in der entsprechenden Schicht organisieren können, haben OpenSim-Gridbetreiber diesen Luxus nicht.
Lösungskonzepte
Neugierig, wie ich bin, habe ich heute mal ein wenig Recherchiert, aber bislang nur einen Anbieter gefunden, der eine "Organisationssoftware" anbietet, bei der man so aufgeteilte Datenbanken praktisch benutzen kann, als wäre eine einzige Datenbankinstanz dahinter. Das Produkt heist: ScaleBase und ist recht teuer, es kostet eine jährliche Lizenzgebühr im vierstelligen Bereich. Dennoch ist es letztlich günstiger, als eigene Lösungen zu entwickeln. Facebook zum Beispiel jongliert mit mehr als 1800 MySQL Servern, da muss man sich nicht wundern, warum schon die Seite schon bei kleinen Änderungen so Fehleranfällig ist.
Fazit:
Wer anfängt ein Grid mit grossen Wachstumsaussichten aufzubauen, sollte beachten, dass hier eventuell ein grosser Kostenfaktor auf ihn zukommt, und es in der Preisgestaltung berücksichtigen. Wenn jemand andere, möglichst kostengünstigere Konzepte kennt, wäre ich sehr gespannt, hier davon zu lesen.
Und was mich auch sehr interessieren würde, wäre, welche Datenbank LindenLab für Second Life verwendet.
PS: Nach Dorenas Kritik den "Sim on a Stick" Teil korrigiert.