MySQL: ¿Alguien ha usado el motor de almacenamiento TokuDB?

¿Alguien ha usado el TokuDB storage engine para MySQL?MySQL: ¿Alguien ha usado el motor de almacenamiento TokuDB?

El sitio web del producto afirma tener un aumento del rendimiento de 50 veces sobre otros motores de almacenamiento MySQL (por ejemplo, Innodb, MyISAM, etc.). Aquí están las declaraciones de rendimiento http://tokutek.com/downloads/tokudb-performance-brief.pdf

¿Es esto cierto?

¿Alguna experiencia personal con este motor de almacenamiento en uso con MySQL?

Fuente

2009-11-17 Timmyboy

Tengo la misma pregunta. Me pareció una comparación bastante decente de tokudb contra innodb

http://www.pythian.com/news/5139/testing-tokudb-faster-and-smaller-for-large-tables/

Sin embargo, estoy interesado en cualesquiera otras experiencias que otros pueden haber tenido con tokudb o cualquier otro motor de almacenamiento similar para MySQL.

Otra revisión aquí http://www.mysqlperformanceblog.com/2009/04/28/detailed-review-of-tokutek-storage-engine/

Fuente

2010-05-05 15:28:10

Si va a guardar manchas tales como imágenes no utilice tokudb. Tiene un límite de tamaño de fila más pequeño.

Si tiene datos de más de 100 millones de filas, use tokudb.

Si eres sensible a la velocidad de ACTUALIZACIÓN, no uses tokudb. Tiene una inserción muy rápida pero, en comparación con innodb, una velocidad de ACTUALIZACIÓN más lenta y especialmente si usa instrucciones INSERT ON DUPLICATE.

Si está almacenando entradas de registro, use tokudb.

Si desea reducir el uso de datos de myisam/innnodb en más de 5x, utilice tokudb. Personalmente, he confirmado que su backend de datos de árbol fractal + compresión es extremadamente eficiente en el uso del espacio.

Regla de oro, utilice la mejor herramienta para el trabajo. Tokudb saca a innodb y myisam de las aguas en situaciones específicas, pero no es un motor db de reemplazo general para todo lo que está debajo del cielo.

Fuente

2011-04-11 05:05:49 Xing

Totalmente de acuerdo. Tenemos tres bases de datos: dos alrededor de 1.5TB y una de 40GB. Hemos trasladado los dos grandes a TokuDB y nos hemos quedado maravillados: estamos viendo más de 15k consultas por segundo (la mitad de las cuales son inserciones/actualizaciones) en hardware bastante común. Agregue mantenimiento de esquema en línea (adición/reducción de columnas, creación/reducción de índices) y ha sido fenomenal. Dicho esto, @Xing tiene razón al usar la herramienta correcta para el trabajo: dejamos el db más pequeño en InnoDB, ya que hemos encontrado que tiene mejor rendimiento para cargas de trabajo más pequeñas. Hemos estado ejecutando TokuDB duro en producción durante 6 meses, y no tuvimos ningún problema. –

Aunque TokuDB es lento en ACTUALIZAR como se comentó anteriormente, es extremadamente rápido en REEMPLAZAR. Por lo general, puede sustituir UPDATEs con REPLACE INTO. Utilizo TokuDB en tablas de hasta 18 mil millones de filas y nada más se acerca, es al menos 100 veces más rápido que innodb para inserciones aleatorias en tablas grandes.

Fuente

2011-04-17 04:46:26 chris14679

¿Qué tal las selecciones? –

Un reemplazo al por mayor de ACTUALIZACIONES CON REPLACE INTOS casi con toda seguridad romperá su base de datos. Si al REEMPLAZO INTO le faltan algunas columnas, ¡se restablecerá a su valor predeterminado! Imagínese si su tabla tiene una columna de recuento de referencia que necesita conservar su valor: el REEMPLAZAR INTO lo establecerá de nuevo en cero. ¡AUGE! – DroidOS

MySQL: ¿Alguien ha usado el motor de almacenamiento TokuDB?

Respuesta

Cuestiones relacionadas