Freigeben über

Leistung der Copy-Aktivität mit SQL-Datenbanken

In diesem Artikel werden Techniken erläutert, mit denen Sie die Copy-Aktivität mit einer SQL-Datenbankquelle optimieren können, indem sie eine Azure SQL-Datenbank als Referenz verwenden. Wir decken verschiedene Aspekte der Optimierung ab, einschließlich Datenübertragungsgeschwindigkeiten, Kosten, Überwachung, Erleichterte Entwicklung und Ausgleich dieser verschiedenen Überlegungen für das beste Ergebnis.

Optionen für Copy-Aktivität

Hinweis

Die in diesem Artikel enthaltenen Metriken sind die Ergebnisse des Vergleichs- und Kontrastverhaltens von Testsituationen über verschiedene Funktionen hinweg und sind keine formalen technischen Benchmarks. Alle Testfälle verschieben Daten von der Region Ost-USA 2 in die Region West-USA 2.

Wenn Sie mit einer Pipelinekopie-Aktivität beginnen, ist es wichtig, die Quell- und Zielsysteme zu verstehen, bevor Sie mit der Entwicklung beginnen. Sie sollten angeben, wofür Sie optimieren, und verstehen, wie Sie die Quelle, das Ziel und die Pipeline überwachen, um die beste Ressourcenauslastung, Leistung und Verbrauch zu erzielen.

Bei der Beschaffung von einer Azure SQL-Datenbank ist es wichtig, Folgendes zu verstehen:

  • Ein-/Ausgabevorgänge pro Sekunde (IOPS)
  • Datenvolumen
  • DDL einer oder mehrerer Tabellen
  • Partitionierungsschemas
  • Primärschlüssel oder eine andere Spalte mit einer guten Verteilung von Daten (Schiefe)
  • Berechnen Sie Einschränkungen, die zugewiesen oder zugeordnet sind, wie z. B. die Anzahl gleichzeitiger Verbindungen.

Das gleiche gilt für Ihr Ziel. Mit einem Verständnis für beides können Sie eine Pipeline so entwerfen, dass sie innerhalb der Grenzen und Beschränkungen sowohl der Quelle als auch des Ziels funktioniert, während Sie Ihre Prioritäten optimieren.

Hinweis

Die Netzwerkbandbreite zwischen der Quelle und dem Ziel kann zusammen mit der Eingabe/Ausgabe pro Sekunde (IOPs) jedes Einzelnen ein Engpass für den Durchsatz sein, und es wird empfohlen, diese Grenzen zu verstehen. Netztechnologie ist jedoch nicht im Rahmen dieses Artikels enthalten.

Sobald Sie sowohl Ihre Quelle als auch Ihr Ziel verstanden haben, können Sie verschiedene Optionen in der Copy-Aktivität verwenden, um die Leistung für Ihre Prioritäten zu verbessern. Hierzu zählen beispielsweise die folgenden Optionen:

  • Quellpartitionierungsoptionen – Keine, physische Partition, Dynamischer Bereich
  • Quellisolationsstufe: Keine, Lesen bestätigt, Lesen unbestätigt, Momentaufnahme
  • Optimierungseinstellung für intelligenten Durchsatz – Auto, Standard, Ausgeglichen, Maximum
  • Einstellung des Parallelitätsgrads für Kopiervorgänge – Auto, angegebener Wert
  • Logische Partitionierung – Pipelinedesign zum Generieren mehrerer gleichzeitiger Copy-Aktivitäten

Quellendetails: Azure SQL-Datenbank

Um konkrete Beispiele bereitzustellen, haben wir mehrere Szenarien getestet und Daten aus einer Azure SQL-Datenbank sowohl in Fabric Lakehouse (Tabellen) als auch in Fabric Warehouse-Tabellen verschoben. In diesen Beispielen haben wir vier Quelltabellen getestet. Alle weisen die gleiche Schema- und Datensatzanzahl auf. Eine nutzt einen Heap, der zweite nutzt einen gruppierten Index, während die dritte und die vierte jeweils 8 bzw. 85 Partitionen nutzen. In diesem Beispiel wurde eine Testkapazität (F64) in Microsoft Fabric (West US 2) verwendet.

  • Dienstebene: Allgemeiner Zweck
  • Computeebene: Serverlos
  • Hardwarekonfiguration: Standardreihe (Gen5)
    • Max. virtuelle Kerne: 80
    • Mindestanzahl virtueller Kerne: 20
  • Datensatzanzahl: 1.500.000.000
  • Region: USA, Osten 2

Standardbewertung

Vor dem Festlegen der Quellpartitionsoption ist es wichtig, das Standardverhalten der Copy-Aktivität zu verstehen.

Die Standardeinstellungen sind folgende:

  • Quelle

    • Partitionsoption - Keine
    • Isolationsstufe - Ohne

    Screenshot der Datenquelleneinstellungen für die Azure SQL-Datenbank.

  • Erweiterte Einstellungen

    • Intelligente Durchsatzoptimierung - Auto
    • Parallelitätsgrad für Kopiervorgänge - Auto

    Screenshot: Weitere Einstellungen für die Azure SQL-Datenbank.

Zum Festlegen eines anfänglichen Benchmarks für einen zukünftigen Vergleich haben wir die Standardeinstellungen für eine Copy-Aktivität verwendet, die 1,5 Milliarden Datensätze in jedes Ziel geladen hat und etwas mehr als 2 Stunden pro Copy-Aktivität dauerte.

Reiseziel Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric Warehouse Keine Auto 1 02:23:21
Fabric-Lakehouse Keine Auto 1 02:10:37

In diesem Artikel konzentrieren wir uns auf die Gesamtdauer. Die Gesamtdauer umfasst andere Phasen wie Warteschlange, Vorkopierskript und Übertragungsdauer. Weitere Informationen zu diesen Phasen finden Sie unter Ausführungsdetails der Copy-Aktivität. Eine umfassende Übersicht über Copy-Aktivität-Eigenschaften für Azure SQL-Datenbank als Quelle finden Sie unter Azure SQL-Datenbank Quelleigenschaften für die Copy-Aktivität.

Einstellungen

Intelligente Durchsatzoptimierung (ITO)

ITO bestimmt die maximale Anzahl an CPU-, Arbeitsspeicher- und Netzwerkressourcenzuordnung, die die Aktivität verbrauchen kann. Wenn Sie ITO auf Maximum (oder 256) festlegen, wählt der Dienst den höchsten Wert aus, der den optimierten Durchsatz bereitstellt. In diesem Artikel ist ITO in allen Testfällen auf Maximum festgelegt, obwohl der Dienst nur das verwendet, was erforderlich ist, und der tatsächliche Wert niedriger als 256 ist.

Eine detailliertere Erklärung von ITO finden Sie in der Intelligenten Durchsatzoptimierung.

Hinweis

Staging ist erforderlich, wenn die Copy-Aktivität-Senke Fabric Warehouse ist. Optionen wie Parallelitätsgrad für Kopiervorgänge und intelligente Durchsatzoptimierung gelten nur in diesem Fall von Quelle zu Staging. Testfälle für Lakehouse hatten kein Staging aktiviert.

Partitionsoptionen

Wenn ihre Quelle eine relationale Datenbank wie Azure SQL-Datenbank ist, können Sie im Abschnitt Erweitert eine Partitionsoption angeben. Standardmäßig ist diese Einstellung auf Keine festgelegt, mit zwei anderen Optionen für physische Partitionen von Tabellen und dynamischen Bereich.

Dynamischer Bereich

Heaptabelle

Mit dynamischem Bereich kann der Dienst Abfragen für die Quelle intelligent generieren. Die Anzahl der generierten Abfragen entspricht der Anzahl der verwendeten parallelen Kopien des zur Runtime ausgewählten Diensts. Der Parallelitätsgrad für Kopiervorgänge und die verwendeten parallelen Kopien sind wichtig, wenn Sie die Verwendung der Partitionsoption Dynamischer Bereich optimieren.

Partitionsgrenzen

Die oberen und unteren Begrenzungen der Partition sind optionale Felder, mit denen Sie den Partitionsschritt angeben können. In diesen Teststiuationen haben wir sowohl die obere als auch die untere Grenze vordefiniert. Wenn diese Felder nicht angegeben sind, verursacht das System zusätzlichen Aufwand beim Abfragen der Quelle, um die Bereiche zu bestimmen. Um eine optimale Leistung zu erzielen, ermitteln Sie die Grenzen vorab, insbesondere für einmalige historische Ladevorgänge.

Weitere Informationen finden Sie in der Tabelle im Abschnitt Paralleles Kopieren aus der SQL-Datenbank des Azure SQL-Datenbank-Konnektor-Artikels.

Die folgende SQL-Abfrage bestimmt unseren Bereich min und max:

Screenshot einer Abfrage, um die Min- und Max-Grenzen der Tabelle zu bestimmen.

Anschließend geben wir diese Details in der Konfiguration des dynamischen Bereichs an.

Screenshot mit der Auswahl der Option „Dynamische Bereichspartition“ mit angegebenen Spalten-, Oberen- und Untergrenzen.

Hier ist eine Beispielabfrage, die von Copy-Aktivität mithilfe des dynamischen Bereichs generiert wird:

SELECT * FROM [dbo].[orders] WHERE [o_orderkey] > '4617187501' AND [o_orderkey] <= '4640625001'
Parallelitätsgrad für Kopiervorgänge

Standardmäßig wird Auto für den Parallelitätsgrad für Kopiervorgänge zugewiesen. Auto erreicht jedoch möglicherweise nicht die optimale Anzahl paralleler Kopien. Parallele Kopien korrelieren mit der Anzahl der Sitzungen, die in der Quelldatenbank erstellt wurden. Wenn zu viele parallele Kopien generiert werden, besteht das Risiko, dass die Quelldatenbank-CPU überlastet ist, was zu Abfragen im Unterbrechungsstatus führt.

Im ursprünglichen Testfall für dynamischen Bereich mit Auto generierte der Dienst tatsächlich 251 parallele Kopien zur Laufzeit. Durch Angeben eines Werts im Parallelitätsgrad für Kopiervorgänge legen Sie die maximale Anzahl paralleler Kopien fest. Mit dieser Einstellung können Sie die Anzahl der gleichzeitigen Sitzungen einschränken, die an Ihrer Quelle vorgenommen wurden, sodass Sie die Ressourcenverwaltung besser steuern können. In diesen Testsituationen wurde durch Angabe von 50 als Wert sowohl die Gesamtdauer als auch die Ressourcenauslastung der Quelle verbessert.

Reiseziel Partitionsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopiervorgänge Gesamtdauer
Fabric Warehouse Keine Auto 1 02:23:21
Fabric Warehouse Dynamischer Bereich 50 50 00:13:05

Der dynamische Bereich mit einem Grad paralleler Kopien kann die Leistung erheblich verbessern. Die Verwendung der Einstellung erfordert jedoch entweder die Vordefinierung der Grenzen oder das Bestimmen der Werte zur Laufzeit durch den Dienst. Das Zulassen des Dienstes, die Werte zur Laufzeit zu ermitteln, kann je nach DDL und Datenvolumen der Quelltabelle die Gesamtdauer beeinflussen. Wenn Sie dem Dienst erlauben, die Werte zur Laufzeit zu bestimmen, sollten Sie außerdem wissen, wie viele Kopien Ihre Quelle gleichzeitig verarbeiten kann. Wenn der Wert zu hoch ist, kann die Leistung des Quellsystems und der Kopieraktivität beeinträchtigt werden.

Weitere Informationen zu parallelen Kopien finden Sie in Leistungsmerkmalen der Kopieraktivitäten: Parallele Kopien.

Fabric Warehouse mit dynamischem Bereich

Standardmäßig ist die Isolationsstufe nicht angegeben, und der Grad der Parallelität wird auf Automatisch festgelegt.

Reiseziel Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric Warehouse Keine Auto 1 02:23:21
Fabric Warehouse Dynamischer Bereich Auto 251 00:39:03
Fabric Lakehouse (Tabellen) mit dynamischem Bereich
Reiseziel Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric-Lakehouse Keine Auto 1 02:23:21
Fabric-Lakehouse Dynamischer Bereich Auto 251 00:36:40
Fabric-Lakehouse Dynamischer Bereich 50 50 00:12:01
Gruppierter Index

Im Vergleich zu einer Heap-Tabelle verbesserte eine Tabelle mit einem gruppierten Schlüsselindex auf der Spalte, die für die Partitionsspalte des dynamischen Bereichs ausgewählt wurde, die Leistung und Ressourcennutzung drastisch. Dies gilt auch dann, wenn der Parallelitätsgrad für Kopiervorgänge automatisch festgelegt wurde.

Fabric Warehouse mit gruppiertem Index
Reiseziel Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric Warehouse Keine Auto 1 02:23:21
Fabric Warehouse Dynamischer Bereich Auto 251 00:09:02
Fabric Warehouse Dynamischer Bereich 50 50 00:08:38
Fabric Lakehouse (Tabellen) mit gruppiertem Index
Reiseziel Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric-Lakehouse Keine Auto 1 02:23:21
Fabric-Lakehouse Dynamischer Bereich Auto 251 00:06:44
Fabric-Lakehouse Dynamischer Bereich 50 50 00:06:34

Logischer Partitionsentwurf

Das logische Partitionsentwurfsmuster ist fortgeschrittener und erfordert mehr Entwickleraufwand. Dieses Design wird jedoch in Szenarien mit strengen Datenladeanforderungen verwendet. Dieses Design wurde ursprünglich entwickelt, um die Anforderungen einer lokalen Oracle-Datenbank zu erfüllen, um 180 GB Daten in weniger als 1,5 Stunden zu laden. Das ursprüngliche Design unter Verwendung der Standardeinstellungen der Kopieraktivität dauerte mehr als 65 Stunden. Bei Verwendung eines logischen Partitionierungsentwurfs werden die gleichen Daten angezeigt, die in weniger als 1,5 Stunden übertragen wurden.

Dieses Design wurde auch in dieser Blogreihe verwendet: Pipelineleistungsverbesserungen Teil 1: Konvertieren eines Zeitintervalls in Sekunden). Dieses Design eignet sich gut, um in Ihrer Umgebung zu emulieren, wenn Sie große Quelltabellen laden und eine optimale Ladeleistung benötigen, indem Techniken verwendet werden wie das Festlegen eines Datenbereichs zum Partitionieren der Quelldatenlesevorgänge. Dieser Entwurf generiert viele Unterdatumsbereiche. Anschließend werden mithilfe einer For-Each-Aktivität zum Durchlaufen der Bereiche viele Copy-Aktivitäten aufgerufen, um Daten zwischen dem angegebenen Bereich zu beziehen. Innerhalb der For-Each-Aktivität werden alle Copy-Aktivitäten parallel (bis zur Batch-Anzahl maximal 50) ausgeführt und weisen eine Einstellung des Parallelitätsgrads für Kopiervorgänge auf Auto auf.

Für die folgenden Beispiele wurden die partitionierten Datumswerte auf diese Werte festgelegt:

  • Startwert: 1992-01-01
  • Endwert: 1998-08-02
  • Bucket-Intervalltage: 50

Parallele Kopien und Gesamtdauer sind ein maximaler Wert für alle 50 Kopieraktivitäten, die erstellt wurden. Da alle 50 Kopiervorgänge parallel abliefen, gibt der Höchstwert für die Gesamtdauer an, wie lange alle Kopiervorgänge parallel dauerten.

Fabric Warehouse mit logischem Partitionsdesign
Reiseziel Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric Warehouse Keine Auto 1 02:23:21
Fabric Warehouse Logisches Design Auto 1 00:12:11
Fabric Lakehouse (Tabellen) mit logischem Partitionsentwurf
Reiseziel Partitionsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric-Lakehouse Keine Auto 1 02:10:37
Fabric-Lakehouse Logisches Design Auto 1 00:09:14

Physische Partitionen der Tabelle

Hinweis

Wenn Sie physische Partitionen verwenden, werden die Partitionsspalte und der Mechanismus automatisch auf der Grundlage Ihrer physischen Tabellendefinition bestimmt.

Um physische Partitionen einer Tabelle zu verwenden, muss die Quelltabelle partitioniert werden. Um zu verstehen, wie sich die Anzahl der Partitionen auf die Leistung auswirkt, haben wir zwei partitionierte Tabellen erstellt, eine mit 8 Partitionen und die andere mit 85 Partitionen.

Die Anzahl der physischen Partitionen begrenzt den Parallelitätsgrad für Kopiervorgänge. Sie können die Anzahl begrenzen, indem Sie einen unter der Anzahl der Partitionen liegenden Wert angeben.

Fabric Warehouse mit physischen Partitionen
Reiseziel Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric Warehouse Keine Auto 1 02:23:21
Fabric Warehouse Physisch Auto 8 00:26:29
Fabric Warehouse Physisch Auto 85 00:08:31
Fabric Lakehouse (Tabellen) mit physischen Partitionen
Reiseziel Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer
Fabric-Lakehouse Keine Auto 1 02:10:37
Fabric-Lakehouse Physisch Auto 8 00:36:36
Fabric-Lakehouse Physisch Auto 85 00:12:21

Isolationsstufen

Vergleichen wir, wie sich die Angabe unterschiedlicher Einstellungen der Isolationsstufen auf die Leistung auswirkt. Wenn Sie die Isolationsstufe mit einem auf Auto festgelegten Parallelitätsgrad für Kopiervorgänge auswählen, besteht das Risiko für die Copy-Aktivität, dass das Quellsystem überlastet und fehlschlägt. Es wird empfohlen, die Isolationsstufe als Keine zu belassen, wenn Sie den Parallelitätsgrad für Kopiervorgänge auf Automatisch festlegen möchten.

Hinweis

Azure SQL-Datenbank ist standardmäßig auf die *IsolationsstufeRead_Committed_Snapshot eingestellt.

Lassen Sie uns den Testfall für den dynamischen Bereich erweitern, wobei der Parallelitätsgrad für Kopiervorgänge auf 50 festgelegt ist und wie sich die Isolationsstufe auf die Leistung auswirkt.

Isolationsstufe Gesamtdauer Kapazitätseinheiten DB max. CPU % DB Max-Sitzung
Keine (Standard) 00:14:23 93.960 70 76
Lesen nicht zugesichert 00:13:46 89.280 81 76
Lesen zugesichert 00:25:34 97.560 81 76

Die Isolationsstufe, die Sie für Ihre Datenbankquellabfragen auswählen, wäre eher eine Anforderung als ein Optimierungspfad. Es ist jedoch wichtig, die Unterschiede bei der Leistung und dem Verbrauch von Kapazitätseinheiten zwischen den einzelnen Optionen zu verstehen.

Weitere Informationen zur Isolationsstufe** finden Sie unter IsolationLevel Enum.

ITO und Kapazitätsverbrauch

Ähnlich wie bei Grad paralleler Kopien ist die Intelligente Durchsatzoptimierung (INTELLIGENT Throughput Optimization, ITO) ein weiterer Maximalwert, der festgelegt werden kann. Wenn Sie die Kosten optimieren möchten, ist es sinnvoll, die ITO-Konfiguration anzupassen, um das gewünschte Resultat zu erreichen.

ITO-Bereiche:

ITO Höchstwert
Auto Nicht angegeben
Standard 64
Ausgeglichen 128
Maximum 256

Während die Dropdown-Liste die oben genannten Einstellungen zulässt, ermöglichen wir auch die Verwendung von benutzerdefinierten Werten zwischen 4 und 256.

Hinweis

Die tatsächliche Anzahl der verwendeten ITO-Daten finden Sie im Feld Copy-Aktivität-Ausgabe usedDataIntegrationUnits.

Für die Heap-Testsituation Dynamischer Bereich, in dem der Grad paralleler Kopien auf Auto festgelegt wurde, hat der Dienst Ausgeglichen mit einem tatsächlichen Wert von 100 ausgewählt. Sehen wir uns an, was passiert, wenn der ITO durch Angabe eines benutzerdefinierten Werts von 50 in der Hälfte gekürzt wird:

ITO spezifiziert Gesamtdauer Kapazitätseinheiten DB max. CPU % DB Max-Sitzung Optimierten Durchsatz nutzen
Höchstwert: (256) 00:13:46 89.280 81 76 Ausgeglichen (100)
50 00:18:28 48.600 76 61 Standard (48)

Durch die Senkung des ITO um 50 % stieg die Gesamtdauer um 34 %, der Dienst verwendete jedoch 45,5 % weniger Kapazitätseinheiten. Wenn Sie nicht für eine verbesserte Gesamtdauer optimieren und die verwendeten Kapazitätseinheiten reduzieren möchten, wäre es von Vorteil, den ITO auf einen niedrigeren Wert festzulegen.

Zusammenfassung

Die folgenden Diagramme fassen das Verhalten des Ladens in die Fabric Warehouse- und Fabric Lakehouse-Tabellen zusammen. Wenn die Tabelle über eine physische Partition verfügt, ist die Verwendung der Option Partition: Physische Partitionen der Tabelle der ausgewogenste Ansatz für Übertragungsdauer, Kapazitätseinheiten und Berechnungsaufwand für die Quelle. Diese Einstellung ist besonders ideal, wenn während der Datenverschiebung mehr Sitzungen für die Datenbank ausgeführt werden.

Wenn Ihre Tabelle keine physischen Partitionen enthält, haben Sie weiterhin die Möglichkeit, die Option Partition zu verwenden: Dynamischer Bereich. Bei dieser Option wäre ein vorheriger Schritt erforderlich, um die oberen und unteren Grenzen zu ermitteln. Es bietet immer noch erhebliche Verbesserungen bei der Übertragungsdauer im Vergleich zu den Standardoptionen auf Kosten eines etwas höheren Kapazitätsverbrauchs, einer höheren Auslastung der Quellcomputer und der Notwendigkeit, den optimalen Grad der Parallelität zu testen.

Ein weiterer wichtiger Faktor, um die Leistung Ihrer Kopieraufträge zu maximieren, besteht darin, die Datenverschiebung innerhalb einer einzelnen Cloud-Region beizubehalten. Beispielsweise ist die Datenverschiebung von einem Quell- und Zieldatenspeicher in USA, Westen mit einer Data Factory in USA, Westen besser als ein Kopierauftrag, der Daten von USA, Osten nach USA, Westen verschiebt.

Wenn Geschwindigkeit der wichtigste Aspekt der Optimierung ist, ist es wichtig, eine optimierte DDL Ihrer Quelltabelle zu verwenden, um physische Partitionsoptionen zu verwenden. Versuchen Sie es bei einer nicht partitionierten Tabelle mit dem dynamischen Bereich. Ist diese Einstellung nicht schnell genug, erwägen Sie die logische Partitionierung oder einen hybriden Ansatz der logischen Partitionierung plus dynamischen Bereich innerhalb der Untergrenzen.

Richtlinien

Kosten: Anpassen der Intelligenten Durchsatzoptimierung und Grad paralleler Kopien. Geschwindigkeit Wenn für partitionierte Tabellen eine gute Anzahl von Partitionen vorhanden ist, verwenden Sie die Partitionsoption: Physische Partitionen von Tabellen. Andernfalls sollten Sie die Verwendung eines dynamischen Bereichs in Betracht ziehen, wenn Daten schief sind oder eine begrenzte Anzahl von Partitionen vorhanden ist. Verwenden Sie für Heap und Tabellen mit Indizes den dynamischen Bereich mit Grad paralleler Kopien, die die Anzahl der angehaltenen Abfragen für Ihre Quelle einschränken würden. Wenn Sie die oberen/unteren Grenzen der Partition vordefinieren können, können Sie weitere Leistungsverbesserungen erzielen.

Berücksichtigen Sie Wartungsfreundlichkeit und Entwickleraufwand. Während die Standardoptionen die längste Zeit zum Verschieben von Daten benötigen, kann es die beste Option sein, mit den Standardeinstellungen zu arbeiten, insbesondere wenn die DDL der Quelltabelle unbekannt ist. Dies sorgt ebenfalls für einen angemessenen Verbrauch von Kapazitätseinheiten.

Testfälle

Fabric Warehouse-Testsituationen
Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer Kapazitätseinheiten Maximale CPU-Auslastung % Maximale Sitzungsanzahl
Keine Auto 1 02:23:21 51.839 < 1 2
Physisch (8) Auto 8 00:26:29 49.320 3 10
Körperlich (85) Auto 85 00:08:31 108.000 15 83
Dynamischer Bereich (Heap) Auto 242 00:39:03 282.600 100 272
Dynamischer Bereich (Heap) 50 50 00:13:05 92.159 81 76
Dynamischer Bereich (gruppierter Index) Auto 251 00:09:02 64.080 9 277
Dynamischer Bereich (gruppierter Index) 50 50 00:08:38 55.440 10 77
Logisches Design Auto 1 00:12:11 226.108 91 50
Fabric Lakehouse (Tabellen) Testsituationen
Partitionierungsoption Parallelitätsgrad für Kopiervorgänge Verwendete parallele Kopien Gesamtdauer Kapazitätseinheiten Maximale CPU-Auslastung % Maximale Sitzungsanzahl
Keine Auto 1 02:10:37 47.520 <1% 2
Physisch (8) Auto 8 00:36:36 64.079 2 10
Körperlich (85) Auto 85 00:12:21 275.759
Dynamischer Bereich (Heap) Auto 251 00:36:12 280.080 100 276
Dynamischer Bereich (Heap) 50 50 00:12:01 101.159 68 76
Dynamischer Bereich (gruppierter Index) Auto 251 00:06:44 59.760 11 276
Dynamischer Bereich (gruppierter Index) 50 50 00:06:34 54.760 10 76
Logisches Design Auto 1 00:09:14 164.908 82 50

Zugehöriger Inhalt

  • Last updated on