Tokyo Cabinet

1 485 vues

Publié le

Présentation de Tokyo Cabinet.
(vieille...)

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 485
Sur SlideShare
0
Issues des intégrations
0
Intégrations
23
Actions
Partages
0
Téléchargements
8
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Tokyo Cabinet

    1. 1. Tokyo Cabinet Tokyo Cabinet est un moteur d’indexation crée par Mikio Hirabayashi. Mikio est le big boss de l’équipe de développement chez Mixi, le Facebook japonais, 3e site au Japon, juste derrière Google et Yahoo. Mikio est un cinglé des structures de données liées à l’indexation et de l’optimisation. À son actif : QDBM, DictD, Estraier, Hyper Estraier et Tokyo Cabinet. http://athlon64.fsij.org/~mikio/wikipedia/estseek.cgi
    2. 2. Un moteur d’indexation permet de mémoriser et de retrouver rapidement des données associées à des clefs. clef A - données A clef B - données B clef C - données C clef C - données C clef D - données A Oracle BerkeleyDB Amazon SimpleDB Memcache, Tugela Cache, MemcacheDB, Flared
    3. 3. Certains moteurs permettent un peu plus que la simple association de clefs à des données : •clefs et données sans tailles fixes, •clefs multiples, •transactions, •conformité ACID (y compris isolation), •curseurs, •intervalles, •choix de la fonction de comparaison, •réplication, •optimisés pour un environnement multi-threads.
    4. 4. Les moteurs dernier cri : COODBMS / Rolonics et Tokyo Cabinet. Tokyo Cabinet : •Performances excellentes, •API et documentation hyper complètes, •Code incroyablement propre et compréhensible, •Bibliothèque de fonctions utiles (listes chaînées, découpage d’URLs, requêtes HTTP, distance entre deux chaînes, calculs sur les dates, chaînes dynamiques...), •Développeur très réactif, •Support de Mixi et de la communauté.
    5. 5. Tokyo Cabinet : •Capable de prendre en charge des tables énormes (64 bits) •Tire profit du gestionnaire de mémoire virtuelle de l’OS •Format portable entre les architectures •Thread-safe •Aucun verrou nécessaire pour les recherches •API officielles pour les langages C, Perl, Ruby et Java. •API officieuses pour PHP et Python. •Les données sont toujours dans un état cohérent. •Cache pour les noeuds internes. •Le format est très compact et une compression supplémentaire peut être activée (deflate ou BWT).
    6. 6. Moteur “hash” •plusieurs enregistrements possibles pour une même clef, •insertion, remplacement, concaténation d’enregistrements, •déplacement d’enregistrements avant ou après n’importe quel enregistrement, •comptage rapide du nombre d’enregistrements pour une clef, •recherche inversée (données => clefs), •cache pour les enregistrements, •mises à jour synchrones ou asynchrones, •curseurs, •espace de stockage nécessaire : taille de la clef + taille de l’enregistrement + 16 octets
    7. 7. Moteur “B+Tree” •Plusieurs enregistrements possibles pour une même clef, •Insertion, remplacement, concaténation d’enregistrements, •Transactions, •L’ordre est préservé, •Insertion avant ou après n’importe quel enregistrement, •Recherches par intervalles (numériques ou sous-chaînes), •Curseurs •Espace de stockage nécessaire : taille de la clef + taille des données + 5 octets.
    8. 8. Moteur “memory” •Fonctions identiques au moteur “hash” •En mémoire uniquement, mais très rapide.
    9. 9. Benchs : Exactement la même séquence de clefs sur 40 bits. Ecriture de quelques millions de données de 157 octets. Mise à jour des même données avec 57 octets. Réécriture avec 257 octets. Lecture entre chaque étape.
    10. 10. “Hash”, 1 million d’enregistrements. Asynchrone : Ecriture : 300 000 enregistrements / seconde Réécriture : 80 000 enregistrements / seconde Lecture : 250 000 enregistrements / seconde Synchrone : Ecriture : 120 000 enregistrements / seconde Réécriture : 76 000 enregistrements / seconde Lecture : 250 000 enregistrements / seconde
    11. 11. “B+Tree”, 1 million d’enregistrements. Ecriture : 6 500 enregistrements / seconde Réécriture : 5 300 enregistrements / seconde Lecture : 9 800 enregistrements / seconde
    12. 12. “Memory”, 2 millions d’enregistrements. Enregistrement / modification des données : Memcache : 3,6 secondes, 3,3 secondes, 4, 2 secondes TC : 3,7 secondes, 3,1 secondes, 4,2 secondes TC2 : 3,5 secondes, 2,9 secondes, 3,9 secondes Consultation des données : Memcache : 8,2 secondes, 7,7 secondes, 8,9 secondes TC : 3,3 secondes, 3,2 secondes, 4,1 secondes TC2 : 3,0 secondes, 2,9 secondes, 3,4 secondes. Mémoire utilisée par Memcache : 1380 Mo Mémoire utilisée par TC : 580 Mo

    ×