Introduksjon til Apache Cassandra, Datastax og Masteroppgaven (Automatisk skalering av Cassandra-clustere).

1. CASSANDRA
Introduksjon til Apache Cassandra
K15/Faggruppemøte
Andreas Baakind
27/03/14

2. HVA ER CASSANDRA? 2
• NoSQL database
• Extensible record store
• Eventual consistent
• Basert på
• Amazon Dynamo
• Google BigTable
• Laget av Facebook
• Videreført av Datastax
• Enterprise
• Flest commits
• Eget spørrespråk
• CQL

3. Kan minne om datamodellen til relasjonsdatabaser
EXTENSIBLE RECORD STORE

4. KEYSPACE 4
• Tilsvarer en database i relasjonsdatabase-verden
• Ett eller flere keyspace i samme cluster
• Mindre applikasjoner kan dele cluster
• Replikasjonsfaktor settes på keyspace-nivå
• Ulik replikasjonsfaktor i samme cluster

5. TABELLER 5
• Sammenlignes med tabeller i relasjonsdatabaser
• Spres over hele clusteret
• Inneholder rader
• Identifiseres av en primary-key

6. SUPER COLUMNS & COLUMN FAMILIES 6
• Column families
• Sterk kobling basert på applikasjonens domene
• Lagres sammen
• Rask uthenting
• Forventes å leses samtidig
• Super columns
• Enda ett abstraksjonsnivå

7. COLUMNS 7
• Satt sammen av tre attributter
• Name
• Navnet på kolonnen
• Value
• Verdien som lagres
• Timestamp
• Tidsstempel for når dataen ble lagret
• Brukes for å bestemme nyeste verdi

8. EVENTUAL CONSISTENT 8
• Cassandra er ikke ACID-compliant
• Ofret for å oppnå skalerbarhet og tilgjengelighet
• Slipper overheaden som følger med ACID
• Konsistent innen kort tid
• Ikke akseptabelt for pengetransaksjoner, aksjesystemer o.l.
• Akseptabelt for sosiale nettverk, analyse-verktøy o.l.
• Oppdaterer replika-noder asynkront

9. CASSANDRA @ FACEBOOK 9
• Løse “Inbox-search” problemet
• Laget av Avinash Lakshman & Prashant Malik
• Lakshman var med å lage Amazon Dynamo
• Amazon sin Key-value store
• Cassandra baserer seg på denne
• Open sourced i 2008
• Apache prosjekt i 2009

10. STERKESTE SIDER 10
• Skalerbarhet og tilgjengelighet
• Takler ekstremt store mengder lese- og skriveoperasjoner
• “One million writes per second” – Google Cloud Platform
• Desentralisert -> “no single point of failure”

11. BRUKSOMRÅDER 11
• Analyseverktøy ala Google Analytics
• Applikasjoner med høy read- and writethroughput
• Som kan akseptere at dataen er eventual consistent!
• Overvåkning
• Logging

12. BENCHMARK TEST 12
• Utført av et uavhengig selskap (End Point Corporation)
• Kjørt på Amazon EC2 instanser
• Hver test ble utført tre ganger, på tre ulike dager
• Minimerer sjansen for støy fra andre pga delte ressurser
• YCSB
• (Yahoo Cloud Service Benchmark)
• http://labs.yahoo.com/news/yahoo-cloud-serving-benchmark/
• Benchmark whitepaper:
• http://www.datastax.com/resources/whitepapers/benchmarking-top-nosql-databases
Cassandra, MongoDB & HBase

13. THROUGHPUT RESULTATER 13
Kilde: http://www.datastax.com/resources/whitepapers/benchmarking-top-nosql-databases

14. THROUGHPUT RESULTATER 14
Kilde: http://www.datastax.com/resources/whitepapers/benchmarking-top-nosql-databases

15. LATENCY RESULTATER 15
Kilde: http://www.datastax.com/resources/whitepapers/benchmarking-top-nosql-databases

16. “ONE MILLION WRITES PER SECOND” 16
• Postet på Google Cloud platform sin blogg den 20.mars.2014
• Skrevet av Performance Engine Lead @ Google Cloud Platform
• Gir en pekepinn på hva Cassandra klarer
“Cassandra Hits One Million Writes Per Second on Google Compute Engine”
Kilde: http://goo.gl/7MmdO8

17. HVEM BRUKER CASSANDRA? 17

18. DESIGN

19. CLUSTER 19

20. REPLIKASJON 20
• Settes på keyspace-nivå
• Bestemmer hvor mange “kopier” av dataen som lagres
• To strategier
• SimpleStrategy
• Default strategi
• Ett datasenter
• NetworkTopologyStrategy
• Har, eller planlegger flere datasentre
• Definerer antall replikaer i hvert datasenter

21. SIMPLESTRATEGY 21

22. PRIMARY KEY 22
• Bestemmer plassering i clusteret
• Første kolonne i definisjonen er primary key
• Kan kombinere flere kolonner
• Compound key
• Resterende kolonner > clustering columns
• Clustering column
• Defineres etter viktighet
• Resultatsettet sorteres basert på clustering columns
• Kun spørre på kolonner som er definert i primary key’en
• Hvilke kolonner må være med I en spørring?
Eksempler
col1
col1, col2, col3
(col1, col2), col3

23. SECONDARY INDEX 23
• Oppretter en “skjult” tabell
• En kopi per node
• For verdier på den lokale noden
• Anbefales kun hvis det er lav kardinalitet
• Kjønn, Sjangre, Land, …
• Høy kardinalitet = dårligere performance
• Bl.a. unødvendig oppslag
• Mye ekstra data
• Denormalisere!

24. DENORMALISERING 24
• Diskplass er billig
• Verdt å ofre for skalerbarhet og tilgjengelighet
• Dupliserer verdier
• Tabeller basert på spørringene, eks:
• Track_by_artist
• Track_by_id
• Track_by_title
• Applikasjonens ansvar å holde tabeller i synk
• F.eks via batch-jobber

25. COUNTER-TABLES 25
• Perfekt for
• Spore trafikk på nettsider
• Registrere “pings” fra mange sensorer, f.eks
• Passeringer
• Hvis telleren ikke finnes, opprettes den
CREATE TABLE websitestats (
page varchar PRIMARY KEY,
visitors counter
);
UPDATE websitestats SET visitors = visitors + 1 WHERE page = 'demo';

26. DATATYPER 26
Kilde: http://goo.gl/X78Rsb

27. LIGHTWEIGHT TRANSACTIONS 27
• Brukes til insert og update (upsert)
• IF EXISTS
• IF NOT EXISTS
• IF a = b
Insert into users (username, password) VALUES (‘foo’,’bar’) IF NOT EXISTS;
Update users SET reset_code = null, password = ‘foobar’ WHERE username =
‘foo’ IF reset_code = ‘provided-reset-code’

28. TIME-TO-LIVE (TTL) 28
• Antall sekunder en verdi skal være gyldig
• Blir slettet etter gitt tid
• Markeres med en tombstone
• Slettes av Garbage collectoren til Cassandra etterhvert
• Kan settes på rader og kolonner
Insert into users (username, password) values (‘foo’,’bar’) USING TTL 60;
UPDATE users USING TTL 10 SET password = ‘bar’ WHERE username =‘foo’;

29. ALLOW FILTERING 29
• Nyttig for debugging
• Ikke anbefalt i produksjon
• Kan spørre på alle indekserte kolonner
• Tar mye ressurser
• Tidkrevende på større datamengder
• Løsning
• Denormaliser tabellen
• Ny tabell-struktur

30. BATCH 30
• Bruke samme timestamp for alle operasjoner innad i batchen
• ATOMIC BATCH
• Alt eller ingenting blir gjort
• Skriver til en batchlog
• Slettes når ferdig
• NB: Ingen isolasjon!
• UNLOGGED BATCH
• 30% raskere enn atomic batch
• Skriver ikke til batchloggen
• COUNTER BATCH
• Designet for counter tables

31. ANTI-PATTERNS 31
• Design og/eller implementasjon som påvirker performance
Anti-pattern Løsning
Gjøre read før write Bruk IF (NOT) EXISTS
JOIN Denormaliser dataen, lag tabell basert
på spørringen
Store batch-prosesseringer Om mulig brytes ned I mindre
batchjobber. Husk: Ingen isolasjon!
Retur av store resultatsett Default LIMIT er 10.000
- Senk denne om mulig
- Bruk paging
Risikerer OutOfMemoryException

32. PAGING 32
• Begrenser antall returnerte verdier
• Innebygd i Cassandra 2.0
• Enkelt å bruker med java-driveren
Statement.setFetchSize(N)
do
Iterate ResultSet
while ResultSet.fetchMoreResults()

33. SIKKERHET 33
• Client-to-node authentication
• Bruker SSL
• Alle nodene må
• Ha SSL-sertifikatene
• Skru på enable_encryption
• Autentisering basert på brukernavn/passord
• Interne brukerprofiler
• Kan bruke clienter som: Hector, Astyanax, CQLSH, Java & C# driveren til DataStax
• Object permission management
• Gi lese/skrive-rettigheter til ulike deler av dataen
• Extern autentisering med DataStax Enterprise
• Støtter LDAP og Kereberos

34. CONSISTENCY LEVEL 34
• ANY
• Kun writes
• Kjappeste.
• Skrive til hvilen som helst node
• Hvis ansvarlig node er nede
• Lagres som hinted handoff
• ONE
• Må skrive/lese fra en av nodene
• ALL
• Må skrive/lese til alle nodene
• QUORUM
• Matematisk definert
• Rundes alltid ned
• (replikasjons_faktor / 2 ) + 1

35. COMMITLOG, MEMTABLE OG SSTABLE 35
• Commitlog
• Append-only filer
• Write er ikke ferdig før data er skrevet hit
• Memtable
• Opprettes asynkront
• Samler data fra commitloggene
• Fjerner dupliserte verdier
• SSTable
• Memtables flushes til disk som SSTables
• Periodisk
• Når en gitt størrelse
• En SSTable = En fil i filsystemet
• Immutable
• In-memory indeksen finner riktig SSTable

36. HVORDAN EN WRITE FUNGERER 36
• Request treffer en vilkårlig node > Coordinator-node
• Router writen til riktig node
• Venter på svar basert på consistency-level
• ANY - returneres første svar
• Evt. hinted handoff
• ONE – første node som svarer
• ALL - venter man på alle
• Asynkront skrives data til memtables, og deretter til SSTables.

37. HVORDAN EN READ FUNGERER 37
• Samme måte som en write
• Venter på antall svar, basert på consistency-level og replikasjonsfaktoren
• Hvis ulike verdier mottas fra nodene
• Returner nyeste basert på timestamp
• Oppdater resterende noder asynkront

38. USE CASES 38
Firma Bruksområde
Netflix - Metadata for filmer
- Subscriber system
- Visningshistorikk
Spotify - Spillelister
- Radiostasjoner
- Notifikasjoner
- Artister du følger
Ebay - Brukeraktivitet
- Anbefalinger i real-time (liker, ikke liker)
Finn.no - Dine siste søk
- Innboks (samme som Cassandra var for Facebook)
- Annonse-statistikk til bruker
- Scam-deteksjon

39. DATASTAX

40. DATASTAX 40
• Viktigste bidragsyter til Cassandra-kodebasen
• Kommersielle verktøy for Cassandra
• OpsCenter
• Overvåkning og administrasjon av clustere
• DevCenter
• GUI for CQL-spørringer
• Enterprise
• Pakke som inkluderer blandt annet support

41. DATASTAX SERTIFISERING 41
• Enkel og grei intro til Cassandra
• Litt Java 101 innimellom
• Syv sesjoner
• Videoer med spørsmål og forklaring
• Oppgaver etter hver sesjon
https://datastaxacademy.elogiclearning.com/

42. DATSTAX OPSCENTER 42
• Visuell overvåkning
• Trafikk
• Datamengde
• Feil
• Varsling ved behov
• Skalering
• Detekter skjevheter i
data-distribusjonen

43. DATASTAX DEVCENTER 43
• Visuelt verktøy for spørringer i CQL
• Bra for testing & verifisering
• Lagre serier med CQL-kommandoer > Script

44. DATASTAX ENTERPRISE 44
• Produksjonsklar versjon av Cassandra
• Analyse-verktøy
• Integrert søk med Solr
• Bedre sikkerhetsløsninger
• In-memory feature*
• Support
*In-memory processing gir 100 ganger raskere prosessering av data

45. DRIVERE 45
• Datastax sine egne drivere
• Java
• C#
• Python
• Community-drivere
• Clojure
• Erlang
• Go
• .Net
• Node.js
• Scala
• Ruby
• …
http://www.datastax.com/download#dl-datastax-drivers

46. MASTEROPPGAVEN
Automatisk skalering av noder i et Cassandra-
cluster

47. MOTIVASJON 47
• Cassandra brukes hos mange av de store
• Facebook
• Netflix
• Spotify
• Ingen løsning for automatisk opp- og nedskalering
• Netflix’ Priam

48. PRIAM 48
• Open sourced av Netflix i 2012
• Kjører parallellt med Cassandra på nodene
• Utfører backup og recovery
• Dobler antall noder ved oppskalering
• Ingen nedskalering
• Spesialtilpasset AWS

49. HECUBA 49
• Automatisk opp- og nedskalering av noder
• Kjører parallellt med Cassandra på nodene
• En agent-implementasjon lignende Priam sin
• Fungerer i teorien på alle cloud services
• Inkludert interne

50. HVORFOR HECUBA? 50
• Gresk mytologi

51. MÅL 51
• Avlaste db-admin
• Ikke erstatte
• Løse nedskalering av noder
• Finnes ingen kjent implementasjon
• Mye vanskeligere enn oppskalering
• Grunnlag for videre utvikling

52. FORSØKENE 52
• Flere forsøk på implementasjon
• Første forsøk direkte i kildekoden
• Eget STAGE
• Utvide gossip-protokollen
• Ta i bruk timestamps
• Endelig forsøk: Separat implementasjon
• Master – Agent
• Master kjører separat fra nodene
• En agent per node
• Enklere vedlikehold
• Uavhengig av oppdateringer til Cassandra
• Generell funksjonalitet

53. SPØRSMÅL?