Zwiększanie wydajności przepływności do usługi Azure SQL Database z usługi Azure Stream Analytics

Artykuł
06/01/2023

W tym artykule omówiono porady dotyczące osiągania lepszej wydajności zapisu podczas ładowania danych do usługi Azure SQL Database przy użyciu usługi Azure Stream Analytics.

Dane wyjściowe SQL w usłudze Azure Stream Analytics obsługują równoległe zapisywanie jako opcja. Ta opcja umożliwia w pełni równoległe topologie zadań, w których wiele partycji wyjściowych zapisuje się równolegle do tabeli docelowej. Włączenie tej opcji w usłudze Azure Stream Analytics może jednak nie być wystarczające do osiągnięcia wyższej przepływności, ponieważ zależy to znacznie od konfiguracji bazy danych i schematu tabeli. Wybór indeksów, klucza klastrowania, współczynnika wypełnienia indeksu i kompresji ma wpływ na czas ładowania tabel. Aby uzyskać więcej informacji na temat optymalizowania bazy danych w celu zwiększenia wydajności zapytań i obciążenia na podstawie wewnętrznych testów porównawczych, zobacz wskazówki dotyczące wydajności SQL Database. Porządkowanie zapisów nie jest gwarantowane podczas zapisywania równoległego w SQL Database.

Poniżej przedstawiono niektóre konfiguracje w ramach każdej usługi, które mogą pomóc w zwiększeniu ogólnej przepływności rozwiązania.

Usługa Azure Stream Analytics

Dziedzicz partycjonowanie — ta opcja konfiguracji danych wyjściowych SQL umożliwia dziedziczenie schematu partycjonowania poprzedniego kroku zapytania lub danych wejściowych. Po włączeniu tej opcji zapisywanie w tabeli opartej na dyskach i posiadanie w pełni równoległej topologii zadania powinno się spodziewać lepszej przepływności. Ta partycjonowanie odbywa się już automatycznie w przypadku wielu innych danych wyjściowych. Blokowanie tabeli (TABLOCK) jest również wyłączone dla operacji wstawiania zbiorczego wykonanego z tą opcją.

Uwaga

Jeśli istnieje więcej niż 8 partycji wejściowych, dziedziczenie schematu partycjonowania wejściowego może nie być właściwym wyborem. Ten górny limit zaobserwowano w tabeli z jedną kolumną tożsamości i indeksem klastrowanym. W takim przypadku rozważ użycie funkcji INTO 8 w zapytaniu, aby jawnie określić liczbę składników zapisywania danych wyjściowych. Na podstawie schematu i wyboru indeksów obserwacje mogą się różnić.
Rozmiar partii — konfiguracja danych wyjściowych SQL umożliwia określenie maksymalnego rozmiaru partii w danych wyjściowych SQL usługi Azure Stream Analytics na podstawie charakteru docelowej tabeli/obciążenia. Rozmiar partii to maksymalna liczba rekordów wysyłanych z każdą transakcją wstawiania zbiorczego. W klastrowanych indeksach magazynu kolumn rozmiary partii około 100 000 umożliwiają bardziej równoległe przetwarzanie, minimalne rejestrowanie i optymalizacje blokowania. W tabelach opartych na dyskach wartość 10K (domyślna) lub niższa może być optymalna dla twojego rozwiązania, ponieważ wyższe rozmiary partii mogą wyzwalać eskalację blokady podczas wstawiania zbiorczego.
Dostrajanie komunikatów wejściowych — jeśli zoptymalizowano przy użyciu dziedziczonych partycji i rozmiaru partii, zwiększenie liczby zdarzeń wejściowych na komunikat na partycję pomaga dodatkowo zwiększyć przepływność zapisu. Dostrajanie komunikatów wejściowych umożliwia dostrajanie rozmiarów partii w usłudze Azure Stream Analytics do określonego rozmiaru partii, co zwiększa przepływność. Można to osiągnąć przy użyciu kompresji lub zwiększenia rozmiaru komunikatów wejściowych w usłudze EventHub lub obiekcie blob.

Usługi SQL Azure

Partycjonowane tabele i indeksy — użycie partycjonowanej tabeli SQL i partycjonowanych indeksów w tabeli z tą samą kolumną co klucz partycji (na przykład PartitionId) może znacznie zmniejszyć rywalizację między partycjami podczas zapisu. W przypadku tabeli podzielonej na partycje należy utworzyć funkcję partycji i schemat partycji w grupie plików PRIMARY. Zwiększy to również dostępność istniejących danych podczas ładowania nowych danych. Limit operacji we/wy dziennika może zostać osiągnięty na podstawie liczby partycji, które można zwiększyć przez uaktualnienie jednostki SKU.
Unikaj unikatowych naruszeń kluczy — jeśli w dzienniku aktywności usługi Azure Stream Analytics zostanie wyświetlonych wiele komunikatów ostrzegawczych o naruszeniu zabezpieczeń klucza , upewnij się, że zadanie nie ma wpływu na unikatowe naruszenia ograniczeń, które mogą wystąpić podczas odzyskiwania. Można tego uniknąć, ustawiając opcję IGNORE_DUP_KEY w indeksach.

tabele Azure Data Factory i In-Memory

Tabela w pamięci jako tabela tymczasowa — tabele w pamięci umożliwiają bardzo szybkie ładowanie danych, ale dane muszą mieścić się w pamięci. Testy porównawcze pokazują, że zbiorcze ładowanie z tabeli w pamięci do tabeli opartej na dysku jest o 10 razy szybsze niż bezpośrednie zbiorcze wstawianie przy użyciu pojedynczego modułu zapisywania do tabeli opartej na dysku z kolumną tożsamości i indeksem klastrowanym. Aby wykorzystać tę wydajność operacji wstawiania zbiorczego, skonfiguruj zadanie kopiowania przy użyciu Azure Data Factory, które kopiuje dane z tabeli w pamięci do tabeli opartej na dysku.

Unikanie pułapek wydajności

Zbiorcze wstawianie danych jest znacznie szybsze niż ładowanie danych za pomocą pojedynczych wstawień, ponieważ unika się wielokrotnego narzutów podczas przesyłania danych, analizowania instrukcji insert, uruchamiania instrukcji i wystawiania rekordu transakcji. Zamiast tego bardziej wydajna ścieżka jest używana do aparatu magazynu w celu przesyłania strumieniowego danych. Koszt konfiguracji tej ścieżki jest jednak znacznie wyższy niż pojedyncza instrukcja insert w tabeli opartej na dysku. Punkt przerwania zazwyczaj wynosi około 100 wierszy, poza którymi ładowanie zbiorcze jest prawie zawsze bardziej wydajne.

Jeśli szybkość zdarzeń przychodzących jest niska, można łatwo utworzyć rozmiary partii mniejsze niż 100 wierszy, co sprawia, że zbiorcze wstawianie jest nieefektywne i zużywa zbyt dużo miejsca na dysku. Aby obejść to ograniczenie, możesz wykonać jedną z następujących czynności:

Utwórz wyzwalacz ZAMIAST wyzwalacza , aby używać prostego wstawiania dla każdego wiersza.
Użyj tabeli In-Memory tymczasowej zgodnie z opisem w poprzedniej sekcji.

Inny taki scenariusz występuje podczas zapisywania w indeksie magazynu kolumn bez klastra (NCCI), gdzie mniejsze operacje wstawiania zbiorczego mogą tworzyć zbyt wiele segmentów, co może spowodować awarię indeksu. W takim przypadku zaleca się użycie indeksu klastrowanego magazynu kolumn.

Podsumowanie

Podsumowując, z funkcją partycjonowanych danych wyjściowych w usłudze Azure Stream Analytics dla danych wyjściowych SQL, wyrównaną równoległość zadania z tabelą partycjonowaną w Usługi SQL Azure powinna zapewnić znaczną poprawę przepływności. Wykorzystanie Azure Data Factory do organizowania przenoszenia danych z tabeli In-Memory do tabel opartych na dyskach może dać kolejność przyrostu przepływności wielkości. Jeśli to możliwe, poprawa gęstości komunikatów może być również głównym czynnikiem zwiększającym ogólną przepływność.