Polyglot Persistence withNoSQLEffektieferes entwickeln durch zielgerichtetesEinsetzen verschiedener Persistenz-Technologie...
Was der Bauer nicht kennt,     frisst er nicht…
Our choice of data storage products
We are used to referential integrity        and transactions
We build a web shop
Bis die Bombe platzt!
Was können wir tun?
Scale up   RAMDiscs/SSDs   CPUsBus systems
Scale out
SQL Servers are not made for          clusters
Wanted: Alternatives!
#NoSQL
Allgemeine NoSQL Eigenschaften  Not using the                  Runnig well   relational                   Open-source     ...
Let’s talk about consistency Roman  Free   Inconsistency   Michael                          Free  NY                      ...
Hauptgründe für NoSQL          Large-scale dataApplication Development Productivity
Es gibt 4 NoSql Kategortien
Key-Value Store Simple Key-    Retrieval byValue storage       key        No Query by          content
Document Store Everything is   Aggregatein a document    Oriented            Query           enabled
{“RowId”:”101”,"FirstName":"Hans","LastName":"Muster","City":"Zürich","Street":"Langstrasse""Orders":[      {"ProductId":"...
Column Family StoreColumn family                                Row  Row           Column1           Column2           Col...
Graph Database                                                            Relationship                           Thomas   ...
Document                                   Key-Value                       Use Cases                                      ...
You have a choice!
Decisions, decisions…                        © Zühlke 2013
Ich will den 5er und das Weggli!
Use the right tool for the job                    WebshopSession Store Shopping Cart    Product   Recommonda              ...
Pol·y·glot – Adjective  Knowing or using several languages          Per·sist·ence –NounThe continued or prolonged existenc...
Sounds great, but where is the catch?
What does this to my code?
Higher administration effort
The service is the data ownerIntegration Database         Application DatabaseApplication    Application   Application    ...
It’s all about layers!
NoSQL is fun, play with it!                              © Zühlke 2013
Quellen          Fowler, Martin. “NoSQL Distilled: A Brief Guide          to the Emerging World of Polyglot Persistence   ...
Upcoming SlideShare
Loading in …5
×

Polyglot persistence with no sql

504 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
504
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • IchhabeeineKundengefragtobsieInteresse an einemVortragüber das ThemaNoSQLhaben.Da kampostwendend,ohne gross zuüberlegen, die Antwoort: NeinLeiderkommt das sehr oft vor. Eben, was der Bauernnichtkennt, das frissternicht.leh
  • Darumistesauchnichtsehrverwunderlich, dassunsere Persistence ProdukteAuswahl so aussieht.Frage: Habtihrbemerkt, was dieseProduktegemeinsamhaben?=> EssindallesRelationaleDatenbankenRelationaleDatenbankenhabensichseitüber 20 Jahrenbewährt und jederkennt und kann SQL.leh
  • Ichdenke das liegtzumteilauchdaran:WirsindunsgewohntunsereSysteme relational zukonstruieren und Transaktionenzuverwenden.Wirgehenimmerdavonaus, dass die Datenkonstistenzzu 100% gewährleistetist.leh
  • WirbaueneinenWebshopfürMusik:ProdukteRecomendation EngineUser DatenWarkenkorbBestellungenWirsetzten auf bewährtes und baueneinemoderneApplikatenmit SQL Server.leh
  • rkuMit der Zeitwächst das Datenvolumen und die BenutzerzahlUnd damit die beginnen die Performance-Probleme:Browsen desKatalogsstocktSchritteimBestellprozesssiindlangsam -> Shopping Cart, Check-outBerechnung der EmpfehlungendauernlangeDadurchmehr Helpdesk-AnfragenBenutzerverliert die Geduld und wandertabWirstellen fest, Problemeliegennicht in der App, sondernbackend-seitig (in der DB)
  • rkuWas könnenwirdagegentun:Cachingdannmüssenwiruns um Synchronisation kümmernWas würdenwirjetztmit SQL Server tun?Ganzeinfach: Wirkaufeneinengrösseren Server mitmehr Power!=============================================Ursachen und Bottlenecks SQL Server:Ausgelastetes Memory und CPUPressure auf Disk-Subsystem und Trx-LogSicherstellung von Konsistenzverursachen waits (Locks)Query und Ausführungsplan
  • rkuGrösseren Server kaufenbedeutet also “Scale Up”D.h. mehrRechenleistungMehrRAMBessereDiscsBesserer CPUBesseren BusPhysikalischeGrenzenLeistungsstarke HW verursachtimmerhöhereKosten
  • rkuEineandereMöglichkeitwäre, mehrere Server zuverwendenDas nennt man “Scale out” (horizontal zuskalieren)MehrereRechnerschliesst man zueinemVerbund (Cluster) zusammen“Scale out” bietetzweiKonzepte (oderPfade):Sharding: wirverteilen die DatenReplication:wirduplizierensieSchliessensichnichtgegenseitigaus, Kombinationistüblich in NoSQL Data StoresEigenschaften von Scale out:TypischerweisemitCommodity Hardware (handelsübliche, g&gRechner)High-available und robust/zuverlässig (eineinzelner Server kannausfallen! -> Replication)====================================================Durch die Parallelisierungsind die Performance-Kennzahlen des einzelnenRechnerswenigerausschlaggebend
  • rkuSQL Server istnichtgeeignetfür scale out resp. ClusteringWarum?RDBMS sindgebaut um concurrency zukontrollieren und damit die KonsistenzsicherzustellenConstraints und FK sindebenfallsWerkzeugedafürFlexibles Datenmodellierunghilft, DatenausverschiedenenPerspektivenabzufragenSomitdienensienochimmerIntegrationsplattformim Enterprise UmfeldAber:Relationensindungeeignet in verteilten Data clusters -> Join ops sindteuer!Zudem:Shardingmit RDBMS bedeutetjeweils separate InstallationLizenzkostenkönnenentstehenDispatching/Balancing fürSharding muss in der ApplikationgemachtwerdenKomplex und teuerClustered RDBMS Beispielist Oracle RACverwendetjedoch das Konzept von Shared disksDisk Subsystem ist Single Point of failure!
  • Wirhaben die Möglichkeitenmit SQL ausgeschöpft, wirbraucheneine Alternative.- ObjektorientierteDatenbanken => Hat sichniewirklichdurchgesetzt 1. SQL war PlattformUnabhängig und konntesomitals Integration Database eingesetztwerden 2. Die meistenProblememitSQlkonnten dank OR-Mapper gelöstwerden- Da istauchnochNoSQLleh
  • Der BegriffNoSQLenstandalsfüreinGipfeltreffenüber alternative DatenSpeicherTechnologieneeineindeutigesWortfür Google und Twitter gesuchtwurde,DabeistehtNoSQLfür “Not – Only – SQL”.NoSQL an sichistkeineTechnologie, sondernmehreineBewegung.leh
  • 1. NoSQLDatenbankensindfür Clusters gemacht, was die ebenerwähntenProblemelösenkann.2. Generellkann man sagen, dassNoSQLDatenbankenkeinrelationalesDatenmodellhaben und damitauchkeine SQL Abfragesprache.3. Meistenswerden die DatenimJson Format abgelegt. Das bedeutet, dasskeinn Schema vorhandenist. Schemalessheisstnichtdasseskein Schema hat, sondernesgibteinImplizites Schema und die verantwortungwandert von der DatenbankzurApplikation (VorteilnurinnerhalbAggregat, wenn Boundaries verlassen, dann Migration wiebei RDBMS)4. ImGegensatzzurelationaleDatenbankenhabenNoSQLDatenbankeneinenganzanderenBezugzurKonsistenz.leh
  • rkuStrong Consistency war und ist oft das obersteGebotMit RDBMS kennenwirKonzeptewieTransaktionenLocks (für pessimistic = verhindern von Konflikten)row versioning (für optimistic = StrategienfürUmgangmitKonflikten)NoSQLmeistenskeineTransaktionenEsgibtKonzepte, wie man siesicherstellenkannbedeutetaberidR. einehöhereLatenzzeit in KaufzunehmenIst strong consistency aberimmernötig?BeispielBuchungHotelzimmer:Michael buchteinHotelzimmer in Paris, Buchung auf Server ZürichRoman buchtdasselbe Zimmer, etwaszeitversetzt, von Server NYMöglich, da Buchung von Server Zürich nochnichtrepliziertwurdeSomithabenwireineKonsistenzverletzung, d.h. einenKonfliktWas istschlimmer: 1 von 1000 FälleneinenKonfliktbehandeln, oderGefahr von Kundenabwanderung, weil die Webseitezulangsamist.IsteinExtrembeispiel und erforderteinentsprechendesBusinessmodell!Das Beispielzeigtaber das Problem auf: FüreinebestimmteZeitsind die Dateninkonsistent (bisalle Nodes konsistentsind = replication consistency), solangeaberkeinKonfliktherrscht, sindsieletztendlichkonsistentDieses Paradigmanennt man “eventual consistent”Eskommtvor, dass die DatenfüreinenbestimmtesZeitfensterinkonsistentsind, da sierepliziertwerden, letztendlichsindsieaberkonsistentLetztendlichAbwägungzwischenPolen “low latency” und “strong consistency”Fazit: Man muss ichsichüberlegenwo man auf die KonsistenzzugunsteneinerkurzenLatenzzeit (Performance) daraufverzichtenkann.Backup:Gefährlichsind logical consistency Konflikte -> A hat LineItems, B liestaus, A macht updates  also businessmässigeKonsistenz- oderIntegritätsverletzungKonzepteverteilterSysteme: Quorum, serializing, approaches wie in dist. versioning tools, Master-Slave===================== CAP Theorem =======================ImUmfeld von VerteiltenSystemenstösst man früheroderspäter auf das CAP Theorem.Esgibt 3 Eigenschaftenim CAP Theorem:1. Availablity: Man bekommt IMMER von mindestenseinem Node eineAntwort.2. Consistency: Werte die ichschreibe und Roman ausliestsindimmer 100% die selben.3. Partition Tolerance: Das System Funktioniertauch, wennsich das NetzwerkpartitioniertCAP Theorem wird oft falschinterpretiert!Eigentlich latency vs. consistency.
  • DaurausergebensichzweiHauptgründefür den Einsatz von NoSQL1. Need for Cluster2. Entwicklingsproduktivität (InmemoryStrukturenpersistieren, Schemaless)LEH
  • Esgibtunzähligeprodukteausserhalb des Relational DatanbankBereiches.Aber man kanndieseprodukteprinzipiell in 4 Kategorienunterteilen:- Key-Value Stores- Document Stores- Column-Family Stores- Graph Databasesleh
  • TypischeVertreter: Redis, Riak, Azure TablesWichtigist, dass die Datennurüber den Key abgefragtwerdenkönnen => Keine Queries auf Dateninhalte!Sehreinfachzubenutzen
  • TypischeVertreter: Couch DB, Mongo DB, Raven DBWichtigist, dassganze “Dokumente” abgespeichertwerden.WirkönnenunsereInMemoryStrukturen (SogenannteArggegationen) ablegen, welchemeistens in Form von Jsonabgelegtwird. Was heisst, dassunsereAggregationen das “Schema” festlegen.
  • Aggregationenwerden of in sogenannten Collections gespeichert, das hieristeinBeispieleinersolchen Aggregation. Wobei die Orders ArggregatevomProduktsind. Man kannAggregatstrukturenbeliebigertiefebilden.AggregationenhabeneinengrossenEinfluss auf Schreib- und inspesondeLesegeschwindigkeiten. Deshalbistbeim Design der Applikationdaraufzuachtenwie die Aggregationsstrukturenaussehen!Wenn man z.B. alle Orders abfragen will, istdieseAggregationsstrukturnicht so geeignet, denn man muss immerüber den Kundengehen um an die Orders zugelangen.Geradedeshalbnimmt man oft auchbewusst die Denormalizierung in kauf. In diesem Fall könnteesbessersein, wennwir die Orders alsduplikate in einereigenen Collection ablegen.D.h. Die Datenintegritätkannnichtmehrdurch die Datenbanksichergestelltwerden! => Das muss in der Applikationberücksichtigtwerden.leh
  • RkuTypischeVetreter Cassandra, Hbase, Hypertable und Amazon DynamoDBColumn Family Stores speichernDaten in als Columns (als Key-values)Eine Row isteine collection von Columns und wirüber key referenziertCollection von “gleichen” Rows zeichneteine Column Family ausSuper-Columns (collection von Columns innerhalb der Column-Family) verwenden, um related Datenzusammenzuhalten -> Achtung Performance! -> DeserializationQuery FeaturesBasic queries that can be run using a Cassandra client include the GET, SET, and DELCassandra Query Language (CQL)Semi-schematic: Columns sind da, abernichtzwingend und in der Reihenfolge.============================================Consistency:Cassandra: zuerst ins commit log, dann in memtable (in-memory structure)  operation isterfolgreich, wennim commit log und in memtableCassandra ist Peer-to-Peer  verwenden Quorum (Definieren, wieviele Nodes angefragt, resp. geschriebenwerden)KeineTrx: a write is atomic at the row levelIf a node goes down, the commit log is used to apply changes to the nodeexternal transaction libraries, such as ZooKeeper
  • RkuTypischerVertreterist Neo4JGraph DBs sindExoten von NoSQLGraph databases Entities und Relationenzwischen Entities.Entities = nodesNodes habenEigenschaftenRelations nennt man Edges (Kanten) und könnenebenfallsEigenschaftenhabenWichtig: Edges sindgerichtetRelationship sind die zentralenElemente der Graph databasesVerschiedene Query SprachenD.h. Querying bedeutettraversieren des graphenUnd genauhierliegt die StärkeimUnterschiedzu RDBMSBeispiel: Welcher Freund einesAngestelltenvom CEO mag Hawaii Shirts?Wiewürdetihr das mit SQL Server machen?Komplexe, voneinanderabhängigeRelationensinddadurcheinfach und performantWeitereEigenschaften:Oft transaction based (ACID-compliant)Nichtgeeignetfür Clusters wegenRelationen
  • Unser altesBild hat sich nun erweitert (NoSQL logos Einblenden)Jetzthabenwireineriesenauswahl an Data Stores.rku
  • rkuAber welches ProduktnehmenwirjetztfürunserenWebshop?JedeTechnologie hat ihreeigenenVor- und Nachteile.Fürwelchewirunsauchimmerentscheiden, wirmüssen Trade-Offs eingehen!
  • Müssenwirüberhauptwählen?Ich will den 5er und das Weggli!Ich will die richtigeTechnologiefürjedesmeinerProbleme:- Session Cache- WarenkorbPersistierung- Recommondation Engine- StammdatenverwaltungWisomischenwirnicht?leh
  • leh
  • DasVerwenden von mehreren Persistence LösungenimselbenSystemkontextes, nennt man Polyglot Persistence.Der Begriffsetztsichaus den beidenWorten Polyglot und Persistence zusammen.leh
  • … Natürlich, wirhabenvorherbei den einzelnenTechnologien auf die Problemehingewiesen, aber was liegt das Problem an unsererArchitektur resp. beim Polyglot Ansatz?rku
  • Complexity:WirverwendenmehrereDatentöpfeSicherstellen der Integritätnichteinheitlich/übersichtlichNo consistency through a Schema (polyglot istStufemehralsnureineNoSQL.) -> consistency, integrity only in app. for different Data stores!Complex code structuresDeploymentrku
  • Multi Skills in AdminAufwandDeploymentVielSpassbeiMigrationen! -> Concept (You will still have to deal with Data mig.)rku
  • Dadurch, dass die Daten in mehreren Data Stores verteiltsind (teilw. Redundant!) kann der einzelne Store die Integrität und Konsistenz (wonötig) gar nichtmehrsicherstellenDie Verantwortungwandertdadurch in die Applikation. D.h. jedeApplikation hat seine eigenenDaten und istdafürverantwortlich (Application Databases)Was machenwirim Enterprise-Umfeld:FrüherfungiertenDatenbankensehr oft alsIntegrationsschnittstellezwischenmehrerenApplikation (Shared Data).Heute SOA  d.h. Der Service istverantwortlichfür die DatenVerwenden Service -> Konzeptbekannt, nurKomplexitäterhöhtleh
  • Um den code sauberzuhaltenistessehrwichtig, dasseinesaubere Layer Strukturaufgebautwird.Integritätsicherstellenleh
  • RelationaleDatenbankenwerdennichtverschwinden!Vorteile: Consistency, VerschiedeneSichtenNoSQLwerdensieergänzen.Vorteilbei Scaling und coding-efficiency  jedochmiterwähnten Trade-offs (übrigensauch Security)Ployglot Persistence einsetzen, wennnötig, nicht per se.Rku/leh
  • leh
  • Polyglot persistence with no sql

    1. 1. Polyglot Persistence withNoSQLEffektieferes entwickeln durch zielgerichtetesEinsetzen verschiedener Persistenz-Technologien Slide 1 27. January 2013 Roman Kuczynski, Michael Lehmann © Zühlke 2013
    2. 2. Was der Bauer nicht kennt, frisst er nicht…
    3. 3. Our choice of data storage products
    4. 4. We are used to referential integrity and transactions
    5. 5. We build a web shop
    6. 6. Bis die Bombe platzt!
    7. 7. Was können wir tun?
    8. 8. Scale up RAMDiscs/SSDs CPUsBus systems
    9. 9. Scale out
    10. 10. SQL Servers are not made for clusters
    11. 11. Wanted: Alternatives!
    12. 12. #NoSQL
    13. 13. Allgemeine NoSQL Eigenschaften Not using the Runnig well relational Open-source on clusters model Eventual Schemaless Rest & Json consistent No SQL
    14. 14. Let’s talk about consistency Roman Free Inconsistency Michael Free NY ZH Conflict!
    15. 15. Hauptgründe für NoSQL Large-scale dataApplication Development Productivity
    16. 16. Es gibt 4 NoSql Kategortien
    17. 17. Key-Value Store Simple Key- Retrieval byValue storage key No Query by content
    18. 18. Document Store Everything is Aggregatein a document Oriented Query enabled
    19. 19. {“RowId”:”101”,"FirstName":"Hans","LastName":"Muster","City":"Zürich","Street":"Langstrasse""Orders":[ {"ProductId":"1", "Price":"150"}, {"ProductId":"2", "Price":"150",“Year":“2013"}]}
    20. 20. Column Family StoreColumn family Row Row Column1 Column2 ColumnN Key X Name1:value1 Name2:value2 NameN:valueN Row Row Column1 Column9 ColumnN Key Y Name1:value1 Name9:value9 NameN:valueN Know the groups of Query enabled Semi-schematic columns
    21. 21. Graph Database Relationship Thomas focused friend employeeJakob sells likes CEO Several query languagesfriend Hawaiian Shirt employee likes sells ACID compliant categoryMarkus Alfred designes designes Limited in Shirts scaling
    22. 22. Document Key-Value Use Cases Column- Family GraphSession InformationsUser Profiles, PreferencesCachesEvent LoggingContent Management SystemsE-Commerce SystemsRelationship among dataSocial NetworksRouting, DispatchingLocation based ServicesACID Operations (Transactions)Massive Update OperationsQuery Content
    23. 23. You have a choice!
    24. 24. Decisions, decisions… © Zühlke 2013
    25. 25. Ich will den 5er und das Weggli!
    26. 26. Use the right tool for the job WebshopSession Store Shopping Cart Product Recommonda Catalog tion Engine Key-Value Document Graph Store Store Database
    27. 27. Pol·y·glot – Adjective Knowing or using several languages Per·sist·ence –NounThe continued or prolonged existence of something
    28. 28. Sounds great, but where is the catch?
    29. 29. What does this to my code?
    30. 30. Higher administration effort
    31. 31. The service is the data ownerIntegration Database Application DatabaseApplication Application Application Application A B A B Service Database Database DB A DB A DB B DB B DB C DB Cand the app accesses the data through the service
    32. 32. It’s all about layers!
    33. 33. NoSQL is fun, play with it! © Zühlke 2013
    34. 34. Quellen Fowler, Martin. “NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence (Michael Lehmanns Library).” Addison-Wesley Professional, 2013. © Zühlke 2013

    ×