Leistungswert der COMB-Guides

Question

Jimmy Nilsson erläutert sein COMB-Guid-Konzept here. Dieses Konzept ist in NHibernate unter anderem wegen seines angenommenen Leistungswerts gegenüber Standard-GUIDs beliebt, die typischerweise viel zufälliger sind.

Im Test scheint dies jedoch nicht der Fall zu sein. Fehle ich etwas?

Testfall:

Ich habe eine Tabelle mit dem Namen Temp (nicht eine temporäre Tabelle, nur eine Tabelle mit dem Namen „temp“) mit 585.000 Zeilen drin. Ich habe eine neue Tabelle namens Codes und möchte alle 585.000 Codewerte aus der temporären Tabelle in die Codetabelle kopieren. Der Test SQL I ausgeführt wurde:

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 

Leistung mit Standard-GUID-Werte:

SQL Server-Ausführungszeiten: CPU Zeit = 17250 ms, verstrichene Zeit = 15735 ms.

(585000 Zeile (n) betroffen)

Leistung mit Werten KAMM GUID:

SQL Server-Ausführungszeiten: CPU Zeit = 17500 ms, verstrichene Zeit = 16419 ms.

(585000 Zeile (n) betroffen)

Was bin ich? Die COMB-GUID-Werte führten zu etwas längeren Zeiten, vermutlich aufgrund der zusätzlichen Konvertierungen. Ich dachte, der Punkt wäre, die Einfügezeit zu reduzieren, indem man die GUIDS mit dem Datum für die letzten 6 Bytes halb anordnet, aber die Leistungssteigerung scheint nicht vorhanden zu sein.

Answer 1

Ich zweitens, dass Sie Unterschiede nur sehen, wenn Sie Indizes (PK, FK oder andere Arten von Indizes, gruppiert oder nicht gruppiert) auf der Guid-Spalte haben, weil die Kosten von Standard-GUID versus Neuguid oder Kamm Guid ist die hohen Kosten der Neuordnung der Indexdaten jedes Mal, wenn eine Einfügung durchgeführt wird.

Siehe meine Frage, in denen ich diese mit einigen wirklichen Leben Daten sowohl von SQL Server und Oracle untermauern: StackOverFlow Question

Grüße Massimo

Answer 2

Ich würde vorschlagen, dass der Bestellvorteil nicht angezeigt wird, da die Zieltabelle kein PK enthält. Es ist also der Conversion Overhead, den Sie sehen. Wenn es eine PK hat, müssen die 585k-Zeilen beim Einfügen noch sortiert werden. Wie weiß SQL, dass es halb sortiert ist?

Nun, wenn es 5,850 x 100 Zeile Einfügungen war, dann können Sie sehen, einige Vorteile, weil die neuen Zeilen "am Ende" nicht "in der Mitte" gehen werden, so Seitenaufteilungen und Overhead zu reduzieren.

Ich würde weiter gehen und sagen, dass der Artikel 2002 datiert ist, und ist für SQL 2000, und wurde vom wirklichen Leben übernommen.

In SQL Server 2005 haben wir SEQUENTIAL GUIDs, um streng monotonen GUIDs zu ermöglichen, einige Probleme zu lösen. Die GUID als PK wurde auch hier erstellt: aktuelles Beispiel: INT vs Unique-Identifier for ID field in database mit Links von Drittanbietern.

Wenn ein ORM GUID als PK und nicht als einen natürlichen Schlüssel oder einen standardmäßigen int-basierten Ersatzschlüssel vorschreibt, ist das eine schwerwiegende Einschränkung des ORM. Und ein Fall, in dem der Kunde mit dem Datenbankhund wackelt.

Answer 3

Ihr Code zum Generieren neuer GUIDs ist nicht korrekt. Für jede Zeile wird eine ganz andere Nummer erstellt (Sie rufen NEWID() für jede Zeile auf). Sie müssen den größten Teil der GUID beibehalten.