Tato databáze je v plamenech...

Dovolte mi vyprávět technický příběh.

Před mnoha lety jsem vyvíjel aplikaci se zabudovanými funkcemi pro spolupráci. Byl to uživatelsky přívětivý experimentální stack, který využil plný potenciál raných React a CouchDB. Synchronizoval data v reálném čase přes JSON OT. Byl používán interně v rámci společnosti, ale jeho široká použitelnost a potenciál v jiných oblastech byla jasná.

Při snaze prodat tuto technologii potenciálním klientům jsme narazili na nečekanou překážku. V ukázkovém videu naše technologie vypadala a fungovala skvěle, žádné problémy. Video přesně ukazovalo, jak to funguje a nic nenapodobovalo. Vymysleli jsme a nakódovali realistický scénář použití programu.


Ve skutečnosti se z toho stal problém. Naše demo fungovalo přesně tak, jak všichni ostatní simulovali své aplikace. Konkrétně, informace byly okamžitě přeneseny z A do B, i když šlo o velké mediální soubory. Po přihlášení se každému uživateli zobrazily nové záznamy. Pomocí aplikace mohli různí uživatelé jasně spolupracovat na stejných projektech, i když bylo někde ve vesnici přerušeno připojení k internetu. To je implicitně naznačeno v každém produktovém videu vystřiženém v After Effects.

I když každý věděl, k čemu slouží tlačítko Refresh, nikdo ve skutečnosti nechápal, že webové aplikace, o jejichž vytvoření nás požádali, obvykle podléhají jejich vlastním omezením. A že pokud už nebudou potřeba, uživatelský zážitek bude úplně jiný. Většinou si všimli, že mohou „chatovat“ zanecháním poznámek lidem, se kterými mluvili, a tak je zajímalo, jak se to liší například od Slacka. Fuj!

Návrh každodenních synchronizací

Pokud máte zkušenosti s vývojem softwaru, musí být nervy drásající pamatovat si, že většina lidí se nemůže jen podívat na obrázek rozhraní a pochopit, co to udělá, když s ním budou komunikovat. Nemluvě o tom, co se děje uvnitř samotného programu. Vědomí, že moci Stát se je z velké části výsledkem poznání toho, co se stát nemůže a co by se stát nemělo. To vyžaduje mentální model nejen co software dělá, ale také jak jsou jeho jednotlivé části sladěny a vzájemně komunikují.

Klasickým příkladem toho je uživatel zírající na a spinner.gif, zvědavý, kdy bude práce konečně dokončena. Vývojář by si uvědomil, že proces se pravděpodobně zasekl a že gif nikdy nezmizí z obrazovky. Tato animace simuluje provádění úlohy, ale nesouvisí s jejím stavem. V takových případech někteří technici rádi koulí očima, ohromeni mírou zmatení uživatelů. Všimněte si však, kolik z nich ukazuje na otáčející se hodiny a říká, že ve skutečnosti stojí?

To je podstata hodnoty v reálném čase. V dnešní době jsou databáze v reálném čase stále velmi málo používané a mnoho lidí je prohlíží s podezřením. Většina těchto databází se výrazně přiklání ke stylu NoSQL, a proto obvykle používají řešení založená na Mongo, na která je nejlepší zapomenout. Pro mě to však znamená pohodlně pracovat s CouchDB a také se naučit navrhovat struktury, které dokáže naplnit daty víc než jen nějaký byrokrat. Myslím, že svůj čas využívám lépe.

Ale skutečným tématem tohoto příspěvku je to, co používám dnes. Ne z vlastní vůle, ale kvůli lhostejně a slepě uplatňované firemní politice. Poskytnu tedy zcela spravedlivé a nezaujaté srovnání dvou úzce souvisejících databázových produktů Google v reálném čase.

Oba mají v názvu slovo Oheň. Na jednu věc vzpomínám rád. Druhá věc je pro mě jiný typ ohně. S jejich jmény nespěchám, protože jakmile to udělám, narazíme na první velký problém: jména.

První se jmenuje Databáze Firebase v reálném časea za druhé - Firebase Cloud Firestore. Oba jsou produkty z Sada Firebase Google. Jejich API se nazývají resp firebase.database(…) и firebase.firestore(…).

Stalo se to proto Databáze v reálném čase - je to jen originál Firebase před jeho zakoupením společností Google v roce 2014. Poté se Google rozhodl vytvořit jako paralelní produkt kopii Firebase založená na velké datové společnosti a nazvala ji Firestore s cloudem. Doufám, že ještě nejste zmatení. Pokud jste stále zmatení, nebojte se, sám jsem tuto část článku přepsal desetkrát.

Protože je potřeba naznačit Firebase v otázce Firebase a Firestore v otázce ohledně Firebase, alespoň abyste pochopili před pár lety na Stack Overflow.

Pokud by existovalo ocenění za nejhorší zážitek z pojmenování softwaru, byl by to určitě jeden z uchazečů. Hammingova vzdálenost mezi těmito jmény je tak malá, že mate i zkušené inženýry, jejichž prsty píšou jedno jméno, zatímco jejich hlava přemýšlí o jiném. Jsou to dobře míněné plány, které žalostně selhávají; splnili proroctví, že databáze bude v plamenech. A to si vůbec nedělám legraci. Osoba, která přišla s tímto schématem pojmenování, způsobila krev, pot a slzy.

Pyrrhické vítězství

Člověk by si myslel, že Firestore je výměna Firebase, jeho potomek další generace, ale to by bylo zavádějící. Firestore není zaručeno, že bude vhodnou náhradou za Firebase. Vypadá to, jako by z toho někdo vystřihl všechno zajímavé a většinu zbytku různě popletl.

Rychlý pohled na tyto dva produkty vás však může zmást: zdá se, že dělají totéž, prostřednictvím v podstatě stejných rozhraní API a dokonce ve stejné databázové relaci. Rozdíly jsou jemné a odhalí je až pečlivé srovnávací studium rozsáhlé dokumentace. Nebo když se snažíte přenést kód, který perfektně funguje na Firebase, aby fungoval s Firestore. I pak zjistíte, že se rozhraní databáze rozsvítí, jakmile se pokusíte přetáhnout myší v reálném čase. Opakuji, nedělám si srandu.

Klient Firebase je zdvořilý v tom smyslu, že ukládá změny do vyrovnávací paměti a automaticky opakuje aktualizace, které upřednostňují poslední operaci zápisu. Firestore má však limit 1 operace zápisu na dokument na uživatele za sekundu a tento limit je vynucován serverem. Při práci s ním je jen na vás, jak to obejít a implementovat omezovač rychlosti aktualizace, i když se teprve snažíte sestavit svou aplikaci. Firestore je tedy databáze v reálném čase bez klienta v reálném čase, který se maskuje jako databáze využívající API.

Zde začínáme vidět první známky raison d'être Firestore. Možná se mýlím, ale mám podezření, že někdo vysoko ve vedení Google se po nákupu podíval na Firebase a jednoduše řekl: „Ne, můj bože, ne. To je nepřijatelné. Jen ne pod mým vedením."

Vyšel ze svých komnat a prohlásil:

„Jeden velký dokument JSON? Ne. Data rozdělíte do samostatných dokumentů, z nichž každý nebude mít velikost větší než 1 megabajt.“

Zdá se, že takové omezení nepřežije první setkání s dostatečně motivovanou uživatelskou základnou. Víš, že je. V práci máme například více než jeden a půl tisíce prezentací, a to je Úplně normální.

S tímto omezením budete nuceni přijmout fakt, že jeden „dokument“ v databázi se nebude podobat žádnému objektu, který by uživatel mohl nazvat dokumentem.

„Pole polí, která mohou rekurzivně obsahovat další prvky? Ne. Pole budou obsahovat pouze předměty nebo čísla s pevnou délkou, jak Bůh zamýšlel."

Pokud jste tedy doufali, že vložíte GeoJSON do svého Firestore, zjistíte, že to není možné. Nic nejednorozměrného není přijatelné. Doufám, že se vám líbí Base64 a/nebo JSON v rámci JSON.

„Import a export JSON přes HTTP, nástroje příkazového řádku nebo panel administrátora? Ne. Data budete moci exportovat a importovat pouze do úložiště Google Cloud Storage. Tak se to teď, myslím, jmenuje. A když říkám „vy“, oslovuji pouze ty, kteří mají pověření vlastníka projektu. Všichni ostatní mohou jít a vytvářet vstupenky.“

Jak vidíte, datový model FireBase lze snadno popsat. Obsahuje jeden obrovský dokument JSON, který spojuje klíče JSON s cestami URL. Pokud píšete s HTTP PUT в / FireBase je následující:

{
  "hello": "world"
}

The GET /hello vrátí se "world". V podstatě to funguje přesně tak, jak byste očekávali. Kolekce objektů FireBase /my-collection/:id ekvivalentní slovníku JSON {"my-collection": {...}} v kořenovém adresáři, jehož obsah je dostupný v /my-collection:

{
  "id1": {...object},
  "id2": {...object},
  "id3": {...object},
  // ...
}

Funguje to dobře, pokud má každá vložka nekolizní ID, pro které má systém standardní řešení.

Jinými slovy, databáze je 100% kompatibilní s JSON(*) a funguje skvěle s HTTP, jako je CouchDB. V zásadě jej však používáte prostřednictvím rozhraní API v reálném čase, které abstrahuje webové sokety, autorizaci a předplatné. Administrátorský panel má obě možnosti a umožňuje úpravy v reálném čase i import/export JSON. Pokud uděláte totéž ve svém kódu, budete překvapeni, kolik specializovaného kódu bude vyplýtváno, když si uvědomíte, že patch a diff JSON řeší 90 % rutinních úkolů zpracování persistentního stavu.

Datový model Firestore je podobný JSON, ale liší se v některých zásadních ohledech. Již jsem zmínil nedostatek polí v polích. Modelem pro podkolekce je, aby byly prvotřídními koncepty, oddělenými od dokumentu JSON, který je obsahuje. Vzhledem k tomu, že pro to neexistuje žádná připravená serializace, je pro načítání a zápis dat vyžadována specializovaná cesta kódu. Chcete-li zpracovat své vlastní sbírky, musíte si napsat vlastní skripty a nástroje. Administrační panel umožňuje provádět malé změny pouze v jednom poli a nemá možnosti importu/exportu.

Vzali databázi NoSQL v reálném čase a přeměnili ji na pomalou non-SQL s automatickým připojením a samostatným sloupcem bez JSON. Něco jako GraftQL.

Horká Java

Pokud měl být Firestore spolehlivější a škálovatelnější, pak je ironií, že průměrný vývojář skončí s méně spolehlivým řešením, než je výběr FireBase z krabice. Druh softwaru, který správce databáze Grumpy potřebuje, vyžaduje takové úsilí a talent, který je prostě nereálný pro oblast, ve které má být produkt dobrý. Je to podobné, jako když HTML5 Canvas vůbec nenahrazuje Flash, pokud neexistují žádné vývojové nástroje a přehrávač. Firestore se navíc utápí v touze po čistotě dat a sterilním ověřování, které se jednoduše neslučuje s tím, jak průměrný podnikový uživatel rád pracuje: pro něj je vše volitelné, protože až do samého konce je všechno návrh.

Hlavní nevýhodou FireBase je, že klient byl vytvořen několik let před svou dobou, než většina webových vývojářů věděla o neměnnosti. Z tohoto důvodu FireBase předpokládá, že budete měnit data, a proto nevyužívá neměnnosti poskytované uživatelem. Kromě toho znovu nepoužívá data ve snímcích, která předává uživateli, což značně ztěžuje rozdíl. Pro velké dokumenty je jeho proměnlivý transakční mechanismus založený na rozdílech prostě nedostačující. Kluci, už máme WeakMap v JavaScriptu. Je to pohodlné.

Pokud dáte datům požadovaný tvar a neuděláte stromy příliš objemné, lze tento problém obejít. Ale jsem zvědavý, jestli by FireBase byla mnohem zajímavější, kdyby vývojáři vydali opravdu dobré klientské API, které by využívalo neměnnost v kombinaci s některými seriózními praktickými radami ohledně návrhu databáze. Místo toho se zdálo, že se snaží opravit to, co nebylo rozbité, a tím to bylo ještě horší.

Neznám veškerou logiku za vytvořením Firestore. Spekulování o motivech, které se objevují uvnitř černé skříňky, je také součástí zábavy. Toto srovnání dvou extrémně podobných, ale nesrovnatelných databází je poměrně vzácné. Jako by si někdo myslel: „Firebase je pouze funkce, kterou můžeme emulovat v Google Cloud“, ale dosud neobjevil koncept identifikace požadavků v reálném světě nebo vytváření užitečných řešení, která by všechny tyto požadavky splňovala. „Ať si to vývojáři rozmyslí. Jen udělejte uživatelské rozhraní krásné... Můžete přidat další oheň?“

Rozumím několika věcem o datových strukturách. Koncept „vše v jednom velkém JSON stromu“ rozhodně vnímám jako pokus o abstrahování jakéhokoli smyslu pro rozsáhlou strukturu z databáze. Očekávat, že si software jednoduše poradí s jakýmkoli pochybným fraktálem datové struktury, je prostě šílené. Nemusím si ani představovat, jak špatné věci mohou být, provedl jsem přísné audity kódu a Viděl jsem věci, o kterých se vám lidem ani nesnilo. Ale také vím, jak vypadají dobré struktury, jak je používat и proč by se to mělo dělat. Umím si představit svět, kde by Firestore vypadal logicky a lidé, kteří jej vytvořili, by si mysleli, že odvedli dobrou práci. Ale nežijeme v tomto světě.

Podpora dotazů FireBase je podle jakéhokoli standardu špatná a prakticky neexistuje. Určitě to potřebuje vylepšení nebo alespoň revizi. Firestore ale není o moc lepší, protože je omezen na stejné jednorozměrné indexy jako v prostém SQL. Pokud potřebujete dotazy, které lidé spouštějí na chaotická data, potřebujete fulltextové vyhledávání, vícerozsahové filtry a vlastní uživatelsky definované řazení. Při bližším zkoumání jsou funkce prostého SQL samy o sobě příliš omezené. Navíc jediné SQL dotazy, které mohou lidé spustit v produkci, jsou rychlé dotazy. Budete potřebovat vlastní řešení indexování s promyšlenými datovými strukturami. Pro všechno ostatní by mělo existovat alespoň inkrementální zmenšení mapy nebo něco podobného.

Pokud o tom budete hledat informace v Dokumentech Google, doufejme, že budete nasměrováni směrem k něčemu, jako je BigTable a BigQuery. Všechna tato řešení však provází tak hutný firemní prodejní žargon, že se rychle obrátíte zpět a začnete hledat něco jiného.

Poslední věc, kterou chcete s databází v reálném čase, je něco, co vytvořili a pro lidi na manažerských platových škálách.

(*) To je vtip, nic takového neexistuje 100% kompatibilní s JSON.

Jako reklama

Hledat VDS pro ladicí projekty, server pro vývoj a hosting? Určitě jste náš klient 🙂 Denní ceny serverů různých konfigurací, anti-DDoS a Windows licencí jsou již zahrnuty v ceně.

Zdroj: www.habr.com