Crogioli, alambicchi e beute: dove mettere i vostri dati.
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

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

on

  • 642 views

Simone Deponti

Simone Deponti

Statistics

Views

Total Views
642
Views on SlideShare
642
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Crogioli, alambicchi e beute: dove mettere i vostri dati. Presentation 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