Surviving the Night - Todos los comentarios

[Windows Phone 7.5] Inserciones masivas en SQL Server CE vs SQL Server vs MongoDb

Josue Yeray — Sun, 11 Dec 2011 10:50:26 GMT

Hola a todos! Desde hace unas semanas, mis compañeros Pablo Doval y Unai Zorrilla están

[Windows Phone 7.5] Inserciones masivas en SQL Server CE vs SQL Server vs MongoDb

Josue Yeray — Thu, 08 Dec 2011 12:16:29 GMT

Hola a todos! Desde hace unas semanas, mis compañeros Pablo Doval y Unai Zorrilla están

re: Roar: Inserciones Masivas en MongoDB vs SQL Server (IV)

Luis M. González — Wed, 23 Nov 2011 13:56:52 GMT

Estoy siguiendo muy de cerca este pique y lo único que puedo decir es que ... me encanta :)

Y la verdad no me imaginaba que SQL Server pudiese plantar cara a MongoDB sin los BULK INSERTS, así que con los números actuales creo que es más que suficiente.

Saludos!

re: Roar: Inserciones Masivas en MongoDB vs SQL Server (IV)

Eduard Tomàs i Avellana — Wed, 23 Nov 2011 08:38:53 GMT

Estoy siguiendo la serie con mucho interés. Primero he de decir que no tenía claro que Sql Server sin Bulk insert pudiese competir tan de cara con MongoDb en este escenario.

Dicho esto, extraigo una conclusión: para conseguir 1,6 segundos en MongoDb Unai no ha tenido que hacer nada extraordinario, cualquiera con un poco de experiencia en MongoDb puede llegar a la solución de Unai (otra cosa es que se le ocurra :p). Por otro lado para conseguir 1,8 segundos en SQL Server se necesita... bueno, se necesita ser Pablo :P

Al menos me da a mi la sensación de que Pablo está manejando temas de SQL Server realmente avanzados! :D

Javier, estaría bien que publicases tus resultados así como el proceso que has seguido con Oracle, para poder comparar!

A menos, a primera vista,

re: Roar: Inserciones Masivas en MongoDB vs SQL Server (IV)

Javier Torrecilla — Wed, 23 Nov 2011 07:36:30 GMT

Simplemente increible los resultado que habeis obtenido con SQL y MONGO.

Yo hice una pequeña prueba con Oracle, y "mas o menos" conociendo las diferencias de hardware entre vuestras maquinas y la mia. Los resultados de Oracle dejaban mucho que desear.

Un saludo y a la espera de ver los últimos post!

re: Roar: Inserciones Masivas en MongoDB vs SQL Server (IV)

Pablo Alvarez — Tue, 22 Nov 2011 23:11:00 GMT

¿¡Que tal Juan?! Tranquilo, yo tampoco lo hubiera pensado :) Coincidio que poco antes del reto leí un par de entradas del señor Kejser, asi como un par de videos suyos del SQLBits, y eso fue lo que me dio la idea.

La verdad es que tanto los tiempos de preparacion de sentencia, como de gestion de conexiones, son aun minimos. Ahora nos encontramos con dos esperas principales del lado de SQL Server: SOS_SCHEDULER_YIELD y WRITELOG. La segunda sabeis que no puedo combatirla, ya que solo podria mejorarlo con BULK INSERTS. La primera... estate atento a la siguiente entrada, pero no vas desencaminado con el tema de la afinidad ;)

Respecto al priority boost, esto solo incrementa la prioridad del proceso de SQL Server; puede ayudar a evitar que otros procesos nos 'roben' memoria, etc.. pero no debiera hacer que esto fuera mas rapido.

Un abrazote!!

re: Roar: Inserciones Masivas en MongoDB vs SQL Server (IV)

Juan Irigoyen — Tue, 22 Nov 2011 20:41:57 GMT

Impresionante, particionar la tabla, nunca lo hubiera pensado, quizás una prueba más lógica pase por aumentar los registros 1,8 segundos es tan poco que seguramente los tiempos de conexión y desconexión sumados a los de la preparación de la sentencia se lleven la mayoría. Una opción que no has comentado y que en excenarios así puede tener sentido es la activación de boost SQL Server priority y probar a habilitar y deshabilitar processor affinity e I/O affinity, quizas nos llevemos alguna sorpresa, algunas veces los programas que hacen uso de varios hilos pueden llegar a ser mas lentos.

Un saludo.

Roar: Inserciones Masivas en MongoDB vs SQL Server (IV)

Surviving the Night — Tue, 22 Nov 2011 19:23:22 GMT

Me alegra comprobar que, al parecer, el pequeño reto que nos traemos Unai y yo está provocando cierto

Roar: Inserciones Masivas en MongoDB vs SQL Server (IV)

Surviving the Night — Tue, 22 Nov 2011 19:23:20 GMT

Me alegra comprobar que, al parecer, el pequeño reto que nos traemos Unai y yo está provocando cierto

re: Hot: Inserciones Masivas en MongoDB vs SQL Server

Juan Irigoyen — Sat, 19 Nov 2011 00:05:58 GMT

Un par de ideas para mejorar, la primera la utilización de las common table expresión para optimizar la sentencia insert y evitar bloqueos,

msdn.microsoft.com/.../ms175972(v=sql.90).aspx, otra podría ser la utilización de un store procedure en lugar de enviar la sentencia directamente, me gustaria saber la razón del porque llegasteis al acuerdo de no utilizar las bulk insert. ¿ se supone que en MongoDB tampoco se han realizado concesiones, o si... ?

Un saludo.

HOT:Inserciones Masivas en MongoDB vs Sql Server (II)

O bruxo mobile — Fri, 18 Nov 2011 10:36:41 GMT

DESCARGO DE RESPONSABILIDAD Antes de empezar la entrada me gustaría dejar claro que esto es un pasatiempos

re: Hot: Inserciones Masivas en MongoDB vs SQL Server

Juanma — Fri, 18 Nov 2011 08:29:43 GMT

"- Una sentencia SQL (o un batch) es una tarea unica que, a no ser que involure paralelismo intra-query, esta atada a la CPU (scheduler) donde se inicio."

Vale, eso me aclara todo. Pensé que a lo mejor enviando 100 inserts del tirón en lugar de 1 insert con 100 values SQL hacía algo, pero tiene sentido que no lo haga. Analizar el batch para saber si hay dependencia en el orden de ejecución sería bastante complicado para SQL (y para cualquiera), sobre todo si tiene que tener en cuenta la posibilidad de triggers y otros efecto colaterales.

Otra idea, si mantuvieras la inserción que realiza cada hebra en una misma transacción, ¿se ahorraría tiempo al acceder sólo una vez al transaction log? Entiendo que al hacer las inserciones de 1000 en 1000 se reduce mucho el acceso, pero no sé si todavía sigue pesando (lo siento pero no tengo mucha idea de esto y no sé interpretar bien las capturas de pantallas que hay en el post).

re: Hot: Inserciones Masivas en MongoDB vs SQL Server

Pablo Alvarez — Thu, 17 Nov 2011 21:22:31 GMT

¡Gracias a todos! Estos días voy a estar muy liado, pero ya estoy deseando sacar un rato para escribir la siguiente parte del artículo, en la que os voy a tratar de explicar un truco muy interesante :)

@Juanma: ¡Genial tu pregunta! Voy a ver si me puedo explicar en poco espacio y en poco tiempo :) SQL Server es capaz de forzar el paralelismo intra-query (es decir, que una única consulta utilize mútliples procesadores) pero solo lo hace a partir de un coste, que podemos definir con la opcion de servidor 'cost threshold for parallelism'.

El asunto está en que ésta consulta es tan sencilla (una insert sin más) que por mucho que quiera, el coste es mínimo y, por tanto, no involucrará el paralelismo intra-query.

En este caso concreto he usado paralelismo desde el servidor para aumentar la carga de trabajo. ¿Por que? Pues porque como habíamos visto en las esperas, el cuello de botella NO esta en la CPU. Cada conexión está lanzando un batch de unas mil filas, y vemos que las esperas están en el evento de tipo LOGWRITER (escritura en el log de transacciones) y en PAGELATCH_EX.

Sabiendo que tengo mas 'CPU' disponible, jugue a meterle mas sentencias... de este modo aumento el paralelismo por concurrencia (que no el paralelismo intra-query) y trato de aprovechar un poco mas los procesadores.

A modo de resumen:

- Una sentencia SQL (o un batch) es una tarea unica que, a no ser que involure paralelismo intra-query, esta atada a la CPU (scheduler) donde se inicio.

- Estos batches empeizan a ejecutarse n el CPU pero cada poco salen de la CPU y se ponen a esperar por disco. Mientras, la CPU esta desocupada.

- Si tengo 4 CPUs y solo 4 hilos, es posible que este en algun momento las CPUs paradas, mientras los hilos estan esperando por disco. Si tuviera mas hilos, seguramente podria maximizarse el uso de CPU.

- Por este ultimo punto decidi ir aumentando las conexiones (Tareas en SQL Server) para que haya mas tareas en cada scheduler (CPU) y, por tanto, minimizar el tiempo ocioso de las CPUs.

El como resolver la contencion de disco, o reducirla, será de lo que hablaremos en la próxima entrada :)

Espero haberme explicado! un saludo!!

re: Hot: Inserciones Masivas en MongoDB vs SQL Server

Juanma — Thu, 17 Nov 2011 19:57:31 GMT

Muy bueno el artículo.

Viendo que eres todo un experto en la materia, te planteo una duda, ¿hay alguna forma de que el paralelismo lo introduzca el sql server en lugar de hacerlo desde la aplicación cliente?

Por ejemplo, no sé si enviando los inserts como un batch (en lugar de usar distintas conexiones) el sql es lo bastante listo como para aprovechar sus fibers y paralelizarlos.

re: Hot: Inserciones Masivas en MongoDB vs SQL Server

El Bruno — Thu, 17 Nov 2011 19:25:32 GMT

Genial !!! ^^

re: Hot: Inserciones Masivas en MongoDB vs SQL Server

Juan Irigoyen — Thu, 17 Nov 2011 13:02:50 GMT

Excelente!!!!, creo que muchos esperan que Unai muerda el polvo... :)

re: Hot: Inserciones Masivas en MongoDB vs SQL Server

Juan Carlos González Martín — Thu, 17 Nov 2011 06:49:55 GMT

Joder,

Buenísimo el post...ahora falta ver la réplica de Unai :P

Un abrazo crack

men's style and fashion

eleniberdetle — Tue, 21 Jun 2011 13:06:12 GMT

full figure fashion doll vinyl thefashionhouse.us/men-page30.html g and tall man fashion 18972

re: Forget Me Not: Análisis de Volcados de Memoria en SQL Server

Pablo Carballude — Tue, 02 Nov 2010 20:00:04 GMT

Oh dios, Tim Minchin que grande. Siempre se acaban las entradas antes de que logre hacerme con una :(

re: Tell Me Where To Go: Estudio de Consultas AdHoc en SQL Server

pregunton cojonero — Thu, 26 Aug 2010 12:41:53 GMT

un post de cómo generar un volcado programáticamente en c# estaría muy bien !!!