¿Por qué el tirano tokio se ralentiza exponencialmente incluso después de ajustar bnum?

Question

¿Alguien ha utilizado con éxito el Tokyo Cabinet/Tokyo Tyrant con grandes conjuntos de datos? Estoy tratando de subir un subgrafo del origen de datos de Wikipedia. Después de alcanzar unos 30 millones de registros, recibo una ralentización exponencial. Esto ocurre con las bases de datos HDB y BDB. Ajusté bnum a 2-4x el número esperado de registros para el caso HDB con solo una ligera aceleración. También configuré xmsiz a 1GB más o menos pero al final todavía golpeo una pared.

Parece que Tokio Tirano es básicamente una base de datos en la memoria y después de superarse el xmsiz o la memoria RAM, se obtiene una base de datos apenas utilizable. ¿Alguien más ha tenido este problema antes? ¿Pudiste resolverlo?

Answer 1

creo que puede haber agrietado éste, y no he visto esta solución en otro sitio. En Linux, generalmente hay dos razones por las que Tokio comienza a desacelerarse. Pasemos por los culpables habituales. Primero, si configuras tu bnum demasiado bajo, quieres que sea al menos igual a la mitad de la cantidad de elementos en el hash. (Preferiblemente más.) En segundo lugar, desea intentar configurar su xmsiz para que se acerque al tamaño de la matriz de cubetas. Para obtener el tamaño del conjunto de cubetas, solo cree un db vacío con el bnum correcto y Tokio inicializará el archivo al tamaño apropiado. (Por ejemplo, bnum = 200000000 es aproximadamente 1.5GB para un db vacío.)

Pero ahora, notará que todavía se ralentiza, aunque un poco más adelante. Descubrimos que el truco consistía en desactivar el periodismo en el sistema de archivos; por alguna razón, el journalling (en ext3) aumenta a medida que su tamaño de archivo hash crece más allá de 2-3GB. (La forma en que nos dimos cuenta de que esto era picos en E/S que no correspondían a los cambios del archivo en el disco, junto con las explosiones de la CPU daemon de kjournald)

Para Linux, simplemente desmontar y volver a montar su partición ext3 como ext2. Construye tu db, y vuelve a montar como ext3. Cuando se inhabilitó la creación de diarios, pudimos construir db de tamaño de clave de 180M sin ningún problema.

Answer 2

estoy empezando a trabajar en una solución para agregar sharding al gabinete de Tokio llamado Shardy.

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

Answer 3

La tienda de valores-clave de Tokyo Cabinet es realmente buena. Creo que la gente lo llama lento porque usan la tienda de mesa de Tokyo Cabinet.

Si desea almacenar datos de documentos, use mongodb u otro motor nosql.

Answer 4

escamas de Tokio maravillosamente !! Pero debes establecer tu bnum y xmsiz de manera apropiada. bnum debe ser .025 a 4 veces mayor que los registros que planea almacenar. xmsiz debe coincidir con el tamaño de BNUM. También configure opts = l si planea almacenar más de 2GB.

Consulte la publicación anterior de Greg Fodor sobre cómo obtener el valor para el tamaño de xmsiz. Tenga cuidado al observar que al establecer xmsiz el valor está en bytes.

Por último, si usted está usando un hash basado en disco es muy, muy, muy importante para apagar diario en el sistema de archivos que los datos Tokio sigue vivo. Esto es cierto para Linux, Mac OSX y probablemente para Windows, aunque aún no lo he probado allí.

Si el diario se enciende verá caídas graves en el rendimiento cuando se aproxima a más de 30 millones de filas. Con el diario desactivado y otras opciones configuradas apropiadamente, Tokio es una gran herramienta.