Die GUID als Schlüssel und Cluster in einem OLTP-System ist nicht fehlerhaft (es sei denn, Sie haben viele Indizes in der Tabelle, die unter der erhöhten Größe des Clusters leiden). Tatsächlich sind sie viel skalierbarer als IDENTITY-Spalten.
Es ist weit verbreitet, dass GUIDs in SQL Server ein großes Problem darstellen - im Großen und Ganzen ist dies ganz einfach falsch. Tatsächlich kann GUID auf Boxen mit mehr als 8 Kernen deutlich skalierbarer sein:
Es tut mir leid, aber Ihre Entwickler haben Recht. Sorgen Sie sich um andere Dinge, bevor Sie sich um GUID sorgen.
Oh, und zum Schluss: Warum möchten Sie überhaupt einen Cluster-Index? Wenn es sich bei Ihrem Unternehmen um ein OLTP-System mit vielen kleinen Indizes handelt, sind Sie mit einem Haufen wahrscheinlich besser dran.
Betrachten wir nun, was die Fragmentierung (die die GUID einführt) für Ihre Lesevorgänge bewirkt. Es gibt drei Hauptprobleme bei der Fragmentierung:
- Seitenteilung kostet Festplatten-E / A
- Halb volle Seiten sind nicht so speichereffizient wie volle Seiten
- Es führt dazu, dass Seiten nicht in der richtigen Reihenfolge gespeichert werden, wodurch sequentielle E / A weniger wahrscheinlich werden
Da es bei Ihrer Frage um Skalierbarkeit geht, die wir als "Hinzufügen von mehr Hardware beschleunigt das System" definieren können, sind dies die geringsten Probleme. Um jeden der Reihe nach anzusprechen
Ad 1) Wenn Sie skalieren möchten, können Sie es sich leisten, I / O zu kaufen. Selbst eine billige Samsung / Intel 512 GB SSD (für ein paar USD / GB) bringt Ihnen weit über 100.000 IOPS. Bei einem 2-Socket-System werden Sie das so schnell nicht verbrauchen. Und wenn Sie darauf stoßen sollten, kaufen Sie noch einen und Sie sind bereit
Ad 2) Wenn Sie in Ihrer Tabelle löschen, haben Sie trotzdem halb volle Seiten. Und selbst wenn Sie dies nicht tun, ist Speicher billig und für alle außer den größten OLTP-Systemen geeignet - die aktuellen Daten sollten dort passen. Der Versuch, mehr Daten in Seiten zu packen, führt zu einer Suboptimierung, wenn Sie nach Skalierung suchen.
Zu 3) Eine Tabelle, die aus häufig seitenweise aufgeteilten, stark fragmentierten Daten besteht, führt zufällige E / A-Vorgänge mit genau der gleichen Geschwindigkeit aus wie eine sequentiell gefüllte Tabelle
In Bezug auf das Beitreten gibt es zwei Haupt-Join-Typen, die Sie wahrscheinlich in einer OLTP-ähnlichen Workload sehen werden: Hash und Schleife. Schauen wir uns diese der Reihe nach an:
Hash-Join: Bei einem Hash-Join wird davon ausgegangen, dass der kleine Tisch gescannt wird und in der Regel der größere gesucht wird. Es ist sehr wahrscheinlich, dass kleine Tabellen im Arbeitsspeicher vorhanden sind, daher ist die E / A hier nicht Ihr Anliegen. Wir haben bereits darauf hingewiesen, dass Suchanfragen im fragmentierten Index dieselben Kosten verursachen wie im nicht fragmentierten Index
Loop Join: Der äußere Tisch wird gesucht. Gleiche Kosten
Möglicherweise werden auch viele schlechte Tabellen gescannt - aber die GUID ist wiederum nicht Ihr Problem, sondern die richtige Indizierung.
Möglicherweise werden jetzt einige legitime Bereichsüberprüfungen durchgeführt (insbesondere beim Verknüpfen von Fremdschlüsseln). In diesem Fall sind die fragmentierten Daten im Vergleich zu den nicht fragmentierten Daten weniger "gepackt". Aber lassen Sie uns überlegen, welche Verknüpfungen Sie wahrscheinlich in gut indizierten 3NF-Daten sehen werden:
Ein Join aus einer Tabelle, der einen Fremdschlüsselverweis auf den Primärschlüssel der Tabelle enthält, auf die er verweist
Umgekehrt
Anzeige 1) In diesem Fall führen Sie eine einzelne Suche zum Primärschlüssel durch - Verbinden von n mit 1. Fragmentierung oder nicht, gleiche Kosten (eine Suche)
Zu 2) In diesem Fall verbinden Sie sich mit demselben Schlüssel, können jedoch mehr als eine Zeile abrufen (Bereichssuche). Der Join ist in diesem Fall 1 bis n. Bei der von Ihnen gesuchten Fremdtabelle wird jedoch nach dem gleichen Schlüssel gesucht, der sich in einem fragmentierten Index mit der gleichen Wahrscheinlichkeit auf derselben Seite wie auf einer nicht fragmentierten Seite befindet.
Betrachten Sie diese Fremdschlüssel für einen Moment. Selbst wenn Sie unsere Primärschlüssel "perfekt" sequentiell gelegt hätten - alles, was auf diesen Schlüssel zeigt, ist immer noch nicht sequentiell.
Natürlich können Sie auf einer virtuellen Maschine in einem SAN in einer Bank laufen, die wenig Geld und viel Prozess hat. Dann geht all dieser Rat verloren. Aber wenn das Ihre Welt ist, ist Skalierbarkeit wahrscheinlich nicht das, wonach Sie suchen - Sie suchen Leistung und hohe Geschwindigkeit / Kosten -, beides verschiedene Dinge.