MongoDB - Datenverteilung, aber wie?

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.

A64aa22451bb30e6fe3cfd5de6f462b3?s=128

Stefan Rudnitzki

November 08, 2013
Tweet

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