La realizzazione di un software per l'automazione di un processo di lavoro ha portato all'implementazione di un sistema di storage in grado di gestire imponenti flussi di dati (raw data, immagini...). Il core del sistema di archiviazione e` il database NoSql Riak. A quasi un anno dall'entrata in produzione, tale configurazione si e` confermata robusta e performante (vengono acquisiti in modo ridondato centinaia di migliaia di files ogni mese, realizzando un archivio permanente in costante crescita dell'ordine di terabytes). Nel corso dell'intervento verranno mostrate le motivazioni che hanno portato a questa scelta. Oltre ad una rapida panoramica volta ad illustrare le funzionalita` di Riak si intende condividere in modo pratico il know-how acquisito ripercorrendo le problematiche riscontrate durante il setup, la configurazione e la gestione di un cluster Riak (ambienti di sviluppo e produzione, ottimizzazioni, deploy del cluster, backup, disaster recovery, ...).

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