Nedávno jsem měl příležitost udělat rozhovor s Orenem Einim, generálním ředitelem a zakladatelem Hibernating Rhinos, který poskytuje RavenDB, open source, dokumentově orientovaný NoSQL navržený speciálně pro platformu .NET/Windows.
Oren má více než 20 let zkušeností ve světě vývoje se silným zaměřením na ekosystém Microsoft a .NET. Oren, který je od roku 2007 uznáván jako jeden z nejhodnotnějších profesionálů společnosti Microsoft, je také autorem „DSLs in Boo:Domain Specific Languages in .NET“. Často vystupuje na průmyslových konferencích, jako jsou DevTeach, JAOO, QCon, Oredev, NDC, Yow! a Progressive.NET.
Celý rozhovor si můžete přečíst níže:
1. V tomto digitalizovaném světě se data stala jedním z nejcennějších aktiv. a proto je způsob, jakým jsou data ukládána, organizována a zpracovávána, rozhodující pro úspěch podnikání. Jak jsou společnosti bombardovány stále větším množstvím dat, ukládání dat a analýzy jsou stále složitější. Můžete nám prozradit některé z běžných výzev, kterým dnes podniky čelí při správě databází?
Domnívám se, že hlavním problémem je pouhá velikost dat. Nemluvím nutně o velkých datech a složitosti správy datové sady měřené ve stovkách terabajtů. Mluvím o počtu databází a datových sil, které máte v organizaci. Vzhledem k tomu, že je vše digitální, máte k dispozici důležité obchodní funkce, které jsou umístěny v excelové tabulce na sdíleném disku a historická data o nákupech zákazníků na serveru, ke kterému se nikdo nechce přiblížit ze strachu z převzetí vlastnictví.
Už jen zjistit, co organizace jako celek ví, může být složitý úkol. Prokluzování dat mezi trhlinami je bohužel běžné.
Pokusy o vytvoření centralizovaného úložiště pro celou společnost jsou rovněž odsouzeny k neúspěchu. Různé části společnosti mají velmi odlišné představy o zdánlivě samozřejmých věcech. Například fakturační oddělení má velmi odlišnou představu o tom, co je zákazník, než marketingové oddělení. Snaha o to, aby data odpovídala běžné formě, dělá každému medvědí službu.
2. Jak tyto výzvy překonáme? Myslíte si, že výběr efektivního řešení pro správu databází je prvním krokem? A proč?
Prvním krokem je definovat na organizační úrovni vlastnictví dat a pravidla odpovědnosti. Na nejzákladnější úrovni fakturace vlastní koncept toho, co je zákazník ve stavu OverduePayment, a Marketing vlastní zájmy zákazníka. Cílem není vytvářet v organizaci sila informací, ale mít výslovné uznání různých potřeb. Jakmile to uděláte, můžete definovat správný tok dat v organizaci.
Fakturační oddělení zpřístupní svůj pohled na zákazníka zbytku organizace, přičemž si zachová svobodu měnit způsob, jakým je utvářen uvnitř oddělení.
Jako tento příklad používám oddělení fakturace a marketingu a pojem zákazníka, abych mohl mluvit o firmě, což je důležité. Abychom to posunuli trochu techničtějším způsobem, mluvíme o smlouvách o službách a toku dat. Odkážu vás na Bezosův mandát a jak proměnil Amazon. Myšlenka je jednoduchá:místo abyste s celou organizací zacházeli jako s jedním celkem, což je po určité velikosti téměř nemožné, zacházejte s ní jako se skupinou spolupracujících organizací, které mezi sebou mají velmi jasné hranice.
Jakmile budete mít tyto hranice a budete mít dobrou představu o toku dat v organizaci, můžete nechat své instalatéry, aby přišli a udělali s tím věci, jako je přesměrování toku dat do centrálního umístění pro analýzu.
Mít takto publikovaná rozhraní hodně pomáhá, když přijde čas změnit chování některých věcí. Dokud je vnější chování stejné, můžeme svobodně změnit způsob, jakým je zpracováváme.
3. V posledních letech podniky přijaly různé typy databází NoSQL. Se stále citlivějšími daty, která jsou ukládána v databázích NoSQL, se problémy se zabezpečením stávají stále větším problémem. Jaký je váš názor na toto?
Celkově vzato, nejčastějším důvodem nedostatečného zabezpečení v NoSQL databázích je nedbalost operátora. Chci zde jasně oddělit dva odlišné problémy. Máme databáze NoSQL, jako je Redis, jehož bezpečnostní model je výslovně o běhu v důvěryhodném prostředí. Redis má několik základních bezpečnostních prvků, ale obecný předpoklad je, že mají sloužit pouze jako třetí nebo čtvrtá obranná linie.
Očekává se, že další databáze NoSQL, jako je MongoDB, poběží v nepřátelských sítích (tj. internetu). Je však snadné nastavit MongoDB bez jakéhokoli zabezpečení. Na první pohled se MongoDB dodává v zabezpečené konfiguraci, která mu umožňuje poslouchat pouze místní počítač.
Úplně první věc, kterou najdete při pokusu o vzdálené připojení k MongoDB, je průvodce, který vysvětluje, jak povolit vzdálený přístup k MongoDB, bez jakéhokoli zabezpečení.
Do jisté míry jde o nedbalost operátora. Ale vzhledem k obrovskému počtu databází MongoDB, které jsou ponechány dokořán, věřím, že to je štěpení vlasů. V Číně měla otevřená databáze MongoDB více než 200 milionů životopisů, které jen čekaly na to, až je někdo slídí; nedbale nastavená databáze odhalila zadní vrátka Ruska do více než 2 000 společností.
Se zabezpečením nedostanete druhou šanci.
Naproti tomu RavenDB prostě odmítne běžet ve zranitelné konfiguraci. Na místním počítači můžete spustit RavenDB bez zabezpečení, ale pokud se pokusíte vystavit databázi internetu bez patřičných zabezpečení, databáze vrátí chybu vysvětlující, jak byste ji měli správně nastavit.
Vyplňujeme maximální množství mezer za předpokladu, že většina lidí udělá minimální množství požadované práce, a ujišťujeme se, že když k tomu dojde, bude konečný stav dobrý, takže jsme pro vás pokrytí.
4. Když mluvíme o RavenDB, můžete jmenovat některé z nejdůležitějších funkcí, které přidávají zákazníkům větší hodnotu? Jak RavenDB vyniká mezi ostatními dodavateli z hlediska funkcí a výkonu?
RavenDB běží v produkčních systémech více než deset let. Některé z nejvýkonnějších funkcí, které se datují do naší původní verze. Schopnost dynamicky reagovat na provozní prostředí je nejzřetelnější. RavenDB neustále analyzuje, co se děje (příchozí dotazy, zatížení serveru atd.) a reaguje na to změnou alokace zdrojů, vnitřních struktur atd. Myšlenka je taková, že místo toho, aby se o vaši databázi staral na plný úvazek DBA, může vaše databáze spravovat své vlastní záležitosti.
Když jsme začali pracovat na RavenDB, chtěli jsme databázi, která by měla všechny výhody relační databáze (rychlá, ACID, spolehlivá), ale žádnou z nevýhod (rigidní schéma, průběžná údržba, vysoká složitost).
Když jsme začínali, netušil jsem, jak velký úkol to je. Za posledních 10 let jsme získali mnoho zkušeností s vytvářením databáze, která může fungovat, aniž byste jí museli věnovat velkou pozornost. Navrhli jsme RavenDB, aby nám usnadnil implementaci věcí se zaměřením na výkon. Nedávný benchmark na počítači Raspberry Pi (25 $, 1 GHz, 1 GB RAM) nás taktoval na více než 5 000 zápisů za sekundu. Na komoditním hardwaru se můžeme dostat přes 100 000 zápisů za sekundu a přes 1 000 000 čtení za sekundu.
To vše je na jediném uzlu, ale RavenDB je distribuovaná databáze od začátku. To znamená, že můžete nastavit cluster během několika minut (a to samozřejmě bezpečným způsobem) a mít vysoce dostupný a robustní systém.
Nabízíme některé unikátní funkce, které jinde nejsou dostupné. ETL je vestavěno uvnitř RavenDB a je silně využíváno našimi zákazníky k umožnění bohatého toku dat. Řešení nemusíte sešívat z různých kusů, vše je přímo v krabici a prostě to funguje.
Funkce Subscription je ta, na kterou jsem obzvlášť hrdý. Umožňuje provádět průběžný dotaz. Databáze vám zpočátku poskytne všechny výsledky, které odpovídaly vašemu dotazu. Protože jste stále přihlášeni k odběru tohoto dotazu, vaše databáze odešle všechny nové dokumenty, které odpovídají vašemu dotazu, jakmile budou zadány nebo aktualizovány, aby odpovídaly tomuto dotazu. To vám umožní snadno budovat robustní obchodní procesy a backendové systémy.
Zaměřili jsme hodně úsilí na to, aby se RavenDB stala multimodelovou databází schopnou zpracovávat dokumenty, páry klíč–hodnota, binární data, distribuované čítače a dotazy na grafy.
5. A konečně, jaká je budoucnost systémů pro správu databází? Jak se to změní v příštích 3-4 letech?
Uvidíte mnohem více zaměření na vícemodelové databáze. Místo toho, abyste museli nasazovat specializované řešení pro každý typ dat, která chcete, a zabývat se složitou integrací mezi jednotlivými částmi, trh se přesouvá k integrovanému řešení, které může nabídnout celou sadu možností v jediné krabici.
Cloud bude i nadále důležitější, ale neunáhlil bych se rozloučit se s místními a distribuovanými systémy. Vidíme, že mnoho našich zákazníků provádí zpracování na okraji a na příležitostně připojených systémech. Myslím, že zaznamenáte posun zaměření, kdy by se datová centra minulosti přesunula do cloudu, ale velká část skutečného zpracování by byla distribuována na okraji a na mobilních zařízeních. To vyžaduje jiný způsob uvažování o distribuci dat a o tom, jak přenášet data do cloudu a stahovat data z cloudu.
Bude kladen mnohem větší důraz na druh distribuovaného zpracování dat, který byl kdysi výhradní řadou špičkových systémů.
Určitě bude velmi zajímavé sledovat, jak se krajina mění a jak vytváříme nástroje a metodiky, abychom zvládli stále rostoucí složitost a funkčnost.