Saltear al contenido principal

Uniqueidentifier vs Identity en el diseño de tablas – Parte 3

Momento de ver las diferencias en inserciones de registros. Como ya vimos en los primeros artículos de esta serie, el diseño de tablas puede impactar tanto en almacenamiento como en rendimiento para tus sistemas. Ahora bien, vamos a la evaluación final de estos escenarios.

No olvides los previos

Primero, son importantes los conceptos. Si no lo has hecho aún, es un buen momento para ver la Primera Parte de la serie Uniqueidentifier vs Identity.

Continuando con la serie, hemos evaluado el rendimiento en lecturas más complejas y con millones de registros en una Segunda Parte.

Ahora bien, vamos a ver qué sucede cuando queremos adicionar nuevos registros a nuestra tabla.

Insertando filas en nuestras tablas

Voy a seguir utilizando las dos tablas con las que he trabajado en el artículo anterior. Las que tienen un millón de registros cada una.

Quiero ver cuál es la reacción cuando insertamos un par de registros en las tablas.

Como puedes ver, las estructuras son iguales a las que hemos visto hasta ahora.

¿Qué resultados podemos ver?

diseño de tablas

Si bien los planes de ejecución se ven muy similares a excepción de un componente, el costo parece ser el mismo para ambos casos.

¿Y qué dicen las estadísticas?

Aquí sí podemos ver una diferencia mayor. La inserción en la tabla cuyo identificador de la tabla es un número entero con valor identity, tiene una evidente menor cantidad de lectura que la tabla con el uniqueidentifier.

¿Qué pasa en concurrencia?

¿Qué tal si tienes varios usuarios en tu sistema tratando de hacer estas inserciones?

Veamos qué sucede cuando simulamos la acción de varios usuarios tal como lo explicamos en el artículo Pruebas de estrés en SQL Server con oStress. (Es importante que veas este artículo para comprender lo que hago en el paso siguiente).

Simularé 20 usuarios concurrentes y cada uno con un ciclo de 1000 inserciones una a una. Las sentencias de la línea de comandos para oStress serían así:

ostress.exe -S.\sql19 -dBigTables -Q”INSERT INTO [dbo].[FakeTable_with_Identity] ([Name], [MiddleName], [Office], [Gender], [DayOfBirth], [DescriptionText]) VALUES (N’Kandace’, N’Suellen’, 180, 4, CAST(N’1980-01-01′ AS Date), N’Lorem ipsum ‘)” -n20 -r1000

ostress.exe -S.\sql19 -dBigTables -Q”INSERT INTO [dbo].[FakeTable_with_Uniqueidentifier] ([Name], [MiddleName], [Office], [Gender], [DayOfBirth], [DescriptionText]) VALUES (N’Kandace’, N’Suellen’, 180, 4, CAST(N’1980-01-01′ AS Date), N’Lorem ipsum ‘)” -n20 -r1000

Los resultados aquí sí son mucho más interesantes.

INSERT en la tabla con IDENTITY

Ejecutado en 23 segundos.

INSERT en la tabla con UNIQUEIDENTIFIER

Ejecutado en 5 minutos y 47 segundos.

Diseño de tablas con Identity o Uniqueidentifier

Viste tremenda diferencia de tiempos en la inserción de datos con el ejemplo de la concurrencia.

Al principio de este artículo viste esa sutil diferencia en la cantidad de lectura que tienen los dos casos.

Esto también es impactado por el índice clustered que tenemos creado en cada una de las tablas. Por teoría sabemos que los registros insertados deben estar ordenados en función al campo llave que hemos escogido. Por supuesto, en este caso, tenemos una llave Uniqueidentifier y otra Identity. Esta teoría la encuentras en la documentación oficial.

Has la prueba en tus escenarios y toma en cuenta todo lo que hemos visto en esta serie de publicaciones.

Pablo Javier Fernández

www.datoptim.com
I love working on SQL Server Performance Tuning and finding the origin of the problems. Music and SQL Server passionate.

Deja una respuesta

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

Close search

Carrito

Volver arriba