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
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
TABELLER 5
• Sammenlignes med tabeller i relasjonsdatabaser
• Spres over hele clusteret
• Inneholder rader
• Identifiseres av en primary-key
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å
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
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
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
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”
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
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
THROUGHPUT RESULTATER 13
Kilde: http://www.datastax.com/resources/whitepapers/benchmarking-top-nosql-databases
THROUGHPUT RESULTATER 14
Kilde: http://www.datastax.com/resources/whitepapers/benchmarking-top-nosql-databases
LATENCY RESULTATER 15
Kilde: http://www.datastax.com/resources/whitepapers/benchmarking-top-nosql-databases
“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
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
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
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!
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
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';
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’
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’;
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
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
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 basertpå spørringen
Store batch-prosesseringer Om mulig brytes ned I mindrebatchjobber. Husk: Ingen isolasjon!
Retur av store resultatsett Default LIMIT er 10.000- Senk denne om mulig- Bruk paging
Risikerer OutOfMemoryException
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()
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
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
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
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.
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
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
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
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/
DATSTAX OPSCENTER 42
• Visuell overvåkning
• Trafikk
• Datamengde
• Feil
• Varsling ved behov
• Skalering
• Detekter skjevheter idata-distribusjonen
DATASTAX DEVCENTER 43
• Visuelt verktøy for spørringer i CQL
• Bra for testing & verifisering
• Lagre serier med CQL-kommandoer > Script
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
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
MOTIVASJON 47
• Cassandra brukes hos mange av de store
• Netflix
• Spotify
• Ingen løsning for automatisk opp- og nedskalering
• Netflix’ Priam
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
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
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
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
Top Related