Udostępnij za pośrednictwem

Zwiększenie przepustowości do usługi Azure SQL Database z Azure Stream Analytics

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

Wyjście SQL w usłudze Azure Stream Analytics obsługuje zapisywanie równoległe jako opcję. Ta opcja umożliwia w pełni równoległe topologie zadań, w których wiele partycji wyjściowych zapisuje się równolegle w 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 usługi SQL Database. Porządkowanie zapisów nie jest gwarantowane podczas zapisywania równolegle do usługi 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.

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 dysku i posiadanie w pełni równoległej topologii zadania, można się spodziewać lepszej przepustowości. To partycjonowanie odbywa się już automatycznie w przypadku wielu innych danych wyjściowych. Blokowanie tabeli (TABLOCK) jest również wyłączone w przypadku wstawiania zbiorczego wykonanego z tą opcją.

    Uwaga / Notatka

    Jeśli istnieje więcej niż 8 partycji wejściowych, dziedziczenie schematu partycjonowania wejściowego może nie być odpowiednim wyborem. Ten górny limit zaobserwowano w tabeli z jedną kolumną tożsamości i indeksem klastrowanym. W takim przypadku rozważ użycie INTO 8 w zapytaniu, aby jawnie określić liczbę writerów 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 tabeli docelowej/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 10K (wartość 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 wykorzystanie odziedziczonego partycjonowania i rozmiaru partii, zwiększenie liczby zdarzeń wejściowych na komunikat na partycję zwiększa 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ąć za pomocą 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 partycjonowanej 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 naruszeń unikalnych kluczy — jeśli w dzienniku aktywności usługi Azure Stream Analytics zostanie wyświetlonych wiele komunikatów ostrzegawczych o naruszeniach klucza, upewnij się, że twoje zadanie nie jest dotknięte naruszeniami ograniczeń unikalności, które mogą wystąpić w przypadkach odzyskiwania danych. Można tego uniknąć, ustawiając opcję IGNORE_DUP_KEY w indeksach.

Azure Data Factory i tabele w pamięci

  • In-Memory Tabela jako tabela tymczasowa — In-Memory Tabele umożliwiają bardzo szybkie ładowanie danych, ale dane muszą się zmieścić w pamięci. Testy porównawcze pokazują, że ładowanie zbiorcze z tabeli w pamięci do tabeli opartej na dysku jest około 10 razy szybsze niż bezpośrednie wstawianie zbiorcze 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 usługi 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 wstawek, ponieważ unika się wielokrotnego przesyłania danych, analizowania instrukcji wstawiania, uruchamiania instrukcji i zapisywania rekordu transakcji. Zamiast tego korzysta się z bardziej wydajnej ścieżki do silnika magazynowania, aby przesyłać strumieniowo dane. Koszt instalacji tej ścieżki jest jednak znacznie wyższy niż pojedyncza instrukcja insert w tabeli opartej na dysku. Punkt rentowności to zwykle 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 niższe niż 100 wierszy, co sprawia, że zbiorcze wstawianie jest nieefektywne i używa zbyt dużej ilości miejsca na dysku. Aby obejść to ograniczenie, możesz wykonać jedną z następujących czynności:

  • Utwórz wyzwalacz INSTEAD OF, aby użyć prostego wstawiania dla każdego wiersza.
  • Użyj tabeli tymczasowej typu In-Memory, zgodnie z opisem w poprzednim rozdziale.

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ównana równoległość twojego zadania z tabelą partycjonowaną w usłudze SQL Azure powinna zapewnić znaczne ulepszenia przepustowości. Wykorzystanie usługi Azure Data Factory do orkiestracji przenoszenia danych z tabeli In-Memory do tabel opartych na dyskach może zapewnić wzrost przepustowości o rząd wielkości. Jeśli jest to możliwe, poprawa gęstości komunikatów może być również głównym czynnikiem poprawy ogólnej przepływności.

Następne kroki

  • Last updated on