Kdy vložit nebo odkazovat data

  • 2 min

V předchozí lekci jsme do nového dokumentu zákazníka vloženého údaje o adrese zákazníka a heslem. Tato akce snižuje počet požadavků, což zlepšuje výkon a snižuje náklady. Data ale nemůžete vkládat vždy. Existují pravidla pro vložení dat do dokumentu místo odkazování na data na jiný řádek.

Kdy byste měli vkládat data?

Data vložte do dokumentu, pokud se na data vztahují následující kritéria:

  • Čtení nebo aktualizace společně: Data, která se čtou nebo aktualizují společně, se téměř vždy modelují jako jeden dokument. Tím se sníží počet požadavků, které jsou naším cílem efektivní. V našem scénáři se všechny entity zákazníků čtou nebo zapisují společně.
  • Vztah 1:1: Například Customer a CustomerPassword mají relaci 1:1.
  • 1:Few relationship: V databázi NoSQL je nutné rozlišovat 1:N relací jako ohraničených nebo nevázaných. Zákazník a CustomerAddress mají ohraničený vztah 1:N, protože zákazníci v aplikaci elektronického obchodování mají obvykle jen několik adres k odeslání. Pokud je relace ohraničená, jedná se o relaci 1:Few.

Kdy byste měli odkazovat na data?

Pokud se na data vztahují následující kritéria, odkazujte na data jako samostatné dokumenty:

  • Čtení nebo aktualizace nezávisle: To platí zejména v případě, že kombinování entit, které by vedlo k velkým dokumentům. Aktualizace ve službě Azure Cosmos DB vyžadují, aby byla nahrazena celá položka. Pokud má dokument několik vlastností, které se často aktualizují společně s velkým počtem převážně statických vlastností, je mnohem efektivnější rozdělit dokument na dva. Jeden dokument pak obsahuje menší sadu vlastností, které se často aktualizují. Druhý dokument obsahuje statické neměnné hodnoty.

  • 1:N relace: To platí zejména v případě, že relace není nevázaná. Pokud máte dokument, který se zvětší neznámou nebo neomezenou velikostí, náklady a latence těchto aktualizací se budou dál zvětšovat. Důvodem je zvýšení velikosti aktualizace, která stojí více RU/s a datových částí procházejících přes síť, která sama o sobě, je také neefektivní.

  • N:N relace: Prozkoumáme příklad této relace v pozdější lekci se značkami produktů.

    Oddělení těchto vlastností snižuje spotřebu propustnosti za účelem vyšší efektivity. Snižuje také latenci pro lepší výkon.