Valor de rendimiento de las guías COMB

Question

Jimmy Nilsson habla sobre su concepto de GUI COMB here. Este concepto es popular en NHibernate, entre otros círculos, por su supuesto valor de rendimiento con respecto a los GUID estándar, que suelen ser mucho más aleatorios.

Sin embargo, en las pruebas, este no parece ser el caso. ¿Me estoy perdiendo de algo?

caso de prueba:

tengo una tabla llamada temperatura (no con una tabla temporal, sólo una tabla denominada "temp") con 585.000 filas en el mismo. Tengo una nueva tabla llamada Códigos, y deseo copiar los 585,000 valores de código de la tabla temporal a la tabla de códigos. La prueba de SQL ejecuté era:

set statistics time on; 

truncate table codes; 
DBCC DBREINDEX ('codes', '', 90); 

insert into codes (codeid, codevalue) 
select newid(), codevalue from temp 

truncate table codes; 
DBCC DBREINDEX ('codes', '', 90); 

insert into codes (codeid, codevalue) 
select CAST(CAST(NEWID() AS BINARY(10)) + CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER), codevalue from temp 

rendimiento con valores estándar GUID:

de ejecución de SQL Server tiempos: CPU tiempo = 17250 ms, tiempo transcurrido = 15735 ms.

(585000 fila (s) affected)

rendimiento con valores GUID COMB:

de ejecución de SQL Server tiempos: CPU tiempo = 17500 ms, tiempo transcurrido = 16419 ms.

(585000 fila (s) affected)

¿Qué me falta? los valores de COMB GUID dieron como resultado tiempos levemente más largos, presumiblemente debido a las conversiones adicionales. Pensé que el objetivo era reducir el tiempo de inserción al hacer un semi ordenamiento de los GUIDS utilizando la fecha de los últimos 6 bytes, pero la ganancia de rendimiento parece inexistente.

Answer 1

En segundo lugar, verá diferencias solo cuando tenga índices (PK, FK u otro tipo de índices, agrupados o no agrupados) en la columna de Guid, porque el costo del guid estándar contra el guíalos newguid o peine se debe a el alto costo de reordenar los datos del índice cada vez que se realiza una inserción.

Ver mi pregunta en la que corroborar esto con algunos datos de la vida real de SQL Server y Oracle: StackOverFlow Question

Saludos Massimo

Answer 2

Le sugiero que no vea el beneficio de la orden porque la tabla de destino no tiene PK. Entonces, es la sobrecarga de conversión que estás viendo. SI tiene un PK, las filas de 585k todavía se deben ordenar en la inserción. ¿Cómo sabe SQL que está semi-clasificado?

Ahora, si se trata de inserciones de fila 5,850 x 100, entonces puede ver algún beneficio porque las nuevas filas irán "al final" no "en el medio" para reducir las divisiones de página y sobrecarga.

Iría más lejos y diría que el artículo está fechado en 2002, y es para SQL 2000, y ha sido superado por la vida real.

En SQL Server 2005 tenemos GUÍAS SECUENCIALES para permitir GUID estrictamente monótona para resolver algunos problemas. El GUID como PK también se ha realizado aquí: ejemplo reciente: INT vs Unique-Identifier for ID field in database con enlaces de terceros.

Si un ORM dicta GUID como PK en lugar de una clave natural o clave sustituta estándar basada en int, esa es una limitación severa del ORM. Y un caso de la cola del cliente moviendo el perro de la base de datos.

Answer 3

Su código para generar nuevos GUID no es correcto. Para cada fila, está creando un número muy diferente (se llama a NEWID() para cada fila). Debe mantener la mayor parte del GUID igual.