MaxNoOfAttributes

Ich hatte ja zuvor schonmal beschrieben, daß wir einige Probleme haben, uns für eine geeignete Methode zur Skalierung unserer Datenbanken zu entscheiden. Es gibt einige Sharding-Lösungen, wie zum Beispiel HiveDB, die auf Applikationsseite implementiert werden müssen und deshalb für uns viel zu teuer sind. Es gäbe natürlich auch die Möglichkeit vertikal zu skalieren, das heißt einfach immer mehr CPUs und Platten nachzustopfen, aber das ist ineffektiv, teuer, unperformant und bietet auch keine zusätzliche Ausfallsicherheit.
Meine derzeit preferierte Lösung ist das MySQL Cluster. Bisher war es ja wohl so, daß die geclusterten Datenbankdaten komplett im Speicher vorgehalten werden mußten, weshalb diese Methode für uns mit den riesigen Datenmengen nicht in Frage kam, dies hat sich mit der aktuellen Version des MySQL Clusters aber erledigt. Das einzige Problem ist, daß die MySQL Cluster Engine keine Fremdschlüssel unterstützt, allerdings läßt sich diese Funktionalität aber auf entsprechende Trigger auslagern. Vielleicht nicht ganz so schnell, aber funktioniert wohl. Leider scheitere ich derzeit kläglich an einem ganz anderen Problem.

Read More»

MySQL Proxy

Ich brauche eine Art Proxy zwischen JBoss Applikationserver und MySQL Datenbankservern. Dieser muß transparent sein, weil wir es uns nicht leisten können diese Funktionalitäten in den Applikations-Code zu integrieren, und mehrere Datenbanken auf verschiedenen Servern auf eine Instanz zusammenfassen können. Dabei sollten Connection Pooling, Caching, sicher aber Load Balancing und Failover unterstützt werden.
Eigentlich garnicht tragisch das Ganze, große Teile davon werden bereits von mysql-proxy geliefert, andere Dinge kann sqlrelay. Leider gibt es kein Produkt, weder Open noch Closed Source, auch nicht für alles Geld der Welt, daß das alles zusammen kann. Und diese Tatsache treibt mich gerade in den Wahnsinn, denn damit geht gefühlt ein ganzen Projekt den Bach runter.

Wir haben das Problem, daß die Datenmengen, für die unser Datenbank-Konzept erstellt wurde leider um den Faktor 3 übertroffen wird, wie es derzeit aussieht. Wir sind jetzt etwa einen Monat vor Release und das Problem scheint sich nicht von selbst zu lösen. Basis der Grundkonzepts ist, immer in die Breite zu Wachsen, was bedeutet, daß wir Datenbanken auf mehrere Server verteilen müssen. Die Alternative, mehr Storage, ist unperformant und zudem nicht bezahlbar. Die Tragik ist, daß das von unserer Load Balancing und Failover-Lösung mysql-proxy nicht unterstützt wird. Das Load Balance von mysql-proxy verteilt Per RW-Split Reads auf die Slaves, ohne zu wissen, was da für Datenbanken hinter hängen. Da wir keine uniformen Slaves beibehalten können, sondern (siehe Bild) die Datenbanken unterschiedlich verteilen müssen, sind wir gef***t.

MySQL Concept

MySQL Concept

Leider hilft uns da auch sqlrelay nicht weiter. Theoretisch deckt sqlrelay zwar die Funktionalität ab, leider funktioniert sqlrelay aber nicht als transparente Schicht, sondern muß in die Applikation integriert werden. Nicht zu akzeptieren.

Also was bleibt? Ich suche nach kommerziellen Load Balancern, die das alles abdecken, konnte bisher aber nichts finden. Sinnige Produkte sind in dem Sektor eh SEHR rar gesät. Ansonsten? RDBMS Wechsel? Ich weiß es nicht. Ich bin etwas verzweifelt.

© Copyright ollo.sh - Theme by Pexeto
Highslide for Wordpress Plugin