Wartość wydajności komunikatów COMB

Question

Jimmy Nilsson omawia swoją koncepcję przewodnika COMB here. Ta koncepcja jest popularna w NHibernate, wśród innych kręgów, ze względu na jego rzekomą wartość wydajności w stosunku do standardowych identyfikatorów GUID, które są zazwyczaj znacznie bardziej losowe.

Jednak w teście nie wydaje się, aby tak się stało. Czy czegoś brakuje?

przypadek testowy:

Mam tabeli o nazwie temp (nie temp tabeli, tylko tabelę o nazwie „temp”) z 585.000 wierszy w nim. Mam nową tabelę o nazwie Kody i chcę skopiować wszystkie 585,000 wartości kodu z tabeli tymczasowej do tabeli kodów. Badanie realizowane było SQL I:

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 

wydajność przy standardowych wartości GUID:

SQL Server Execution Times: CPU czas = 17250 ms, czas, jaki upłynął = 15735 ms.

(585000 row (s) affected)

Wyniki z wartościami GUID grzebień:

SQL Server Execution Times: CPU czas = 17500 ms, czas, jaki upłynął = 16419 ms.

(585000 row (s) affected)

Czego mi brakuje? wartości GUID COMB były nieco dłuższe, prawdopodobnie z powodu dodatkowych konwersji. Pomyślałem, że chodzi o to, by skrócić czas wstawiania przez pół-porządkowanie GUIDS, używając daty dla ostatnich 6 bajtów, ale przyrost wydajności wydaje się nie istnieć.

Answer 1

Po drugie, różnice będą widoczne tylko w przypadku indeksów (PK, FK lub innego rodzaju indeksów, klastrowanych lub nie klastrowanych) w kolumnie Guid, ponieważ koszt standardowego guid versus newguid lub comb guid wynika z wysoki koszt ponownego uporządkowania danych indeksu za każdym razem, gdy wykonywana jest wstawka.

Zobacz moje pytanie, w którym potwierdzają to dane z prawdziwych życiowych zarówno z SQL Server i Oracle: StackOverFlow Question

Pozdrawiam Massimo

Answer 2

Zasugeruję, że nie widzisz korzyści z zamówienia, ponieważ tabela docelowa nie ma PK. A więc widzisz, jak dużo konwersji. JEŻELI ma PK, 585k wierszy musi być nadal posortowane na insert. W jaki sposób SQL wie, że jest on częściowo posortowany?

Teraz, jeśli było to 5,850 x 100 rzędów wstawek, możesz zauważyć pewną korzyść, ponieważ nowe wiersze zostaną "na końcu", a nie "w środku", co zmniejszy podziały strony i narzut.

Chciałbym pójść dalej i powiedzieć, że artykuł jest datowany na rok 2002, i jest dla SQL 2000, i został wyprzedzony przez prawdziwe życie.

W SQL Server 2005 mamy SEQUENTIAL GUID, aby umożliwić ściśle monotoniczne identyfikatory GUID do rozwiązywania niektórych problemów. Identyfikator GUID jako PK również został tutaj zrobiony: ostatni przykład: INT vs Unique-Identifier for ID field in database z linkami do stron trzecich.

Jeśli ORM dyktuje GUID jako PK, zamiast klucza naturalnego lub standardowego klucza zastępczego opartego na int, jest to poważne ograniczenie ORM. I przypadek klienta goniącego psa bazy danych.

Answer 3

Twój kod do generowania nowych identyfikatorów GUID jest nieprawidłowy. Dla każdego wiersza jest tworzony bardzo różny numer (wywołujesz NEWID() dla każdego wiersza). Musisz zachować większość GUID tak samo.