Continuous Database Design

Größe: px

Ab Seite anzeigen:

Download "Continuous Database Design"

Maike Roth
vor 6 Jahren
Abrufe

1 Continuous Database Design Entwicklertag Karlsruhe Mai 2017 Version: 2.0 Orientation in Objects GmbH Weinheimer Str Mannheim

2 Ihr Sprecher Thorsten Maier Trainer, Berater, Entwickler Orientation in Objects GmbH Continuous Database Design 2

3 Die Welt der Entwickler 3

4 Die Welt des Betriebs 4

5 Die Welt der Entwickler Die Welt des Betriebs 5

6 Continuous Delivery 6

7 Wann Continuous Delivery? Schnelle Reaktion auf Anforderungsänderungen 7

8 Was brauchen wir dazu? Automatisierung Modularisierung 8

9 3 Bausteine 9

10 Anwendung mit 3 Bausteinen Orientation in Objects GmbH Continuous Database Design 10

11 Anwendung mit 3 Bausteinen Deployment auf einem Server 11

12 Anwendung mit 3 Bausteinen Baustein wird 4 mal benötigt 12

13 Anwendung mit 3 Bausteinen Nachteile Änderung an wird nur 2 mal benötigt erfordert Reploy von Baustein wird 4 mal benötigt 13

14 Anwendung mit 3 Bausteinen Unabhängige Artefakte Baustein wird 4 mal benötigt 14

15 Anwendung mit 3 Bausteinen Unabhängige Artefakte Baustein wird 4 mal benötigt Flexible Skalierung auf 3 Server 15

16 Vorteile Unabhängige Artefakte Isolierte Entwicklung Schnellere Reaktionszeiten Austauschen im laufenden Betrieb Continuous Delivery wird möglich Flexible Skalierung auf 3 Server 16

17 Was brauchen wir noch? Umdenken was ein Feature ist 30 Feature pro Tag? 17

18 Deploy Feature Launch 18

19 Wir brauchen noch mehr Zustandslose Anwendung 19

@EnableRedisHttpSession public class SpringSessionConfig { @Bean public

20 @EnableRedisHttpSession public class SpringSessionConfig public JedisConnectionFactory connectionfactory() { return new JedisConnectionFactory(); } } API GATEWAY Redis 20

21 Wie viele Datenbanken haben wir eigentlich? Eine? Mehrere? 21

22 API GATEWAY DB 22

23 DB API GATEWAY Bounded Context DB 23

24 Schemaänderungen Wie ändern wir das Schema? 24

25 25

26 26

27 27

28 Vor dem Update von Version auf 1.1 musst du erst noch die neuen SQL-Skript einspielen. 28

schema.sql 1.0 10_to_11.sql 1.1 10_to_101.

29 schema.sql _to_11.sql _to_101.sql 101_to_102.sql _to_11.sql _to_11.sql 29

30 Eigentlich noch komplizierter Orientation in Objects GmbH Continuous Database Design 30

31 Die Lösung Orientation in Objects GmbH Continuous Database Design 31

32 Liquibase Orientation in Objects GmbH Continuous Database Design 32

33 Changelog.xml <changeset author="tmaier" id=" "> <createtable schemaname="public" tablename="person"> <column name="address" type="varchar(255)"/> </createtable> </changeset> Orientation in Objects GmbH Continuous Database Design 33

34 Metadaten in der Datenbank Orientation in Objects GmbH Continuous Database Design 34

35 Liquibase aktualisiert beim Starten der Anwendung automatisch die Datenbank. Orientation in Objects GmbH Continuous Database Design 35

36 BEISPIEL 36

37 Ersetze die Spalte Name durch die Spalte Vorname 37

38 38

39 Wer ändert wann die DB? It depends ;-) DB 39

40 Zu viele Köche DB Ab einer gewissen Größe nur noch so! DB 40

41 Warum nehmen wir eigentlich keine schemalose NoSQL DB? 41

42 Relationale Datenbanken skalieren nicht Warum? Normalisierung => Joins Forderung nach Konsistenz => Transaktionen Orientation in Objects GmbH Continuous Database Design 42

43 NoSQL = Relationale Datenbank - Transaktionen - Normalisierung - Joins - Konsistenz - hartes Schema (+) Skalierung (+) Performance Orientation in Objects GmbH Continuous Database Design 43

44 Datenmodellierung NoSQL Konkret für den Anwendungsfall Denormalisierung und Duplizierung sind normal Orientation in Objects GmbH Continuous Database Design 44

45 userids 1, 2, 5, 7, 12, 1 John Doe, , 2 Richard Miles, , 45

46 userids 1, 2, 5, 7, 12, user:1:firstname John user:1:lastname Doe user:1:birthday

47 user:tmaier:name Key Server 0 Value Key-Hash: 39E5DC60AAD55349 Modulo Anzahl der Server (3): 1 Key Key Server 1 Value Value Key auf Server 1 speichern Key Value Key Value Key Value Server 2 Key Value Orientation in Objects GmbH Continuous Database Design 47

48 0 0 Key 1 3 Key 2 48

49 Twitter Viel Aktion beim Schreiben, wenig beim Lesen reads/sec 6000 writes/sec 49

50 {Tweet-Inhalt} User: 12 Tweet-ID: 4711 Tweet wird unter der ID 4711 eingetragen Tweet:4711 User-Timeline:17 {Tweet-Inhalt} 4711, 3013, 302, Follower von User 12? Graph-DB Ein Eintrag pro Follower! User-Timeline:123 Key-Value-Store 4711, 2001, 878, 50

51 NoSQL? Falls die Anforderungen passen! Anwendung kümmert sich um das Schema 51

52 ??? Fragen?? Orientation in Objects GmbH? Weinheimer Str Mannheim

53 Vielen Dank für ihre Aufmerksamkeit! Orientation in Objects GmbH Weinheimer Str Mannheim

Ähnliche Dokumente

It's time to rethink Datenbank-Design in der schönen neuen Welt

It's time to rethink Datenbank-Design in der schönen neuen Welt Java User Group Hessen 2015 Version: 1.1 Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de info@oio.de Ihr Sprecher