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

  • 282 views
Uploaded on

La realizzazione di un software per l'automazione di un processo di …

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

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
282
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
7
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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