HOT:Inserciones masivas en Sql Sersver vs Mongo DB ( III)

 
DESCARGO DE RESPONSABILIDAD

Antes de empezar la entrada me gustaría dejar claro que esto es un pasatiempos, una forma de dilucidar quien pagaba las cenas durante el tiempo que nos toco a los dos estar perdidos en una ciudad que no es la nuestra con nuestros respectivos trabajos. La idea de esta serie de blogs no es ver si queremos más a Papa o a Mama, a Sql Server o a una NoSQL. Los resultados que se obtengan no tienen porque hacer pensar que una es mejor que la otra ( sobre todo cuando son compatibles) y por supuesto el performance no es una(la única) razón de selección de una NoSQL como Mongo, escalabilidad, schema-free, base, last-update ni de un sistema transacciónl como Sql Serve. Si esto te queda claro y quieres jugar con nosotros, y por supuesto, aprender como lo hemos hecho nosotros, a forzar situaciones como la presente tanto de Sql Server como de Mongo entonces sigue leyendo…

 

La bala de la recamara….

 

Me voy a permitir adelantarme al post de Pablo Doval con sus conclusiones puesto que, este finde esta muy, pero que muy ocupado haciendo que el Sql Server de otro ande más rapido. Como había dicho, me preocupaba mucho el tema de mis bloqueos, puesto que o cambiaba de tercio o no tendría mucho margen de mejora. Pensando y pensando (algún comodín también) me puse a ver que podría hacer y recorde que con las Capped Collections de Mongo DB podría ganar algo, puesto que a la hora de crearlas podría especificar el espacio a ocupar y por lo tanto hacer un pequeño prefetch de la base de datos. En realidad, una colección capped no es más que una colección con un tamaño máximo dado y un número de documentos máximo. La definición exacta de las capped collections la tenéis en la siguiente frase:

 

Capped collections are fixed sized collections that have a very high performance auto-FIFO age-out feature (age out is based on insertion order). They are a bit like the "RRD" concept if you are familiar with thatç

Bueno, “high performance auto-FIFO”…. esto es lo que andaba buscando…. Vamos, además, a unirlo con un poco de paralelismo para ver si nos sorprendemos con los resultados que obtengamos. Para ello, lo primero que haremos será levantar nuestro servidor de mongodb con prácticamente las mismas opciones que en la entrada anterior, he incluido alguna más pero no han tenido demasiado efecto…

 

mongod  — dbpath c:mongodata

        — nohttpinterface

        — noauth

        — nojournal

        — quiet

        — verbose

        — diaglog

        — logpath log.txt

        — install

Ahora, modificaremos nuestro código para que se cree la colección a utilizar como una capped collection, fíjese que en esta creación hemos puesto ya tamaños máximos de documentos y espacio. Además también hemos realizado otra optimización al poner SetAutoIndex a false eliminando así la creación del índice  sobre _id por defecto.

 

El paralelismo es sencillo, basta con usar el magnífico API de TPL y agregar unas cuantas Task como se ve a continuación. Como seguramente muchos os preguntéis, he probado diferente número de hilos, y la verdad es que no he obtenido mejor, lo cual, me hace indicar que el problema no es de contención en el procesador, ni de uso, es ya un tema en MongoDB.

 

El código de Work es el siguiente  :

 

Venga, vamos a hacer la prueba…. [redoble de tambores…….] el resultado es …. 1,6 segundos, gracias a las capped collections y al prefetch del tamaño  y número de documentos he aumentado el rendimiento enormemente, de 3,5 a 1,6 segundos en insertar 500K documentos…

…….Sigo preocupado…..

 

Las malas lenguas me han dicho que pablo bajará ese tiempo…. y ya, lo único que se me ocurre es montar un sharding y no tengo muy claro que eso NO sea hacer TRAMPAS….

Nos leemos,

Unai

5 comentarios sobre “HOT:Inserciones masivas en Sql Sersver vs Mongo DB ( III)”

  1. Esto está de lo más entretenido.

    No tengo ni idea de mongodb y seguro que ya lo has probado pero, ¿no es muy pequeño el tamaño del batch? Me haría mucha ilusión que ganaras al Sql 😉

  2. En cualquier caso 1,6 segundos es increíble, solo la generación de la colección, la apertura y cierre de la conexión ya tomara gran parte de este tiempo.

    Un saludo.

Responder a kash Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *