Crogioli, alambicchi e beute: dove mettere i vostri dati.

698 views

Published on

Simone Deponti

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
698
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Crogioli, alambicchi e beute: dove mettere i vostri dati.

  1. 1. Crogioli, alambicchi e beute Dove mettere i vostri dati Simone Deponti (simone.deponti@abstract.it)
  2. 2. Il problema della persistenza 1.Problema fondamentale dell'informatica 2.Soluzione semplice: file 3.Soluzione complessa: sistemi di storage
  3. 3. Cenni storici 1960 1970 1980 2000 ●COBOL ●C ●C++ ●Java ●CODASYL ●RDBMS ●OO-DB ●NoSQL
  4. 4. Gli sfidanti SQLAlchemy BigTable ZODB
  5. 5. SQLAlchemy: ORM e oltre 1.ORM: semplificano l'uso di SQL ● No problemi compatibilità ● Più sicurezza 2.Astrazione RDBMS ● Compensazione feature 3.Non solo tabelle ● Mappa oggetti su espressioni
  6. 6. SQLAlchemy: in azione
  7. 7. SQLAlchemy Forza Debolezze 1.Semplice 1.Programmazione generica difficile ● API “scala” bene 2.Veloce 2.Difficile con ● Come sviluppo ● Definizioni schemi labili ● Come prestazioni ● Strutture gerarchiche 3.Flessibile 3.Scalabilità ● Normalizzazione ● Verticalizzazione
  8. 8. SQLAlchemy: per chi Potenza (e problemi) del relazionale • Ottimale se: • • Strutture dati definite • Collezioni omogenee • Forte tipizzazione del dato ~ 99% casi applicativi •
  9. 9. ZODB: Object DataBase 1.Object database: il ritorno del filesystem 2.Inserimento oggetti nativi Python 3.Le referenze vengono registrate 4.Dinamico 5.Pickling
  10. 10. ZODB: in azione
  11. 11. ZODB Forza Debolezze 1.Dinamismo 1.“Listing cartella con 2. Programmazione 10000 files” generica e 2.No index, no search introspezione 3.Scalabilità 3.Collezioni “differente” eterogenee 4.API trasparente
  12. 12. ZODB: per chi 1.Definizioni schemi labili 2.Necessità di componenti generici 3.Indicizzare non è un problema 4.Esempio ● Content Management System
  13. 13. BigTable: distribuito 1.Problema strutture fortemente distribuite 2.Simile a RDBMS ● Concetto di record e colonna 3.Differente da RDBMS ● Famiglie di colonne 4.CAP Theorem ● Consistenza “a latere”
  14. 14. BigTable: cosa 1.Matrice sparsa ● Famiglie di colonne e colonne ● Righe, inserimento non atomico su intera riga 2.Matrice 3D ● (Id riga, Id colonna, timestamp) → valore 3.Matrice 4D ● Solo Cassandra
  15. 15. BigTable: con Python? 1.Hbase (BigTable classico) o Cassandra (BigTable + Dynamo) 2.Via Thrift ● Generazione protocolli binari multilinguaggio 3.Molto diverso da concetti base presenti
  16. 16. BigTable: in azione
  17. 17. BigTable Forza Debolezze 1.Superscalabilità 1.API non intuitiva 2.Avaliability & Partition 2.Delega consistenza tolerance ● Fa del proprio meglio, 3.Buon dinamismo non garantisce 3.Sforzo sviluppo applicativo ● Tablet e località
  18. 18. BigTable: per chi 1.Google, Facebook, Yahoo 2.Data mining su grandi moli ● Map/Reduce 3.Dati spezzati in microelementi 4.Necessità di distribuire aggressivamente
  19. 19. Conclusioni 1.Idee chiare: ORM + RDBMS 2.“robe”, “documenti”: OO-DB 3.Grandissime moli: BigTable
  20. 20. Per saperne di più • http://sqlalchemy.org/docs/ • http://www.zodb.org • http://www.julianbrowne.com/article/viewer/bre wers-cap-theorem • http://wiki.apache.org/cassandra/DataModel • http://github.com/digg/lazyboy
  21. 21. Credits 1.Brueghel the Elder 2.Rob Word 3.http://www.flickr.com/photos/gilest/1

×