it-swarm-eu.dev

Co je databáze úložiště klíčů a hodnot?

Díval jsem se na stránku wikipedia pro NoSQL a uvádí několik variací v databázi úložiště klíčů a hodnot, ale v tomto kontextu nemohu najít žádné podrobnosti o tom, co to znamená úložiště klíčů a hodnot. Mohl by mi někdo vysvětlit nebo spojit vysvětlení? Kdy bych také použil takovou databázi?

56
indyK1ng

Znáte koncept dvojice klíč/hodnota? Za předpokladu, že jste obeznámeni s Java nebo C # je to v jazyce jako mapa/hash/datatable/KeyValuePair (poslední je v případě C #)

Jak to funguje, je ukázáno v této malé ukázkové tabulce:

Color        Red
Age          18
Size         Large
Name         Smith
Title        The Brown Dog

Pokud máte klíč (vlevo) a hodnotu (vpravo) ... všimněte si, že to může být řetězec, int nebo podobně. Většina objektů KVP vám umožňuje uložit jakýkoli objekt napravo, protože je to jen hodnota.

Protože vždy budete mít jedinečný klíč pro konkrétní objekt, který chcete vrátit, stačí dotazovat databázi pro tento jedinečný klíč a získat výsledky zpět od kteréhokoli uzlu, který má objekt (proto je to dobré pro distribuované systémy, protože se jedná o jiné věci, jako je dotazování pro první uzly, které vrátí hodnotu, která odpovídá návratům ostatních uzlů).

Nyní je můj výše uvedený příklad velmi jednoduchý, takže zde je o něco lepší verze KVP

user1923_color    Red
user1923_age      18
user3371_color    Blue
user4344_color    Brackish
user1923_height   6' 0"
user3371_age      34

Jak vidíte, jednoduché generování klíčů je dát uživateli „uživatelské“ číslo, podtržítko a objekt. Opět se jedná o jednoduchou variantu, ale myslím si, že začneme chápat, že pokud dokážeme definovat část nalevo a nechat ji konzistentně naformátovat, můžeme hodnotu vytáhnout.

Všimněte si, že neexistuje žádná omezení na hodnotu klíče (ok, mohou existovat určitá omezení, například pouze text) nebo na vlastnost value (může existovat omezení velikosti), ale zatím jsem neměl opravdu složité systémy. Zkusme to trochu dál:

app_setting_width      450
user1923_color         Red
user1923_age           18
user3371_color         Blue
user4344_color         Brackish
user1923_height        6' 0"
user3371_age           34
error_msg_457          There is no file %1 here
error_message_1        There is no user with %1 name
1923_name              Jim
user1923_name          Jim Smith
user1923_lname         Smith
Application_Installed  true
log_errors             1
install_path           C:\Windows\System32\Restricted
ServerName             localhost
test                   test
test1                  test
test123                Brackish
devonly
wonderwoman
value                  key

Získáte představu ... všechny by byly uloženy v jedné masivní „tabulce“ na distribuovaných uzlech (za tím je matematika) a jednoduše byste požádali distribuovaný systém o hodnotu, kterou potřebujete podle jména.

Přinejmenším to je moje chápání toho, jak to funguje. Možná se mýlím pár věcí, ale to jsou základy.


povinný odkaz na wikipedii http://en.wikipedia.org/wiki/Associative_array

42
jcolebrand

Z hlediska SQL je databáze NoSQL jedna tabulka se dvěma sloupci: jeden je (primární) klíč a druhý je hodnota. A to je vše, to je magie NoSQL.

NoSQL byste použili z jednoho hlavního důvodu: škálovatelnosti.

Pokud vaše aplikace potřebuje zpracovat miliony dotazů za sekundu, jediným způsobem, jak toho dosáhnout, je přidat další servery. To je s NoSQL velmi levné a snadné. Naproti tomu škálování tradiční databáze SQL je mnohem složitější.

Pouze největší webové stránky tam skutečně využívají plný potenciál NoSQL, tj. Facebook, kde běží tisíce serverů Cassandra .

Důrazně doporučujeme přečíst tento blogový příspěvek, který porovnává SQL, NoSQL a ORM:

http://seldo.com/weblog/2010/07/12/in_defence_of_sql

25
vz0

Předpokládám, že máte základní znalosti o pohybech NoSQL a ne-relačních databázových modelech.

Úložiště klíčových hodnot je jedním z nesouvislých databázových modelů, jako je graf, databázové modely orientované na dokumenty.

kládá klíčovou hodnotu a pohyb NoSQL

Obecně se SQL dokázalo vypořádat se speciálně strukturovanými daty a umožnilo vysoce dynamické dotazy podle potřeb příslušného oddělení.

I když v této konkrétní oblasti stále neexistují skuteční konkurenti pro SQL, případ použití v každodenních webových aplikacích je jiný. Na velkých stolech nenajdete vysoce dynamický rozsah dotazů plných vnějších a vnitřních spojení, spojení a složitých výpočtů. Obvykle najdete velmi objektově orientovaný způsob myšlení. Zejména s přijetím takových vzorů, jako je MVC, nejsou data v pozadí obvykle modelována pro databázi, ale pro logickou integritu, která také lidem pomáhá zvládat porozumění obrovským softwarovým infrastrukturám. Co se dělá, aby se tyto objektově orientované modely dostaly do relačních databází, je velké množství normalizace, které vede ke složitým hierarchiím tabulek a zcela se řídí proti hlavní myšlence objektového programování. Servery, které dodržují standard SQL, musí také implementovat velkou část kódu, který není k jednoduchému ukládání dat k ničemu, a tak nafoukne pouze stopu paměti, bezpečnostní rizika a výsledkem je výkonnostní zásahy.

Skutečnost, že SQL umožňuje libovolné dynamické dotazy na složité soubory dat, se stává zbytečnou pomocí databáze SQL pouze pro trvalé ukládání objektově orientovaných dat, což je v současné době většina aplikací.

Zde vstupují do hry obchody Key Value. Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship. Samotná data jsou obvykle jakýmsi primitivem programovacího jazyka (řetězec, celé číslo, pole) nebo objektem, který je spojen vazbami programovacích jazyků do úložiště klíčové hodnoty. Nahrazuje to potřebu pevného datového modelu a snižuje se požadavek na správně formátovaná data.

They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval. Největší rozdíl pro „jednodušší“ obchody je způsob, jakým můžete (nebo nemůžete) autentizovat nebo přistupovat k různým obchodům (pokud je to možné). Zatímco rychlostní výhody při ukládání a získávání dat mohou být důvodem, proč je zvážit nad běžnými databázemi SQL, další velkou výhodou, která se objeví při používání úložišť klíč-hodnota, je to, že výsledný kód má tendenci vypadat čistě a jednoduše ve srovnání s vloženými řetězci SQL v váš programovací jazyk. To je něco, co lidé mají tendenci bojovat s objektově relačními mapovacími rámcimi, jako je Hibernace nebo Aktivní záznam. Zdá se, že mít objektové relační mapovače v podstatě napodobují úložiště klíčových hodnot přidáním hodně opravdu složitého kódu mezi databází SQL a objektově orientovaným programovacím jazykem.

Celá komunita lidí se schází pod značkou „ NoSQL “ a diskutuje o těchto výhodách a nevýhodách použití alternativ k relačním systémům správy databází. číst více
Tohle je trochu starý článek, ale zjistil jsem, že je velmi užitečný.

when would I use such a database?Could someone explain or link an explanation to me?
Je to více architektonické rozhodnutí a diskutabilní ... Musíte zvážit spoustu faktorů, jako je škálovatelnost, výkon atd. ...

Podívejte se níže na snímky/články a získáte představu, kdy, proč a proč nepoužít úložiště klíčových hodnot :)

14
CoderHawk

Jiní to vysvětlili, ale stejně to udělám.

Databáze klíč/hodnota ukládá data pomocí primárního klíče. To nám umožňuje jednoznačně identifikovat záznam v kbelíku. Protože jsou všechny hodnoty jedinečné, vyhledávání jsou neuvěřitelně rychlá: je to vždy jednoduché hledání disku.

Hodnota je jen jakákoli hodnota. Způsob uložení dat je neprůhledný pro samotnou databázi. Když ukládáte data do úložiště klíčů a hodnot, databáze neví, zda je to XML, JSON, text nebo obrázek. Ve skutečnosti to, co děláme v úložišti klíčů a hodnot, přesouvá odpovědnost za pochopení toho, jak jsou data ukládána z databáze do aplikací, které získávají naše data. Vzhledem k tomu, že máte pouze jednu řadu klíčů, o které byste se měli starat v jednom kbelíku, je velmi snadné rozložit klíče na mnoho serverů a pomocí technik distribuovaného programování umožnit rychlý přístup k těmto datům (každý server ukládá řadu dat) .

Nevýhodou tohoto přístupu k datům je, že vyhledávání je velmi obtížný úkol. Musíte si buď přečíst každý záznam v kbelíku o 'data, nebo jinak musíte vytvořit sekundární indexy sami.

Existuje několik důvodů, proč byste mohli chtít použít databázi klíčů a hodnot:

  • Když je výkon zápisu nejvyšší prioritou. Mozilla Test Pilot používá databázi klíč/hodnota k rychlému záznamu dat.
  • Pokud je zaručeno, že čtení bude probíhat pouze pomocí PK.
  • Když pracujete s plochým datovým modelem.
  • Pokud pracujete s bohatým a komplexním datovým modelem, který nelze modelovat v RDBMS.

Existuje asi tolik důvodů, proč používat databázi klíč/hodnota, jako je použití RDBMS a existuje tolik argumentů, které odůvodňují jeden nad druhým. Je důležité se podívat, jak zadáváte dotazy na data, a pochopit, jak tento vzorec přístupu k datům vede, jak budete vkládat a ukládat data.

Nezapomeňte, že databáze klíčů a hodnot je pouze jedním typem databáze NoSQL.

12
Jeremiah Peschka

Pokud máte relační databázi, můžete s ní snadno experimentovat:

create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);

Takto byly všechny databáze, s Berkeley DBM je dobrým příkladem, od roku 1979. Od té doby se věci zlepšily (můžete mít mnoho hodnoty na klíč v libovolném RDBMS). Pro mnoho aplikací postačuje úložiště klíč-hodnota (např. Takto ukládá sendmail své aliasy). Pokud však zjistíte, že předběžně zpracováváte hodnotu ve svém vlastním kódu (nebo zřetězené řetězce, abyste vytvořili svůj „klíč“), možná rozdělíte hodnotu na oddělovač nebo ji rozložíte, než ji budete moci použít, pravděpodobně bude lepší RDBMS a skutečně to tak ukládat.

8
Gaius