- potřeba velké množství dat, decentralizace úložiště, redundance, …
- iterativní vývoj - částečné nebo žádné schéma při vývoji
- jsou post-relační = přestávají odpovídat relační databázi, umí mít jako hodnotu xml a indexovat např. pomocí xpath
- ACID je nevhodný / nemožný v distribuované databázi
- Teorém
- U sdílených systémů je možné uspokojit maximálně 2 ze 3 požadavků
- Consistency
- každý uzel/klient vidí ve stejný čas stejná data
- data jsou konzistentní
- Availability
- aby se tvářilo, jako lokální databáze
- Partition Tolerance (vlastnost distribuované databáze)
- je možný částečný výpadek
- znemožňuje ACID (potřebuje trvalost)
- Consistence + Availability = 2 fázový commit, protokoly pro (in)validaci dat
- řeší CAP omezením konzistence dat
- nemějme ACID, ale mějme rychlejší přístup k db
- Basically Available - záleží na velikosti výpadku, je většinově dostupná
- Soft-state (consistence) - nemusí být vždy konzistentní
- Eventual consistency - nějakou dobu trvá, než bude v konsistentním stavu, ale někdy v tom skončí
- když někdo postne příspěvek, tak nevadí, že ho všichni neuvidí zároveň
- vs banka výběr peněz, nemůže být zpoždění mezi výběrem z účtu (mohlo by se jít do mínusu)
- vs skladovní systém
- ACID je konzervativní / pesimistický přístup
- předpokládaly, že k něčemu dojde a snažili se tomu zabránit
- BASE: agresivní / optimistické
- víme, že k nekonzistenčnosti dojde, ale jen krátce / ono se to vyřeší
- → jsou jednodušší
- mazání je problematické v distribuovaném systému = jen se přepíše prázdnou hodnotou
- Jeden klíč, jedna hodnota, žádný duplikát.
- Přístup podle klíče přes hash tabulky - “brutálně rychlé”
- Hodnota je BLOB, databáze se nesnaží ani chápat
- Získání/zapsání pouze část hodnoty je neefektivní!
- hodnota je strukturovaná
- hodnota např json, zml, nebo “objekt”
- i složitější dotazy než jen přes klíč.
- mongoDB
- tváří se jako relační databáze, ale u řádků 1 sloupec klíč a zbytek sloupců jsou hodnoty
- v praxi každý řádek může mít jiný počet sloupců
- Grafy = uzly, vlastnosti uzlů, hrany spojující uzly
- s predikáty = RDF db
- SPARQL speciální dotazovací jazyk
- pro klasické inf. sys. stále nejlepší rel. db
- kombinace 2 db
- tam kde se hodně čte, tak použít NoSQL
- tam kde se často modifikuje - rel. db
- při výběru NoSQL
-
- podle druhu dat
- sensory, atd - db časové řady
- žel. sítě, dopravní síť - grafové
- wide-column store = hodnota se skládá z více sloupců
PRIMARY KEY - slouží k partitioning key, použití pro hashování hash table
- druhá část indexace dat v uzlu
- nejde udělat range scan přes hash hodnoty
- změna by byla předistribuování dat přes uzly - není vůbec jednoduché = big data
- 2. část 2. projektu - nechceme zvolit špatný klíč
- jestli potřebujeme komentáře i mimo články nebo ne, potřeba odůvodnit v projektu
- time series NoSQL db
- tag = místo kde měřím
- line protokol = stream “sypání” dat to db
- lze dobře komprimovat - $\delta = 0$ → 1bit změna neproběhla