Distribuerede systemer på CBS, 26. september 2016 - transaktioner

Slides til undervisningen i distribuerede systemer på CBS d. 26. september 2016 omhandlende transaktioner.

Transcript

1. Velkommen til min undervisning. Distribuerede systemer på CBS, september 2016, DS-bogens kapitel 16 og 17 plus en vigtig artikel
2. kt@tdmn.co. Skriv til mig, hvis I har brug for hjælp.
3. Hvordan laver man forespørgsler i en NoSQL-database? Det blev jeg spurgt om sidst - og det er et godt spørgsmål.
4. I kender jo MySQL.
5. Vi vælger noget, der lever op til et kriterium.
6. Riak er et eksempel på en distribueret NoSQL-database.
7. Sådan starter man databasen og ja, bum, bum…
8. En distribueret key-value store. Essensen af Riak.
9. Sådan kan noget, der er gemt i Riak, se ud.
10. Her laver jeg en søgning via Riak Search.
11. Det er en udfordring af lave queries i en distribueret NoSQL-database. Og databaserne har ofte forskellige engines til at lave queries.
12. En beskrivelse af Apache Hive. The Apache Hive data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage using SQL.
13. En beskrivelse af Apache Spark. Apache Spark is a fast and general engine for large-scale data processing.
14. Vi skal tale om transaktioner. De bliver nemlig brugt hele tiden.
15. Definitionen fra ordbogen.
16. En transaktion er en behandling af informationer, der enten lykkes eller ikke lykkes. Den generelle definition inden for IT.
17. Det kunne fx skabe kaos, hvis der ikke blev anvendt transaktioner i banken… Transaktioner er en måde at skabe et forløb på, så behandlinger af data ikke foregår kaotisk.
18. Her læser vi en kontos anløbende og lægger 10% til. Tidspunkt Handling Resultat 12:00 beløb = kontoA.læsBeløb() 1.000 kr. 12:01 kontoA.sætInd(beløb * 1.1) 1.100 kr.
19. Her gør vi det samme igen på samme tid fra en anden maskine. Tidspunkt Handling Resultat 12:00 beløb = kontoA.læsBeløb() 1.000 kr. 12:01 kontoA.sætInd(beløb * 1.1) 1.100 kr. 12:00 beløb = kontoA.læsBeløb() 1.000 kr. 12:01 kontoA.sætInd(beløb * 1.1) 1.100 kr.
20. For at citere DS-bogen for en gangs skyld. Det er det, der hedder the lost update problem.
21. Når to transaktioners operationer giver samme resultat. Sig hej til seriel ækvivalens.
22. En-efter-en versus samtidig afvikling. We say that an interleaving of two blocks is serially equivalent, if the result is equivalent to an execution in which one block was executed entirely before the other.
23. Jeg nævnte det jo sidste gang. Lad os bringe det på banen igen. Vi skal tale om atomicitet igen.
24. Et lille tip: flyv direkte. Det kan man jo nu. Du vil gerne til San Francisco. Du beder et rejsebureau om at arrangere din tur. De fortæller at du skal over Chicago. De booker først en billet til Chicago, og finder så ud af at der ikke er flere pladser i flyet derfra til San Francisco - og du ærgrer dig.
25. Drako var en græsk politiker med nogle meget stramme love. Det kunne undgås med en transaktion, der på drakonisk vis enten ville lykkes eller slet ikke.
26. Konflikter kan opstå når der er afhængigheder i rækkefølgen. Operationer i to transaktioner Konflikt Årsag læs læs Nej Effekten af to læse-operationer er ikke afhængig af deres rækkefølge læs skriv Ja Effekten af en læs- og skriv- operationer er afhængig af deres rækkefølge skriv skriv Ja Effekten af en skriv- og skriv- operation er afhængig af deres rækkefølge
27. Microsoft Access er et eksempel på en database som har streng afvikling af instruktioner.
28. Tænk MySQL, PostgreSQL, Oracle og så videre. ACID er et begreb inden for databaser, som står for Atomicity, Consistency, Isolation og Durability.
29. ACID er et stærkt koncept fra den gamle skole inden for databaser. Atomicity Enten virker hele molevitten eller også bliver det droppet. Consistency Sørger for at data er korrekte, fx at en ny række har en primærnøgle. Isolation Sætter lighedstegn mellem samtidig og seriel kørsel af transaktioner. Durability Hvis nu serveren eksploderer, så skal transaktioner kunne overleve - typisk ved at være gemt på disken.
30. At bruge locks og locking er meget udbredt i databaser. Man kan sikre seriel ækvivalens ved fx at låse værdier eller ved at lave wait-for-grafer.
31. Om hvordan det forholder sig med læse- og skrive-låse. Læse-operation Skrive-operation Hvis der ikke er nogen lås OK OK Hvis læse-lås på værdien OK Vent Hvis skrive-lås på værdien Vent Vent
32. Og det kan jo opstå når man bruger låse-mekanismer. Deadlocking er ikke godt.
33. Her er der skabt en deadlock-situation. Transaktion 1 Transaktion 2 Operationer Låse Operationer Låse kontoA.sætInd(200) skrive-lås på konto A kontoB.sætInd(200) skrive-lås på konto B kontoB.læsBeløb() (venter på skrive-låsen på konto B) kontoA.læsBeløb() (venter på skrive-låsen på konto A)
34. Det er essensen af two-phase locking. Hvis en værdi ikke allerede er låst, så lås den. Hvis værdien har en lås i forvejen, der er i konflikt med operationen, så vent til låsen fjernes. Hvis værdien har en lås i forvejen, der ikke er i konflikt, så fortsæt som planlagt. Hvis værdien allerede er låst i samme transaktion, så forfrem den eventuelt og fortsæt som planlagt.
35. En måde at styre samtidig afvikling på, så det ikke går rabundus. Locking er en form for concurrency control.
36. I kender locking fra dagligdagen.
37. Det kan skabe bedre performance at være optimistisk. Optimistic concurrency control er en antagelse om at flere forskellige transaktioner kan gennemføres uden at påvirke hinanden. Når en transaktion bliver kørt, så foregår det uden brug af locking. Når resultatet af en transaktion bliver gemt, så undersøges hvorvidt de data, den har brug, er blevet ændret i mellemtiden. Hvis ja, så forsøges transaktionen gentaget på ny.
38. Altså: adgang til værdier styres af tidsstempler. Timestamp ordering har som regel at en transaktion ikke må gemme en værdi, der er blevet læst på et senere tidspunkt af en anden transaktion. En transaktion må ikke gemme en værdi, der er blevet gemt på et senere tidspunkt af en anden transaktion. En transaktion må ikke læse en værdi, der er blevet gemt på et senere tidspunkt af en anden transaktion.
39. Det har at gøre med Leslie Lamport. Ham vender vi tilbage til. Et tidsstempel kan være et tidspunkt eller blot en værdi som stiger.
40. Endnu et citat fra bogen. Transactions all limit to some extent the potential for concurrent operation.
41. Fx når en transaktion læser værdier fra et cluster af database-servere. Transaktioner er distribuerede når de anvender værdier fra flere forskellige steder.
42. Nu kommer vi til noget af det, som er virkelig interessant. Med distribuerede transaktioner har vi flere forskellige aktører, og hvem styrer så hvad?
43. Two Generals’ Problem hvor sendebude bliver sendt ud og hjem - og nogen bliver slået ihjel undervejs.
44. Det handler om at lede og fordele ansvar. Der skal være en, der styrer slagets gang. Det skal ikke være den samme altid - turen skal gå på skift. Det kaldes blandt andet for en coordinator role, en log leader eller generelt set log election. Husk at transaktioner skal gemmes og kunne genskabes - det gøres via en log over hvad der er sket.
45. Det er jo nødvendigt at koordinere hændelser i et distribueret system. For at koordinere har vi skabt det, der hedder en two-phase commit protocol.
46. Sådan ser en atomic commit protocol ud. – Er I klar? – Ja, mand! – På hvad? – Næ!
47. Atomic commit protocol, forklaret. Hvis alle melder tilbage med grønt lys, så bliver transaktionen gennemført (commit). Hvis ikke alle melder positivt tilbage, så bliver transaktionen afbrudt (abort/rollback). Hvis en deltager har meldt positivt tilbage og ikke hører mere fra lederen, så er deltageren i en uncertain state.
48. Konsensus vender vi tilbage til senere. Den form for koordinering er et eksempel på konsensus i et distribueret system.
49. Stjålet direkte fra Wikipedia. A fundamental problem in distributed computing is to achieve overall system reliability in the presence of a number of faulty processes. This often requires processes to agree on some data value that is needed during computation. Examples of applications of consensus include whether to commit a transaction to a database, agreeing on the identity of a leader, state machine replication, and atomic broadcasts.
50. Pause.
51. Og når vi stemmer, så er det fordi vi skal opnå konsensus. Demokrati er en form for konsensus i den virkelige verden.
52. Altså hvis en server crasher, fx. Hvad sker der så hvis det hele går op i hat og briller?
53. Evnen til at håndtere og udbedre fejl er essentiel. Transaktioner skal som udgangspunkt være persisteret, altså gemt et sted, så de kan genskabes om nødvendigt. Hvis en server ikke svarer, så kan der anvendes en timeout, som opgiver at få svar efter noget tid. Ergo: et distribueret system skal som minimum kunne håndtere forsinkelser (latency) og nedbrud (failures).
54. Et beslutningsdygtigt flertal. 2/3.
55. Som i livet generelt er det ofte flertallet som bestemmer. Et quorum er et udtryk for et givent flertal, der skal til for at et distribueret system kan overleve nedbrud. Et quorum på to tredjedele betyder at et system med alle noder intakte kan overleve at en tredjedel af dem dør på grund af systemfejl eller lignende. Et quorum kan samtidig anvendes til at løse konflikter omkring data i systemer, der er eventually consistent.
56. Bitcoin er et eksempel på distribuerede transaktioner, der kan overleve nedbrud.
57. Det er humlen i det. Bitcoin har en block chain, som er en stor log over alt det, der er sket.
58. Yes! Vi skal tilbage til Leslie Lamport.
59. Leslie Lamport er de distribuerede systemers grand old man.
60. Det ser måske kringlet ud, men symbolerne dækker over simple sammenhænge.
61. En tidlig definition af kausalitetsbegrebet. Leslie Lamport fremsætter i juli 1978 idéen om begivenheder, der er indtruffet før hinanden. a → b
62. Et simpelt koncept, egentlig. Han omtaler clocks som en logisk konstruktion, der tæller når en værdi bliver ændret. hvis a → b, så C(a) < C(b)
63. Også det her. Brugen af clocks gør det muligt at opstille en samlet rækkefølge over begivenheder i et distribueret system. a 㱺 b eller Ci(a) < Cj(b) eller Ci(a) = Cj(b) og Pi ≺ Pj
64. Sidstnævnte er en vigtig pointe. Når der er opstillet en samlet rækkefølge for begivenheder i et distribueret system, så kan hver node vedligeholde en liste over hvilke ressourcer, der er ledige hvornår - og sørge for at sende forespørgsler på ressourcer når der er behov for det. Det kræver dog at alle noder kender til hinanden i det distribuerede system.
65. Yes. En node kan få adgang til en ressource når den har en forespørgsel på en ressource i sin liste, og den forespørgsel kommer før andre forespørgsler i henhold til den samlede rækkefølge. a 㱺 b
66. Så måske er det en god idé at anvende rigtige ure i stedet for tilnærmede. Problemet er at en begivenhed kan være vigtig, men hvis den ankommer for sent, så honoreres den reelle rækkefølge ikke.
67. Altså: rigtige ure. I stedet for en værdi, der stiger løbende, så kan der anvendes rigtige ure til at afgøre den reelle rækkefølge af begivenheder i et distribueret system. Det skal selvfølgelig forstås som ure i en computer - og ikke det armbåndsur, du har på armen.
68. Strong clock condition optræder når forsinkelser ikke ændrer i en faktisk rækkefølge. One of the mysteries of the universe is that it is possible to construct a system of physical clocks which, running quite independently of one another, will satisfy the Strong Clock Condition.
69. For en god ordens skyld. Opsummering.
70. Jeg glæder mig til at se jer næste gang. Tak for i dag!