Pourquoi le tyran tokyo ralentit-il exponentiellement même après avoir ajusté bnum?

Question

Est-ce que quelqu'un a utilisé avec succès Tokyo Cabinet/Tokyo Tyrant avec de grands ensembles de données? J'essaye de télécharger un sous-graphique de la source de données de Wikipedia. Après avoir touché environ 30 millions d'enregistrements, je ralentis exponentiellement. Cela se produit avec les bases de données HDB et BDB. J'ai ajusté bnum à 2-4x le nombre attendu d'enregistrements pour le cas HDB avec seulement une légère accélération. J'ai également mis xmsiz à 1GB ou plus mais finalement je frappe toujours un mur.

Il semble que Tokyo Tyrant est fondamentalement une base de données en mémoire et après avoir dépassé le xmsiz ou votre RAM, vous obtenez une base de données à peine utilisable. Est-ce que quelqu'un d'autre a déjà rencontré ce problème? Avez-vous pu le résoudre?

Answer 1

Je pense que je l'ai craqué celui-ci, et je n'ai pas vu cette solution nulle part ailleurs. Sous Linux, il y a généralement deux raisons pour lesquelles Tokyo commence à ralentir. Passons par les coupables habituels. Tout d'abord, si vous définissez votre bnum trop bas, vous voulez qu'il soit au moins égal à la moitié du nombre d'éléments dans le hachage. (De préférence plus.) Deuxièmement, vous voulez essayer de définir votre xmsiz pour être proche de la taille du tableau de baquets. Pour obtenir la taille du tableau de seau, il suffit de créer un db vide avec le bnum correct et Tokyo va initialiser le fichier à la taille appropriée. (Par exemple, bnum = 200000000 est d'environ 1,5 Go pour un db vide.)

Mais maintenant, vous remarquerez qu'il ralentit encore, bien qu'un peu plus loin. Nous avons trouvé que l'astuce consistait à désactiver la journalisation dans le système de fichiers - pour une raison quelconque, le journalisation (sur ext3) augmente la taille de votre fichier de hachage au-delà de 2-3Go. (Pour ce qui est de Linux, il suffit de démonter et de remonter votre partition ext3 en tant qu'ext2. Construisez votre db, et remontez comme ext3. Lorsque la journalisation était désactivée, nous pouvions créer des db de taille de 180 Mo sans problème.

Answer 2

Je commence à travailler sur une solution pour ajouter du sharding au cabinet tokyo appelé Shardy.

http://github.com/cardmagic/shardy/tree/master

Answer 3

La boutique de valeurs-clés de Tokyo est vraiment bonne. Je pense que les gens l'appellent lent parce qu'ils utilisent le magasin ressemblant à une table de Tokyo.

Si vous souhaitez stocker des données de document, utilisez mongodb ou un autre moteur nosql.

Answer 4

Tokyo balance merveilleusement !! Mais vous devez définir votre bnum et xmsiz de manière appropriée. bnum devrait être de 0,025 à 4 fois plus grand que les enregistrements que vous avez l'intention de stocker. xmsiz doit correspondre à la taille de BNUM. Définissez également opts = l si vous prévoyez de stocker plus de 2 Go.

Voir le message de Greg Fodor ci-dessus à propos de la valeur de xmsiz. Veillez à noter que lors de la définition de xmsiz, la valeur est en octets. Enfin, si vous utilisez un hachage sur disque, il est très, très, TRÈS important de désactiver la journalisation sur le système de fichiers sur lequel les données de tokyo survivent. C'est vrai pour Linux, Mac OSX et probablement Windows, même si je ne l'ai pas encore testé.

Si la journalisation est activée, vous constaterez de graves baisses de performances à l'approche de plus de 30 millions de lignes. Avec la journalisation désactivée et d'autres options correctement définies Tokyo est un excellent outil.