OK. Ich habe hier und da etwas über SQL Server-Heaps gelesen, aber nichts zu definitives, um mich wirklich zu führen. Ich werde versuchen, die Leistung zu messen, hoffe aber auf eine Anleitung, was ich untersuchen sollte. Dies ist SQL Server 2008 Enterprise. Hier sind die Tabellen:Uniqueneidentifier PK: Ist ein SQL Server-Heap die richtige Wahl?
Jobs
- JobID (PK, GUID, extern erzeugte)
- Startdate (datetime2)
- AccountId
- Mehrere weitere Rechnungslegungs Felder, vor allem Dezimalzahlen und bigints
JobSteps
- JobStepID (PK, GUID, extern erzeugte)
- JobID FK
- Startdatum
- Mehrere weitere Rechnungslegungs Felder, vor allem Dezimalzahlen und bigints
Verbrauch: Viele Einsätze (Hunderte/Sek.), normalerweise 1 JobStep pro Job. Schätze vielleicht 100-200 Millionen Reihen pro Monat. Es gibt überhaupt keine Updates, und die einzigen Löschungen stammen von Archivierungsdaten, die älter als 3 Monate sind.
Do ~ 10 Abfragen/Sek. Gegen die Daten. Einige treten JobSteps zu Jobs bei, manche schauen sich nur Jobs an. Fast alle Abfragen werden auf StartDate basieren, die meisten von ihnen enthalten AccountId und einige der anderen Accounting-Felder (wir haben Indizes für sie). Abfragen sind ziemlich einfach - der größte Teil der Ausführungspläne ist der Join für JobSteps.
Die Priorität ist die Einfügungsleistung. Einige Verzögerungen (etwa 5 Minuten) sind tolerierbar, damit Daten in den Abfragen angezeigt werden. Daher ist das Replizieren auf andere Server und das Ausführen von Abfragen aus diesen Abfragen zulässig.
Suchen auf der Grundlage der GUIDs ist sehr selten, abgesehen von JobSteps zu Jobs beizutreten.
Aktuelle Konfiguration: Kein Clustered-Index. Der einzige, der wie ein Kandidat aussieht, ist StartDate. Aber es erhöht sich nicht perfekt. Jobs können an einer beliebigen Stelle in einem 3-Stunden-Fenster nach ihrem StartDate eingefügt werden. Das könnte bedeuten, dass eine Million Zeilen in einer Reihenfolge eingefügt werden, die nicht endgültig ist.
Datengröße für einen 1 Job + 1 JobStepId, mit meinen aktuellen Indizes, ist ungefähr 500 Bytes.
Fragen:
Ist das eine gute Verwendung eines Haufens?
Was ist der Effekt von Clustering auf StartDate, wenn es für ~ 2 Stunden/1 Million Zeilen ziemlich nicht sequenziell ist? Meine Vermutung ist, dass die konstante Nachbestellung die Insert-Perf-Funktion beenden würde.
Sollte ich nur bigint PKs hinzufügen, nur um kleinere, immer zunehmende Schlüssel zu haben?(Ich würde immer noch die GUIDs für Lookups müssen.)
ich GUIDs as PRIMARY KEYs and/or the clustering key lesen, und es schien zu vermuten, dass auch einen Schlüssel zu erfinden auf anderen Indizes vielen Platz sparen. Auch einige Ressourcen deuten darauf hin, dass Heaps irgendeine Art von Perf-Problemen im Allgemeinen haben, aber ich bin mir nicht sicher, ob das immer noch in SQL 2008 gilt.
Und wieder, ja, ich werde versuchen zu perf testen und zu messen. Ich versuche nur, einige Anleitungen oder Links zu anderen Artikeln zu bekommen, damit ich eine fundiertere Entscheidung darüber treffen kann, welche Wege in Betracht gezogen werden sollten.
Ja, ich wollte auf jeden Fall GUIDs als gruppierten Schlüssel zu vermeiden, da alle anderen Fragen zeigen. StartDate würde eine zusätzliche Identität benötigen. Ich war nur besorgt, dass das Einfügen von im Wesentlichen "zufälligen" Startdaten über einen Zeitraum von 2 Stunden eine Menge Nachbestellung oder etwas anderes bedeuten könnte. Also, kurz gesagt, fügen Sie eine bigint PK hinzu, um alles schön und gruppiert zu bekommen? – MichaelGG
@MichaelGG: ja. es ist schmal, numerisch, streng monoton steigend, unique = gut gruppierter Index – gbn
Richtig, ich verstehe, dass eine int PK viel besser geeignet ist als eine GUID. Meine Frage war, ob ich eine neue Bigint-Spalte hinzufügen sollte, nur um geclusterte Indizes zu haben, anstatt sie als Heap zu verwenden, war eine gute Idee. Es scheint, dass es der richtige Schritt ist. – MichaelGG