Přístup 1(A): Vytvoření jediné databáze pro vše. (S jedinou sbírkou)
Výhody:
- Menší údržba:Zálohování, vytváření uživatelů databáze, obnova atd
Nevýhody:
- Můžete vidět zámek na úrovni databáze pro vytváření indexů na velké databázi
- Chcete-li provádět operace s konkrétními daty senzoru, musíte přidat další indexy, abyste načetli pouze kolekci specifickou pro senzor
- Jste povinni nevytvořit více než 64 indexů na jedné kolekci. Ačkoli to zní jako špatná strategie indexování.
Přístup 1(B): Vytvoření jediné databáze pro vše. (S 1 kolekcí pro každý senzor)
Výhody:
- Menší údržba:Zálohování, vytváření uživatelů databáze, obnova atd
- Minimalizuje potřebu vytváření indexů k identifikaci dat specifických pro senzor z celé monolitické kolekce
- Každý dotaz specifický pro senzor bude zacílen pouze na konkrétní kolekci. Nevyžaduje stahování velké pracovní sady do paměti ve srovnání s jednou velkou sbírkou.
- Vytváření indexu na relativně menší sbírce je schůdnější než u velké sbírky v jedné databázi
Nevýhody:
- Může se stát, že vytvoříte příliš mnoho indexů. (Součet celkového počtu indexů ve všech kolekcích).
- Velký počet indexů vyžaduje větší údržbu.
- WiredTiger interně vytvoří 1 soubor pro kolekci a 1 pro index. Pokud se váš případ použití rozroste o velký počet senzorů. Můžete skončit používáním limitu 64 kB otevřených souborů.
Pokud jde o výkon, záleží na tom, jestli data rozdělím podle jednotlivých senzorů nebo podle metrik?
- To závisí na vzorech přístupu očekávaných od vaší analytické aplikace.
Pokud jde o výkon, mám vytvořit sbírku pouze pro informace ze senzorů a poté sbírku pro data, nebo je jen sloučit do stejné kolekce?
-
Může být potřeba vytvořit kolekci pro metadata senzoru a data senzoru. Minimalizuje duplicitní metadata senzoru ve všech shromážděných datech senzoru.
-
Možná si budete chtít přečíst Příspěvek na blogu Williams zde o navrhování tohoto vzoru.
Jako vždy je lepší navrhnout vzorové schéma a otestovat své dotazy ve svém testovacím prostředí.