Hadoop získává velkou část kreditu za velké objemy dat, ale realita je taková, že databáze NoSQL jsou mnohem širší - a mnohem širší - rozvinuty. Ve skutečnosti je nakupování u dodavatele Hadoop relativně jednoduché, výběr databáze NoSQL je něco jiného než. Koneckonců existuje více než 100 databází NoSQL, jak ukazuje hodnocení popularity databáze DB-Engines.
Které byste si měli vybrat?
Zkažený na výběr
Protože si musíte vybrat. Jak je hezké žít ve šťastné utopii tzv. Polyglotové perzistence, „kde každý slušný podnik bude mít řadu různých technologií pro ukládání dat pro různé druhy dat,“ jak tvrdí Martin Fowler, realita je nemůžete si dovolit investovat do učení více než pár.
Naštěstí je výběr snazší, protože trh se spojuje kolem tří dominantních databází NoSQL: MongoDB (podporovaný mým bývalým zaměstnavatelem), Cassandra (primárně vyvinutý společností DataStax, ačkoli se vylíhla na Facebooku) a HBase (úzce propojený s Hadoopem a vyvinutý stejná komunita).
Všimněte si, že záměrně vylučuji Redis z tohoto seznamu. I když je skvělým úložištěm dat, používá se primárně pro ukládání dat do mezipaměti a není vhodný pro širokou škálu úloh.
Údaje z LinkedIn od 451 Research ukazují, jak trh gravituje na MongoDB, Cassandra a HBase:
To jsou údaje z profilu LinkedIn. Úplnějším pohledem je databáze DB-Engines, která agreguje úlohy, vyhledávání a další data, aby pochopila popularitu databáze. Zatímco Oracle, SQL Server a MySQL vládnou na nejvyšší úrovni, MongoDB (č. 5), Cassandra (č. 9) a HBase (č. 15) jim dávají peníze.
I když je příliš brzy na to, abychom nazvali každou druhou databázi NoSQL chybou zaokrouhlování, rychle se dostáváme k tomuto bodu, přesně tak, jak se to stalo na trhu relačních databází.
Abych lépe pochopil, proč tyto tři databáze září, požádal jsem zástupce každého z nich, aby identifikovali klíčové atributy jejich úspěchu: Kelly Stirman, ředitel produktů MongoDB; Patrick McFadin, vedoucí evangelista Cassandra ve společnosti DataStax; a Justin Kestelyn, senior ředitel vývojářských vztahů ve společnosti Cloudera.
Nejprve ale musíme pochopit, proč je NoSQL důležité.
Svět postavený na nestrukturovaných datech
Stále více žijeme ve světě, kde data nezapadají pěkně do uklizených řádků a sloupců RDBMS. Mobilní, sociální a cloudové výpočty způsobily obrovskou záplavu dat. Podle různých odhadů bylo za poslední dva roky vytvořeno 90 procent světových dat, přičemž Gartner 80 procent všech podnikových dat fixoval jako nestrukturované. A co víc, nestrukturovaná data rostou dvojnásobnou rychlostí než strukturovaná data.
Jak se svět mění, požadavky na správu dat přesahují efektivní rozsah tradičních relačních databází. První organizace, které sledovaly potřebu alternativních řešení, byli průkopníci webu, vládní agentury a společnosti specializující se na informační služby.
Společnosti všech skupin se stále častěji snaží využít výhod alternativ, jako jsou NoSQL a Hadoop: NoSQL k budování provozních aplikací, které řídí jejich podnikání prostřednictvím systémů zapojení, a Hadoop k budování aplikací, které retrospektivně analyzují jejich data a pomáhají poskytovat výkonné poznatky .
MongoDB: Z vývojářů, pro vývojáře
Mezi možnostmi NoSQL, jak uvádí Stirman z MongoDB, se MongoDB zaměřil na vyvážený přístup vhodný pro širokou škálu aplikací. Zatímco funkčnost je blízká funkčnosti tradiční relační databáze, MongoDB umožňuje uživatelům těžit z výhod cloudové infrastruktury díky její horizontální škálovatelnosti a díky flexibilnímu datovému modelu snadno pracovat s různými datovými sadami, které se dnes používají.
MongoDB je často první vývojář NoSQL databáze, který se pokusí, protože je tak snadné se ho naučit. Will Shulman, generální ředitel MongoLab (poskytovatel služby MongoDB jako služba), to říká takto:
Nepřiměřený úspěch MongoDB je do značné míry založen na jeho inovaci jako úložiště datové struktury, která nám umožňuje snadněji a expresivně modelovat „věci“ v jádru našich aplikací….
Mít stejný základní datový model v našem kódu a v databázi je pro většinu případů použití lepší metodou, protože to dramaticky zjednodušuje úkol vývoje aplikace a eliminuje vrstvy komplexního mapovacího kódu, které jsou jinak vyžadovány.
Je pozoruhodné, že MongoDB, stejně jako ostatní databáze na tomto seznamu, není poník s jedním trikem. Podniky, které se učí MongoDB „mohou amortizovat své investice do MongoDB v mnoha projektech, což z něj činí jeden z krátkého seznamu standardů, na které se spoléhají pro veškerou správu dat,“ řekl mi Stirman.
Samozřejmě jako každá technologie má MongoDB své silné a slabé stránky. MongoDB je určen pro úlohy OLTP. Může dělat složité dotazy, ale nemusí to být nejvhodnější řešení pro úlohy ve stylu reportingu. Nebo pokud potřebujete složité transakce, nebude to dobrá volba. Díky jednoduchosti MongoDB je to skvělé místo pro začátek.
Cassandra: Bezpečně běžte ve velkém
Existují nejméně dva druhy jednoduchosti databáze: vývojová a provozní. Zatímco MongoDB oprávněně získává uznání za snadný provoz ihned po vybalení z krabice, Cassandra získává plné známky za snadnou správu v měřítku.
Jak mi řekl McFadin z DataStaxu, uživatelé mají tendenci gravitovat ke Cassandře, čím víc se opírají o potíže s rychlejším a spolehlivějším vytvářením relačních databází, zejména v měřítku. McFadin, bývalý Oracle DBA, byl nadšený, když zjistil, že „replikace a lineární škálování jsou primitivní“ s Cassandrou a funkce byly „primárním cílem designu od začátku.“
Ve světě RDBMS jsou funkce databáze, jako je změna měřítka a replikace, těžkou částí ponechanou uživateli. Ve včerejším podniku to fungovalo dobře, když měřítko nebylo velkým problémem. Dnes se rychle stává the problém.
Jak jsem slyšel od McFadina a dalších, Cassandra obzvlášť zářila ve škálovatelném nasazení. Cassandra přichází s integrovanou podporou pro více datových center. Pokud jde o přidání kapacity do klastru, „jednoduše nastartujete nový stroj a řeknete Cassandře, kde jsou další uzly,“ řekl McFadin, „a o zbytek se postará.“
Toto snadné škálování spolu s výjimečným výkonem zápisu („Vše, co děláte, je připojení na konec souboru protokolu“) a předvídatelným výkonem dotazů, přispívá k vysoce výkonnému pracovnímu koni v Cassandře.
Jeden článek o víře v NoSQL, který už dlouho zastávám, je, že Cassandra může být mocná v měřítku, ale pro začátek je zapotřebí doktorát. Není tomu tak, McFadin trval na tom:
Cesty replikace a čtení a zápisu jsou záměrně jednoduché. Základní vnitřní součásti Cassandry se můžete naučit za pár hodin. To vám při nasazování nové technologie může přinést velkou jistotu, protože existuje méně detailů „černé skříňky“, které zavádějí složité režimy selhání.
To znamená, že cena za přijetí k efektivnímu vývoji Cassandry je v porozumění datovému modelu a v tom, jak bude fungovat s vaší aplikací. Vzhledem k povědomí dotazovacího jazyka CQL Cassandry (který má být „přesně jako SQL, kromě případů, kdy to není“), řekl McFadin, není to strmá křivka učení.
Ještě důležitější je, řekl mi: „Cassandra vás odmění za jednu věc, kterou chcete z databáze: žádné drama. To je důvod, proč uživatelé rádi používají Cassandru. “
HBase: Bosom kamarádi s Hadoop
HBase, stejně jako Cassandra, sloupcově orientovaný obchod s hodnotami klíčů, má velké využití díky svému společnému rodokmenu s Hadoop. Ve skutečnosti, jak uvedl Kestelyn od společnosti Cloudera, „HBase poskytuje vrstvu úložiště založenou na záznamech, která umožňuje rychlé, náhodné čtení a zápis do dat, což doplňuje Hadoop zdůrazněním vysoké propustnosti na úkor I / O s nízkou latencí.“
Kestelyn pokračuje:
Změny jsou efektivně katalogizovány v paměti, aby se dosáhlo maximálního přístupu, zatímco se data uchová na HDFS. Tento design umožňuje EDH [podnikové datové centrum] založené na Hadoopu, aby poskytovalo náhodné čtení a zápisy uživatelům a aplikacím v reálném čase, a přesto si užívalo odolnost vůči chybám a odolnost HDFS.
Příbuznost s Hadoop není jediným důvodem, proč HBase stále roste v řadách popularity databáze, i když to může stačit. Podobně jako Cassandra, kořeny HBase jako open source implementace Google Bigtable se promítají do databáze, která je designově vysoce škálovatelná.
Protože může využívat úložiště, paměť a prostředky CPU libovolného počtu serverů a má také funkce škálování, jako je automatické dělení, může HBase neomezeně škálovat, protože požadavky na zatížení a výkon se zvyšují jednoduše přidáním uzlů serveru. HBase byl od základu navržen tak, aby poskytoval optimální výkon při kritické konzistenci.
Měřítko však není jen užitečnost. Jak poznamenal Kestelyn, „Díky těsné integraci se zbytkem ekosystému Hadoop jsou data snadno dostupná uživatelům a aplikacím prostřednictvím dotazů SQL (pomocí Cloudera Impala, Apache Phoenix nebo Apache Hive) nebo dokonce pomocí hledání volného textu (pomocí Cloudera Search). “ HBase tedy dává vývojářům způsob, jak využít stávající odborné znalosti s SQL a stavět na modernější distribuované databázi.
Každá databáze má své silné stránky a nedostatky, ale každá ze tří zde profilovaných vyplnila hlavní díru v prostředí velkých dat. I když je možné, že si nová databáze přijde na své místo v první trojce NoSQL (DynamoDB?), Realita je taková, že vývojáři a podniky, kterým slouží, již standardizují několik silných možností: MongoDB, Cassandra a HBase.
Matt Asay, viceprezident pro mobil ve společnosti Adobe, byl dříve viceprezidentem komunity ve společnosti MongoDB, Inc. Je emeritním členem správní rady Open Source Initiative (OSI) a získal doktorát z jurisdikce ve Stanfordu, kde se zaměřil na open source a další problémy s licencemi na duševní vlastnictví a magisterský titul z University of Kent v Canterbury a jeho bakalářský titul z Brigham Young University. Asay byla jednou z prvních blogerek.
Nové technologické fórum poskytuje místo, kde můžete prozkoumat a diskutovat o nově vznikajících podnikových technologiích v nebývalé hloubce a šíři. Výběr je subjektivní, založený na našem výběru technologií, které považujeme za důležité a pro čtenáře nejzajímavější. nepřijímá marketingové materiály ke zveřejnění a vyhrazuje si právo upravovat veškerý přispěný obsah. Všechny dotazy zasílejte na [email protected].
