NoSQL: Cassandra
Lorenz Verschingel
10 juni 2016
Inhoudstafel
Werking CassandraArchitectuur
Data structuren
Herstelmechanismes
Snelheid
OnderzoekSchaalbaarheid
Betrouwbaarheid
Datamodellering
Data importeren
Use cases
Besluit
Partitioner
Horizontaal schalen:
- dynamische partitionering van data over de nodes
- partitioners -> fysieke plaats
- hashfuncties
3 Soorten
1. RandomPartitioner
- MD5 hash
2. Murmur3Partitioner
- Murmur hash
- Standaard sinds 1.2
3. ByteOrderedPartitioner
- Volgens bytes primaire sleutel
- Problemen:
- "Hot spots"
- Gebalanceerde cluster
Voorbeeld
- 6 nodes -> 6 ranges van hashwaardes a, b, c...
- record wegschrijven
- hash berekenen
- kijken tot welke ranges het behoort
- doorgeven aan juiste node
- node handelt write afReplicatie
- Zorgt voor betrouwbaarheid
- Geen "single point of failure"
- Replicatiefactor
- 2 Replicatiestrategieën
- SimpleStrategy
- NetworkTopologyStrategy
SimpleStrategy
- Replicatiefactor 3
- kloksgewijs replica's plaatsen
- Zwart = origineel, grijs=replica
NetworkTopologyStrategy
- Aangeraden voor productieclusters
- Meerdere datacenters
- Ieder datacenter kan andere replicatie factor hebben
- Rack-awareness
- Replica's op verschillende racksSnitch
- Snel en efficiënt data ophalen
- 8 soorten:
- Fysieke datacenters: GossipingPropertyFileSnitch
- Cloud: bijhorende snitch
SimpleSnitch
1. Query op de coördinator
1. Snitch zoekt uit waar de replica's staan en haalt informatie over deze nodes op
2. Op basis van deze info wordt de query doorgegeven aan de meest geschikte node
3. Coördinator krijgt resultaat
4. Client krijgt resultaatData structuren
- CQL en opslagstructuren
- zelfde terminologie maar anders
- hier CQLData structuren
1. Column
- Kleinste element
- 4 Velden
- Naam
- Value
- Timestamp
- TTL
2. Row
- Geordende kolommen
3. Table
- Rijen met eenzelfde schema
- Toch schemaloos want kolommen hebben geen schema
4. Keyspace
5. cfr. database en schema in relationele dbsHerstelmechanismes
Beschikbaarheid garanderen
- Communiceren over status
- Statussen lokaal opslaan
- 'Phi Accrual Failure Detection Algorithm'
- Kans op dood of levendHerstelmechanismes
Hinted-handoff
Anti-entropy repair
Read repairSynchrone read repair
Asynchrone read repair
Manuele read repair
Hinted handoff
- Online node houdt hint bij voor offline node (max 3uur)
- Online komen:
- Reads blokkeren (consistentie)
- Hints doorvoeren
- Reads toestaan
Anti-entropy
- Anti-entropy: replica's vergelijken en bijwerken indien nodig
- Asynchroon proces
- Continu uitvoeren
Read repair
- Allemaal identiek
- Enkel wanneeer verschilt
- Checksum vergelijken
- Niet gelijk -> ophalen -> updaten op basis van timestampSnelheid
manier van opslaanSnelheid
- Partities
- Boomstrucuur binnen partities
Partities:
- Snel node bepalen
- Werk/data verspreiden over alle nodes
- Snitch node waar snel resultaat van verwacht wordt
Boomstructuur
- lagen gesorteerd
- Snel plaats bepalenSchaalbaarheid
Vagrant clusterSchaalbaarheid
Apache Cassandra
Datastax Cassandra
Apache
- Op iedere node werkende Cassandra
- Na aanpassing yaml file om cluster te bekomen problemen met pid file
Datastax
- Webinterface
- Monitoring + beheer
- Eenvoudig dmv wizards
- Soms zoeken waar de functie juist staatBeschikbaarheid
kijken of herstelmechanismes werkenHoe onderzocht
- 4 nodes en replicatiefactor = 4
- 3 nodes uitzetten
- Wijzigingen doorvoeren
- Nodes online brengen
- Originele node met wijzigingen offline
- Nodes die eerst offline waren een voor een controleren
- 4 node en repl 4 => Iedere node heeft een kopie
- zelfde manier voor werken bij toevoegen en wijzigen
- bij online komen van de andere nodes communicatieDoel
Data evenwichtig verspreiden
Weinig partitie reads
Onbelangrijk:
- Aantal writes
- Duplicate data
Evenwichtig:
- partitie kolommen
- werk verdelen over alle nodes
Partitie reads:
- Iedere partitie op andere node => overhead want query naar alle nodes
- Zelf partities op dezelfde nodes queryen is inefficiënt
- Cassandra is geoptimaliseerd voor groot aantal writes
- Schijfruimte is goedkoop tov CPU, netwerk, geheugen ed
- Basis van CassandraPrimaire sleutel
((part-col-1, part-col-2, ...) clus-col-1, clus-col-2, ...)
(part-col-1, clus-col-1, clus-col-2, ...)
Partitiekolom:
- Fysieke locatie
- Data gebalanceerd verspreiden
- Restrictie:
- 'Slechts' 2 miljard entry's per partitie
Clusteringkolom:
- Boomstructuur binnen partitie
Niet uniek
- INSERT = UPDATE
- Indien geen haakjes rond part cols: maar 1 part col nl de eerste col
Restricties door de manier waarop op geslagen wodt en performantie te garanderen
Restricties partitie:
- Enkel rechtstreeks '=' en 'IN' mogelijk
- '<', '<=', '>', '>='
- Via token - Niet altijd gewenste resultaat
- Rechtstreeks met ByteOrderedPartitionerRestricties - Clusteringkolommen
CREATE TABLE NumberOfTwitterMessages (
userid bigint, date text, hour int, minute int, nrOfTweets int,
PRIMARY KEY ()(userid, date), hour, minute)
);
- Restrictie op date enkel indien restrictie op userid
- '<', '<=', '>', '>='
- Enkel op laatste kolom met restrictie
- Multi-column slice
SELECT * FROM NumberOfTwitterMessages
WHERE userid = 2222
AND date = '2016−04−25'
AND (hour, minute ) >= (12, 30)
AND (hour, minute ) <= (14, 0)
;
Enkel restrictie op clusteringkolom als die ervoor ook een restrictie heeftModel opstellen
- Modelleren naar de query's
- Users ophalen volgens username of email:
CREATE TABLE users_by_username (
username text PRIMARY KEY,
email text,
birthday timestamp
);
CREATE TABLE users_by_email (
email text PRIMARY KEY,
username text,
birthday timestamp
);
- 1 partitie read
- data verspreidModel opstellen - Foutief
- Users ophalen volgens username of email
- Redundante data verminderen
CREATE TABLE users (
id uuid PRIMARY KEY,
username text,
email text,
birthday int
);
CREATE TABLE users_by_username (
username text PRIMARY KEY,
id uuid
);
CREATE TABLE users_by_email (
email text PRIMARY KEY,
id uuid
);
- data verspreid
- 2 partitie reads
- Join onmogelijk
- 2 query's
- '<=' over part-kol met tokensMethodes
cqlsh
COPY tablename (column1 , column2, ...)
FROM 'path/to/file'
(WITH option1 = 'value' (AND option2 = 'true' AND ...))
Tijd is lineair afhankelijk van de hoeveelheid data
sstableloader
Alle nodes gebruiken
Zelf applicatie schrijven
cassandra-loader
Alle nodes gebruiken
cqlsh
- Asynchroon
- Connectie op 1 node
- Kan vastlopen bij meer dan 1 miljoen rijen
- Opsplitsen
- sstableloader
- cassandra-loader
- Kolomnamen meegeven want csv heeft niet noodzakelijk zelfde volgorde als Cassandra intern
- scheidingsteken tussen velden en encapsulering kan gespecificieerd worden
- meegegeven wat er met een null waarde aangevangen moet worden
sstableloader
- Alle nodes gebruiken
- Aangepaste applicatie schrijven
- Alle nodes moeten online zijn
cassandra-loader
- Brian Hess
- Vergelijkbaar met COPY maar alle nodes gebruiken
- Minimaal 8GB werkgeheugen nodigUse cases
- Messaging
- Fraudebestrijding
- Catalogi en afspeellijsten
- Internet of Things
- Aanbevelingen en personalisatie
- Messaging
- 100% uptime
- geen single point of failure
- Fraudebestrijding
- Via nodetool monitoren
- Spammail
- Berichten met zelfde inhoud in 1 rij
- Count
- Count groter dan bepaald getal = spam
- Catalogi en afspeellijsten
- performantie en beschikbaarheid
- Internet of Things
- Sensor data
- Snel specifieke data opvragen mits goed model
- TTL zodat database niet uit z'n voegen barst
- Aanbevelingen en personalisatie
- Hoge throughputMarkten
- Retail en aanbieders van digitale media
- Financiële sector
- Retail en aanbieders van digitale media
- boodschappen wagentje = catalogus
- notificaties = messaging
- persoonlijke suggesties
- Financiele sector
- hoge throughput
- Fraude detectie
- Internet of Things
- verzekeraars die sensoren inbouwenBesluit
- Schaalbaarheid
- Apache niet werkend gekregen
- Met OpsCenter eenvoudig
- Betrouwbaarheid
- Data is altijd beschikbaar
- Datamodellering
NoSQL: Cassandra
Lorenz Verschingel
10 juni 2016