1. Cloud storage in azienda:
perchè riak ci è piaciuto
Alberto Eusebi
alberto@biodec.com
Biodec Srl
http://www.biodec.com

2. Il problema
●
Flusso di dati: 100.000/mese
●
Archiviare
●
Dimensione media: 300KB
●
Versionare
●
In rapida crescita
●
Query system

3. Idee?
●
Storage basato su db SQL
●
Storage su filesystem (metadati su SQL)
●
Dati su NoSql (metadati su SQL)

4. La scelta: Riak + Postgres
●
Usato e consigliato in scenari simili
●
Ridondanza
●
High availability e affidabilità (masterless; no single
point of failure)
●
Scalabilità
●
Setup -ragionevolmente- semplice
●
Versatilità (eg. pluggable storage backends)
●
Buona documentazione e supporto tecnico
●
Codice open; progetto “vivo”

5. Riak
●
Rilasciato nel 2009 da Basho Technology
●
Basato su Amazon Dynamo
–
http://docs.basho.com/riak/latest/theory/dynamo/
●
Licenza Apache2
●
Altri prodotti:
–
Riak CS
–
Versioni enterprise
●
Erlang (C, Java, Javascript)
●
API native:
–
–
●
Http
Protocol Buffer (Google)
Clients libraries (Basho supported): Java, Erlang, Ruby,
Php, Python
–
http://docs.basho.com/riak/latest/dev/using/libraries/

6. Anti-outline
●
Map-reduce
●
Strutture dati specifiche:
–
–
Key indexing (2i)
–
●
Full text search (tagging)
Link walking
Gestione avanzata di conflitti (vector clocks)

7. Requisiti e progettazione
●
System:
–
–
Debian based: Debian, Ubuntu
–
●
Red Hat based: Red Hat Enterprise Linux, CentOS, Fedora
Solaris based: Sun Solaris, OpenSolaris
Hardware
–
Multi-core 64-bit CPU
–
Minimum 4 GB RAM
–
Multiple Fast Hard Disks (RAID and/or SSD)
–
Fast Network (Gigabit +)
●
Virtualization?
●
Network load balancing (eg. Haproxy)

8. Setup
●
Packages (deb, rpm …)
–
–
Facile gestione dell'upgrade
–
●
Un nodo per macchina
Limitazione di problemi con Erlang
Source tarball
–
Massima libertà nel setup (ambiente di test)
–
Utilizzo di make e rebar per la creazione e la distribuzione
dei nodi
–
Gestire la dipendenza con Erlang (kerl)

9. Partizionamento dei dati
●
●
●
Indirizzamento basato sugli hash delle chiavi (consistent hashing)
Spazio di indirizzamento: 160-bit (“bucket/key”)
Numero di partizioni fissato (ring_creation_size)

10. Replicazione

11. Eventual consistency
●
Parametri default per gestire la replicazione:
–
Numero di repliche: nval (3)
–
Controlli sulla lettura/scrittura:
●
Sloppy check: r / w (quorum)
●
Primary check: pr / pw (0)
●
Durable check: dr / dw (quorum)
Immagine presa da:
http://highlyscalable.wordpress.com/2012/09/18/distributed-algorithms-in-nosql-databases/

12. Entropy
●
Inconsistenza in scrittura
–
–
●
last write wins (default)
allow multi (disabilitato)
Inconsistenza in lettura
–
(Passive/Active) Read repair

13. Scelta del backend
●
Bitcask (default)
●
LevelDB
●
Memory
●
Multi

14. Bitcask
Append only

15. Bitcask
●
Bassa latenza (Append only)
●
High throughhput
●
Backup agevolato
Attenzione a:
●
Uso della ram (chiavi in memoria)
●
Overheads sull'utilizzo del disco
●
Open files limit

16. Live demo

17. Gestione del cluster
●
Aggiornamento
●
Scalabilità: verticale vs orizzontale
●
Backup
●
Monitoraggio

18. Limiti
●
Limite nella dimensione degli oggetti
●
Gestione degli errori rivedibile
●
Fallimento a cascata
●
Occhio al tuning

19. Domande?

20. Riak Stack
http://littleriakbook.com

21. CAP Theorem
Immagine presa da:
http://www.w3resource.com/mongodb/nosql.php

22. Il “buon” vecchio metodo
●
Directories enormi
●
Ridondanza/partizionamento manuale
●
Sistema di ricerca improvvisato