MongoDB - Datenverteilung, aber wie?

Die NoSQL Datenbank MongoDB bietet eine gute Grundlage für flexible und skalierbare Applikationen. Besonders die Skalierung des Backends beim Wachstum der eigenen Applikation kann mit MongoDB sehr einfach sein, wenn man das richtige Verteilungskriterium definiert. Im Rahmen dieses Vortrages wird die grundlegende Funktionsweise der Verteilung skizziert und den Zuhörern mögliche Lösungsansätze für die Skalierung ihrer Datenmengen gezeigt.

Transcript

1. MongoDB Datenverteilung, aber wie? Stefan Rudnitzki
2. _talk:ich • Stefan Rudnitzki • Job: Softwareentwickler @hypoport • „Frei“zeit: Organisator @MUGBerlin • Java, Volltextsuche, verteilte Systeme, NoSQL, Vagrant, Puppet
3. _talk:ziel • Wie verteilt man Daten mit MongoDB? • Sharding!
4. _talk:ziel • „Weniger als 10 % der MongoDB User verwenden Sharding“ • Ziel: Angst nehmen
5. _talk:agenda • Sharding • Vor-/Nachteile • Anwendungsfall • Praxis https://www.iconfinder.com/icons/171757/calendar_icon
6. Sharding
7. _sharding:basics • Skalierbarkeit • Dokumente über mehre Knoten verteilen • Lese-/Schreibzugriffe optimieren
8. _sharding:terminologie
9. _sharding:terminologie • mongod (Daten) • shard (Teilmenge von Daten) shard01 mongod mongod mongod
10. _sharding:terminologie • mongod (Daten) • shard (Teilmenge von Daten) • replica set (Spiegelung) shard01 mongod mongod mongod
11. _sharding:terminologie • mongos (Sharding Proxy) • configserver (Metadaten) configservers config01 config02 config03 mongos
12. _sharding:terminologie
13. _sharding:terminologie • sharding-key: Verteilungskriterium • chunk: Zerlegung der Daten in Teile ?
14. _sharding:beispiel • Server: 1 TB, 64 GB RAM • Datenmenge: < 950 GB, gesch. Indexgröße < 56 GB https://www.iconfinder.com/icons/171754/data_icon
15. _sharding:beispiel • Datenwachstum 2,3 TB, gesch. Indexgröße 275 GB • Verteilungsansätze • 3 Shards (Datengröße) • 6 Shards (Indexgröße) https://www.iconfinder.com/icons/171754/data_icon
16. _sharding:funktionsweise Shard01 Shard02 Shard03 d .. u v .. z a .. c mongos ? ? ?
17. _sharding:funktionsweise Shard01 Shard02 Shard03 d .. u v .. z a .. c mongos d u n
18. _sharding:funktionsweise Shard01 Shard02 Shard03 d .. u v .. z a .. c Balancer
19. _sharding:funktionsweise Shard01 Shard02 Shard03 m .. r h .. l c .. g s .. t a .. b u .. z mongos d u n
20. Vor-/Nachteile https://www.iconfinder.com/icons/171728/settings_icon + - /
21. _sharding:vorteile • gegen „Last“ Skalieren • Verteilung von Lesezugriffen • Verteilung von Schreibzugriffen • selbstdefiniertes Verteilungskriterium +
22. _sharding:nachteile • einmalige Definition des sharding-keys • RAM-Grenzen • Monitoring ist wichtiger denn je • Sharding macht nicht alles schneller • Sharding macht nicht alles einfacher !
23. Anwendungsfall https://www.iconfinder.com/icons/171729/search_icon
24. _anwendungsfall:setup • Ausprobieren und selbst im kleinen Testen! • Testsetup mit Vagrant/Puppet (3 mongod, mongos, configserver) • online (mit Dokumentation): https:/ /github.com/strud/vagrant- machines
25. _anwendungsfall:vagrant
26. _anwendungsfall:puppet
27. _anwendungsfall:daten • Wikipedia Dump • „Real World“ Daten • ~ 4,4 Mio. Abstracts (3,8 GB XML)
28. _anwendungsfall:daten • URL • Titel (Text) • Abstract (Volltext) https://www.iconfinder.com/icons/171735/note_icon
29. _anwendungsfall:daten • Java Parser und Import • online: https:/ /github.com/strud/db_evaluation
30. _anwendungsfall:kandidaten • Titel • Text • unklare Verteilung
31. _anwendungsfall:kandidaten • künstlich, z.B. count(docs) % Anzahl Shards + Random ID • ideale Verteilung beim Einfügen • Weitere Shards? • alternativ: _id
32. _anwendungsfall:kandidaten • URL • strukturiert • geeignet für Baumdatenstrukturen
33. _anwendungsfall:kandidaten • ab 2.4: Hashed Index • zufällig • von MongoDB selbst erzeugt
34. Praxis https://www.iconfinder.com/icons/171728/settings_icon
35. _sharding:_id • Balancer sehr aktiv • sehr unbalanciert 0 750000 1500000 2250000 3000000 shard00 shard01 shard02
36. _sharding:titel • Balancer anfangs aktiv (Einschwingen) • unbalanciert • Titel-Queries performant 0 500000 1000000 1500000 2000000 shard00 shard01 shard02
37. _sharding:url • Balancer anfangs aktiv (Einschwingen) • unbalanciert • URL Queries performant 0 500000 1000000 1500000 2000000 shard00 shard01 shard02
38. _sharding:hash(titel) • kaum Balanceraktivität • (fast) ausbalanciert • max. Insertperformance • aber: nicht alle Queries möglich 0 500000 1000000 1500000 2000000 shard00 shard01 shard02
39. _sharding:hash(titel) • 1.457.725 • 1.462.456 • 1.465.252 • gleichmäßig!
40. ?
41. _talk:fazit • Sharding kann die Datenmenge eines Systems erhöhen • Sharding könnte die Performance verbessern
42. _talk:fazit • hashed sharding-keys = gute Lösung für balancing, nicht alle Abfragen werden unterstützt • selbstdefiniert = beste Performance • schlechter sharding-key = Problem
43. _talk:fazit • „Kenne die Daten des Systems“ • „Teste mit realen Daten des Systems“ • „Kenne die realen UseCases!“ • „Beratersprech“? • Mut zum Ausprobieren!
44. Fragen? • https:/ /github.com/strud/vagrant-machines • https:/ /github.com/strud/db_evaluation • http:/ /www.meetup.com/MUGBerlin • Twitter: @StRud2nd
45. http:/ /www.wordle.net