Graf Databází pro Začátečníky: KYSELINY vs. BÁZE Vysvětlil

Když přijde na NoSQL databáze, konzistence dat modelů může být někdy nápadně odlišné než ty, které používají relační databáze (stejně jako zcela odlišné od jiných NoSQL obchodech).
dva nejběžnější modely konzistence jsou známé pod zkratkami ACID and BASE. I když jsou často postaveni proti sobě v bitvě o konečné vítězství(prosím, někdo z toho udělá video), oba modely konzistence přicházejí s výhodami – a nevýhodami-a ani jeden není vždy perfektní.
podívejme se blíže na kompromisy obou modelů konzistence databáze.

V tomto Grafu Databází pro Začátečníky blog série, budu vás provede základy grafu technologie za předpokladu, že máte málo (nebo žádné) zázemí v prostoru. V minulých týdnech jsme řešit, proč graf technologii je budoucnost, proč připojených datech záleží, základy (a úskalí), modelování dat, proč databáze, dotazovací jazyk věcech, rozdíly mezi imperativní a deklarativní dotazovací jazyky, prediktivní modelování pomocí teorie grafů, základy graph search algoritmy a proč potřebujeme NoSQL databází.
Tento týden se blíže podíváme na klíčové rozdíly mezi modely konzistence kyselé a bazické databáze a na to, co jejich kompromisy znamenají pro vaše datové transakce.

Model konzistence kyselin

mnoho vývojářů je obeznámeno s transakcemi kyselin z práce s relačními databázemi. Jako takový je model konzistence kyseliny již nějakou dobu normou.
klíčová acid záruka je, že poskytuje bezpečné prostředí, ve kterém pracovat s vašimi daty. Zkratka ACID znamená:
Atomic

• všechny operace v transakci uspějí nebo se každá operace vrátí zpět.

konzistentní

• po dokončení transakce je databáze strukturálně zdravá.

izolované

• transakce mezi sebou nekončí. Sporný přístup k datům je moderován databází, takže se zdá, že transakce probíhají postupně.

Trvanlivé

• výsledky použití transakcí jsou trvalé, a to i v přítomnosti poruch.

vlastnosti kyseliny znamenají, že jakmile je transakce dokončena, její data jsou konzistentní (tech lingo: write consistency) a stabilní na disku, což může zahrnovat více různých paměťových míst.
konzistence zápisu je skvělá věc pro vývojáře aplikací, ale také vyžaduje sofistikované zamykání, které je pro většinu případů použití obvykle vzorem těžké váhy.
Pokud jde o NoSQL technologií, většina grafu databází(včetně Neo4j) použití KYSELINY konzistence modelu pro zajištění dat je bezpečná a trvale uloženy.

základní konzistenční Model

pro mnoho domén a případů použití jsou transakce mnohem pesimističtější (tj. více se obávají bezpečnosti dat), než doména skutečně vyžaduje.

ve světě databází NoSQL jsou transakce s kyselinou méně módní, protože některé databáze uvolnily požadavky na okamžitou konzistenci, čerstvost a přesnost dat, aby získaly další výhody, jako je měřítko a odolnost.
(Zejména .NET-based RavenDB má vzepřeli trendu mezi agregátní obchodech v podporu ACID transakcí.)
zde je návod, jak se základní zkratka rozpadá:
Základní dostupnost

• zdá se, že databáze funguje většinu času.

Soft-state

• obchody nemusí být konzistentní pro zápis, ani různé repliky nemusí být vzájemně konzistentní po celou dobu.

eventuální konzistence

• obchody vykazují konzistenci v nějakém pozdějším bodě (např. líně v době čtení).

ZÁKLADNÍ vlastnosti jsou mnohem volnější než KYSELINA záruky, ale tam není přímý one-for-one mapování mezi dvěma konzistence modelů (bod, který pravděpodobně nelze přeceňovat).
základní úložiště dat hodnotí dostupnost (protože to je důležité pro měřítko), ale nenabízí zaručenou konzistenci replikovaných dat v době zápisu. Celkově model základní konzistence poskytuje méně přísnou jistotu než ACID: data budou v budoucnu konzistentní, buď v době čtení (např. Riak), nebo budou vždy konzistentní, ale pouze pro určité zpracované minulé snímky (např. Datomické).
model základní konzistence je primárně používán agregovanými obchody, včetně sloupců, klíčových hodnot a obchodů s dokumenty.

navigace ACID vs. Základní kompromisy

neexistuje správná odpověď na to, zda vaše aplikace potřebuje model konzistence kyseliny versus báze. Vývojáři a datoví architekti by si měli vybrat své kompromisy konzistence dat případ od případu-nikoli na základě toho, co je trendy nebo jaký model byl dříve použit.
vzhledem k volné konzistenci základny musí být vývojáři více informovaní a důslední ohledně konzistentních dat, pokud si pro svou aplikaci zvolí základní úložiště. Je nezbytné se seznámit se základním chováním vybraného agregovaného obchodu a pracovat v rámci těchto omezení.
Na druhou stranu, plánování kolem základních omezení může být někdy hlavní nevýhodou ve srovnání s jednoduchostí kyselých transakcí. Plně kyselá databáze je ideální pro případy použití, kde je nezbytná spolehlivost a konzistence dat (bankovnictví, kdokoliv?).
V nadcházejících týdnech budeme ponořit do více KYSELINY/ZÁKLADNÍ specifika, pokud jde o souhrnné obchody a další graf technologií.

Dohnat zbytek Grafu Databází pro Začátečníky série:

• Proč Grafu Technologie Je Budoucnost
• Proč Připojených Datech Záleží,
• Základy Modelování Dat
• Modelování Dat Úskalí, aby se Zabránilo
• Proč Databáze, Dotazovací Jazyk Věcech (Víc, Než Si Myslíte)
• Nezbytné vs. Deklarativní Dotazovací Jazyky: Jaký je Rozdíl?
• Teorie Grafů & Prediktivní Modelování
• Graf Vyhledávací Algoritmus Základy
• Proč Potřebujeme NoSQL Databází
• Turné Agregátní Obchodech
• Další Graf Datových Technologií
• Nativní vs. Non-Nativní Graf, Technologie