Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fachmodell-First: Einstieg in das NoSQL-Schema-Design

1,083 views

Published on

Die letzten zehn Jahre haben uns gezeigt, dass der Datenbank zu hohe Priorität zugesprochen wurde. Die meisten Diskussionen drehten sich um das Datenmodell, statt um Geschäftsprozesse und Vorgänge. Kein Wunder, denn klassische SQL-Datenbanken erzwingen diese Vorgehensweise von uns. In dieser Session zeigt der MongoDB-Experte Gregor Biswanger eine zeitgemäße Alternative mit NoSQL und wie durch ein Umdenken auch ein Booster in unsere Architektur einfließt bezüglich Produktivität, Flexibilität und Performance.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Fachmodell-First: Einstieg in das NoSQL-Schema-Design

  1. 1. Fachmodell-First Einstieg in das NoSQL-Schema-Design Gregor Biswanger | Freier Berater, Trainer, Autor und Sprecher about.me/gregor.biswanger
  2. 2. Über mich ▪ Freier Berater, Trainer und Autor ▪ Schwerpunkte: Softwarearchitektur, Web und Cross-Plattform Entwicklung mit JavaScript ▪ Technologieberater für die Intel Developer Zone ▪ Internationaler Sprecher auf Konferenzen und User Groups ▪ Freier Autor für heise.de, dotnetpro, WindowsDeveloper und viele weitere Fachmagazine ▪ Video-Trainer bei video2brain und Microsoft Gregor Biswanger Microsoft MVP, Intel Black Belt & Intel Software Innovator cross-platform-blog.de about.me/gregor.biswanger
  3. 3. Mein Versprechen…
  4. 4. Durch NoSQL erhalten wir ein Booster in unsere Architektur bezüglich Produktivität, Flexibilität und Performance.
  5. 5. Unser Reiseplan ▪ Was ist schlecht an relationalen Datenbanken ▪ Einführung in NoSQL ▪ Dokumentenorientierte Datenbank ▪ Dokumentenorientiert modellieren ▪ Gemeinsam ein Beispiel modellieren ▪ Domain-Driven Design und das Fachmodell ▪ Fazit
  6. 6. Relationale Datenbanken machen mich Aggro!
  7. 7. Relationale Datenbanken sind nicht für Entwickler gemacht
  8. 8. Sie geben sich als König in der Architektur aus
  9. 9. Der Datenbank wird zu hohe Priorität zugesprochen und die meisten Diskussionen drehen sich um die Datenbank und das Datenmodell statt um Geschäftsprozesse und - vorgänge.
  10. 10. Weil Sie es uns durch Ihre Regeln aufzwingen.
  11. 11. Das Datenbank-Schema wird zur…
  12. 12. Londoner U-Bahn Karte
  13. 13. Entwickler Relationale Datenbank O/R-Mapper
  14. 14. Das macht die Entwickler traurig
  15. 15. Retrain your relational brain…
  16. 16. NoSQL = Not Only SQL
  17. 17. NoSQL Datenbanken verfolgen einen nicht-relationalen Ansatz.
  18. 18. Sie brechen damit die lange Geschichte relationaler Datenbanken.
  19. 19. Diese benötigen keine festgelegten Tabellenschemata und versuchen Joins zu vermeiden.
  20. 20. NoSQL-Datenbanken können horizontal skalieren.
  21. 21. Die Ziele der NoSQL-Bewegung
  22. 22. Verwaltung von unstrukturierten Daten
  23. 23. Stark vernetzten Daten
  24. 24. Schnellen Strukturänderungen
  25. 25. Großen Datenmengen
  26. 26. Unterscheidung nach Datenmodell und Leistung Datenmodell Leistung Skalierbarkeit Flexibilität Komplexität Funktionalität Key–Value Hoch Hoch Hoch Keine Unterschiedlich (keine) Spaltenorientiert Hoch Hoch Mittel Gering Minimal Dokumentenorientiert Hoch Unterschiedlich (Hoch) Hoch Gering Unterschiedlich (gering) Graphbasiert Unterschiedlich Unterschiedlich Hoch Hoch Graphentheorie Relational Unterschiedlich Unterschiedlich Gering Mittel Relationale Algebra Quelle: https://de.wikipedia.org/wiki/NoSQL Datenmodell Leistung Skalierbarkeit Flexibilität Komplexität Funktionalität Key–Value Hoch Hoch Hoch Keine Unterschiedlich (keine) Spaltenorientiert Hoch Hoch Mittel Gering Minimal Dokumentenorientiert Hoch Unterschiedlich (Hoch) Hoch Gering Unterschiedlich (gering) Graphbasiert Unterschiedlich Unterschiedlich Hoch Hoch Graphentheorie Relational Unterschiedlich Unterschiedlich Gering Mittel Relationale Algebra
  27. 27. Dokumentenorientierte Datenbank
  28. 28. Eine relationale Datenbank besteht aus Datenbanktabellen, die einem festen Datenbankschema unterliegen.
  29. 29. Modeling data, the relational way
  30. 30. Eine dokumentenorientierte Datenbank besteht aus einzelnen Dokumenten mit einem eindeutigen Identifikator.
  31. 31. Modeling data, the document way { "id": "0ec1ab0c-de08-4e42-...", "addresses": [ { "street": "sesamstraße", "city": "gotham city" } ], "contractdetails": [ { "type": "home": "detail": "555-1212" }, { "type": "email": "detail": "no@no.com" } ], ... }
  32. 32. SQL NoSQL Data normalization Come as you are
  33. 33. Relationale Daten sind wie das recherchieren von Informationen
  34. 34. Dokumentenorientiere Daten bieten alle benötigten Informationen
  35. 35. Dokumentenorientiert modellieren
  36. 36. Dokumentenorientierte Datenbanken meinen NICHT, das es keine relationale Daten geben darf.
  37. 37. „Design with No-Reference first“
  38. 38. Oder auch…
  39. 39. „Design with embedded first“
  40. 40. Im Allgemeinen bietet die Einbettung von Daten eine bessere Leistung für Leseoperationen.
  41. 41. Eingebettete Datenmodelle ermöglichen die Aktualisierung der zugehörigen Daten in einem atomaren Schreibvorgang.
  42. 42. Integriert oder Referenziert?
  43. 43. Eingebettete Datenmodelle verwenden, wenn: ▪ Bei One-to-One-Beziehungen zwischen Entitäten. ▪ Bei One-to-Many-Beziehungen zwischen Entitäten. ▪ In diesen Beziehungen werden die "vielen" oder untergeordneten Dokumente immer zusammen mit dem "ein" oder den übergeordneten Dokumenten angezeigt.
  44. 44. Referenzierte Datenmodelle verwenden, wenn: ▪ Ein Einbetten würde zu einer Duplizierung von Daten führen, würde jedoch keine ausreichenden Leseleistungsvorteile bieten, um die Auswirkungen der Duplizierung zu überwiegen. ▪ Komplexere Many-to-Many-Beziehungen. ▪ Große hierarchische Datensätze.
  45. 45. Mein NoSQL Dokumenten- Schema Kompass für Dich!
  46. 46. Dokumenten-Schema Kompass Immer Manchmal Selten Integriert x x x Referenziert x x Wie oft werden die Daten zusammen benutzt?
  47. 47. Dokumenten-Schema Kompass Weniger als 100 Mehr als 100 Tausend Integriert x x Referenziert x x Wie groß ist der Datensatz?
  48. 48. Dokumenten-Schema Kompass Nie / Selten Gelegentlich Konstant Integriert x x Referenziert x x Wie oft ändern sich die Daten?
  49. 49. Das Beispiel: Rezeptdatenbank
  50. 50. Aktueller Stand
  51. 51. Optimierter Stand Datenbankspezifisch Datenbankspezifisch Datenbankspezifisch Zusammenfügen in Datentyp: Zutat Datentyp: Quelle Datentyp: Tag Datentyp: Rezept (Root-Document)
  52. 52. Weniger als 100 Mehr als 100 Tausend X Wie groß ist der Datensatz? Immer Manchmal Selten Wie oft werden die Daten zusammen benutzt? Nie / Selten Gelegentlich Konstant X Wie oft ändern sich die Daten? Analyse vom Datentyp: Rezept
  53. 53. Vergleich mit dem Dokumenten-Schema Kompass Immer Manchmal Selten Integriert x x x Referenziert x x Wie oft werden die Daten zusammen benutzt? Weniger als 100 Mehr als 100 Tausend Integriert x x Referenziert x x Wie groß ist der Datensatz? Nie / Selten Gelegentlich Konstant Integriert x x Referenziert x x Wie oft ändern sich die Daten?
  54. 54. interface Rezept { titel: string; beschreibung: string; seitenzahl?: number; anzahlPersonen?: number; } Zu Dokument
  55. 55. Weniger als 100 Mehr als 100 Tausend X Wie groß ist der Datensatz? Immer Manchmal Selten X Wie oft werden die Daten zusammen benutzt? Nie / Selten Gelegentlich Konstant X Wie oft ändern sich die Daten? Analyse vom Datentyp: Tag
  56. 56. Vergleich mit dem Dokumenten-Schema Kompass Immer Manchmal Selten Integriert x x x Referenziert x x Wie oft werden die Daten zusammen benutzt? Weniger als 100 Mehr als 100 Tausend Integriert x x Referenziert x x Wie groß ist der Datensatz? Nie / Selten Gelegentlich Konstant Integriert x x Referenziert x x Wie oft ändern sich die Daten?
  57. 57. interface Rezept { titel: string; beschreibung: string; seitenzahl?: number; anzahlPersonen?: number; tags?: Tag[]; } interface Tag { titel: string; } Zu Dokument
  58. 58. Weniger als 100 Mehr als 100 Tausend X Wie groß ist der Datensatz? Immer Manchmal Selten X Wie oft werden die Daten zusammen benutzt? Nie / Selten Gelegentlich Konstant X Wie oft ändern sich die Daten? Analyse vom Datentyp: Zutat
  59. 59. Vergleich mit dem Dokumenten-Schema Kompass Immer Manchmal Selten Integriert x x x Referenziert x x Wie oft werden die Daten zusammen benutzt? Weniger als 100 Mehr als 100 Tausend Integriert x x Referenziert x x Wie groß ist der Datensatz? Nie / Selten Gelegentlich Konstant Integriert x x Referenziert x x Wie oft ändern sich die Daten?
  60. 60. interface Rezept { titel: string; beschreibung: string; seitenzahl?: number; anzahlPersonen?: number; tags?: Tag[]; zutaten?: Zutat[]; } interface Tag { titel: string; } interface Zutat { stueck: number; lebensmittel: string; einheit?: string; } Zu Dokument
  61. 61. Weniger als 100 Mehr als 100 Tausend X Wie groß ist der Datensatz? Immer Manchmal Selten X Wie oft werden die Daten zusammen benutzt? Nie / Selten Gelegentlich Konstant X Wie oft ändern sich die Daten? Analyse vom Datentyp: Quelle
  62. 62. Vergleich mit dem Dokumenten-Schema Kompass Immer Manchmal Selten Integriert x x x Referenziert x x Wie oft werden die Daten zusammen benutzt? Weniger als 100 Mehr als 100 Tausend Integriert x x Referenziert x x Wie groß ist der Datensatz? Nie / Selten Gelegentlich Konstant Integriert x x Referenziert x x Wie oft ändern sich die Daten?
  63. 63. interface Rezept { titel: string; beschreibung: string; seitenzahl?: number; anzahlPersonen?: number; quelle: Quelle; tags?: Tag[]; zutaten?: Zutat[]; } interface Quelle { titel: string; standort?: string; kurzbezeichnung?: string; herkunft?: string; anzahlRezepteGeschaetzt?: number; } interface Tag { titel: string; } interface Zutat { stueck: number; lebensmittel: string; einheit?: string; } Zu Dokument
  64. 64. Rezept ----------------------------------- Titel Beschreibung … Quelle … Tags Zutaten Tag … Zutat …
  65. 65. Unterschiedliche Beziehungen behandeln in dokumentenorientierten Datenbanken
  66. 66. Abfrage von Array-Werten ohne Duplikationen > db.foo.save({ tags: ['Eierspeisen', 'Backstube'] }) > db.foo.save({ tags: ['Eierspeisen', 'Eingelegtes', 'Beilagen'] } ) > db.foo.save({ tags: ['Buttermischungen', 'Beilagen'] } ) > db.foo.distinct("tags") [ "Backstube", "Eierspeisen", "Beilagen", "Eingelegtes", "Buttermischungen" ] >
  67. 67. Anfragen für Array Felder > db.foo.save({ _id: 1, "things" : [ 1, 2, 3 ] }); > db.foo.save({ _id: 2, "things" : [ 2, 3 ] }); > db.foo.save({ _id: 3, "things" : [ 3 ] }); > db.foo.save({ _id: 4, "things" : [ 1, 3 ] }); > db.foo.find({ things: 1 }) { "_id" : 1, "things" : [ 1, 2, 3 ] } { "_id" : 4, "things" : [ 1, 3 ] } > Wichtig! Mongo ist Case-Sensitive.
  68. 68. Dot Notation > db.foo.save({ _id: 1, "info" : { "canFly": false } }); > db.foo.save({ _id: 2, "info" : { "canFly": false } }); > db.foo.save({ _id: 3, "info" : { "canFly": true } }); > db.foo.save({ _id: 4, "info" : { "canFly": false } }); > db.foo.find({ "info.canFly": true }) { "_id": 3, "info": { "canFly": true }} > ▪ Ein Query kann ebenfalls Hierarchische Bedingungen beinhalten. ▪ Diese werden als String-Wert angeben. ▪ Wichtig! Mongo ist Case-Sensitive.
  69. 69. And-Kombination ebenfalls möglich > db.foo.save({ _id: 1, "info": { "canFly": false } }); > db.foo.save({ _id: 2, "info": { "canFly": false } }); > db.foo.save({ _id: 3, "name": "Sample", "info": { "canFly": true } }); > db.foo.save({ _id: 4, "info" : { "canFly": false } }); > db.foo.find({ "name": "Sample", "info.canFly": true }) { "_id": 3, "name": "Sample", "info": { "canFly": true }} > Das Komma steht hierbei als And-Operator.
  70. 70. Referenzierte Dokumente abfragen mit dem integrierten Aggregation-Framework und der $lookup-Funktion Dokumentation und Beispiel unter: https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/
  71. 71. Domain-Driven Design und das Fachmodell
  72. 72. Was ist DDD?
  73. 73. Domain-Driven Design (DDD) ist eine Herangehensweise an die Modellierung komplexer, objektorientierter Software. Quelle: wikipedia.de
  74. 74. Die Modellierung der Software wird dabei maßgeblich von den umzusetzenden Fachlichkeiten der Anwendungsdomäne beeinflusst. Quelle: wikipedia.de
  75. 75. Domain = Fachlichkeit
  76. 76. Der Kunde Der Entwickler Business-Experte Business-Experte Fachlichkeit == Code und Struktur Eine „Common Language“ aufbauen!
  77. 77. Quelle:http://bonkersworld.net/object-world
  78. 78. Entwickler geben sich nicht genug Mühe, die Objekte und Operationen so zu benennen, dass die Namen zu den fachlichen Aufgaben passen.
  79. 79. Das führt zu einer großen Lücke zwischen dem mentalen Modell, das die Anwender haben, und der Software, die die Entwickler den Anwendern liefern.
  80. 80. Was macht der folgende Code?
  81. 81. Fachmodell / Domain Model ▪ Um also ein einheitliches Verständnis zwischen diesen Gruppen (Domänenexperte und Entwickler) zu schaffen, wird ein Modell der Domäne etabliert ▪ Ein Model ist eine auf bestimmte Zwecke ausgerichtete vereinfachende Beschreibung der Wirklichkeit
  82. 82. Anemic domain model ▪ Unter DDD ein Anti-Pattern ▪ Trennt Datenstruktur und Funktionen ▪ Kein „richtiges“ objektorientiertes programmieren ▪ Braucht eigene Business-Logic-Schicht ▪ Macht ein Domain Model schwerer zu verstehen
  83. 83. Die Onion Architecture Domain Model (Core) User Interface (ASP.NET MVC, WPF etc.) Tests (BDD) Services Infrastructure Application Services Domain Services
  84. 84. Habt mehr Fokus auf das Fachmodell
  85. 85. Fazit
  86. 86. NoSQL is NOT a Silver Bullet!
  87. 87. Use the right tool for the right job!
  88. 88. Polyglot persistence gehört der Zukunft!
  89. 89. „NoSQL gibt uns mehr Freiheiten, dafür tragen wir mehr Verantwortung“
  90. 90. http://about.me/Gregor.Biswanger I´m looking forward to get your feedback Thank you!

×