Dovolte mi vyprávět technický příběh.
Před mnoha lety jsem vyvíjel aplikaci se zabudovanými funkcemi pro spolupráci. Byla to pohodlná experimentální sada, která využívala plný potenciál raného Reactu a CouchDB. V reálném čase synchronizovala data pomocí JSON. . Používala se v interní práci společnosti, avšak široká použitelnost a potenciál v dalších oblastech byly očividné.
Když jsme se snažili prodat tuto technologii potenciálním klientům, narazili jsme na neočekávanou překážku. V demonstrativním videu naše technologie vypadala a fungovala skvěle, žádné problémy. Video ukazovalo přesně to, jak to funguje, a nic se neimitovalo. Vymysleli jsme a zakódovali realistický scénář použití programu.
Ve skutečnosti se to stalo problémem. Naše demo fungovalo přesně tak, jak imitovali práci svých aplikací všichni ostatní. Konkrétně, informace byla okamžitě přenášena z A do B, i když se jednalo o velké mediální soubory. Po přihlášení každý uživatel viděl nové záznamy. Díky aplikaci mohli různí uživatelé spolupracovat přesně na stejných projektech, i když došlo k přerušení internetového připojení někde na vesnici. Nepřímo bylo toto naznačeno v jakémkoli sestříhaném videu o produktu v After Effects.
I když všichni věděli, k čemu slouží tlačítko Obnovit, nikdo vůbec nechápal, že webové aplikace, které od nás žádají, mají obvykle svá omezení. A že pokud už nebudou potřeba, uživatelský zážitek bude zcela odlišný. Většinou si všímal, že se dá 'chatovat', a zanechávat poznámky, proto se ptali, čím se to liší od Slacku. Uf!
Design každodenních synchronizací
Pokud máte už nějaké zkušenosti s vývojem softwaru, musí vás štvát nutnost pamatovat si, že většina lidí se prostě nemůže podívat na obrázek rozhraní a pochopit, co bude dělat při interakci s ním. O tom, co se děje uvnitř samotného programu, nemluvě. může to se v mnoha ohledech děje díky znalosti toho, co se nemůže stát a co by se dít nemělo. K tomu je třeba nejen toho, co software dělá, ale také toho, jak jsou jednotlivé části vzájemně sladěny a komunikují.
Klasickým příkladem toho je uživatel, který po dobu dvaceti minut sleduje spinner.gif, přemýšleje, kdy konečně skončí práce. Vývojář by pochopil, že proces pravděpodobně zamrzl, a že gif nikdy nezmizí z obrazovky. Tato animace simuluje provádění práce, ale není spojena s jejím stavem. V takových případech mají někteří technici rádi zakrývání očí, ohromením mírou omylu uživatelů. Nicméně si povšimněte, kdo z nich ukazuje na otáčející se hodiny a říká, že ve skutečnosti stojí na místě?
O tom přece jde o hodnotu reálného času. V dnešní době se databáze reálného času využívají stále velmi málo, a mnozí se na ně dívají s podezřením. Většina těchto databází se aktivně orientuje na styl NoSQL, což obvykle vede k používání řešení založených na Mongo, na která je lepší zapomenout. Ale pro mě to znamená pohodlnou práci s CouchDB a také studium projektování struktur, které budou schopny naplňovat data nejen nějakým byrokratem. Myslím, že svůj čas využívám optimálněji.
Ale skutečné téma tohoto příspěvku je to, co dnes používám. Ne z vlastního výběru, ale kvůli lhostejně a slepě používané firemní politice. Proto uvedu Úplně Čestné a Nezaujaté srovnání dvou úzce spojených produktů pro práci s databázemi reálného času Google.
V názvech obou je slovo Fire. Na jeden si vzpomínám s nostalgia. Druhý pro mě představuje jiný druh ohně. Nechci se uspěchat se zmiňováním jejich názvů, protože jakmile to udělám, narazíme na první velký problém – na jména.
První se nazývá Firebase Real-Time Database, a druhý je Firebase Cloud Firestore. Oba jsou produkty z Firebase suite Google. Jejich API se nazývají, odpovídajícím způsobem, firebase.database(…) a firebase.firestore(…).
Stalo se to proto, že Real-Time Database je prostě původní Firebase před jeho zakoupením Google v roce 2014. Poté se Google rozhodl vytvořit jako paralelní produkt kopii Firebase založená na velkých datech společnosti, a nazvali ji Firestore with a cloud. Doufám, že jste se ještě neztratili. Pokud jste se přece jen ztratili, nebojte se, tuto část článku jsem sám přepisoval desetkrát.
Protože je potřeba uvést Firebase ve věci týkající se Firebase, a Firestore ve věci týkající se Firebase, abyste byli pochopeni před několika lety na Stack Overflow.
Kdyby existovala cena za nejhorší pojmenování softwarových produktů, tento případ by se určitě stal jedním z uchazečů. Hammingova vzdálenost mezi těmito názvy je natolik malá, že mate i zkušené inženýry, kteří píší jedno jméno, zatímco myslí na jiné. To jsou plánování, která selhala s velikým kraválem, vymýšlená s těmi nejlepšími úmysly; splnila proroctví, že databáze bude v plamenech. A vůbec si nedělám legraci. Člověk, který vymyslel takový pojmenovací systém, byl příčinou krve, potu a slz.
Pyrrhovo vítězství
Mohlo by se zdát, že Firestore je náhrada Firebase, jeho potomek nové generace, ale to by bylo klamné. Firestore zcela určitě nenahrazuje Firebase. Vypadá to, že někdo z něj odstranil vše zajímavé, a většinu zbylého zmatečně předělal různými způsoby.
Avšak letmý pohled na dva produkty vás může zmást: zdá se, že dělají to samé, přes většinou stejné API a dokonce ve stejné databázové relaci. Rozdíly jsou nenápadné a objeví se pouze při pečlivém porovnání obsáhlé dokumentace. Nebo když se snažíte portovat dokonale fungující kód z Firebase, aby fungoval s Firestore. Tehdy už zjistíte, že databázové rozhraní se rozsvítí, jakmile se pokusíte provést přetahování myší v reálném čase. Opakuji, nedělám si legraci.
Klient Firebase je slušný v tom smyslu, že ukládá změny do mezipaměti a automaticky opakuje pokusy o aktualizaci, kdy dává přednost poslední operaci zápisu. Firestore má však omezení na 1 zápis na dokument na uživatele za sekundu, a toto omezení je uloženo serverem. Při jeho používání se musíte sami postarat o to, abyste našli způsob, jak ho obejít, a zavést rychlostní limit pro aktualizace, i když se jen snažíte vytvořit svou aplikaci. To znamená, že Firestore je databáze v reálném čase, ale bez klienta v reálném čase, která se snaží se takovou tvářit pomocí API.
Na tomto bodu začínáme vidět první náznaky smyslu existence Firestore. Možná se pletu, ale mám podezření, že někdo vysoko v Google vedení se po koupi Firebase podíval a jednoduše řekl: „Ne, bože, ne. To je nepřijatelné. Jen ne pod mým vedením.“
Vystoupil ze svých komnat a prohlásil:
„Jednoduchý velký dokument JSON? Ne. Rozdělíte data na jednotlivé dokumenty, přičemž každý z nich bude mít maximální velikost 1 megabajt.“
Zdá se, že takové omezení nepřežije první střetnutí s jakoukoli dostatečně motivovanou uživatelskou základnou. Víte, že to tak je. Například u nás v práci máme více než tisíc pět set prezentací, a to je zcela normální.
S tímto omezením budete muset přijmout skutečnost, že jeden „dokument“ v databázi nebude vypadat jako žádný objekt, který by uživatel mohl nazvat dokumentem.
„Pole polí, která mohou rekurzivně obsahovat jiné prvky? Ne. Pole budou obsahovat pouze objekty nebo čísla pevné délky, jak bylo zamýšleno Pánem.“
Pokud jste tedy doufali, že do svého Firestore umístíte GeoJSON, zjistíte, že to není možné. Nic víc než jednorozměrné není přípustné. Doufám, že máte rádi Base64 a/nebo JSON uvnitř JSON.
„Import a export JSON přes HTTP, nástroje příkazového řádku nebo administrátorský panel? Ne. Budete moci pouze exportovat a importovat data do Google Cloud Storage. Tak to teď vypadá. A když říkám „vy“, myslím tím pouze ty, kteří mají oprávnění Project Owner. Všichni ostatní mohou jít a vytvořit tikety.“
Jak vidíte, model dat FireBase je snadno popsatelné. Obsahuje jeden obrovský dokument JSON, který propojuje JSON klíče s URL cestami. Pokud to zapíšete pomocí HTTP PUT v / FireBase následující:
{
"hello": "world"
} Takže GET /hello vrátí "world". V podstatě to funguje přesně tak, jak očekáváte. Kolekce objektů FireBase /my-collection/:id je ekvivalentní JSON slovníku {"my-collection": {...}} v kořeni, jehož obsah je dostupný na /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}To funguje skvěle, pokud každé vložení má ID bez kolizí, pro což má systém standardní řešení.
Jinými slovy, databáze je 100% kompatibilní s JSON (*) a skvěle funguje s HTTP, například s CouchDB. Ale většinou ji používáte prostřednictvím API v reálném čase, které abstrahuje sockets, autorizaci a odběry. Administrátorská panel nabízí obě možnosti, umožňuje jak provádět úpravy v reálném čase, tak také import/export JSON. Pokud se ve svém kódu budete držet stejného přístupu, překvapí vás, kolik specializovaného kódu zmizí, když pochopíte, že patch a diff JSON řeší 90% rutinních úloh zpracování trvalého stavu.
Model dat Firestore je podobný JSON, ale v některých kritických aspektech se od něj liší. Již jsem zmínil absenci polí uvnitř polí. Model sub-kolekcí spočívá v tom, že jsou koncepty první třídy, oddělené od dokumentu JSON, který je obsahuje. Protože neexistuje žádná hotová serializace, vyžaduje získávání a zápis dat specializovaný postup kódu. Pro zpracování vlastních kolekcí je nutné psát vlastní skripty a nástroje. Administrátorská panel vám umožňuje provádět pouze drobné změny po jednom poli najednou a nemá možnosti importu/exportu.
Vzali real-time NoSQL databázi a proměnili ji na pomalou non-SQL s automatickým slučováním a odděleným sloupcem non-JSON. Něco jako GraftQL.
Horký Java
Pokud má Firestore být spolehlivější a škálovatelnější, je ironické, že průměrný vývojář dostává méně spolehlivé řešení, než by získal výběrem FireBase „z krabice“. Software, který potřebuje Hádavý Správce Dat, vyžaduje takovou úroveň úsilí a kvality specialistů, že je to zkrátka nerealistické pro inovaci, ve které by měl být dobrý produkt. Je to podobné tomu, jak HTML5 Canvas není skutečnou náhradou za Flash, pokud nejsou k dispozici vývojářské nástroje a přehrávač. Navíc Firestore uvízla v touze po čistotě dat a sterilní validaci, což jednoduše neodpovídá tomu, jak průměrný obchodní uživatel, rád pracuje: pro něj není nic nezbytné, protože až do konce je všechno jen koncept.
Hlavní nevýhodou FireBase je, že klient byl vytvořen o několik let dříve, než měl, ještě předtím, než většina webových vývojářů pochopila imutabilitu. Z tohoto důvodu FireBase předpokládá, že budete data měnit, a proto nevyužívá výhod, které imutabilita pro uživatele nabízí. Navíc nepoužívá data opakovaně v uživatelských snímcích, což způsobuje, že provádět diff je mnohem složitější. Pro velké dokumenty je její mechanismus transakcí na základě měnitelných diff naprosto nedostatečný. Kluci, vždyť už máme WeakMap v JavaScriptu. Je to pohodlné.
Pokud datům dodáte požadovaný tvar a neuděláte stromy příliš objemnými, lze tomuto problému uniknout. Ale zajímá mě, zda by FireBase byla mnohem zajímavější, kdyby vývojáři vydali skutečně dobré klientské API, které by používalo imutabilitu ve spojení se skutečně praktickým radou ohledně struktury databází. Místo toho se zdá, že se snažili opravit něco, co není rozbité, a tím se to zhoršilo.
Nevím, jaká logika stála za vytvořením Firestore. Úvahy o motivech, které vznikají uvnitř černé skříňky, jsou také součástí zábavy. Takové postavení protikladu dvou extrémně podobných, avšak nesrovnatelných databází se vyskytuje poměrně zřídka. Jakoby si někdo pomyslel: „Firebase je prostě funkce, kterou můžeme emulovat v Google Cloud“, ale přitom ještě neobjevil koncept definování požadavků reálného světa nebo vytváření užitečných řešení, která splňují všechny tyto požadavky. „Nechte to na vývojářích. Prostě udělejte uživatelské rozhraní pěkné… A co takhle přidat víc ohně?“
Rozumím pár věcem o datových strukturách. Určitě vidím, že koncept „všechno v jednom velkém JSON stromě“ je pokusem abstrahovat z databáze jakýkoli pocit rozsáhlé struktury. Očekávat, že software si jednoduše poradí s jakýmikoli pochybnými fraktály datové struktury — to je prostě šílenství. Ani si nemusím představovat, jak špatně to může vypadat, provedl jsem přísné audity kódu a viděl jsem věci, které vám, lidé, ani nesnily.. Ale také vím, jak vypadají dobré struktury, a . Můžu si představit svět, ve kterém by Firestore vypadala zcela logicky, a lidé, kteří ji vytvořili, by si mysleli, že odvedli dobrou práci. Ale nežijeme v tomto světě.
Podpora dotazování v Firebase je podle jakýchkoli standardů špatná, prakticky neexistuje. Určitě vyžaduje zlepšení nebo alespoň revizi. Ale Firestore není o moc lepší, protože je omezena stejnými jednorozměrnými indexy, které máme v jednoduchém SQL. Pokud potřebujete dotazy, které lidé provádějí s chaotickými daty, pak potřebujete fulltextové vyhledávání, filtry na více rozsazích a libovolně definovaný pořádek. Při pečlivém zkoumání jsou funkce jednoduchého SQL samy o sobě příliš omezené. Navíc jediné SQL dotazy, které lidé mohou provádět v produkci — jsou rychlé dotazy. Budete potřebovat specializované řešení pro indexaci s promyšlenými datovými strukturami. Pro všechno ostatní by alespoň mělo být inkrementální map-reduce nebo něco podobného.
Pokud vyhledáte informace o tom v dokumentech Google, doufám, že vás nasměrují k něčemu jako BigTable a BigQuery. Nicméně všechna tato řešení přicházejí s takovým objemem husté korporátní prodejní hantýrky, že se rychle vrátíte zpět a začnete hledat něco jiného.
Poslední, co potřebujete v případě databáze v reálném čase — je něco, co vytvořili lidé a pro lidi, kteří pracují na mzdové škále pro vedení.
(*) To je vtip, takové pojmy neexistují, jako .
Na základě reklamy
Hledáte server pro ladění projektů, hosting a vývoj? Určitě jste naším klientem 🙂 Denní tarify serverů s různými konfiguracemi, antiDDoS a licence Windows již zahrnuty v ceně.
Zdroj: habr.com
