Udostępnij za pośrednictwem

Optymalizowanie pod kątem wysokiej współbieżności za pomocą usługi Azure Data Explorer

  • Artykuł

Wysoce współbieżne aplikacje są potrzebne w scenariuszach z dużą bazą użytkowników, gdzie aplikacja jednocześnie obsługuje wiele żądań z małym opóźnieniem i wysoką przepływnością.

Przypadki użycia obejmują pulpity nawigacyjne monitorowania i alertów na dużą skalę. Przykłady obejmują produkty i usługi firmy Microsoft, takie jak Azure Monitor, Azure Time Series Insights i Playfab. Wszystkie te usługi używają usługi Azure Data Explorer do obsługi obciążeń o wysokiej współbieżności. Azure Data Explorer to szybka, w pełni zarządzana usługa analizy danych big data na potrzeby analizy danych w czasie rzeczywistym na dużych ilościach danych przesyłanych strumieniowo z aplikacji, witryn internetowych, urządzeń IoT i nie tylko.

Uwaga

Rzeczywista liczba zapytań, które mogą być uruchamiane współbieżnie w klastrze, zależy od czynników, takich jak jednostka SKU klastra, woluminy danych, złożoność zapytań i wzorce użycia.

Aby skonfigurować aplikacje o wysokiej współbieżności, zaprojektuj architekturę zaplecza w następujący sposób:

W tym artykule przedstawiono zalecenia dotyczące każdego z powyższych tematów, które można zaimplementować w celu osiągnięcia wysokiej współbieżności w optymalny, ekonomiczny sposób. Te funkcje mogą być używane samodzielnie lub w połączeniu.

Optymalizowanie danych

W przypadku wysokiej współbieżności zapytania powinny zużywać najmniej możliwą ilość zasobów procesora CPU. Można użyć dowolnej lub wszystkich następujących metod:

Korzystanie z najlepszych rozwiązań dotyczących projektowania schematu tabeli

Skorzystaj z poniższych sugestii dotyczących projektowania schematu tabeli, aby zminimalizować używane zasoby procesora CPU:

  • Kolumny identyfikatorów powinny być definiowane jako typy danych ciągów niezależnie od tego, czy wartości są liczbowe. Indeksowanie kolumn ciągów jest bardziej zaawansowane niż w przypadku kolumn liczbowych i zapewnia lepszą wydajność filtrowania.
  • Dopasuj typ danych kolumny optymalnie do rzeczywistych danych przechowywanych w tych kolumnach. Na przykład nie przechowuj wartości daty/godziny w kolumnie ciągu.
  • Unikaj dużej tabeli rozrzedzanej z wieloma kolumnami i używaj kolumn dynamicznych do przechowywania rozrzedzanych właściwości.
  • Przechowuj często używane właściwości we własnej kolumnie przy użyciu niedynamicznego typu danych.
  • Zdenormalizuj dane, aby uniknąć sprzężeń, które wymagają stosunkowo dużych zasobów procesora CPU.

Partycjonowanie danych

Dane są przechowywane w postaci zakresów (fragmentów danych) i są domyślnie partycjonowane według czasu pozyskiwania. Za pomocą zasad partycjonowania można ponownie podzielić zakresy na podstawie jednej kolumny ciągu lub jednej kolumny daty/godziny w procesie w tle. Partycjonowanie może zapewnić znaczną poprawę wydajności, gdy większość zapytań używa kluczy partycji do filtrowania, agregowania lub obu tych operacji.

Uwaga

Sam proces partycjonowania używa zasobów procesora CPU. Jednak zmniejszenie procesora CPU w czasie zapytania powinno przeważyć nad procesorem używanym do partycjonowania.

Wstępne agregowanie danych za pomocą zmaterializowanych widoków

Wstępne agregowanie danych w celu znacznego zmniejszenia zasobów procesora CPU w czasie wykonywania zapytań. Przykładowe scenariusze obejmują podsumowanie punktów danych w zmniejszonej liczbie przedziałów czasu, przechowywanie najnowszego rekordu danego rekordu lub deduplikację zestawu danych. Użyj zmaterializowanych widoków , aby łatwo skonfigurować zagregowany widok dla tabel źródłowych. Ta funkcja upraszcza proces tworzenia i obsługi tych zagregowanych widoków.

Uwaga

Proces agregacji w tle używa zasobów procesora CPU. Jednak zmniejszenie użycia procesora CPU w czasie zapytania powinno przeważyć nad użyciem procesora w celu agregacji.

Konfigurowanie zasad buforowania

Skonfiguruj zasady buforowania, tak aby zapytania działały na danych przechowywanych w magazynie gorącym, nazywanym również pamięcią podręczną dysku. Uruchamiaj tylko ograniczone, starannie zaprojektowane scenariusze na zimnym magazynie lub w tabelach zewnętrznych.

Ustawianie wzorca architektury obserwowanej przez lidera

Baza danych obserwowanych jest funkcją zgodną z bazą danych lub zestawem tabel w bazie danych z innego klastra znajdującego się w tym samym regionie. Ta funkcja jest udostępniana za pośrednictwem usługi Azure Data Share, interfejsów API usługi Azure Resource Manager i zestawu poleceń klastra.

Użyj wzorca lidera, aby ustawić zasoby obliczeniowe dla różnych obciążeń. Na przykład skonfiguruj klaster na potrzeby pozyskiwania danych, klaster do wykonywania zapytań lub obsługi pulpitów nawigacyjnych lub aplikacji oraz klaster obsługujący obciążenia nauki o danych. Każde obciążenie w tym przypadku będzie miało dedykowane zasoby obliczeniowe, które można skalować niezależnie, oraz różne konfiguracje buforowania i zabezpieczeń. Wszystkie klastry używają tych samych danych, a lider zapisuje dane i obserwujących, używając ich w trybie tylko do odczytu.

Uwaga

Bazy danych obserwowanych mają opóźnienie od lidera, zwykle z kilku sekund. Jeśli twoje rozwiązanie wymaga najnowszych danych bez opóźnień, to rozwiązanie może być przydatne. Użyj widoku w klastrze obserwowanym, który tworzy połączenie danych z lidera i obserwowanego oraz wykonuje zapytania dotyczące najnowszych danych od lidera i reszty danych z obserwowanego elementu.

Aby zwiększyć wydajność zapytań w klastrze obserwowanych, możesz włączyć konfigurację zakresów pobierania wstępnego. Użyj tej konfiguracji ostrożnie, ponieważ może to mieć wpływ na świeżość danych w poniższej bazie danych.

Optymalizowanie zapytań

Użyj następujących metod, aby zoptymalizować zapytania pod kątem wysokiej współbieżności.

Postępuj zgodnie z najlepszymi rozwiązaniami dotyczącymi zapytań, aby zapytania są tak wydajne, jak to możliwe.

Używanie pamięci podręcznej wyników zapytania

Gdy więcej niż jeden użytkownik ładuje ten sam pulpit nawigacyjny w podobnym czasie, pulpit nawigacyjny do drugiego i kolejnych użytkowników może być obsługiwany z pamięci podręcznej. Ta konfiguracja zapewnia wysoką wydajność bez użycia procesora CPU. Użyj funkcji pamięci podręcznej wyników zapytania i wyślij konfigurację pamięci podręcznej wyników zapytania za pomocą zapytania przy użyciu instrukcji set .

Grafana zawiera ustawienie konfiguracji pamięci podręcznej wyników zapytania na poziomie źródła danych, więc wszystkie pulpity nawigacyjne używają tego ustawienia domyślnie i nie muszą modyfikować zapytania.

Konfigurowanie spójności zapytań

Domyślny tryb spójności zapytania jest silny. W tym trybie węzeł administracyjny zarządza metadanymi i pozyskiwaniem klastra, a także planowanie i delegowanie wykonywania zapytań do innych węzłów.

W aplikacjach o wysokiej współbieżności zarządzanie zapytaniami może spowodować wysokie użycie procesora CPU węzła administracyjnego , podczas gdy inne węzły są mniej zajęte. Może to spowodować wąskie gardło, w którym liczba współbieżnych zapytań nie może wzrosnąć. Jednak może to nie być widoczne w raporcie procesora CPU klastra (witryna Azure Portal > {your_cluster} > Metryka > procesora CPU), która pokazuje średnie użycie procesora CPU dla klastra.

W tym scenariuszu zalecamy używanie słabego trybu spójności. W tym trybie więcej węzłów może zarządzać zapytaniami, co umożliwia skalowanie w poziomie liczby współbieżnych zapytań. Węzły w tym trybie okresowo odświeżają kopię metadanych i nowo pozyskanych danych, co prowadzi do opóźnienia zwykle krótszego niż minutę w miarę synchronizowania danych. Jednak to krótkie opóźnienie jest preferowane w sytuacji wąskiego gardła, która może wystąpić w przypadku korzystania z trybu silnej spójności.

Tryb spójności można ustawić w zasadach spójności zapytań grupy obciążeń, we właściwościach żądania klienta lub w konfiguracji źródła danych Grafana.

Ustawianie zasad klastra

Liczba współbieżnych żądań jest domyślnie ograniczona i kontrolowana przez zasady limitu szybkości żądań, aby klaster nie był przeciążony. Te zasady można dostosować w sytuacjach o wysokiej współbieżności. Te zasady powinny być dostosowywane tylko po rygorystycznym testowaniu, najlepiej w przypadku wzorców użycia i zestawów danych podobnych do środowiska produkcyjnego. Testowanie gwarantuje, że klaster może utrzymać zmodyfikowaną wartość. Ten limit można skonfigurować na podstawie potrzeb aplikacji.

Monitorowanie klastrów usługi Azure Data Explorer

Monitorowanie kondycji zasobów klastra ułatwia utworzenie planu optymalizacji przy użyciu funkcji sugerowanych w poprzednich sekcjach. Usługa Azure Monitor dla usługi Azure Data Explorer zapewnia kompleksowy widok wydajności, operacji, użycia i niepowodzeń klastra. Uzyskaj szczegółowe informacje na temat wydajności zapytań, współbieżnych zapytań, ograniczonych zapytań i różnych innych metryk, wybierając kartę Szczegółowe informacje (wersja zapoznawcza) w sekcji Monitorowanie klastra usługi Azure Data Explorer w witrynie Azure Portal.

Aby uzyskać informacje na temat monitorowania klastrów, zobacz Usługa Azure Monitor dla usługi Azure Data Explorer. Aby uzyskać informacje na temat poszczególnych metryk, zobacz Metryki usługi Azure Data Explorer.