See andmebaas on tulekahjus…

Laske mulle rääkida tehnilisest loost.

Palju aastaid tagasi arendasin ma rakendust, kus olid integreeritud koostöörakenduse funktsioonid. See oli mugav eksperimentaalne virna, kus kasutati täielikult varase Reacti ja CouchDB potentsiaali. See sünkroniseerib andmeid reaalajas JSON-i kaudu. OT. Seda kasutati ettevõtte sisetöös, kuid selle laiem rakendatavus ja potentsiaal teistes valdkondades olid ilmsed.

Püüdes müüa potentsiaalsetele klientidele seda tehnoloogiat, kohtasime ootamatut takistust. Meie demo-videol nägi meie tehnoloogia suurepärane välja ja töötas suurepäraselt; probleeme ei olnud. Video näitas täpselt, kuidas see töötab, ja seal ei olnud midagi simuleeritud. Me välja mõeldud ja kodeeritud realistlik stsenaarium tarkvara kasutamiseks.


Tegelikult sai see probleemiks. Meie demo töötas just nii, nagu simuleerisid oma rakenduste tööd kõik teised. Konkreetsemalt, teave edastati koheselt A-st B-sse, isegi kui need olid suured meediafailid. Pärast sisse logimist nägid kõik kasutajad uusi kirjeid. Rakenduse abil said erinevad kasutajad koos töötada selgelt sama projektiga, isegi kui Interneti-ühendus katkestati kuskil maal. Indirektse vormis tähendab see, et igas After Effects'i tootevideotes on sarnane eeldus.

Kuigi kõik teadsid, milleks on Refresh-nupp, ei saanud küllalt arusaadavaks, et veebirakendused, mille loomist nad meilt paluvad, on tavaliselt oma piirangute all. Ja kui need ei osutuks enam vajalikuks, oleks kasutajakogemus täiesti erinev. Peamiselt märkisid nad, et nad saavad 'vestelda', jättes vestluspartneritele märkmeid, ning ikkagi küsisid nad, kuidas see erineb näiteks Slackist. Uf-f-f!

Igalapäevaste sünkroonimiste disain

Kui teil on juba tarkvaraarenduse kogemus, siis peaks teid ärritama vajadus meeles pidada, et enamus inimesi ei saa lihtsalt pilti kasutajaliidesest vaadates aru, mida see teha kavatseb, kui nad sellega suhtlevad. Rääkimata sellest, mis toimub tarkvara sisemuses. Teadlikkus sellest, võib mis juhtub – on suures osas seotud teadlikkusega sellest, mis ei saa juhtuda ja mis ei tohiks juhtuda. Selleks on vaja vaimne mudel mitte ainult selle, mida tarkvara teeb, vaid ka seda, kuidas selle erinevad osad omavahel kooskõlas ja suhtlevad.

Klassikaline näide sellest on kasutaja, kes vaatab kahekümne minuti jooksul spinner.gif, pidades meeles, millal see töö lõpuks valmis saab. Arendaja oleks mõistnud, et protsess on tõenäoliselt seiskunud ning gif ei kao ekraanilt kunagi. See animatsioon imiteerib töö tegemist, kuid ei ole seotud selle olekuga. Sellistes olukordades armastavad mõned tehnikud ohata, imestades, kui ekslikud võivad kasutajate arusaamad olla. Kuid märkige, kes neist näitab keerleva kella poole ja ütleb, et see on tegelikult liikumatuks jäänud?

Selles seisnebki reaalaja väärtuse olemus. Tänapäeval kasutatakse reaalaja andmebaase endiselt äärmiselt harva ja paljusid nähakse nende suhtes umbusuga. Enamik selliseid andmebaase kaldub aktiivselt NoSQL stiili, mistõttu kasutatakse tavaliselt lahendusi, mis põhinevad Mongo'l, millest on parem unustada. Siiski tähendab see minu jaoks mugavust töötada CouchDB-ga ja õppida ülesehitust, mida võiks täita andmetega mitte üksnes mingi bürokraat. Arvan, et kasutan oma aega efektiivsemalt.

Kuid selle postituse tõeline teema on see, mida ma täna kasutan. Mitte oma valikul, vaid hoolimatult ja pimeda ettevõtte poliitika tõttu. Seetõttu toon välja täiesti ausa ja erapooletu võrdluse kahe tihedalt seotud toote vahel, mis töötavad reaalaja andmebaasidega Google'is.

Mõlema nimetuses on sõna Fire. Ühte mäletan ma soojusega. Teine on minu jaoks teise tüüpi tuli. Ma ei kiirusta nende nimede ütlemisega, sest kohe, kui ma seda teen, seisame silmitsi esimese suure probleemiga – nimedega.

Esimene on Firebase Real-Time Database, teine aga — Firebase Cloud Firestore. Mõlemad on tooted Firebase komplektist Google'ist. Nende API-d nimetatakse vastavalt firebase.database(…) ja firebase.firestore(…).

See juhtus seetõttu, et Real-Time Database on lihtsalt algne Firebase , enne kui Google selle 2014. aastal ostis. Seejärel otsustas Google luua paralleelse tootena koopiana Firebase'i, mis põhines ettevõtte suurandmetel, ja nimetas selle Firestore'iks pilves. Loodan, et te pole veel segadusse sattunud. Kui siiski olete, ärge muretsege, ma ise kirjutasin selle artikli osa kümme korda ümber.

Kuna tuleb näidata Firebase Firebase'i osaselt, ja Firestore Firebase'i osas, et teid mõistetaks mõni aasta tagasi Stack Overflow's.

Kui olemasolev tarkvara toote nimede halvim nimiauhind, siis see juhtum oleks kindlasti üks kandidaatidest. Hamming'i kaugus nende nimede vahel on nii väike, et see segaduses isegi kogenud insenere, kelle sõrmed kirjutavad üht nime, kuigi pea mõtleb teisele. Need on ebaõnnestunud plaanid, mis olid välja mõeldud kõige paremate kavatsustega; nad täitsid ennustuse, et andmebaas põleb. Ja ma ei nalja. Isik, kes sellise nimetamisstruktuuri välja mõtles, põhjustas verd, higi ja pisaraid.

Pyrrhose võit

Võib arvata, et Firestore on asendaja Firebase'ile, selle järgmise põlvkonna järeltulija, aga see oleks eksiarvamus. Firestore ei sobi kindlasti Firebase'ile asenduseks. Tundub, et keegi on sellest välja lõiganud kõik huvitava, ja suure osa allesjäänust on erinevatel viisidel segamini ajanud.

Kuid kiire pilk kahele tootelle võib sind eksitada: tundub, et nad teevad sama asja, peamiselt sama API kaudu ja isegi samas andmebaasi sessioonis. Erinevused on vaevu märgatavad ja ilmnevad ainult põhjaliku võrdleva uurimise käigus ulatuslikus dokumentatsioonis. Või siis, kui püüad portida ideaalselt toimivat Firebase'i koodi, et see töötaks Firestore'is. Juba siis avastad, et andmebaasi kasutajaliides põleb, kui proovid reaalajas hiirega lohistada. Kordan jälle, ma ei nalja.

Firebase'i klient on viisakas selles mõttes, et see puhverdab muudatused ja teeb automaatseid värskendamise korduskatseid, andes prioriteedi viimasele kirjutamise toimingule. Kuid Firestore'l on piirang 1 kirjutamisoperatsioon dokumendi kohta kasutaja kohta sekundis, ja see piirang kehtestatakse serveri poolt. Kui töötate sellega, peate ise leidma viisi selle ületamiseks ja rakendama värskenduste kiiruspiiraja, isegi kui proovite lihtsalt oma rakendust luua. Teisisõnu, Firestore on reaalaja andmebaas ilma reaalaja kliendita, mis peidab end selle alla API abil.

Sellega hakkame nägema esimesi märke Firestore'i olemasolu mõttest. Võib-olla eksin, kuid kahtlustan, et keegi kõrgel Google'is vaatas pärast Firebase'i ostu ja ütles lihtsalt: "Ei, jumal, ei. See on vastuvõetamatu. Ainult mitte minu juhtimise ajal."

Ta ilmus oma ruumidest ja kuulutas:

„Üks suur JSON dokument? Ei. Te jagate andmed eraldi dokumentideks, millest igaühe suurus ei tohi ületada 1 megabaiti.“

Tundub, et selline piirang ei kesta kaua koos piisavalt motiveeritud kasutajabaasiga. Teate, et see on nii. Meil näiteks on üle tuhande esitluse ja see on täiesti normaalne.

Sellise piirangu korral peate leppima faktiga, et üks "dokument" andmebaasis ei sarnane mitte ühegi objektiga, mida kasutaja võiks nimetada dokumendiks.

„Ahelad ahelates, mis võivad rekursiivselt sisaldada teisi elemente? Ei. Ahelad sisaldavad ainult objekte või kindla pikkusega numbreid, nagu Looja on ette näinud.“

Seega, kui lootsite oma Firestore'i GeoJSON'i paigutada, leiate, et see on võimatu. Ükski mitmemõõtmeline ei ole lubatud. Loodan, et armastate Base64 ja/või JSON-i JSON-i sees.

„JSON-i import ja eksport HTTP kaudu, käsurealt või administraatori paneelist? Ei. Te saate ainult eksportida ja importida andmeid Google Cloud Storage'i. Nii see praegu tundub nimetatuna. Ja kui ma räägin „teist”, siis pöördun ainult nende poole, kes on Project Owner'i õigused. Kõik teised võivad minna ja luua pileteid.“

Nagu näete, on FireBase andmemudelit lihtne kirjeldada. See sisaldab ühte suurt JSON dokumenti, mis seob JSON võtmed URL-i teedega. Kui te kirjutate HTTP PUT ja / FireBase järgmist:

{
  "hello": "world"
}

Siis GET /hello tagastab "world". Põhimõtteliselt töötab see just nii, nagu te ootate. FireBase'i objektide kollektsioon /my-collection/:id on võrdne JSON sõnaraamiga {"my-collection": {...}} juures, mille sisu on saadaval /my-collection:

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

See töötab suurepäraselt, kui igal sisestusel on ID-d, millel pole konfliktide, milleks on süsteemis olemas standardlahendus.

Teisisõnu, andmebaas on 100% ühilduv JSON-iga (*) ja töötab suurepäraselt HTTP-ga, näiteks CouchDB-ga. Kuid põhiliselt kasutate seda läbi reaalajas API, mis abstraheerib websockets, autentimise ja tellimused. Administreerimisplaan toetab mõlemat võimalust, võimaldades reaalajas muutmisi ning JSON-i importimist/eksportimist. Kui teie kood järgib seda printsiipi, siis üllatute, kui palju spetsialiseeritud koodi võite kõrvaldada, kui mõistate, et patch ja diff JSON lahendavad 90% rutiinseid püsiseisundi töötlemise ülesandeid.

Firestore andmemudel sarnaneb JSON-ile, kuid erineb sellest mitmes kriitilises aspektis. Olen juba maininud, et massiive ei ole massiivide sees. Alamhulga mudel seisneb selles, et need on esmaklassilised kontseptsioonid, mis on eraldi JSON-i sisaldavast dokumendist. Kuna valmisseerialiseerimist ei ole, on andmete lugemiseks ja kirjutamiseks vajalik spetsialiseeritud koodi täitmise rada. Oma kollektsioonide töötlemiseks tuleb kirjutada oma skripte ja tööriistu. Administreerimisplaan võimaldab teil teha vaid väikseid muudatusi ühe välja kaupa ning ei toeta importimist/eksportimist.

Nad muutsid reaalajas NoSQL andmebaasi aeglaseks mitte-SQL lahenduseks automaatse liitmise ja eraldi mitte-JSON veergudega. Midagi sarnast GraftQL-iga.

Kuum Java

Kui Firestore peab olema usaldusväärsem ja skaleeritavam, siis iroonia seisneb selles, et keskmine arendaja saab vähem usaldusväärse lahenduse kui valides FireBase 'karbist välja'. See tarkvara, mida näputöörik ehk Noogutav Andmebaasi Administraator vajab, nõuab nii suurt pingutust ja spetsialistide taset, et see on lihtsalt reaalsuses ebatõenäoline valdkonnale, kus peaks olema hea toode. See on sarnane sellele, et HTML5 Canvas ei ole sugugi Flashi asendaja, kui ei ole arendustööriistu ja mängijat. Veelgi enam, Firestore on kinni jäänud andmete puhtuse ja steriilsete valideerimiste püüdlemisse, mis lihtsalt ei vasta sellele, kuidas keskmine ärikasutaja meeldib töötada: tema jaoks ei ole see vajalik, kuna lõpuni on kõik mustand.

FireBase'i peamine puudus on see, et klient loodi mitu aastat enne tähtaega, veel enne, kui enamik veebiarendajatest sai teada immutamatuse mõistest. Seetõttu eeldab FireBase, et te muudate andmeid, mistõttu ei kasutata ära kasutaja poolt tagatud immutamatuse eeliseid. Lisaks ei taaskasutata andmeid kasutajale edastatavates hetkede piltides, mis muudab erinevuste leidmise märksa keerulisemaks. Suurte dokumentide jaoks on selle muutuvate erinevuste põhine tehingumehhanism lihtsalt ebapiisav. Meil on ju juba olemas WeakMap JavaScriptis. See on mugav.

Kui andmed õigesse vormi viia ja puid mitte liiga mahukaks teha, saab seda probleemi vältida. Kuid mind huvitab, kas FireBase oleks palju huvitavam, kui arendajad vabastaksid tõeliselt hea kliendipoolse API, mis kasutab immutamatust koos tõsiste praktiliste soovitustega andmebaasi struktuuri osas. Selle asemel näib, et nad üritavad parandada midagi, mis pole katki, ja seetõttu on olukord halvenenud.

Ma ei tea kogu loogikat, mis oli Firestore'i loomise aluseks. Arutlused motiivide üle, mis tekivad mustas kastis, on samuti osa naljast. Selline vastandamine kahe äärmiselt sarnase, kuid üksteisega võrreldamatute andmebaaside vahel toimub üsna harva. Justkui keegi mõtleks: «Firebase on lihtsalt funktsioon, mida saame simuleerida Google Cloudis», aga samas ei ole ta veel avastanud reaalse maailma nõuete määratlemise kontseptsiooni või kasulike lahenduste loomise kontseptsiooni, mis rahuldavad kõiki neid nõudeid. «Las arendajad mõtlevad sellele. Lihtsalt tehke UI ilusaks… Kas saaks lisada rohkem tuld?»

Ma mõistan paar asja andmestruktuuride kohta. Ma näen väga selgelt, et mõte «kõik ühes suures JSON-puus» on katse kaotada andmebaasist igasugune suurem struktuuriline tunne. Oodata, et tarkvara saaks hakkama igasuguste kahtlaste andmestruktuuride fraktaalidega, on lihtsalt meeletu. Ma ei pea isegi ette kujutama, kui halvasti asjad võivad olla, olen teinud rangeid koodiauditeid ja näinud sellist, millest teie, inimesed, ei ole isegi unistanud. Kuid ma tean ka, millised head struktuurid välja näevad, kuidas neid kasutada ja miks seda on vaja tehaMa võin ette kujutada maailma, kus Firestore tundub täiesti loogiline ja selle loonud inimesed arvavad, et nad on head tööd teinud. Kuid me ei ela selles maailmas.

FireBase'i päringute toetamine on igas mõttes nõrk, praktiliselt puudub. See vajab kindlasti parandamist või vähemalt ülevaatamist. Kuid Firestore ei ole märkimisväärselt parem, kuna seda piiravad samad ühemõõtmelised indikaatorid, mis on lihtsas SQL-is. Kui vajate päringuid, mida inimesed teevad kaootiliste andmetega, on vajalik täisteksti otsing, mitme vahemiku filtrid ja kasutaja määratud juhuslik järjekord. Sügava uurimise korral on lihtsa SQLi funktsioonid iseenesest liiga piiratud. Lisaks on ainsad SQL-päringud, mida inimesed toimetuses saavad teha, kiired päringud. Teil on vaja spetsialiseeritud lahendust indekseerimiseks, millel on hästi läbi mõeldud andmestruktuurid. Kõik muu vajab vähemalt järkjärgulist map-reduce'i või midagi sarnast.

Kui otsite sellest teavet Google'i dokumentides, suunatakse teid loodetavasti millegi sarnase suunas nagu BigTable ja BigQuery. Kuid kõik need lahendused on nii tihedalt üksteise peal, et te kiiresti tagastate tagasi ja hakkate otsima midagi muud.

Viimane asi, mida vajate reaalajas andmebaasi puhul, on midagi, mille on loonud inimesed ja mis on loodud inimestele, töötades palgaastmetel juhtimiseks.

(*) See on nali, sellist mõistet ei ole 100% JSON-i ühilduvus.

Reklaami õigustes

Otsite VDS projektide silumiseks, arendus- ja majutusseeri? Te olete kindlasti meie klient 🙂 Erinevate konfiguratsioonide serverite päevane hindamine, antiDDoS ja Windowsi litsentsid on juba hinna sees.

Allikas: habr.com