Tämä tietokanta on tulessa...

Kerronpa teknisen tarinan.

Monia vuosia sitten kehitin sovellusta, jossa oli sisäänrakennettuja yhteistyöominaisuuksia. Se oli käyttäjäystävällinen kokeellinen pino, joka hyödynsi varhaisen Reactin ja CouchDB:n koko potentiaalia. Se synkronoi tiedot reaaliajassa JSONin kautta OT. Sitä käytettiin yrityksen sisällä, mutta sen laaja sovellettavuus ja potentiaali muilla alueilla oli selvä.

Kun yritimme myydä tätä teknologiaa potentiaalisille asiakkaille, kohtasimme odottamattoman esteen. Demovideossa tekniikkamme näytti ja toimi erinomaiselta, eikä siinä ollut ongelmia. Video osoitti tarkalleen, miten se toimii, eikä jäljitelty mitään. Keksimme ja koodasimme realistisen skenaarion ohjelman käyttöön.


Itse asiassa tästä tuli ongelma. Demomme toimi täsmälleen samalla tavalla kuin muut simuloivat sovelluksiaan. Tarkemmin sanottuna tiedot siirtyivät välittömästi paikasta A paikkaan B, vaikka ne olisivat suuria mediatiedostoja. Sisäänkirjautumisen jälkeen jokainen käyttäjä näki uusia merkintöjä. Sovelluksen avulla eri käyttäjät voisivat työskennellä selkeästi samoissa projekteissa, vaikka nettiyhteys katkeaisi jossain kylässä. Tämä sisältyy implisiittisesti mihin tahansa After Effectsin tuotevideoon.

Vaikka kaikki tiesivät, mitä varten Päivitä-painike oli tarkoitettu, kukaan ei todellakaan ymmärtänyt, että verkkosovellukset, joita he pyysivät meitä rakentamaan, olivat yleensä omien rajoitustensa alaisia. Ja jos niitä ei enää tarvita, käyttökokemus on täysin erilainen. Useimmiten he huomasivat, että he voivat "chattaa" jättämällä muistiinpanoja ihmisille, joiden kanssa he keskustelivat, joten he ihmettelivät, miten tämä eroaa esimerkiksi Slackista. Huh huh!

Arjen synkronoinnin suunnittelu

Jos sinulla on kokemusta ohjelmistokehityksestä, on varmasti hermoja raastavaa muistaa, että useimmat ihmiset eivät voi vain katsoa kuvaa käyttöliittymästä ja ymmärtää, mitä se tekee vuorovaikutuksessa sen kanssa. Puhumattakaan siitä, mitä itse ohjelman sisällä tapahtuu. Tieto siitä voida Tapahtuminen on suurelta osin seurausta tiedosta, mitä ei voi tapahtua ja mitä ei pitäisi tapahtua. Tämä vaatii henkinen malli ei vain mitä ohjelmisto tekee, vaan myös kuinka sen yksittäiset osat koordinoidaan ja kommunikoivat keskenään.

Klassinen esimerkki tästä on käyttäjä, joka tuijottaa a spinner.gif, mietin milloin työ vihdoin valmistuu. Kehittäjä olisi ymmärtänyt, että prosessi oli todennäköisesti jumissa ja että gif ei koskaan katoa näytöltä. Tämä animaatio simuloi työn suorittamista, mutta ei liity sen tilaan. Tällaisissa tapauksissa jotkut teknikot haluavat pyörittää silmiään hämmästyneenä käyttäjien hämmennyksen laajuudesta. Huomaa kuitenkin, kuinka monet heistä osoittavat pyörivää kelloa ja sanovat, että se on todella paikallaan?

Tämä on reaaliaikaisen arvon ydin. Nykyään reaaliaikaisia ​​tietokantoja käytetään vielä hyvin vähän ja monet ihmiset suhtautuvat niihin epäluuloisesti. Useimmat näistä tietokannoista nojaavat voimakkaasti NoSQL-tyyliin, minkä vuoksi ne käyttävät yleensä Mongo-pohjaisia ​​ratkaisuja, jotka on parasta unohtaa. Minulle tämä merkitsee kuitenkin CouchDB:n kanssa työskentelyn oloa mukavaksi sekä oppimista suunnittelemaan rakenteita, joita muukin kuin joku byrokraatti voi täyttää datalla. Luulen, että käytän aikaani paremmin.

Mutta tämän viestin todellinen aihe on se, mitä käytän tänään. Ei valinnasta, vaan välinpitämättömästi ja sokeasti sovelletun yrityspolitiikan takia. Joten annan täysin oikeudenmukaisen ja puolueettoman vertailun kahdesta läheisesti liittyvästä Googlen reaaliaikaisesta tietokantatuotteesta.

Molempien nimessä on sana Tuli. Yhden asian muistan lämmöllä. Toinen asia minulle on erilainen tuli. Minulla ei ole kiire sanoa heidän nimiään, koska kun sanon, törmäämme ensimmäiseen suureen ongelmaan: nimiin.

Ensimmäinen on nimeltään Firebase reaaliaikainen tietokantaja toiseksi - Firebase Cloud Firestore. Molemmat ovat tuotteita Firebase-sviitti Google. Niiden API:ita kutsutaan vastaavasti firebase.database(…) и firebase.firestore(…).

Tämä tapahtui, koska Reaaliaikainen tietokanta - Se on vain alkuperäinen Firebase ennen kuin Google osti sen vuonna 2014. Sitten Google päätti luoda rinnakkaistuotteena kopio Firebase perustuu isoon datayritykseen ja kutsui sitä Firestore with a cloud. Toivottavasti et ole vielä hämmentynyt. Jos olet edelleen hämmentynyt, älä huoli, kirjoitin itse tämän artikkelin osan kymmenen kertaa uudelleen.

Koska sinun on ilmoitettava Firebase Firebase-kysymyksessä ja Firestore Firebasea koskevassa kysymyksessä, ainakin jotta ymmärrät muutama vuosi sitten Stack Overflow:ssa.

Jos pahimmasta ohjelmiston nimeämiskokemuksesta myönnettäisiin palkinto, tämä olisi ehdottomasti yksi kilpailijoista. Näiden nimien välinen Hamming-etäisyys on niin pieni, että se hämmentää kokeneitakin insinöörejä, joiden sormet kirjoittavat yhtä nimeä, kun heidän päänsä ajattelee toista. Nämä ovat hyvää tarkoittavia suunnitelmia, jotka epäonnistuvat surkeasti; he täyttivät ennustuksen, että tietokanta olisi tulessa. Enkä vitsaile ollenkaan. Tämän nimeämisjärjestelmän keksijä aiheutti verta, hikeä ja kyyneleitä.

Pyrrhic voitto

Voisi luulla, että Firestore on korvaaminen Firebase, sen seuraavan sukupolven jälkeläinen, mutta se olisi harhaanjohtavaa. Firestorea ei taata sopivan korvaavan Firebasen. Näyttää siltä, ​​​​että joku leikkasi siitä pois kaiken mielenkiintoisen ja hämmensi suurimman osan muusta eri tavoin.

Nopea vilkaisu näihin kahteen tuotteeseen voi kuitenkin hämmentää sinut: ne näyttävät tekevän saman asian periaatteessa samojen API:iden kautta ja jopa samassa tietokantaistunnossa. Erot ovat hienovaraisia, ja ne paljastuvat vain laajan dokumentaation huolellisella vertailevalla tutkimisella. Tai kun yrität siirtää koodia, joka toimii täydellisesti Firebasessa, jotta se toimii Firestoren kanssa. Silloinkin huomaat, että tietokantaliittymä syttyy heti, kun yrität vetää ja pudottaa hiirellä reaaliajassa. Toistan, en vitsaile.

Firebase-asiakas on kohtelias siinä mielessä, että se puskuroi muutokset ja yrittää automaattisesti uudelleen päivityksiä, jotka antavat etusijalle viimeiselle kirjoitustoiminnolle. Firestoressa on kuitenkin rajoitus 1 kirjoitusoperaatioon asiakirjaa ja käyttäjää kohden sekunnissa, ja tämä raja on palvelimen toimesta. Kun työskentelet sen kanssa, sinun on löydettävä keino kiertää se ja ottaa käyttöön päivitysnopeuden rajoitin, vaikka yrität vain rakentaa sovellustasi. Toisin sanoen Firestore on reaaliaikainen tietokanta ilman reaaliaikaista asiakasta, joka naamioituu API:n avulla.

Täällä alamme nähdä ensimmäisiä merkkejä Firestoren oikeudesta. Saatan olla väärässä, mutta epäilen, että joku korkealla Googlen johdossa katsoi Firebasea oston jälkeen ja sanoi vain: "Ei, voi luoja, ei. Tätä ei voida hyväksyä. Ei vain minun johdollani."

Hän ilmestyi kammioistaan ​​ja julisti:

"Yksi iso JSON-dokumentti? Ei. Jaat tiedot erillisiksi asiakirjoiksi, joista kukin on enintään 1 megatavun kokoinen."

Näyttää siltä, ​​​​että tällainen rajoitus ei kestä ensimmäistä kohtaamista riittävän motivoituneen käyttäjäkunnan kanssa. Tiedät, että se on. Esimerkiksi töissä meillä on yli puolitoista tuhatta esitystä, ja tämä on täysin normaalia.

Tämän rajoituksen myötä sinun on hyväksyttävä se tosiasia, että yksi tietokannan "asiakirja" ei muistuta mitään objektia, jota käyttäjä saattaa kutsua asiakirjaksi.

"Matriisitaulukoita, jotka voivat sisältää rekursiivisesti muita elementtejä? Ei. Taulukot sisältävät vain kiinteäpituisia objekteja tai numeroita, kuten Jumala tarkoitti."

Joten jos toivoit GeoJSONin sijoittamista Firestore-palveluun, huomaat, että tämä ei ole mahdollista. Mikään ei-yksiulotteinen ei ole hyväksyttävää. Toivottavasti pidät Base64:stä ja/tai JSON:ista JSONissa.

"JSON-tuonti ja vienti HTTP:n, komentorivityökalujen tai hallintapaneelin kautta? Ei. Voit viedä ja tuoda tietoja vain Google Cloud Storageen. Näin sitä nyt sanotaan, luulen. Ja kun sanon "sinä", puhun vain niille, joilla on projektinomistajan valtuustiedot. Kaikki muut voivat mennä luomaan lippuja."

Kuten näet, FireBase-tietomalli on helppo kuvata. Se sisältää yhden valtavan JSON-dokumentin, joka yhdistää JSON-avaimet URL-polkuihin. Jos kirjoitat kanssa HTTP PUT в / FireBase on seuraava:

{
  "hello": "world"
}

То GET /hello palaa "world". Periaatteessa se toimii juuri niin kuin odotat. FireBase-objektien kokoelma /my-collection/:id vastaa JSON-sanakirjaa {"my-collection": {...}} juuressa, jonka sisältö on saatavilla /my-collection:

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

Tämä toimii hyvin, jos jokaisella lisäkkeellä on törmäysvapaa tunnus, johon järjestelmällä on vakioratkaisu.

Toisin sanoen tietokanta on 100 % JSON(*)-yhteensopiva ja toimii hyvin HTTP:n, kuten CouchDB:n, kanssa. Mutta periaatteessa käytät sitä reaaliaikaisen API:n kautta, joka tiivistää verkkoliitännät, valtuutukset ja tilaukset. Hallintapaneelissa on molemmat ominaisuudet, jotka mahdollistavat sekä reaaliaikaisen muokkauksen että JSON-tuonnin/-viennin. Jos teet saman koodissasi, hämmästyt kuinka paljon erikoistunutta koodia menee hukkaan, kun huomaat, että patch and diff JSON ratkaisee 90 % jatkuvan tilan käsittelyn rutiinitehtävistä.

Firestore-tietomalli on samanlainen kuin JSON, mutta eroaa joillakin kriittisillä tavoilla. Mainitsin jo taulukoiden puutteen taulukoiden sisällä. Alakokoelmien mallina on, että ne ovat ensiluokkaisia ​​käsitteitä, jotka ovat erillään ne sisältävästä JSON-dokumentista. Koska tätä varten ei ole valmiita sarjoituksia, tietojen hakemiseen ja kirjoittamiseen tarvitaan erikoistunut koodipolku. Omien kokoelmien käsittelemiseksi sinun on kirjoitettava omat skriptit ja työkalut. Hallintapaneelissa voit tehdä vain pieniä muutoksia kenttään kerrallaan, eikä siinä ole tuonti-/vientiominaisuuksia.

He ottivat reaaliaikaisen NoSQL-tietokannan ja muuttivat sen hitaaksi ei-SQL:ksi, jossa oli automaattinen liittyminen ja erillinen ei-JSON-sarake. Jotain GraftQL:n kaltaista.

Kuuma Java

Jos Firestoren piti olla luotettavampi ja skaalautuvampi, niin ironista on, että keskivertokehittäjä päätyy vähemmän luotettavaan ratkaisuun kuin FireBasen valitseminen alusta alkaen. Sellaiset ohjelmistot, joita Grumpy Database Administrator tarvitsee, vaativat ponnisteluja ja kykyjä, jotka ovat yksinkertaisesti epärealistisia sille markkinaraolle, jossa tuotteen oletetaan olevan hyvä. Tämä on samanlaista kuin HTML5 Canvas ei korvaa Flashia ollenkaan, jos kehitystyökaluja ja soitinta ei ole. Lisäksi Firestore on juuttunut tiedon puhtauden ja steriilin validoinnin haluun, joka ei yksinkertaisesti sovi keskivertoyrityskäyttäjän tapaan. rakastaa työskennellä: hänelle kaikki on valinnaista, koska loppuun asti kaikki on luonnosta.

FireBasen suurin haittapuoli on, että asiakas luotiin useita vuosia aikaansa edellä, ennen kuin useimmat verkkokehittäjät tiesivät muuttumattomuudesta. Tämän vuoksi FireBase olettaa, että muutat tietoja, eikä siksi hyödynnä käyttäjän tarjoamaa muuttumattomuutta. Lisäksi se ei käytä uudelleen käyttäjälle välittämiensä tilannekuvien tietoja, mikä tekee erotuksesta paljon vaikeampaa. Suurille asiakirjoille sen vaihtuva erotuspohjainen tapahtumamekanismi on yksinkertaisesti riittämätön. Kaverit, meillä on jo WeakMap JavaScriptissä. Se on mukava.

Jos annat tiedoille halutun muodon etkä tee puista liian suuria, tämä ongelma voidaan kiertää. Mutta olen utelias, olisiko FireBase paljon mielenkiintoisempi, jos kehittäjät julkaisisivat todella hyvän asiakassovellusliittymän, joka käyttäisi muuttumattomuutta yhdistettynä vakaviin käytännön neuvoihin tietokannan suunnittelussa. Sen sijaan he näyttivät yrittävän korjata sitä, mikä ei ollut rikki, ja se pahensi tilannetta.

En tiedä kaikkea Firestoren luomisen taustalla olevaa logiikkaa. Myös mustan laatikon sisällä nousevien motiiveiden pohdiskelu on osa hauskaa. Tämä kahden äärimmäisen samanlaisen mutta vertaansa vailla olevan tietokannan rinnakkain on melko harvinaista. Ihan kuin joku ajattelisi: "Firebase on vain toiminto, jota voimme emuloida Google Cloudissa", mutta ei ole vielä löytänyt käsitettä todellisten vaatimusten tunnistamisesta tai hyödyllisten ratkaisujen luomisesta, jotka täyttävät kaikki nämä vaatimukset. "Anna kehittäjien miettiä sitä. Tee käyttöliittymästä kaunis... Voitko lisätä tulta?"

Ymmärrän pari asiaa tietorakenteista. Näen ehdottomasti "kaikki yhdessä suuressa JSON-puussa" -konseptin yrityksenä poistaa tietokannasta kaikki suuren mittakaavan rakenteen tunne. On yksinkertaisesti mieletöntä odottaa, että ohjelmisto yksinkertaisesti selviytyisi minkä tahansa arveluttavan tietorakenteen fraktaalin kanssa. Minun ei tarvitse edes kuvitella kuinka huonosti asiat voisivat olla, olen tehnyt tiukat kooditarkastukset ja Näin asioita, joista te ihmiset ette koskaan uneksineet. Mutta tiedän myös miltä hyvät rakenteet näyttävät, miten niitä käytetään и miksi näin pitäisi tehdä. Voin kuvitella maailman, jossa Firestore vaikuttaisi loogiselta ja sen luoneet ihmiset ajattelisivat tehneensä hyvää työtä. Mutta me emme elä tässä maailmassa.

FireBasen kyselytuki on heikko minkään standardin mukaan ja käytännössä olematon. Se vaatii ehdottomasti parannusta tai ainakin korjausta. Mutta Firestore ei ole paljon parempi, koska se on rajoitettu samoihin yksiulotteisiin indekseihin, jotka löytyvät tavallisesta SQL:stä. Jos tarvitset kyselyitä, joita ihmiset suorittavat kaoottisilla tiedoilla, tarvitset koko tekstihaun, usean alueen suodattimet ja mukautetun käyttäjän määrittämän järjestyksen. Tarkemmin tarkasteltuna pelkän SQL:n toiminnot ovat itsessään liian rajoitettuja. Lisäksi ainoat SQL-kyselyt, joita ihmiset voivat suorittaa tuotannossa, ovat nopeat kyselyt. Tarvitset mukautetun indeksointiratkaisun harkituilla tietorakenteilla. Kaikessa muussa pitäisi olla ainakin inkrementaalinen map-reduce tai jotain vastaavaa.

Jos haet Google-dokumenteista tietoa tästä, sinut ohjataan toivottavasti kohti BigTablea ja BigQueryä. Kaikkiin näihin ratkaisuihin liittyy kuitenkin niin tiukkaa yritysmyyntislangia, että käännyt nopeasti takaisin ja alat etsiä jotain muuta.

Viimeinen asia, jonka haluat reaaliaikaisen tietokannan kanssa, on jotain johdon palkkaasteikolla olevien ihmisten valmistamaa ja heille tarkoitettua.

(*) Tämä on vitsi, sellaista ei ole olemassa 100 % JSON-yhteensopiva.

Mainonnan oikeuksista

Etsii vds virheenkorjausprojekteihin, palvelin kehitystä ja isännöintiä varten? Olet ehdottomasti asiakkaamme 🙂 Päivittäinen hinnoittelu eri kokoonpanoilla palvelimille, anti-DDoS ja Windows-lisenssit sisältyvät jo hintaan.

Lähde: will.com