Lubage mul rääkida üks tehniline lugu.
Aastaid tagasi töötasin välja rakendust, millesse on sisse ehitatud koostööfunktsioonid. See oli kasutajasõbralik eksperimentaalne pinu, mis kasutas ära varajase Reacti ja CouchDB kogu potentsiaali. See sünkroonis andmeid reaalajas JSON-i kaudu . Seda kasutati ettevõttesiseselt, kuid selle laialdane rakendatavus ja potentsiaal muudes valdkondades oli selge.
Püüdes seda tehnoloogiat potentsiaalsetele klientidele müüa, puutusime kokku ootamatu takistusega. Demovideos nägi meie tehnoloogia välja ja töötas suurepäraselt, probleeme polnud. Video näitas täpselt, kuidas see töötab ja ei imiteerinud midagi. Mõtlesime välja ja kodeerisime programmi kasutamiseks realistliku stsenaariumi.
Tegelikult sai sellest probleem. Meie demo töötas täpselt nii, nagu kõik teised oma rakendusi simuleerisid. Täpsemalt edastati teave koheselt punktist A punkti B, isegi kui tegemist oli suurte meediumifailidega. Pärast sisselogimist nägi iga kasutaja uusi kirjeid. Rakendust kasutades said erinevad kasutajad samade projektide kallal selgelt koostööd teha, isegi kui kuskil külas internetiühendus katkes. See on kaudselt viidatud igas After Effectsi tootevideos.
Kuigi kõik teadsid, mille jaoks nupp Värskenda on, ei saanud keegi õieti aru, et veebirakendustele, mida nad palusid meil luua, kehtivad tavaliselt oma piirangud. Ja et kui neid enam vaja ei lähe, on kasutajakogemus hoopis teine. Enamasti märkasid nad, et nad saavad "vestelda", jättes inimestele, kellega nad rääkisid, märkmeid, nii et nad mõtlesid, kuidas see erineb näiteks Slackist. Pheh!
Igapäevaste sünkroonimiste kujundamine
Kui teil on tarkvaraarenduse kogemus, peab olema närvesööv meeles pidada, et enamik inimesi ei saa lihtsalt vaadata liidese pilti ja mõista, mida see sellega suhtlemisel teeb. Rääkimata sellest, mis toimub programmi enda sees. Teadmine sellest võib juhtuda on suures osas teadmise tulemus, mis ei saa juhtuda ja mis ei tohiks juhtuda. See nõuab mitte ainult seda, mida tarkvara teeb, vaid ka seda, kuidas selle üksikud osad on kooskõlastatud ja omavahel suhtlevad.
Selle klassikaline näide on kasutaja, kes vaatab a spinner.gif, huvitab, millal töö lõpuks valmis saab. Arendaja oleks aru saanud, et protsess on tõenäoliselt takerdunud ja gif ei kao kunagi ekraanilt. See animatsioon simuleerib töö täitmist, kuid ei ole seotud selle olekuga. Sellistel juhtudel meeldib mõnele tehnikaspetsialistile silmi pööritada, olles hämmastunud kasutajate segaduse ulatusest. Kuid pange tähele, kui paljud neist osutavad pöörlevale kellale ja ütlevad, et see on tegelikult paigal?
See on reaalajas väärtuse olemus. Tänapäeval kasutatakse reaalajas andmebaase veel väga vähe ja paljud suhtuvad neisse kahtlustavalt. Enamik neist andmebaasidest kaldub tugevalt NoSQL-stiili poole, mistõttu kasutavad nad tavaliselt Mongo-põhiseid lahendusi, mis on kõige parem unustada. Minu jaoks tähendab see aga CouchDB-ga töötamise mugavaks saamist, aga ka struktuuride kujundamise õppimist, mida saab andmetega täita rohkem kui lihtsalt mõni bürokraat. Arvan, et kasutan oma aega paremini.
Kuid selle postituse tegelik teema on see, mida ma täna kasutan. Mitte omal valikul, vaid ükskõikselt ja pimesi rakendatud ettevõtete poliitika tõttu. Seega annan kahe tihedalt seotud Google'i reaalajas andmebaasitoote täiesti õiglase ja erapooletu võrdluse.
Mõlema nimes on sõna Tuli. Üks asi on mul hea sõnaga meeles. Teine asi on minu jaoks teist tüüpi tuli. Ma ei kiirusta nende nimesid ütlema, sest kui ma seda ütlen, puutume kokku esimese suure probleemiga: nimedega.
Esimest nimetatakse Firebase'i reaalajas andmebaasja teiseks - Firebase Cloud Firestore. Mõlemad on pärit tooted Firebase'i komplekt Google. Nende API-sid nimetatakse vastavalt firebase.database(…) и firebase.firestore(…).
See juhtus sellepärast Reaalajas andmebaas - see on lihtsalt originaal Firebase enne selle ostmist Google'i poolt 2014. aastal. Seejärel otsustas Google luua paralleeltootena koopia Firebase, mis põhineb suurandmete ettevõttel ja nimetas seda pilvega Firestore'iks. Loodan, et te pole veel segaduses. Kui olete endiselt segaduses, ärge muretsege, ma ise kirjutasin selle artikli osa kümme korda ümber.
Sest peate märkima Firebase Firebase'i küsimuses ja Firestore küsimuses Firebase'i kohta, vähemalt selleks, et saaksite aru mõne aasta tagusest Stack Overflow'st.
Kui oleks auhind halvima tarkvaranimetamise kogemuse eest, oleks see kindlasti üks kandidaate. Hammingi vahemaa nende nimede vahel on nii väike, et ajab segadusse isegi kogenud insenerid, kelle sõrmed trükivad üht nime, samal ajal kui pea mõtleb teisele. Need on heade kavatsustega plaanid, mis ebaõnnestuvad haledalt; nad täitsid ennustuse, et andmebaas põleb. Ja ma ei tee üldse nalja. Inimene, kes selle nimeskeemi välja mõtles, tekitas verd, higi ja pisaraid.
Pürrose võit
Võiks arvata, et Firestore on asendamine Firebase, selle järgmise põlvkonna järeltulija, kuid see oleks eksitav. Firestore ei ole Firebase'i sobiv asendus garanteeritud. Näib, et keegi lõikas sellest välja kõik huvitava ja ajas enamiku ülejäänutest mitmel viisil segadusse.
Kuid kiire pilk kahele tootele võib teid segadusse ajada: näib, et nad teevad sama asja, põhimõtteliselt samade API-de kaudu ja isegi samas andmebaasi seansis. Erinevused on peened ja need ilmnevad ainult ulatusliku dokumentatsiooni hoolikas võrdlev uurimine. Või kui proovite portida koodi, mis töötab Firebase'is ideaalselt, et see töötaks koos Firestore'iga. Isegi siis saate teada, et andmebaasi liides süttib kohe, kui proovite hiirega reaalajas lohistada. Kordan, ma ei tee nalja.
Firebase'i klient on viisakas selles mõttes, et puhverdab muudatused ja proovib automaatselt uuesti värskendusi, mis annavad prioriteediks viimasele kirjutamistoimingule. Firestore'il on aga limiit 1 kirjutamisoperatsioon dokumendi ja kasutaja kohta sekundis ning selle piirangu kehtestab server. Sellega töötades on teie ülesanne leida sellest möödapääs ja rakendada värskendussageduse piiraja, isegi kui proovite lihtsalt oma rakendust luua. See tähendab, et Firestore on reaalajas andmebaas ilma reaalajas kliendita, mis maskeerub API abil.
Siin hakkame nägema esimesi märke Firestore'i raison d'être'ist. Ma võin eksida, kuid kahtlustan, et keegi kõrgel Google'i juhtkonnast vaatas pärast ostu Firebase'i ja ütles lihtsalt: "Ei, issand, ei. See on vastuvõetamatu. Lihtsalt mitte minu juhtimise all."
Ta ilmus oma kambrist ja teatas:
"Üks suur JSON-dokument? Ei. Jagate andmed eraldi dokumentideks, millest igaüks ei ole suurem kui 1 megabait.
Näib, et esimest kohtumist ühegi piisavalt motiveeritud kasutajaskonnaga selline piirang üle ei ela. Teate küll. Näiteks tööl on meil üle pooleteise tuhande esitluse ja see on Täiesti normaalne.
Selle piiranguga olete sunnitud leppima tõsiasjaga, et üks andmebaasis olev "dokument" ei sarnane ühelegi objektile, mida kasutaja võib dokumendiks nimetada.
"Massiivide massiivid, mis võivad rekursiivselt sisaldada muid elemente? Ei. Massiivid sisaldavad ainult kindla pikkusega objekte või numbreid, nagu Jumal kavatses."
Nii et kui lootsite GeoJSONi oma Firestore'i lisada, avastate, et see pole võimalik. Miski mitteühemõõtmeline pole vastuvõetav. Loodan, et teile meeldib Base64 ja/või JSON JSON-is.
"JSON-i importimine ja eksportimine HTTP, käsureatööriistade või administraatoripaneeli kaudu? Ei. Saate andmeid eksportida ja importida ainult teenusesse Google Cloud Storage. Ma arvan, et seda nimetatakse praegu nii. Ja kui ma ütlen "teie", siis ma pöördun ainult nende poole, kellel on projektiomaniku volitused. Kõik teised võivad minna ja pileteid luua."
Nagu näete, on FireBase'i andmemudelit lihtne kirjeldada. See sisaldab ühte tohutut JSON-dokumenti, mis seob JSON-võtmed URL-i teedega. Kui kirjutate koos HTTP PUT в / FireBase on järgmine:
{
"hello": "world"
}
То GET /hello tuleb tagasi "world". Põhimõtteliselt töötab see täpselt nii, nagu ootate. FireBase'i objektide kogu /my-collection/:id samaväärne JSON-sõnastikuga {"my-collection": {...}} juurtes, mille sisu on saadaval /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}See toimib hästi, kui igal vahetükil on kokkupõrkevaba ID, mille jaoks on süsteemil standardlahendus.
Teisisõnu on andmebaas 100% JSON(*)-ühilduv ja töötab suurepäraselt HTTP-ga, näiteks CouchDB-ga. Kuid põhimõtteliselt kasutate seda reaalajas API kaudu, mis võtab kokku veebipistikupesad, autoriseerimise ja tellimused. Administraatoripaneelil on mõlemad võimalused, võimaldades nii reaalajas redigeerimist kui ka JSON-i importi/eksporti. Kui teete sama oma koodis, üllatate, kui palju spetsialiseeritud koodi raisatakse, kui mõistate, et paiga ja erinevuse JSON lahendab 90% püsiva oleku käsitlemise rutiinsetest ülesannetest.
Firestore'i andmemudel sarnaneb JSON-iga, kuid erineb mõnel kriitilisel viisil. Ma juba mainisin massiivide puudumist massiivides. Alamkogude mudeli järgi peavad need olema esmaklassilised mõisted, mis on neid sisaldavast JSON-dokumendist eraldiseisvad. Kuna selleks pole valmis serialiseerimist, on andmete toomiseks ja kirjutamiseks vaja spetsiaalset kooditeed. Oma kogude töötlemiseks peate kirjutama oma skriptid ja tööriistad. Administraatoripaneel võimaldab teha väikseid muudatusi ainult ühel väljal korraga ja sellel pole impordi-/ekspordivõimalusi.
Nad võtsid reaalajas NoSQL-i andmebaasi ja muutsid selle aeglaseks mitte-SQL-iks, millel oli automaatne liitumine ja eraldi mitte-JSON-veerg. Midagi nagu GraftQL.
Kuum Java
Kui Firestore pidi olema töökindlam ja skaleeritavam, siis iroonia on see, et keskmine arendaja saab lõpuks vähem töökindla lahenduse kui FireBase'i kastist välja valimine. Selline tarkvara, mida Grumpy andmebaasi administraator vajab, nõuab pingutust ja talentide kaliibrit, mis on lihtsalt ebareaalne selle niši jaoks, milles toode peaks olema hea. See sarnaneb sellega, kuidas HTML5 Canvas ei asenda üldse Flashi, kui puuduvad arendustööriistad ja pleier. Lisaks on Firestore kinni püüdnud andmete puhtuse ja steriilse valideerimise järele, mis lihtsalt ei ühti sellega, kuidas keskmine ärikasutaja armastab tööd teha: tema jaoks on kõik valikuline, sest kuni lõpuni on kõik mustand.
FireBase'i peamine puudus on see, et klient loodi mitu aastat oma ajast ees, enne kui enamik veebiarendajaid muutus muutumatusest teada. Seetõttu eeldab FireBase, et muudate andmeid, ega kasuta seetõttu ära kasutaja pakutavat muutumatust. Lisaks ei kasuta see kasutajale edastatavate hetktõmmiste andmeid uuesti, mis muudab erinevuse palju keerulisemaks. Suurte dokumentide puhul on selle muutuva erinevuse baasil tehingumehhanism lihtsalt ebapiisav. Poisid, meil juba on WeakMap JavaScriptis. See on mugav.
Kui annate andmetele soovitud kuju ja ei muuda puid liiga mahukaks, saab sellest probleemist mööda hiilida. Kuid ma olen uudishimulik, kas FireBase oleks palju huvitavam, kui arendajad annaksid välja tõeliselt hea kliendi API, mis kasutaks muutumatust koos tõsiste praktiliste nõuannetega andmebaasi kujundamisel. Selle asemel näis, et nad üritasid parandada seda, mis polnud katki, ja see tegi asja hullemaks.
Ma ei tea kogu Firestore'i loomise loogikat. Musta kasti sees esile kerkivate motiivide üle spekuleerimine on samuti osa lõbususest. Kahe äärmiselt sarnase, kuid võrreldamatu andmebaasi kõrvutamine on üsna haruldane. Nagu keegi oleks mõelnud: "Firebase on lihtsalt funktsioon, mida saame Google Cloudis jäljendada", kuid pole veel avastanud reaalsete nõuete tuvastamise ega kõigile neile nõuetele vastavate kasulike lahenduste loomise kontseptsiooni. "Las arendajatel mõelda. Lihtsalt tehke kasutajaliides ilusaks... Kas saate lisada rohkem tuld?
Ma saan andmestruktuuride kohta paarist asjast aru. Kindlasti näen kontseptsiooni "kõik ühes suures JSON-puus" kui katset võtta andmebaasist välja igasugune suuremahuline struktuur. Oodata, et tarkvara saab lihtsalt hakkama mis tahes kahtlase andmestruktuuri fraktaalidega, on lihtsalt hull. Ma ei pea isegi ette kujutama, kui halvasti asjad võivad olla, olen teinud rangeid koodiauditeid ja Ma nägin asju, millest te, inimesed, ei osanud unistadagi. Kuid ma tean ka, millised näevad välja head struktuurid, и . Ma kujutan ette maailma, kus Firestore tunduks loogiline ja inimesed, kes selle lõid, arvaksid, et nad tegid head tööd. Kuid me ei ela selles maailmas.
FireBase'i päringutugi on ühegi standardi järgi kehv ja praktiliselt olematu. See vajab kindlasti parandamist või vähemalt ülevaatamist. Kuid Firestore pole palju parem, kuna see on piiratud samade ühemõõtmeliste indeksitega, mis on tavalises SQL-is. Kui vajate päringuid, mida inimesed käitavad kaootiliste andmete põhjal, vajate täistekstiotsingut, mitme vahemiku filtreid ja kohandatud kasutaja määratud järjestust. Lähemal vaatlusel on tavalise SQL-i funktsioonid iseenesest liiga piiratud. Lisaks on ainsad SQL-päringud, mida inimesed saavad tootmises käivitada, kiirpäringud. Teil on vaja kohandatud indekseerimislahendust läbimõeldud andmestruktuuridega. Kõige muu jaoks peaks olema vähemalt incremental map-reduce või midagi sarnast.
Kui otsite Google Docsist selle kohta teavet, suunatakse teid loodetavasti BigTable ja BigQuery poole. Kõikide nende lahendustega käib aga kaasas nii tihe ettevõtete müügižargoon, et keerad kiiresti tagasi ja hakkad midagi muud otsima.
Viimane asi, mida soovite reaalajas andmebaasiga kasutada, on midagi, mille on loonud juhtkonna palgaskaalal olevad inimesed.
(*) See on nali, sellist asja pole olemas .
Reklaamide õiguste kohta
Otsin silumisprojektide jaoks, server arenduseks ja hostimiseks? Olete kindlasti meie klient 🙂 Erineva konfiguratsiooniga serverite päevahinnad, DDoS-i vastased ja Windowsi litsentsid on juba hinna sees.
Allikas: www.habr.com