Crogioli, alambicchi e beute
                                              Dove mettere i vostri dati




Simone Deponti (...
Il problema della persistenza
1.Problema fondamentale dell'informatica
2.Soluzione semplice: file
3.Soluzione complessa: s...
Cenni storici

    1960       1970    1980          2000




●COBOL     ●C          ●C++      ●Java
●CODASYL   ●RDBMS     ...
Gli sfidanti

     SQLAlchemy


     BigTable


     ZODB
SQLAlchemy: ORM e oltre
1.ORM: semplificano l'uso di SQL
  ●   No problemi compatibilità
  ●   Più sicurezza
2.Astrazione ...
SQLAlchemy: in azione
SQLAlchemy
        Forza                   Debolezze
1.Semplice               1.Programmazione
                           ...
SQLAlchemy: per chi
Potenza (e problemi) del relazionale
•


Ottimale se:
•


    •   Strutture dati definite
    •   Coll...
ZODB: Object DataBase
1.Object database: il ritorno del filesystem
2.Inserimento oggetti nativi Python
3.Le referenze veng...
ZODB: in azione
ZODB
      Forza                Debolezze
1.Dinamismo           1.“Listing cartella con
2. Programmazione       10000 file...
ZODB: per chi
1.Definizioni schemi labili
2.Necessità di componenti generici
3.Indicizzare non è un problema
4.Esempio
  ●...
BigTable: distribuito
1.Problema strutture fortemente distribuite
2.Simile a RDBMS
  ●   Concetto di record e colonna
3.Di...
BigTable: cosa
1.Matrice sparsa
  ●   Famiglie di colonne e colonne
  ●   Righe, inserimento non atomico su intera riga
2....
BigTable: con Python?
1.Hbase (BigTable classico) o Cassandra
  (BigTable + Dynamo)
2.Via Thrift
  ●   Generazione protoco...
BigTable: in azione
BigTable
       Forza                       Debolezze
1.Superscalabilità           1.API non intuitiva
2.Avaliability & Pa...
BigTable: per chi
1.Google, Facebook, Yahoo
2.Data mining su grandi moli
  ●   Map/Reduce
3.Dati spezzati in microelementi...
Conclusioni
1.Idee chiare: ORM + RDBMS
2.“robe”, “documenti”: OO-DB
3.Grandissime moli: BigTable
Per saperne di più
•   http://sqlalchemy.org/docs/
•   http://www.zodb.org
•   http://www.julianbrowne.com/article/viewer/...
Credits
1.Brueghel the Elder
2.Rob Word
3.http://www.flickr.com/photos/gilest/1
Upcoming SlideShare
Loading in...5
×

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

460

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
460
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×