Hlavní navigace

MongoDB - závislost za 30 minut!

25. 3. 2015 0:05 (aktualizováno) sentan

Znáte to asi všichni. Dlouho se chcete na něco podívat, ale pořád je dost ostatní práce a pádný důvod to neustále odkládat. Pracuji již v IT více než 15 let a zabývám se především zpracováním dat a implementací systémů v podnikovém prostředí. Za celou dobu jsem pracoval s databázemi a BI aplikacemi od Oracle, Microsoftu a v poslední době, souběžně s přechodem k operačním systémům založených na Linuxu, jsem intenzivně začal využívat open source aplikace. Je jasné, že musím tedy zmínit i databázi MySql.

Naprosto všechny vyvíjené aplikace i systémy, na kterých jsem pracoval, byly založeny na relačních databázích. S myšlenkou seznámit se i s jiným typem databází (nebo jiných přístupů v oblasti zpracování dat) jsem se zabýval dlouho. Jediné, co jsem však učinil, byly jednoduché experimenty s data platformou  od Hortonworks. Zkoušel jsem i Clouderu, vždy jsem se vrátil však zpět k Hortonworks. Hlavním důvodem, proč se do toho nepouští člověk často, je nechuť ztrácet ten čas, než se vše nainstaluje, nakonfiguruje, najdou se data na zkoušení apod. Teprve pak se člověk dostane k tomu co chtěl dělat. V práci se pracuje, zbývají večery. Více večerů, rozhodně to nebývá pouze pár hodin než si tím vším člověk projde a může dělat experimenty.

Poměrně často mi klienti volají, zda bych jim „nepomohl s daty“. Často to znamená připravit nástroje na konverzi, sloučení, vyčištění a uložení do databáze, ze které vše přetáhnou k sobě do systému. Přesně takový požadavek jsem opět dostal. Soubor dat se skládal z 28 HDD, které byly v rámci upgrade výrobních linek nahrazeny novým řešením. Nové řešení už je navíc online připojené k datovému skladu a ze všech výrobních linek se data nyní shromažďují a ukládají a analyzují pro každou šarži produkčních dávek. Historické záznamy z vyřazených jednotek tedy, alespoň pro posledních 8 let, bylo třeba zpracovat a migrovat do datového skladu.

Objem dat nebyl problém (jen asi 70GB celkem). Oříšek spočíval především v interpretaci uložených dat a v transformaci. Nové řešení, podporované dodavatelem, data poskytuje ve formátu JSON. Historické záznamy ale byly kombinace binárních a textových dat zachycených na sběrnici, přímo uložených bez dalších úprav. Dispečer měl pouze možnost přes starou ovládací aplikaci sledované parametry a stavy kontrolovat, tuto možnost musela vždy servisní firma zadrátovat přímo do kódu. V průběhu osmi let byl počet linek rozšiřován a i linky samotné byly upravovány. Tzn. co linka a období, to drobné nuance ve významu a struktuře zaznamenaných dat. Navíc s každou rekonfigurací linky docházelo ke změnám v přijímaných větách dat z řídících a monitorovacích jednotek (další bloky od nově instalovaných senzorů apod.). Prostě děs běs pro uložení v klasické relační databázi.

Pak jsem uviděl ve správnou chvíli MONGO! 

Ne že by MONGO bylo to jedno jediné správné řešení! Pouze mi přišlo pod ruku ve správný okamžik. Právě tehdy, když už bylo jasné, že navrhnout relační databázi by byl vzhledem k formátu a struktuře historických dat velký oříšek.

Hlavním argumentem pustit se do experimentu byla možnost uložit data do databáze v prvním kroku bez nutnosti připravovat schéma databáze. Už po analýze dat z pouhé jedné  výrobní linky bylo jasné, že by to pro tuto „jednoúčelovou“ operaci migrace dat zabralo příliš mnoho času. Bez benefitu, že to bude snadno použitelné pak přímo v datovém skladu. Mongo nabízelo toto:

  • NEPOTŘEBUJE SCHÉMA – jako dokumentová databáze nepotřebuje mít definované jednotné schéma (každý záznam – tedy dokument), může mít jinou strukturu. Nové čidlo, ovládací prvek, nebo i blok takových prvků na jiné adrese je v DB uložený jako nový klíč nebo jako samostatná větev (objekt). Bez nutnosti zahrnout toto do návrhu schématu jak je tomu u relačních databází – nemluvě pak o rekurzích při ukládání apod.
  • KOMUNITA VÝVOJÁŘŮ – téměř pro všechny operace a kroky, které jsem potřeboval, jsem už mohl ihned využít postřehy vývojářů, kteří podobné problémy už řešili. V porovnání třeba s MySQL rozsah a detail témat to pro Mongo není zase až tak velký, nepředstavovalo to ale žádný problém. Vždy jsem našel co jsem potřeboval.
  • EXISTUJE JAVA DRIVER – historická data v původním formátu bylo nutné nejdříve načíst, transformovat do formátu dokumentu (JSON) a vložit do databáze. Java se mi pro tyto účely osvědčila především proto, že ji pak lze spouštět jak na libovolném OS (pokud se musíte přizpůsobovat operačním systémům používanými klienty, víte o čem mluvím).
  • JAVASCRIPT SHELL – veškeré operace v databázi (místo SQL) provádíte jednoduše v JS. Vytvořil jsem si závislost na Db.schema.find().forEach.
  • READY TO USE SYSTEM – abych si nemusel procházet instalací, konfigurací,…apod., využil jsem možnosti stáhnout si hotový systém a ihned ho používat. V mém případě to byla volba TurnKey GNU/Linux (s MongoDB). Jejich LAMP používám na experimenty a i k práci vemi často, verze s MongoDB je tomu velmi podobná.

 Jak to dopadlo?

Dobře! Veškerá historie dat je nyní v jedné databázi, snadno přístupná a téměř 95% dat (ze struktury, nikoliv objemu!) se podařilo úspěšně integrovat do datového skladu. Vypadalo a začínalo jako nesmělý experiment, prvních 30 minut. To byl přesně ten čas, kdy jsem pořád ještě viděl možnost udělat krok zpět a vrátit se k relační databázi. Po půl hodině jsem měl zprovozněnou plnododnotnou Mongo databázi a z diskuzních serverů bylo jasné co a jak budu dělat.

Výsledek už je to nedílnou součástí analytických dat. Nejzajímavější je ale skutečnost, že tímto to vše nekončí. V MongoDB (když už jsem to měl rozchozené) jsem udělal ještě několik dalších experimentů:

  • Zpracování geografických dat – kdo někdy dělal aplikaci v DB pro vyhledávání nejbližších bodů dle GPS souřadnic ví, o co to znamená. Nicméně to ještě jde poměrně snadno. Hledat pak ale nejbližší body k o objektu (shape), nebo přímo zjišťovat, zda se bod nalézá v daném útvaru… to už je komplikovanější. Mongo tohle vše umí, snadno a rychle!
  • Vyhodnocení sentimentu z českých recenzí – na webu lze najít mnoho příkladů s daty ze sítě Twitter (anglické texty, Hortonworks Hadoop). Relativně triviální metodou se za použití slovníku pozitivních a negativních výrazů to samé dá udělat i v Mongu. Pro změnu ale česky.
  • Využití MapReduce – z Hadoopu jsem už měl nějaké zkušenosti s tímto přístupem pro zpracování dat. Teprve na MongoDB jsem si to zažil a dokonce byl schopný to vysvětlit na příkladech snadno kolegům.

Nejhorší je začátek – pak už to jde tak nějak samo. Výsledkem experimentů je řada poznatků, které jsem tím získal. Pořád mám testovací data. Pokud zde bude zájem, rád se o vše podělím. MongoDB mám nyní jako oblíbenou alternativu pro řešení, která se v relačních databázích nedělají snadno (v porovnaní s NoSQL apod.).

 

 

 

 

Sdílet