Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud storage in azienda: perche` Riak ci e` piaciuto

740 views

Published on

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, ...).

Published in: Technology
  • Be the first to comment

Cloud storage in azienda: perche` Riak ci e` piaciuto

  1. 1. Cloud storage in azienda: perchè riak ci è piaciuto Alberto Eusebi alberto@biodec.com Biodec Srl http://www.biodec.com
  2. 2. Il problema ● Flusso di dati: 100.000/mese ● Archiviare ● Dimensione media: 300KB ● Versionare ● In rapida crescita ● Query system
  3. 3. Idee? ● Storage basato su db SQL ● Storage su filesystem (metadati su SQL) ● Dati su NoSql (metadati su SQL)
  4. 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. 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. 6. Anti-outline ● Map-reduce ● Strutture dati specifiche: – – Key indexing (2i) – ● Full text search (tagging) Link walking Gestione avanzata di conflitti (vector clocks)
  7. 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. 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. 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. 10. Replicazione
  11. 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. 12. Entropy ● Inconsistenza in scrittura – – ● last write wins (default) allow multi (disabilitato) Inconsistenza in lettura – (Passive/Active) Read repair
  13. 13. Scelta del backend ● Bitcask (default) ● LevelDB ● Memory ● Multi
  14. 14. Bitcask Append only
  15. 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. 16. Live demo
  17. 17. Gestione del cluster ● Aggiornamento ● Scalabilità: verticale vs orizzontale ● Backup ● Monitoraggio
  18. 18. Limiti ● Limite nella dimensione degli oggetti ● Gestione degli errori rivedibile ● Fallimento a cascata ● Occhio al tuning
  19. 19. Domande?
  20. 20. Riak Stack http://littleriakbook.com
  21. 21. CAP Theorem Immagine presa da: http://www.w3resource.com/mongodb/nosql.php
  22. 22. Il “buon” vecchio metodo ● Directories enormi ● Ridondanza/partizionamento manuale ● Sistema di ricerca improvvisato

×