it-swarm-eu.dev

Proč nemohou relační databáze splňovat měřítka velkých dat?

Často se opakuje, že problém velkých dat spočívá v tom, že relační databáze nemohou škálovat zpracování obrovských objemů dat, která jsou nyní vytvářena.

Jaká jsou však tato omezení škálovatelnosti, na která nejsou řešení Big Data, jako je Hadoop, vázáni? Proč nemohou Oracle RAC nebo MySQL sharding nebo MPP RDBMS jako Teradata (atd.) Dosáhnout těchto výkonů?

Zajímám se o technická omezení - jsem si vědom toho, že finanční náklady na seskupování RDBMS mohou být neúnosné.

17
Jeremy Beard

MS právě mělo v Nizozemsku tech talk , kde diskutovalo o některých těchto věcech. Začíná pomalu, ale dostane se do masa Hadoop kolem 20 minutové značky.

Hlavní myšlenkou je, že „záleží“. Pokud máte rozumně uspořádané (alespoň poněkud) snadno rozdělitelné soubory dat, které (alespoň poněkud) jsou homogenní, mělo by být poměrně snadné škálovat na velké objemy dat pomocí RDBMS, v závislosti na tom, co děláte .

Zdá se, že Hadoop a MR jsou více zaměřeni na situace, kdy jste nuceni provádět velké distribuované skenování dat, zejména pokud tato data nemusí být nutně tak homogenní nebo strukturovaná jako to, co najdeme ve světě RDBMS.

Jaká omezení nejsou řešení Big Data vázána? Pro mě je největším omezením, na které nejsou vázáni, nutnost předem vytvořit přísné schéma. S řešeními Big Data nyní nyní do pole „vkládáte“ obrovské množství dat a později přidáváte logiku do svých dotazů, abyste se vypořádali s nedostatkem homogenity dat. Z pohledu vývojáře je kompromisem snadná implementace a flexibilita na front-end projektu, versus složitost dotazování a menší okamžitá konzistence dat.

15
Dave Markle

Databázový průkopník a výzkumník Michael Stonebraker společně napsal příspěvek , který pojednává o omezeních tradičních databázových architektur. Obecně se rozšiřují s dražším hardwarem, ale mají problémy s rozšiřováním paralelně s více komoditním hardwarem a jsou omezeni starší softwarovou architekturou, která byla navržena pro starší éru. Tvrdí, že éra BigData vyžaduje více nových architektur databází, které využívají moderní infrastruktury a optimalizují pro konkrétní pracovní vytížení. Příkladem toho je projekt C-store, který vedl k komerční databázi Vertica Systems, a projekt H-store, který vedl k VoltDB, in-memory OLTP SQL databáze určené pro vysokou rychlost) Pracovní zatížení BigData (úplné zveřejnění, pracuji pro VoltDB).

Tento webinář je pro toto téma zajímavý. Reaguje na některé mýty, které vznikly s úspěchem databází NoSQL. V podstatě tvrdí, že SQL nebyl problém, nemělo by být nutné vzdát se tradičních databázových funkcí, jako je konzistence, aby se získal výkon.

6
BenjaminBallard

Není úplně pravda, že RDBMS nemůže škálovat. Částečná pravda v prohlášení však závisí na architektuře. V seznamu, který jste uvedli, se Oracle RAC liší od ostatních (sharded MySQL a Teradata). Hlavním rozdílem je sdílený disk vs architektury sdílených nic.

Architektury sdílených disků, jako je Oracle RAC, trpí škálováním, protože v určitém okamžiku nebo v jiném by všechny spuštěné stroje měly synchronizovat část dat. Například globální zámek zámku je vrah. Můžete to do určité míry doladit, ale nakonec narazíte na zeď. Pokud nemůžete snadno přidat stroje, měli byste mít méně, ale super výkonných strojů, které by mohly spálit vaši kapsu. V případě sdílené architektury nic (nebo sharded data), každý počítač převezme vlastnictví některých dat. Pokud chcete aktualizovat některá data, nemusí se synchronizovat s jinými mahciny.

Pak přichází plemeno databází NoSQL. Zacházel bych s nimi jako s podskupinou tradičních RDBMS databází. Ne všechny aplikace v tomto světě budou potřebovat všechny funkce, které nabízí RDBMS. Pokud chci použít databázi jako mezipaměť, nestarám se o trvanlivost. Mohlo by to být v některých případech i o důslednost. Pokud jsou všechna data vyhledávání založena na klíči, nepotřebuji podporu pro dotazy na rozsah. Možná nepotřebuji sekundární indexy. Nepotřebuji celou vrstvu pro zpracování dotazů/optimalizaci dotazů, kterou mají všechny tradiční databáze.

5
sunil