Montag, 23. Oktober 2017
Portfolio minimieren
Aug 24

Erstellt von: Thomas Huber
24.08.2010 15:53 

Letzte Woche konnte ich noch ein besonderes Schmankerl klar machen. Im Juni, an dem Tag, als die DFB-Elf gegen Serbien verlor war ich in London, um mich tiefer über MongoDB zu informieren. Bei Skillsmatter.com kann man sich die Vorträge nachträglich nochmal ansehen: skillsmatter.com/podcast/cloud-grid/mongodb-indexing-query-optimizer
Ca. ein Drittel der Vorträge wurde von Gast-Speakern gehalten. Als der Termin für die MongoBerlin bekannt gegeben wurde erkundigte ich mich, ob noch eine Session für mich als Gast-Speaker frei ist - naja was soll ich sagen - seht selbst:
www.10gen.com/conferences/mongoberlin2010
04. Oktober - Salon3 - 13:15Uhr bis 14:00Uhr - Scaling the server side of occasionally-connected, mobile systems with MongoDB - Thomas Huber - Fertl EDV Systeme

In früheren Veröffentlichungen, unter anderem auch von Microsoft, wurde daruf hingewiesen, dass Replication mit der Anzahl der zu replizierenden Slaves sehr aufwändig werden kann  scholar.google.de/scholar

Zwar setzen wir auf der Serverseite ein sehr potentes Datenbank-System ein, welches mit der Hardware ordentlich skaliert, dennoch sind auch hier Grenzen gesetzt. Je größer x86-NUMA-Server-Systeme werden desto teurer wird die Anschaffung derartiger Hardware. Ab 4-Sockel-Server und mehr wird diese Hardware exponentiell teurer. Die Scale-Up-Strategie rechnet sich nur bis zu einem gewissen Punkt. Nun kann man natürlich pragmatisch an die Sache gehen und auf Appliaktionsebene selbst "sharden", also die Datenmengen an bestimmten Punkten aufteilen und entweder auf den DB-Server1 oder DB-Server2 leiten - gäbe es da nicht mittlerweile sehr interessante Lösungen im Bereich NoSQL.

NoSQL - Not only SQL

In den letzten ein einhalb bis zwei Jahren entwickelte sich die Basis der heutigen öffentlich erhältlichen NoSQL-Engines. Einige Jahre früher entwickelte Google diese Software und integrierte sie in ihre Suchmaschine. Nicht zuletzt der Einsatz von Big Table in Googles Infrastruktur war mit ein wichtiger Grund wieso Google einen derartigen Siegeszug antreten konnte.

In der Open-Source-Szene streiten derzeit einige NoSQL-Projekte um die Gunst der Community. Die wohl bekanntesten sind CouchDB, CassandraDB, MongoDB, Riak, Tokyo Cabinet, Hadoop. Diese Liste kann sicher noch weiter aufgespannt werden, auch gibt es Oberkategorien, in die die jeweiligen Storage Engines eingeordnet werden können - wer mehr darüber wissen will - Googeln und gut.

Für unser Projekt wählten wir MongoDB, da es sich derzeit hervorragend entwickelt, es unsere Anforderungen an die Skalierbarkeit erfüllt und es am wenigsten mit den Vorstellungen eines "SQL-Denkers" kolidiert. Der Umstieg von einem RDBMS zu MongoDB lässt sich in überschaubarer Zeit bewerkstelligen, gleichzeitig bringt das System aber den Vorteil der Skalierbarkeit mit sich.

Unser Mobile-Assistance-Framework wurde zu einer Hybrid-Lösung umgebaut. Ein RDBMS und MongoDB teilen sich die Arbeit der Datenhaltung. Nur mäßig anwachsende Tabellen werden im RDBMS gehalten -  z.B. die Daten für User-Account/Passwort oder die Berechtigungen der einzelnen User für gewisse Module. Schnell wachsende Daten wie z.B. EKG-Kurven werden in MongoDB abgelegt.

Also dann vielleicht am 4. Oktober in Berlin ....

spacer