Share via

Projektowanie pod kątem modyfikacji danych

  • Artykuł

Ten artykuł koncentruje się na zagadnieniach projektowych dotyczących optymalizowania wstawiania, aktualizacji i usuwania. W niektórych przypadkach należy ocenić kompromis między projektami, które optymalizują zapytania względem projektów zoptymalizowanych pod kątem modyfikacji danych tak samo jak w projektach relacyjnych baz danych (chociaż techniki zarządzania kompromisami projektowymi różnią się w relacyjnej bazie danych). W sekcji Wzorce projektowe tabel opisano pewne szczegółowe wzorce projektowe dla usługi Table Service i wyróżniono niektóre te kompromisy. W praktyce okaże się, że wiele projektów zoptymalizowanych pod kątem wykonywania zapytań o jednostki również dobrze sprawdza się w przypadku modyfikowania jednostek.

Optymalizowanie wydajności operacji wstawiania, aktualizowania i usuwania

Aby zaktualizować lub usunąć jednostkę, musisz mieć możliwość jej zidentyfikowania przy użyciu wartości PartitionKey i RowKey . W tym względzie wybór opcji PartitionKey i RowKey do modyfikowania jednostek powinien być zgodny z podobnymi kryteriami do wyboru w celu obsługi zapytań punktów, ponieważ chcesz zidentyfikować jednostki tak wydajnie, jak to możliwe. Nie chcesz używać nieefektywnego skanowania partycji lub tabeli w celu zlokalizowania jednostki w celu odnalezienia wartości PartitionKey i RowKey , które należy zaktualizować lub usunąć.

Następujące wzorce w sekcji Wzorce projektowe tabeli dotyczą optymalizacji wydajności lub operacji wstawiania, aktualizowania i usuwania:

  • Wzorzec usuwania dużego woluminu — umożliwia usunięcie dużej liczby jednostek, przechowując wszystkie jednostki do jednoczesnego usuwania we własnej oddzielnej tabeli; jednostki można usunąć, usuwając tabelę.
  • Wzorzec serii danych — przechowywanie pełnych serii danych w jednej jednostce w celu zminimalizowania liczby żądań, które należy wykonać.
  • Wzorzec szerokich jednostek — użyj wielu jednostek fizycznych do przechowywania jednostek logicznych z więcej niż 252 właściwościami.
  • Wzorzec dużych jednostek — użyj magazynu obiektów blob do przechowywania dużych wartości właściwości.

Zapewnianie spójności w przechowywanych jednostkach

Innym kluczowym czynnikiem wpływającym na wybór kluczy do optymalizacji modyfikacji danych jest sposób zapewnienia spójności przy użyciu transakcji niepodzielnych. Do obsługi jednostek przechowywanych w tej samej partycji można używać tylko egT.

Następujące wzorce w artykule Wzorce projektowe tabel dotyczą zarządzania spójnością:

  • Wzorzec indeksu pomocniczego wewnątrz partycji — przechowuj wiele kopii każdej jednostki przy użyciu różnych wartości RowKey (w tej samej partycji), aby umożliwić szybkie i wydajne wyszukiwanie oraz alternatywne zamówienia sortowania przy użyciu różnych wartości RowKey .
  • Wzorzec indeksu pomocniczego między partycjami — przechowuj wiele kopii każdej jednostki przy użyciu różnych wartości RowKey w oddzielnych partycjach lub w oddzielnych tabelach, aby umożliwić szybkie i wydajne wyszukiwanie i alternatywne kolejności sortowania przy użyciu różnych wartości RowKey.
  • Ostatecznie spójny wzorzec transakcji — umożliwia ostatecznie spójne zachowanie między granicami partycji lub granicami systemu magazynowania przy użyciu kolejek platformy Azure.
  • Wzorzec jednostek indeksu — obsługa jednostek indeksu w celu umożliwienia wydajnych wyszukiwań zwracających listy jednostek.
  • Wzorzec denormalizacji — łączenie powiązanych danych w jednej jednostce w celu umożliwienia pobierania wszystkich potrzebnych danych za pomocą pojedynczego zapytania punktowego.
  • Wzorzec serii danych — przechowywanie pełnych serii danych w jednej jednostce w celu zminimalizowania liczby żądań, które należy wykonać.

Aby uzyskać informacje na temat transakcji grupy jednostek, zobacz sekcję Transakcje grupy jednostek.

Upewnij się, że projekt wydajne modyfikacje ułatwia wydajne zapytania

W wielu przypadkach projekt wydajnego wykonywania zapytań powoduje efektywne modyfikacje, ale zawsze należy ocenić, czy jest to przypadek konkretnego scenariusza. Niektóre wzorce w artykule Wzorce projektowania tabel jawnie oceniają kompromisy między wykonywaniem zapytań i modyfikowaniem jednostek, a zawsze należy wziąć pod uwagę liczbę każdego typu operacji.

Następujące wzorce w artykule Wzorce projektowe tabel dotyczą kompromisów między projektowaniem wydajnych zapytań i projektowaniem pod kątem wydajnej modyfikacji danych:

  • Wzorzec klucza złożonego — użyj złożonych wartości RowKey , aby umożliwić klientowi wyszukiwanie powiązanych danych z pojedynczym zapytaniem punktowym.
  • Wzorzec ogona dziennika — pobierz jednostki n ostatnio dodane do partycji przy użyciu wartości RowKey , która sortuje w kolejności odwrotnej daty i godziny.