Výběr správné databáze pro danou úlohu může být skličujícím úkolem, zvláště pokud bavíte celý prostor možností SQL a NoSQL. Pokud hledáte flexibilní, univerzální možnost, která umožňuje plynulá schémata a složité vnořené datové struktury, databáze dokumentů může být pro vás to pravé. MongoDB a Couchbase Server jsou dvě populární možnosti. Jak si vybrat
MongoDB kombinuje výhody nesmírné popularity, podpory jednoduchého vyhledávání grafů a schopnosti provádět dotazy SQL prostřednictvím konektoru BI. Couchbase má vlastní velkou komunitu uživatelů, výkonnou architekturu klíč-hodnota a dotazovací jazyk podobný SQL schopný navigovat ve vnořených strukturách dokumentů.
Stručně řečeno, MongoDB i Couchbase jsou výkonné a flexibilní databáze orientované na dokumenty se spoustou doplňků. To znamená, že mají důležité rozdíly, které naklánějí rovnováhu tak či onak, v závislosti na vašich potřebách. Abychom vám pomohli se rozhodnout, provedeme pochod těchto databází pomocí rukavice klíčových úvah, která pojednává o tom, jak každá z nich funguje s ohledem na instalaci a nastavení, správu, snadné použití, škálovatelnost a dokumentaci.
Tato diskuse je založena na MongoDB 3.4 a Couchbase Server 4.6. Můžete se také podívat na mé samostatné recenze MongoDB 3.4 a Couchbase Server 4.0.
Instalace a nastavení
Na instalaci a nastavení lze nahlížet ze dvou pohledů: vývojáři pracující proti místní instanci a inženýři infrastruktury nastavující počáteční produkční klastr. Mnoho databází NoSQL má silné příběhy o přívětivosti pro vývojáře, což zvyšuje šance vývojáře vyzkoušet produkt a zavést jej do svých systémů. Přímé místní nastavení je silným prodejním bodem. Na druhou stranu, databáze se v produkci nakonec osvědčí, takže nastavení produkce je stejně důležité, aby byla správná.
Nastavení vývojáře
Místo použití binárních souborů běžících na holém metalu se podíváme na to, co je potřeba k nastavení těchto dvou databází v prostředí Dockeru. Nastavení Dockeru pro MongoDB i Couchbase je docela jednoduché. Couchbase vyžaduje, aby bylo vystaveno několik dalších portů, ale je to jednoduchá záležitost. Jakmile se obrázky stáhnou dolů a kontejnery se spustí, v prostředí vývojářů je znatelný rozdíl. S MongoDB jste hotovi. Můžete se připojit prostřednictvím aplikace nebo prostředí Mongo a okamžitě začít pracovat. Couchbase vás naopak provede povinným procesem nastavení prostřednictvím uživatelského rozhraní, kde se potýkáte s řadou možností konfigurace zaměřených na inženýry infrastruktury. Jako vývojář si můžete ponechat vybrané možnosti a použít výchozí kbelík, ale přidává tření na zážitku.
MongoDB to vyhrává, ale ne bez výhrady. To, že místní nasazení bylo snadné, ještě neznamená, že můžete dělat totéž ve výrobě. Může se zdát zřejmé, že produkční prostředí vyžadují větší péči a konfiguraci, ale rozšířené výkupné útoky na nezabezpečené, veřejně přístupné instance MongoDB na začátku tohoto roku naznačují, že mnoho obchodů používá nebezpečné zkratky.
Vítěz kola: MongoDB.
Nastavení výroby
Nasazení distribuované databáze do výroby má tendenci zahrnovat mnoho kroků a spravedlivý stupeň koordinace; MongoDB a Couchbase se nijak neliší. V obou případech bude obtížnost instalace záviset na požadavcích nasazení, přičemž různé kompromisy výkonu budou zahrnovat různé úrovně složitosti.
Klastry MongoDB se budou skládat buď z repliky, nebo z horizontálně děleného klastru. Sada replik je skupina serverů MongoDB, které všechny obsahují stejná data, zatímco shardovaný cluster distribuuje data mezi několik sad replik. Sady replik se snadno konfigurují a skládají se z jediného typu serveru, který se má nasadit. Shardované clustery jsou více zapojeny a vyžadují nasazení tří různých typů serverů, kde je každý replikován. Klastry lze konfigurovat pomocí příznaků příkazového řádku, konfiguračních souborů a příkazů databáze.
Klastry Couchbase se mohou skládat z jednoho typu serveru nebo více typů serverů, v závislosti na výkonových charakteristikách, které od klastru potřebujete. Architektura Couchbase se skládá z různých služeb, které lze povolit nebo zakázat na základě jednotlivých uzlů. V jednoduchém scénáři povolíte všechny služby na všech uzlech. Pokud je však požadováno naladění potřeb každé služby nebo chcete každou službu škálovat samostatně, budete muset začít konfigurovat různé typy serverů, přidělit komoditní hardware pro datovou službu, SSD pro indexovou službu, CPU optimalizované pro dotazovací služba atd. Klastry lze konfigurovat pomocí integrovaného webového uživatelského rozhraní, rozhraní příkazového řádku a rozhraní REST API.
Pokud jde o produkční nastavení datové infrastruktury, MongoDB i Couchbase jsou poměrně jednoznačné. Jistě, můžete se ponořit do možností konfigurace a ladění a nikdy nevycházet, ale ve většině případů to bude pro inženýry infrastruktury jednodušší.
Vítěz kola: Kravata.
Správa
Jakmile je databáze spuštěna ve výrobě a přijímá provoz, stává se klíčovým problémem správa. Abych vyhodnotil snadnost správy, podívám se na proces zálohování, upgrady databáze a přístupy k monitorování.
Zálohy
Zálohy jsou důležitou součástí hygieny produkční databáze a běh databází vysoce dostupným a distribuovaným způsobem to nezmění.
MongoDB nabízí několik možností pro zálohování dat běžícího klastru. Pokud základní operační systém podporuje snímky point-in-time, můžete se spolehnout, že tato funkce zachytí zálohu v přesném okamžiku. To bude trochu složité pro zálohování shardovaných klastrů, protože budete muset pořídit sekundární snímek každého shardu a konfiguračního serveru současně.
Ke kopírování databázových souborů do jiného umístění lze použít nástroje na úrovni systému, jako je cp nebo rsync, ale kvůli povaze těchto nástrojů je nutné během procesu pozastavit zápisy. Ačkoli MongoDB je dodáván s nástroji příkazového řádku pro zálohování a obnovu databází, tyto nástroje se nedoporučují pro větší klastry. Alternativně můžete zaplatit za Cloud Manager nebo Ops Manager, nebo nasadit prostřednictvím platformy MongoDB Atlas DBaaS a získat nástroje založené na uživatelském rozhraní, které se postarají o zálohy a obnovení za vás.
Couchbase je dodáván s nástroji příkazového řádku pro zálohování dat z různých služeb a tyto lze nakonfigurovat tak, aby spouštěly úplné zálohy nebo dva druhy přírůstkových záloh. Přírůstkové zálohy mohou být přírůstkové od poslední úplné zálohy (kumulativní přírůstkové) nebo přírůstkové od poslední zálohy jakéhokoli druhu (rozdílové přírůstkové). To umožňuje složité zálohovací struktury, které vyžadují různé úrovně úložného prostoru a zahrnují různé úrovně složitosti obnovení.
Podnikoví zákazníci mohou čerpat z nástroje cbbackupmgr, který používá různé podkladové datové struktury k dosažení lepšího výkonu při zálohování dat.
Vítěz kola: Couchbase, díky své větší flexibilitě a podpoře přírůstkových záloh.
Aktualizace
Dlouhodobě fungující cluster by měl mít jasnou a snadnou cestu upgradu. Čím těžší je upgrade, tím méně je pravděpodobné, že bude udržován v aktuálním stavu. To znamená, že vývojářům i správcům budou chybět nové funkce.
Upgrady MongoDB lze nejlépe pochopit z úrovně sady replik. Pokud provozujete shardovaný cluster, většinou postupujte podle pokynů pro upgrade sad replik na každém horizontálním oddílu. V sadě replik je každá sekundární jednotka vypnuta, upgradována na místě a spuštěna. Jakmile jsou sekundární zařízení v provozu a jsou v souladu s primárním nastavením, je vyvoláno převzetí služeb při selhání a bývalý primární server může být odstraněn a upgradován. Spustí se znovu jako sekundární a dohoní zapomenuté zápisy, když je offline. Upgrady jsou tedy většinou online proces, ale primární převzetí služeb při selhání bude pravděpodobně mít za následek 10 až 20 sekund bez zápisu, takže je vyžadováno okno údržby s přijatelným prostojem.
Couchbase přistupuje k upgradům stejným způsobem, jako byste přidali nebo odebrali uzel z klastru. Všechna data upgradujícího uzlu musí být znovu vyvážena napříč klastrem, poté znovu vyvážena, když je aktualizace dokončena a uzel se znovu připojí ke klastru. K tomuto procesu vyvážení musí dojít u každého uzlu v klastru, jeden za druhým. Bude to trvat mnohem déle než upgrade clusteru MongoDB, kvůli všem datům, která se musí přesouvat. Další možností je přepnout celý cluster do režimu offline, upgradovat každý uzel a přivést je všechny zpět do režimu online.
Zatímco cesta k upgradu Couchbase vyžaduje nulové prostoje, proces je dlouhý a vyžaduje velké množství míchání dat, aby fungoval.
Vítěz kola: Kravata. Tiebreaker: Pokud je výpadek údržby přijatelný, pak MongoDB vyhrává. Pokud ne, pak je Couchbase jedinou volbou.
Monitorování
Viditelnost do běžícího klastru je samozřejmě nezbytná pro úspěšnou správu databáze. Když se věci zhoršují, není nic horšího, než mít omezený pohled na pravdu v kupě.
MongoDB nabízí nástroje a příkazy CLI v prostředí, které poskytují metriky o aktivitě a výkonu instance. Kromě toho vás MongoDB ochotně upozorní na nástroje třetích stran nebo vlastní podnikové produkty (Cloud Manager, Ops Manager, Atlas).
Couchbase se naproti tomu dodává s webovým uživatelským rozhraním, které obsahuje statistiky a vizualizace instancí, uzlů, výkonu dotazů a dalších. Couchbase lze navíc nakonfigurovat tak, aby odesílal e-mailová upozornění, když některé statistiky spadnou mimo rozsah.
Kolo vítěz: Couchbase, pro out-of-the-box vizualizace a upozornění.
Snadnost použití
Poté, co je databáze nastavena a jsou splněny všechny naše administrativní potřeby, se hlavní problém přesouvá z provozu na použití. Rozdělím to na modelování dat, návrh indexu, základní dotazování a agregace.
Datové modelování
Jako databáze dokumentů se MongoDB ani Couchbase nemohou vyhnout výzvě, jak zacházet s relačními daty. Oba nabízejí možnost ukládat relační data jako vnořená, denormalizovaná data i ve formě odkazů na další dokumenty nejvyšší úrovně. Tento přístup k ukládání dat končí jako hlavní hledisko pro modelování dat pro obě databáze, navzdory tomu, že každý podporuje rostoucí šířku případů použití, funkcí a vzorů dotazů.
Vítěz kola: Kravata.
Návrh indexu
Rejstříky plní stejnou funkci v databázích dokumentů jako v relačních databázích. To znamená, že představují určitá data efektivnějším způsobem, jak zvýšit výkon dotazu. MongoDB a Couchbase používají velmi odlišné přístupy k návrhu a tvorbě indexů.
MongoDB podporuje vytváření indexů pro jedno nebo více polí v dokumentu, což vám umožňuje určit pořadí a směr (vzestupně nebo sestupně) standardních indexů. Jako součást stejné syntaxe je také možné zahrnout speciální geoprostorové indexy a fulltextové indexy. Dotazovací stroj použije tyto indexy, předpony těchto indexů nebo kombinaci několika indexů k urychlení požadavků.
Couchbase spoléhá na dva různé mechanismy pro zlepšení výkonu dotazu: MapReduce zobrazení a globální sekundární index (GSI). Zobrazení MapReduce se skládají z uživatelsky definovaného kódu JavaScript, který zpracovává data při průchodu systémem, jako je přírůstková předběžná agregace. Zobrazení MapReduce mohou být stejně jednoduchá jako povolení vyhledávání dokumentů ve vnitřním poli, nebo mohou zahrnovat složitější logiku, která provádí výpočty a agregace dat v dokumentech.
Psaní MapReduce v JavaScriptu na podporu dotazů je trochu nepraktické, takže pokud je to možné, budete obecně chtít použít GSI. Indexy v GSI jsou popsány pomocí N1QL (vyslovuje se „nikl“), což je částečná implementace SQL nad Couchbase. Syntaxe N1QL je poměrně jasná a dotazy N1QL jsou mnohem lepší než MapReduce, ale index musíte umístit na konkrétní uzel. Pokud chcete, aby byl index vysoce dostupný, musíte jej ručně vytvořit na více než jednom uzlu.
Vítěz kola: MongoDB, za své konsolidované indexování API a schopnost úplně se vyhnout MapReduce.
Základní dotazy
Vzhledem k vhodnému datovému modelu je většina dotazů do databáze jednoduchá. Kromě operací CRUD, kde je známo ID dotyčného dokumentu, je důležité umět vyjádřit různé způsoby filtrování dokumentů a vybrat si pole, která nás zajímají.
MongoDB popisuje dotazy v JSON a poskytuje deklarativní syntaxi pro určení podmínek a filtrů v polích. Dokument dotazu se může skládat z libovolného počtu selektorů dotazů, které popisují, jak by výsledná sada měla vypadat. Rozsahy, rovnost, textové vyhledávání a geoprostorové dotazy lze definovat v tomto dokumentu dotazu. Dokument podporuje logické operátory, takže lze logicky spojit více klauzulí dotazu s A, NEBO, a tak dále. Dokument dotazu může rychle přerůst v silně vnořený dokument JSON, který může být občas ohromující a určitě si na něj zvykne. Je také možné použít projekce v dotazech, což vám umožní vrátit pouze pole, na kterých vám záleží, a zmenšit celkovou velikost výsledku přes drát.
