See andmebaas on tulekahjus…

Laske mul rääkida tehnilisest loost.

Palju aastaid tagasi töötasin rakenduse kallal, millel olid integreeritud koostööfunktsioonid. See oli mugav eksperimentaalne tehnoloogia, mis kasutas varase Reacti ja CouchDB täit potentsiaali. See sünkroniseeris andmeid reaalajas JSON-i kaudu. OT. Seda kasutati ettevõtte sisetöödes, kuid laiem rakendatavus ja potentsiaal muudes valdkondades olid ilmsed.

Püüdes müüa seda tehnoloogiat potentsiaalsetele klientidele, kohtasime ootamatut takistust. Meie demonstraatsioonivideo näitas, et meie tehnoloogia nägid välja ja töötasid suurepäraselt, selles ei olnud probleeme. Video näitas täpselt, kuidas see töötab, ja seal ei olnud mitte midagi simuleeritud. Me mõtlesime välja ja kodeerisime realistliku programmi rakendamise stsenaariumi.


Tegelikult see oligi probleem. Meie demo töötas just nii, nagu kõik teised oma rakenduseid simuleerides. Konkreetselt edastati teave A-st B-sse kohe, isegi kui need olid suured meediafailid. Pärast süsteemi sisenemist nägid kõik kasutajad uusi kirjeid. Rakenduse abil said erinevad kasutajad selgelt koos töötada samadel projektidel, isegi kui mõnes külas oli Interneti-ühendus katkendlik. Nii on see kaudselt selgitatud igas After Effectsis toodetud toote videos.

Kuigi kõik teadsid, milleks on vajaliku Refresh nupp, ei saanud keegi täpselt aru, et veebirakendused, mida nad paluvad meil luua, on tavaliselt oma piirangutega kokku puutunud. Ja kui neid enam ei vajata, on kasutajakogemus sootuks erinev. Peamiselt märgati, et saab 'chatis' suhelda, jättes vestluskaaslastele märkmeid, mistõttu küsiti, kuidas see erineb näiteks Slackist. Uff!

Igapäevase sümbioosi disain

Kui teil on juba tarkvaraarenduse kogemus, siis peab teid närima vajadus mäletada, et enamik inimesi ei suuda lihtsalt vaadata kasutajaliidese pilti ja mõista, mida see selle kasutamise ajal teha kavatseb. Rääkimata sellest, mis toimub programmi enda sees. Teadlikkus sellest, suuteline mis võib juhtuda — on suuresti teadmiste tulemus sellest, mis ei saa juhtuda ja mis ei peaks juhtuma. Selleks on vajalik vaimne mudel mitte ainult selle kohta, mida tarkvara teeb, vaid ka selle kohta, kuidas selle erinevad osad on omavahel seotud ja suhtlevad.

Klassikaliseks näiteks on kasutaja, kes vaatab kakskümmend minutit spinner.gif, püüdes arvata, millal töö lõpuks lõpule jõuab. Arendaja mõistaks, et protsess on tõenäoliselt hangunud ja gif ei kao kunagi ekraanilt. See animatsioon imiteerib töö tegemist, kuid ei ole seotud selle seisundiga. Taolistes olukordades armastavad mõned tehnilised inimesed silmi pööritada, imetledes, kui ekslikud kasutajad võivad olla. Kuid tähelepanuväärne on, kes neist osutab pöörlevatele kelladele ja ütleb, et need tegelikult seisavad paigal?

Selle sisuks on reaalajas andmebaaside väärtus. Tänapäeval kasutatakse reaalajas andmebaase endiselt väga vähe ning paljud suhtuvad neisse ettevaatlikult. Enamik selliseid andmebaase kaldub NoSQL stiilile, mistõttu kasutatakse tavaliselt Mongo-põhiseid lahendusi, millest on parem unustada. Minu jaoks tähendab see aga mugavust CouchDB kasutamisel ja struktuuride kavandamise õppimist, mille suudab täita andmetega mitte ainult mõni bürokraat. Arvan, et kasutan oma aega tõhusamalt.

Kuid selle postituse tõeline teema on see, mida kasutan täna. Mitte oma valikul, vaid ühtse ja pimedalt rakendatud ettevõtte poliitika tõttu. Seetõttu teen ma täiesti ausa ja objektiivse võrdluse kahe tihedalt seotud toote vahel, mis käsitlevad reaalajas andmebaase Google'ilt.

Mõlema nime seas on sõna Fire. Üks neist toob mulle meelde helluse. Teine minu jaoks on teistsugune tuli. Ma ei kiirusta nende nimede ütlemisega, sest niipea kui ma seda teen, satume silmitsi esimese suure probleemiga – nimedega.

Esimene on nimetatud Firebase Real-Time Database, aga teine on Firebase Cloud Firestore. Mõlemad on tooted, mis pärinevad Firebase komplektist Google. Nende API-d kannavad vastavalt nimetusi firebase.database(…) ja firebase.firestore(…).

See juhtus, sest Reaalajas andmebaas — see on lihtsalt algne Firebase enne selle Google'i ostmist 2014. aastal. Seejärel otsustas Google luua selle kõrvaltoote, tuues välja koopia Firebase suure andmemahu põhjal ja nimetas selle Firestore with a cloud. Loodan, et te ei ole veel segadusse sattunud. Kui siiski, siis ärge muretsege, ma kirjutasin selle osa artiklist üle kümme korda.

Sest tuleb märkida Firebase küsimuses Firebase, ja Firestore küsimuses Firebase, vähemalt et teid mõistetaks paar aastat tagasi Stack Overflow's.

Kui oleks olemas auhind halvimate tarkvaranimedega, oleks see juhtum kindlasti üks kandidaate. Hamming'i kaugus nende nimetuste vahel on nii väike, et see segab isegi kogenud insenere, kelle sõrmed trükivad üht nime, kuigi pea mõtleb teisest. Need on plaanid, mis on suure kõmakaga ebaõnnestunud, välja mõeldud parimate kavatsustega; nad täitsid ennustuse, et andmebaas põleb tulekahjus. Ja ma ei nalja. Inimene, kes sellise nimetamisstruktuuri välja mõtles, on vere, higi ja pisarate põhjustaja.

Pürrhoose võit

Võimalik, et Firestore on asendus Firebase'ile, selle järgmise põlvkonna järeltulijale, kuid see oleks vale arusaam. Firestore ei sobi kindlasti Firebase'i asendamiseks. Tundub, et keegi lõikas sellest välja kõik huvitava ja segas suure osa, mis alles jäi, erinevate viisidega.

Kuid kiire pilk kahe toote vahel võib teid petta: näib, et nad teevad sama asja, kaudu peaaegu identsete API-de ja isegi sama andmebaasi seansi kaudu. Erinevused on vaevu märgatavad ja need ilmnevad alles põhjaliku võrdleva dokumentatsiooni uurimise käigus. Või siis, kui üritad portida suurepäraselt töötavat Firebase'i koodi, et see töötaks Firestore'iga. Juba siis saad aru, et andmebaasi liides süttib, kui proovid reaalajas hiirega lohistada. Kordan, ma ei nalja.

Firebase klient on hoolikas, kuna ta salvestab muudatused ja täidab automaatseid uuendamisproovi, kus viimane kirjutusoperatsioon on prioriteetne. Kuid Firestore'l on piirang, et üks kasutaja tohib dokumenti kirjutada ainult ühe korra sekundis, ning see piirang on serveripoolne. Töötades sellega peate leidma viisi selle kõrvaldamiseks ja rakendama uuenduste sageduse piiramist, isegi kui proovite lihtsalt oma rakendust luua. Teisisõnu on Firestore reaalajas andmebaas ilma reaalajas kliendita, mis varjab end API abil.

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

Ta ilmus oma reservuaarist ja kuulutas:

„Üks suur JSON dokument? Ei. Te jagate andmed eraldi dokumentideks, millest igaühe suurus on maksimaalselt 1 megabait.“

Tundub, et selline piirang ei suuda taluda esimest kohtumist piisavalt motiveeritud kasutajate baasiga. Teate, et see on tõsi. Meie juures, näiteks, on üle tuhande esitlust, ja see on täiesti normaalne.

Selle piirangu korral peate leppima sellega, et üks "dokumend" andmebaasis ei sarnane ühele objekti, mida kasutaja võiks nimetada dokumendiks.

"Massiivide massiivid, mis võivad rekursiivselt sisaldada teisi elemente? Ei. Massiivid sisaldavad ainult objekte või fikseeritud pikkusega numbreid, nagu Issand soovis."

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

"JSON-i import ja eksport HTTP kaudu, käsurea tööriistad või administraatori paneel? Ei. Saate ainult eksportida ja importida andmeid Google Cloud Storage'i. Nii see praegu tundub olevat. Ja kui ma ütlen 'te', siis pöördun ainult nende poole, kellel on Project Owneri õigused. Kõik teised võivad minna ja luua piletid."

Nagu näete, on FireBase andmemudel lihtne kirjeldada. See sisaldab üht suurt JSON-dokumenti, mis seob JSON-võtmed URL-teedega. Kui te salvestate kasutades HTTP PUT ühes / FireBase järgmise:

{
  "hello": "world"
}

Siis GET /hello tagastab "world". Põhimõtteliselt töötab see täpselt nii, nagu te ootate. FireBase'i objektide kogu /my-collection/:id on võrreldav JSON-sõnaraamatuga {"my-collection": {...}} juures, mille sisu on kättesaadav /my-collection:

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

See töötab suurepäraselt, kui igal sisestusel on konfliktivaba ID, mille jaoks süsteemis on standardlahendus.

Teisisõnu on andmebaas 100% ühilduv JSON-iga (*) ja töötab suurepäraselt HTTP-ga, näiteks CouchDB-ga. Kuid peamiselt kasutate seda reaalajas API kaudu, mis abstraktiseerib websockets, autolariseerimise ja tellimused. Administraatori paneel omab mõlemaid võimalusi, võimaldades reaalajas redigeerimist ning JSON-i importimist/ekspordimist. Kui oma koodis järgite sama, siis imestate, kui palju spetsialiseeritud koodi kaduma läheb, kui mõistate, et JSON-i patch ja diff võimaldavad lahendada 90% rutiinsetest probleemidest, mis on seotud püsiva olekuga.

Firestore'i andmemudel meenutab JSON-i, kuid erineb sellest mõnede kriitiliselt oluliste aspektide poolest. Olen juba maininud, et massiivid ei tohi sisaldada massiive. Alamkollektsioonide mudel peab olema esmaklassilised kontseptsioonid, mis on eraldatud neid sisaldavast JSON-dokumendist. Kuna selleks ei ole olemas valmis serialiseerimist, on andmete lugemiseks ja kirjutamiseks vajalik spetsialiseeritud koodi täitmise tee. Omandatud kollektsioonide töötlemiseks tuleb kirjutada oma skripte ja tööriistu. Administraatori paneel võimaldab teha ainult väikeseid muudatusi korraga ühe välja kaupa ning tal ei ole impordi/väljaande võimalusi.

Nad võtsid reaalajas NoSQL andmebaasi ja muutsid selle aeglaseks mitte-SQL-ks automaatsete ühendustega ja eraldiseisva mitte-JSON veeruga. Midagi GraftQL-i vaimus.

Kuum Java

Kui Firestore peab olema usaldusväärsem ja skaleeritavam, siis on iroonia see, et keskmine arendaja saab vähem usaldusväärse lahenduse kui valides FireBase "kastist välja". See tarkvara, mis on vajalik nürilt kriitiliste andmehaldurite jaoks, nõuab niivõrd suurt pingutust ja spetsialistide kalibreerimist, et see on lihtsalt ebareaalne nišis, kus peaks olema hea toode. See on sarnane sellele, et HTML5 Canvas ei asenda Flashi, kui puuduvad arendustooted ja mängijad. Veelgi enam, Firestore on kinni andmete puhtuse ja steriilse valideerimise püüdlemises, mis lihtsalt ei vasta keskmise ärikasutaja vajadustele. armastab töötada: tema jaoks ei ole see vajalik, kuna kõik lõpuks jääb eelnõuks.

FireBase'i peamine puudus on see, et klient loodi juba mitu aastat enne oma tähtaega, veel enne, kui enamik veebiarendajatest immutavusest teadlikud olid. Seetõttu eeldab FireBase, et te muudate andmeid, mistõttu ei kasuta ta ära kasutaja pakutavat immutavust. Lisaks ei kasuta ta andmeid korduvates kasutajale edastatavates snapshotides, mistõttu on diffide tegemine palju keerulisem. Suurte dokumentide puhul on tema muudetud diffide põhine tehingumehhanism lihtsalt ebapiisav. Poisid, meil on ju juba olemas WeakMap JavaScriptis. See on mugav.

Kui andmetele anda õige kuju ja mitte teha puid liiga mahukateks, siis on võimalik see probleem vältida. Kuid mind huvitab, kas FireBase oleks palju huvitavam, kui arendajad esitaksid tõeliselt hea kliendi API, mis kasutaks immutavust koos tõsiste praktiliste nõuannete andmisega andmebaasi struktuuri kohta. Selle asemel näib, et nad püüdsid parandada seda, mis ei ole katki, ja sellest sai halvem.

Ma ei tea kogu loogikat, mis seisnes Firestore'i loomises. Argumente musta kasti sees tekkivate motiivide üle on samuti osa lõbust. Selline kahe üksteisega väga sarnase, kuid võrreldamatud andmebaasi vastandamine on üsna haruldane. Justkui keegi oleks mõelnud: „Firebase on lihtsalt funktsioon, mida saame Google Cloudis emuleerida“, kuid samas pole ta veel avastanud reaalse maailma nõuete määratlemise kontseptsiooni või kasulike lahenduste loomise, mis neid nõudeid rahuldavad. „Las arendajad mõtlevad sellele. Lihtsalt tehke UI ilusaks… Aga kas võiks rohkem tuld lisada?“

Ma tean andmestruktuuridest paar asja. Näen kindlasti, et kontseptsioon „kõik ühes suures JSON-puus“ on katse andmebaasist eemaldada mistahes suurstruktuuri tunne. Oodata, et tarkvara lihtsalt toimetab iga kahtlase andmestruktuuri fraktaaliga — see on lihtsalt hullumeelsus. Ma ei pea isegi ette kujutama, kui halb kõik olla võiks, olen teinud ranged koodiauditid ja näinud sellist, millest te, inimesed, ei ole isegi unistanud.. Kuid ma tean ka, kuidas head struktuurid välja näevad, ja kuidas neid kasutada. ja miks seda on vaja teha. Ma suudan ette kujutada maailma, kus Firestore tundub täiesti loogiline ja selle loonud inimesed arvavad, et nad on head tööd teinud. Kuid me ei elame selles maailmas.

FireBase'i päringute koostamise toetus on igasuguste standardite järgi halb, seda ei practically ole. See vajab kindlasti parandamist või vähemalt läbivaatamist. Kuid Firestore ei ole palju parem, kuna see on piiratud samade ühekaaluliste indeksitega, mis on olemas lihtsas SQL-is. Kui vajate päringuid, mida inimesed teevad kaootiliste andmetega, on vajalik täisteksti otsing, mitme vahemiku filtrid ja kasutaja määratud suvaline järjestus. Sügavale vaatamise korral on lihtsa SQL funktsioonid ise liiga piiratud. Lisaks saavad ainult ainsad SQL-päringud, mida inimesed saavad töödelda, olla kiirete päringute. Te vajate spetsialiseeritud lahendust indekseerimiseks koos läbimõeldud andmestruktuuridega. Kogu muu jaoks peaks vähemalt olema täiendav kaardistamine-reduce või midagi sarnast.

Kui otsite selle kohta teavet Google'i dokumentidest, loodan, et suunatakse teid millegi nagu BigTable ja BigQuery suunas. Kuid kõik need lahendused on ümbritsetud nii tiheda ettevõtlusjargooniga, et te pöördute kiiresti tagasi ja hakkate otsima midagi muud.

Viimane asi, mida vajate reaalajas andmebaasi puhul, on midagi, mis on loodud inimeste jaoks ja mida haldavad inimeste palkade süsteemid.

(*) See on nalja, 100% JSON-i ühilduvuse mõistet ei eksisteeri. Otsite.

Reklaami õigustes

projekti arendamiseks ja majutamiseks mõeldud serverit? Te olete just meie klient 🙂 Meie päevapõhine serverihind võimaldab erinevate konfiguratsioonide, DDoS kaitse ja Windows litsentside kaasamist juba hinna sisse. VDS Las ma räägin teile tehnilise loo. Aastaid tagasi arendasin rakendust, milles olid sisseehitatud koostööfunktsioonid. See oli mugav katsetav tehnoloogiate kogum, mis kasutas varase Reacti ja CouchDB täielikku potentsiaali. See sünkroniseeris andmeid reaalajas JSON OT abil. Seda kasutati ettevõtte sisetöödes, kuid selle laiem kasutus ja potentsiaal muudes valdkondades oli silmapaistev.

Allikas: habr.com