Udostępnij za pośrednictwem

Zasady buforowania (gorąca i zimna pamięć podręczna)

  • Artykuł

Usługa Azure Data Explorer używa wielowarstwowego systemu pamięci podręcznej danych, aby zapewnić szybką wydajność zapytań. Dane są przechowywane w niezawodnym magazynie, takim jak Usługa Azure Blob Storage, ale części są buforowane na węzłach przetwarzania, ssd, a nawet w pamięci RAM w celu szybszego dostępu.

Analiza w czasie rzeczywistym używa wielowarstwowego systemu pamięci podręcznej danych, aby zapewnić szybką wydajność zapytań. Dane są przechowywane w niezawodnym magazynie, takim jak OneLake, ale części są buforowane na węzłach przetwarzania, ssd, a nawet w pamięci RAM w celu szybszego dostępu.

Zasady buforowania umożliwiają wybranie, które dane mają być buforowane. Możesz odróżnić gorącą pamięć podręczną danych i zimną pamięć podręczną danych, ustawiając zasady buforowania na gorących danych. Gorące dane są przechowywane w lokalnym magazynie SSD w celu zwiększenia wydajności zapytań, podczas gdy zimne dane są przechowywane w niezawodnym magazynie, który jest tańszy, ale wolniejszy do uzyskania dostępu.

Pamięć podręczna używa 95% lokalnego dysku SSD na potrzeby gorących danych. Jeśli nie ma wystarczającej ilości miejsca, najnowsze dane są preferencyjnie przechowywane w pamięci podręcznej. Pozostałe 5% jest używane dla danych, które nie są klasyfikowane jako gorące. Ten projekt gwarantuje, że zapytania ładujące dużo zimnych danych nie będą wykluczać gorących danych z pamięci podręcznej.

Najlepsza wydajność zapytań jest osiągana, gdy wszystkie pozyskane dane są buforowane. Jednak niektóre dane mogą nie uzasadniać wydatków przechowywanych w gorącej pamięci podręcznej. Na przykład rzadko używane stare rekordy dziennika mogą być uznawane za mniej istotne. W takich przypadkach zespoły często decydują się na niższą wydajność wykonywania zapytań w porównaniu z płaceniem, aby dane były ciepłe.

Użyj poleceń zarządzania, aby zmienić zasady buforowania na poziomie bazy danych, tabeli lub zmaterializowanego widoku .

Użyj poleceń zarządzania, aby zmienić zasady buforowania na poziomie klastra, bazy danych, tabeli lub zmaterializowanego widoku .

Napiwek

Klaster jest przeznaczony dla zapytań ad hoc z zestawami wyników pośrednich, które mieszczą się w całkowitej pamięci RAM klastra. W przypadku dużych zadań, takich jak redukcja mapy, przydatne może być przechowywanie wyników pośrednich w magazynie trwałym. W tym celu utwórz zadanie eksportu ciągłego. Ta funkcja umożliwia wykonywanie długotrwałych zapytań wsadowych przy użyciu usług, takich jak HDInsight lub Azure Databricks.

Jak są stosowane zasady buforowania

Gdy dane są pozyskiwane, system śledzi datę i godzinę pozyskiwania oraz zakres, w jakim został utworzony. Wartość daty i godziny pozyskiwania zakresu (lub maksymalna wartość, jeśli zakres został skompilowany z wielu wcześniej istniejących zakresów), służy do oceny zasad buforowania.

Uwaga

Wartość daty i godziny pozyskiwania można określić przy użyciu właściwości creationTimepozyskiwania . W takim przypadku upewnij się, że Lookback właściwość w obowiązujących zasadach scalania zakresów tabeli jest zgodna z wartościami ustawionymi dla creationTimeelementu .

Domyślnie obowiązująca zasada to null, co oznacza, że wszystkie dane są traktowane jako gorące. Zasady null na poziomie tabeli oznaczają, że zasady zostaną odziedziczone z bazy danych. Zasady nanull poziomie nienależące do tabeli zastępują zasady na poziomie bazy danych.

Określanie zakresu zapytań do gorącej pamięci podręcznej

Podczas uruchamiania zapytań można ograniczyć zakres tylko do wykonywania zapytań dotyczących danych w gorącej pamięci podręcznej.

Uwaga

Określanie zakresu danych dotyczy tylko jednostek, które obsługują zasady buforowania, takie jak tabele i zmaterializowane widoki. Jest on ignorowany dla innych jednostek, takich jak tabele zewnętrzne i dane w magazynie wierszy.

Istnieje kilka możliwości zapytań:

  • Dodaj właściwość żądania klienta o nazwie query_datascope do zapytania. Możliwe wartości: default, alli hotcache.
  • set Użyj instrukcji w tekście zapytania: set query_datascope='...'. Możliwe wartości są takie same jak dla właściwości żądania klienta.
  • datascope=... Dodaj tekst bezpośrednio po odwołaniu do tabeli w treści zapytania. Możliwe wartości to all i hotcache.

Wartość default wskazuje użycie ustawień domyślnych klastra, które określają, że zapytanie powinno obejmować wszystkie dane.

Jeśli istnieje rozbieżność między różnymi metodami, set pierwszeństwo ma właściwość żądania klienta. Określanie wartości odwołania do tabeli ma pierwszeństwo przed obydwoma.

Na przykład w poniższym zapytaniu wszystkie odwołania do tabeli używają tylko danych gorącej pamięci podręcznej, z wyjątkiem drugiego odwołania do "T", które jest ograniczone do wszystkich danych:

set query_datascope="hotcache";
T | union U | join (T datascope=all | where Timestamp < ago(365d)) on X

Zasady buforowania a zasady przechowywania

Zasady buforowania są niezależne od zasad przechowywania:

  • Zasady buforowania definiują sposób określania priorytetów zasobów. Zapytania dotyczące ważnych danych są szybsze.
  • Zasady przechowywania definiują zakres danych z możliwością wykonywania zapytań w tabeli/bazie danych (w szczególności SoftDeletePeriod).

Skonfiguruj te zasady, aby osiągnąć optymalną równowagę między kosztami i wydajnością na podstawie oczekiwanego wzorca zapytania.

Przykład:

  • SoftDeletePeriod = 56d
  • hot cache policy = 28d

W tym przykładzie dane z ostatnich 28 dni będą znajdować się na dysku SSD klastra, a dodatkowe 28 dni danych będzie przechowywanych w usłudze Azure Blob Storage. Zapytania można uruchamiać na pełnych 56 dniach danych.

Powiązana zawartość