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

  • 410 views
Uploaded on

Simone Deponti

Simone Deponti

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
410
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
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. Crogioli, alambicchi e beute Dove mettere i vostri dati Simone Deponti (simone.deponti@abstract.it)
  • 2. Il problema della persistenza 1.Problema fondamentale dell'informatica 2.Soluzione semplice: file 3.Soluzione complessa: sistemi di storage
  • 3. Cenni storici 1960 1970 1980 2000 ●COBOL ●C ●C++ ●Java ●CODASYL ●RDBMS ●OO-DB ●NoSQL
  • 4. Gli sfidanti SQLAlchemy BigTable ZODB
  • 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. SQLAlchemy: in azione
  • 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. SQLAlchemy: per chi Potenza (e problemi) del relazionale • Ottimale se: • • Strutture dati definite • Collezioni omogenee • Forte tipizzazione del dato ~ 99% casi applicativi •
  • 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. ZODB: in azione
  • 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. ZODB: per chi 1.Definizioni schemi labili 2.Necessità di componenti generici 3.Indicizzare non è un problema 4.Esempio ● Content Management System
  • 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. 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. 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. BigTable: in azione
  • 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. 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. Conclusioni 1.Idee chiare: ORM + RDBMS 2.“robe”, “documenti”: OO-DB 3.Grandissime moli: BigTable
  • 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. Credits 1.Brueghel the Elder 2.Rob Word 3.http://www.flickr.com/photos/gilest/1