Il documento discute la persistenza dei dati nell'informatica e presenta vari sistemi di storage, inclusi ORM come SQLAlchemy, database object-oriented come ZODB e soluzioni distribuite come Bigtable. Vengono esplorate le rispettive caratteristiche, potenzialità e limiti di ciascun sistema, insieme a raccomandazioni per il loro utilizzo in base ai requisiti specifici. La conclusione evidenzia la combinazione di ORM e RDBMS per casi d'uso comuni e propone OO-DB e Bigtable per esigenze di gestione documentale e grandi volumi di dati.

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