Provozní faktory, které je třeba vzít v úvahu při modelování dat MongoDB

V mém předchozím blogu Jak používat datové modelování MongoDB ke zlepšení propustnosti operací jsme diskutovali o 2 hlavních přístupech k modelování dat, kterými jsou vkládání a odkazování. Škálovatelnost MongoDB je dosti závislá na jeho architektuře a konkrétně na datovém modelování. Při navrhování NoSQL DBM je hlavním bodem úvahy kromě malého počtu kolekcí zajistit dokumenty bez schémat za účelem snadné údržby. Dobrá integrita dat, přijetí ověření dat pomocí některých definovaných pravidel před uložením je podporováno. Databázová architektura a design by měly být normalizovány a rozloženy do několika malých kolekcí jako způsob, jak se vyhnout opakování dat, zlepšit integritu dat a usnadnit vyhledávání pomocí vzorů. Díky tomu můžete zlepšit konzistenci dat, atomicitu, trvanlivost a integritu vaší databáze.

Datové modelování není dodatečným krokem ve fázi vývoje aplikace, ale počáteční úvahou, protože mnoho aspektů aplikace je ve skutečnosti realizováno ve fázi datového modelování. V tomto článku probereme, které faktory je třeba vzít v úvahu při modelování dat, a uvidíme, jak obecně ovlivňují výkon databáze.

Mnohokrát budete muset nasadit cluster vaší databáze jako jeden způsob, jak zvýšit dostupnost dat. S dobře navrženým datovým modelem můžete efektivněji distribuovat aktivity do sdíleného clusteru, a tím snížit propustnost operací zaměřených na jedinou instanci mongoda. Mezi hlavní faktory, které je třeba vzít v úvahu při modelování dat, patří:

Škálovatelnost
Atomicita
Výkon a využití dat
Sharding
Indexování
Optimalizace úložiště
Struktura a růst dokumentu
Životní cyklus dat

1. Škálovatelnost

Jedná se o zvýšení pracovní zátěže aplikace způsobené zvýšeným provozem. Mnoho aplikací má vždy očekávání v nárůstu počtu svých uživatelů. Když je jedinou instancí databáze obsluhováno tolik uživatelů, výkon vždy nesplňuje očekávání. Jako správce databází máte tedy mandát navrhnout tento DBM tak, aby kolekce a datové entity byly modelovány na základě současných a budoucích požadavků aplikace. Struktura databáze by měla být obecně prezentovatelná, aby se zjednodušil proces replikace a sdílení. Máte-li více fragmentů, operace zápisu jsou rozděleny mezi tyto fragmenty tak, že jakákoli aktualizace dat se provádí v rámci fragmentu obsahujícího tato data, nikoli vyhledávání v jedné velké sadě dat za účelem aktualizace.

2. Atomicita

To se vztahuje na úspěšnou nebo neúspěšnou operaci jako jednu jednotku. Můžete mít například operaci čtení, která zahrnuje operaci řazení po načtení výsledku. Pokud není operace řazení provedena správně, celá operace proto nepostoupí do další fáze.

Atomové transakce jsou série operací, které nejsou ani dělitelné, ani redukovatelné, a proto se vyskytují jako jednotlivé entity nebo selhávají jako jedna operace. Verze MongoDB starší než 4.0 podporují operace zápisu jako atomické procesy na úrovni jednoho dokumentu. S verzí 4.0 lze nyní implementovat transakce s více dokumenty. Datový model, který vylepšuje atomové operace, má tendenci mít skvělý výkon, pokud jde o latenci. Latence je jednoduše doba, během níž je odeslán požadavek na operaci a kdy je vrácena odpověď z databáze. Chcete-li být sekán, je snadné aktualizovat data, která jsou vložena do jediného dokumentu, nikoli do dokumentu, na který se odkazuje.

Podívejme se například na soubor dat níže

{
    childId : "535523",
    studentName : "James Karanja",
    parentPhone : 704251068,
    age : 12,
    settings : {
        location : "Embassy",
        address : "420 01",
        bus : "KAZ 450G",
        distance : "4"
      }
}

Pokud chceme aktualizovat věk zvýšením o 1 a změnit místo na Londýn, můžeme:

db.getCollection(‘students’).update({childId: 535523},{$set:{'settings.location':'London'}, $inc:{age:1}}).

Pokud selže například operace $set, pak nebude automaticky implementována operace $inc a obecně celá operace selže.

Na druhou stranu uvažujme referenční data, například že existují 2 kolekce, jedna pro studenta a druhá pro nastavení.

Studentská sbírka

{
    childId : "535523",
    studentName : "James Karanja",
    parentPhone : 704251068,
    age : 12
}

Kolekce nastavení

{
  childId : "535523",  
  location : "Embassy",
  address : "420 01",
  bus : "KAZ 450G",
  distance : "4"
}

V tomto případě můžete aktualizovat hodnoty stáří a umístění pomocí samostatných operací zápisu .e

db.getCollection(‘students’).update({childId: 535523},{$inc:{age:1}})
db.getCollection('settings’).update({childId: 535523 } , {$set: { 'settings.location':'London'}})

Pokud jedna z operací selže, nemusí to nutně ovlivnit druhou, protože jsou prováděny jako různé entity.

Transakce pro více dokumentů

S MongoDB verze 4.0 nyní můžete provádět více transakcí dokumentů pro sady replik. To zlepšuje výkon, protože operace jsou vydávány do řady kolekcí, databází a dokumentů pro rychlé zpracování. Když byla transakce potvrzena, data se uloží, zatímco pokud se něco pokazí a transakce selže, provedené změny se zahodí a transakce bude obecně přerušena. Během transakce nedojde k žádné aktualizaci sad replik, protože operace je viditelná venku pouze tehdy, když je transakce plně potvrzena.

Jakkoli můžete aktualizovat více dokumentů ve více transakcích, přichází to se sníženým výkonem ve srovnání se zápisem jednoho dokumentu. Kromě toho je tento přístup podporován pouze pro úložiště WiredTiger, a proto je nevýhodou pro úložiště In-Memory a MMAPv1.

3. Výkon a využití dat

Aplikace jsou navrženy odlišně, aby vyhovovaly různým účelům. Některé slouží pouze pro aktuální data jako aplikace zpráv o počasí. V závislosti na struktuře aplikace by člověk měl být schopen navrhnout odpovídající optimální databázi pro server požadovaného případu použití. Pokud například vyvíjíte aplikaci, která stahuje nejnovější data z databáze, bude nejlepší volbou použití omezené kolekce. Omezená kolekce zvyšuje výkon s vysokou propustností, stejně jako vyrovnávací paměť, takže při využití přiděleného prostoru jsou nejstarší dokumenty přepsány a dokumenty mohou být načteny v pořadí, v jakém byly vloženy. Vzhledem k načítání objednávky vložení nebude potřeba používat indexování a absence režie indexu stejně zlepší propustnost zápisu. S omezenou sbírkou jsou související data poměrně malá, protože je lze po určitou dobu udržovat v paměti RAM. Časová data jsou v tomto případě uložena v mezipaměti, která se spíše čte, než do ní zapisuje, takže operace čtení je poměrně rychlá. Omezená kolekce má však některé nevýhody, jako je, že nemůžete smazat dokument, dokud nezrušíte celou kolekci, jakákoliv změna velikosti dokumentu selže v operaci a konečně není možné skartovat omezenou kolekci.

V datovém modelování databáze jsou integrovány různé aspekty v závislosti na potřebách použití. Jak je vidět, aplikace sestav budou mít tendenci být intenzivnější při čtení, a proto by jejich návrh měl být takovým způsobem, aby zlepšil propustnost čtení.

4. Sharding

Výkon prostřednictvím horizontálního škálování lze zlepšit shardingem, protože zátěž pro čtení a zápis je rozdělena mezi členy klastru. Nasazení shluku úlomků má tendenci rozdělit databázi do několika malých kolekcí s distribuovanými dokumenty v závislosti na nějakém střepinovém klíči. Měli byste vybrat vhodný klíč, který kromě zvýšení kapacity zápisu může zabránit izolaci dotazů. Lepší výběr obecně zahrnuje pole, které je přítomno ve všech dokumentech v rámci cílené kolekce. Díky shardingu se zvětšuje úložiště, protože jak data rostou, vytváří se další fragmenty, které udrží podmnožinu tohoto clusteru.

5. Indexování

Indexování je jedním z nejlepších přístupů ke zlepšení zátěže při zápisu, zejména tam, kde se pole vyskytují ve všech dokumentech. Při indexování je třeba vzít v úvahu, že každý index bude vyžadovat 8 kB datového prostoru. Kromě toho, když je index aktivní, spotřebovává určité místo na disku a paměti, a proto by měl být sledován pro plánování kapacity.

Somenines Staňte se MongoDB DBA – Uvedení MongoDB do produkce Zjistěte, co potřebujete vědět, abyste mohli nasadit, monitorovat, spravovat a škálovat MongoDBDdownload zdarma

6. Optimalizace úložiště

Mnoho malých dokumentů ve sbírce bude mít tendenci zabírat více místa, než když máte několik dokumentů s vloženými dokumenty. Při modelování je proto třeba seskupit související data před uložením. S několika dokumenty lze provést databázovou operaci s malým počtem dotazů, čímž se sníží náhodný přístup na disk a v odpovídajícím indexu bude méně přidružených klíčových položek. V tomto případě proto bude třeba vzít v úvahu následující:použijte vkládání, abyste měli méně dokumentů, což zase snižuje režii na dokument. Pokud je v kolekci zahrnuto méně polí, použijte kratší názvy polí, abyste nezvýšili režii dokumentu. Kratší názvy polí snižují expresivitu, tj.

{ Lname : "Briston", score : 5.9 }

ušetří 9 bajtů na dokument namísto použití

{ last_name : "Briston", high_score: 5.9 }

Explicitně použijte pole _id. Klienti MongoDB standardně přidávají pole _id do každého dokumentu přiřazením jedinečného 12bajtového ObjectId pro toto pole. Kromě toho bude indexováno pole _id. Pokud jsou dokumenty velmi malé, bude tento scénář představovat značné množství místa v celkovém počtu dokumentů. Pro optimalizaci úložiště můžete při vkládání dokumentů do kolekce explicitně zadat hodnotu pro pole _id. Ujistěte se však, že je hodnota jednoznačně identifikována, protože slouží jako primární klíč pro dokumenty v kolekci.

7. Struktura a růst dokumentu

K tomu dochází v důsledku operace nabízení, kdy jsou vnořené dokumenty vloženy do pole pole nebo když jsou do existujícího dokumentu přidána nová pole. Růst dokumentu má určité překážky, např. u omezené kolekce, pokud se velikost změní, operace se automaticky nezdaří. U úložiště MMAPv1 verze před 3.0 přemístí dokument na disku, pokud je překročena velikost dokumentu. V pozdějších verzích od 3.0 však existuje koncept Power of 2 Sized Allocations, který snižuje šance na takovéto přerozdělení a umožňuje efektivní opětovné využití uvolněného prostoru pro záznamy. Pokud očekáváte, že vaše data porostou, možná budete chtít přefaktorovat svůj datový model tak, aby používal odkazy mezi daty v odlišných dokumentech namísto použití denormalizovaného datového modelu. Chcete-li se vyhnout růstu dokumentů, můžete také zvážit použití strategie předběžného přidělení.

8. Životní cyklus dat

Pro aplikaci, která používá pouze nedávno vložené dokumenty, zvažte použití omezené kolekce, jejíž funkce byly popsány výše.

Pro svou sbírku můžete také nastavit funkci Time to Live. To je zcela použitelné pro přístupové tokeny ve funkci resetování hesla pro aplikace.

Time To Live (TTL)

Toto je nastavení shromažďování, které umožňuje mongodu automaticky odstranit data po určité době. Ve výchozím nastavení se tento koncept používá pro strojově generovaná data událostí, protokoly a informace o relacích, které musí přetrvávat po omezenou dobu.

Příklad:

db.log_events.createIndex( { "createdAt": 1 }, { expireAfterSeconds: 3600 } )

Vytvořili jsme index createdAt a zadali určitou hodnotu expireAfterSeconds 3600, což je 1 hodina po vytvoření. Nyní, když vložíme dokument jako:

db.log_events.insert( {
   "createdAt": new Date(),
   "logEvent": 2,
   "logMessage": "This message was recorded."
} )

Tento dokument bude smazán po 1 hodině od vložení.

Můžete také nastavit konkrétní čas hodin, kdy chcete dokument odstranit. Chcete-li tak učinit, nejprve vytvořte index, tj.:

db.log_events.createIndex( { "expireAt": 1 }, { expireAfterSeconds: 0 } )

Nyní můžeme vložit dokument a určit čas, kdy má být smazán.

db.log_events.insert( {
   "expireAt": new Date(December 12, 2018 18:00:00'),
   "logEvent": 2,
   "logMessage": "Success!"
} )

Tento dokument bude automaticky smazán, když bude hodnota expireAt starší než počet sekund zadaný v parametru expireAfterSeconds, tj. v tomto případě 0.

Závěr

Datové modelování je rozsáhlý podnik pro jakýkoli návrh aplikace s cílem zlepšit výkon databáze. Před vložením dat do vaší databáze zvažte potřeby aplikace a jaké jsou nejlepší vzory datových modelů, které byste měli implementovat. Kromě toho důležité aspekty aplikací nelze realizovat, dokud není implementován správný datový model.