Það kviknar í þessum gagnagrunni...

Leyfðu mér að segja tæknilega sögu.

Fyrir mörgum árum síðan var ég að þróa forrit með samvinnueiginleikum innbyggðum í það. Þetta var notendavænn tilraunastafla sem nýtti sér alla möguleika snemma React og CouchDB. Það samstillti gögn í rauntíma í gegnum JSON OT. Það var notað innan fyrirtækisins en víðtækt notagildi þess og möguleikar á öðrum sviðum voru augljósir.

Þegar við reyndum að selja þessa tækni til hugsanlegra viðskiptavina lentum við í óvæntri hindrun. Í kynningarmyndbandinu leit tæknin okkar út og virkaði frábærlega, engin vandamál þar. Myndbandið sýndi nákvæmlega hvernig það virkar og hermdi ekki eftir neinu. Við komum með og kóðuðum raunhæfa atburðarás til að nota forritið.


Reyndar varð þetta vandamálið. Sýningin okkar virkaði nákvæmlega eins og allir aðrir líktu eftir forritunum sínum. Nánar tiltekið voru upplýsingar fluttar samstundis frá A til B, jafnvel þótt um stórar miðlunarskrár væri að ræða. Eftir að hafa skráð sig inn sá hver notandi nýjar færslur. Með því að nota forritið gátu mismunandi notendur unnið greinilega saman að sömu verkefnum, jafnvel þótt nettengingin væri rofin einhvers staðar í þorpinu. Þetta er óbeint gefið í skyn í hvaða vöruvídeói sem er klippt í After Effects.

Jafnvel þó að allir vissu til hvers Refresh hnappurinn var, skildi enginn í raun að vefforritin sem þeir báðu okkur að smíða væru yfirleitt háð eigin takmörkunum. Og að ef þeirra er ekki lengur þörf verður notendaupplifunin allt önnur. Þeir tóku aðallega eftir því að þeir gátu „spjallað“ með því að skilja eftir glósur fyrir fólk sem þeir voru að tala við, svo þeir veltu fyrir sér hvernig þetta væri frábrugðið til dæmis Slack. Púff!

Hönnun daglegra samstillinga

Ef þú hefur reynslu af hugbúnaðarþróun hlýtur það að vera taugatrekkjandi að muna að flestir geta ekki bara horft á mynd af viðmóti og skilið hvað það mun gera í samskiptum við það. Svo ekki sé minnst á það sem gerist inni í forritinu sjálfu. Þekki það getur gerast er að miklu leyti afleiðing af því að vita hvað má ekki gerast og hvað má ekki gerast. Þetta krefst andlegt fyrirmynd ekki aðeins hvað hugbúnaðurinn gerir, heldur einnig hvernig einstakir hlutar hans eru samræmdir og hafa samskipti sín á milli.

Klassískt dæmi um þetta er notandi sem starir á a spinner.gif, velti því fyrir sér hvenær verkinu verði loksins lokið. Framkvæmdaraðilinn hefði áttað sig á því að ferlið væri líklega fast og að gifið myndi aldrei hverfa af skjánum. Þetta hreyfimynd líkir eftir framkvæmd verks en tengist ekki ástandi þess. Í slíkum tilfellum finnst sumum tæknimönnum gaman að reka augun, undrandi á umfangi ruglings notenda. Taktu samt eftir því hversu margir þeirra benda á klukkuna sem snýst og segja að hún sé í raun kyrrstæð?

Þetta er kjarninn í rauntímagildi. Þessa dagana eru rauntímagagnagrunnar enn mjög lítið notaðir og margir líta þá með tortryggni. Flestir þessara gagnagrunna hallast mjög að NoSQL stílnum, þess vegna nota þeir venjulega lausnir sem eru byggðar á Mongo, sem helst gleymast. Hins vegar þýðir þetta fyrir mér að vera ánægður með að vinna með CouchDB, auk þess að læra að hanna mannvirki sem meira en bara einhver embættismaður getur fyllt með gögnum. Ég held að ég sé að nýta tímann betur.

En raunverulegt efni þessarar færslu er það sem ég er að nota í dag. Ekki að eigin vali, heldur vegna afskiptaleysis og í blindni beittri stefnu fyrirtækja. Svo ég mun veita fullkomlega sanngjarnan og óhlutdrægan samanburð á tveimur nátengdum Google rauntíma gagnagrunnsvörum.

Báðir hafa orðið Eldur í nöfnum sínum. Eitt man ég með hlýhug. Annað fyrir mig er önnur tegund af eldi. Ég er ekkert að flýta mér að segja nöfn þeirra, því þegar ég geri það, munum við lenda í fyrsta stóra vandamálinu: nöfnum.

Sá fyrsti heitir Firebase rauntímagagnagrunnur, og annað - Firebase Cloud Firestore. Báðar eru þær vörur frá Firebase föruneyti Google. API þeirra eru kölluð í sömu röð firebase.database(…) и firebase.firestore(…).

Þetta gerðist vegna þess Rauntíma gagnagrunnur - þetta er bara upprunalega Firebase áður en Google keypti það árið 2014. Þá ákvað Google að búa til sem samhliða vöru afrita Firebase byggt á stórgagnafyrirtæki og kallaði það Firestore með skýi. Ég vona að þú sért ekki ruglaður ennþá. Ef þú ert enn ruglaður, ekki hafa áhyggjur, ég sjálfur endurskrifaði þennan hluta greinarinnar tíu sinnum.

Vegna þess að þú þarft að gefa til kynna Firebase í Firebase spurningunni, og Firestore í spurningu um Firebase, að minnsta kosti til að gera þér grein fyrir því fyrir nokkrum árum síðan á Stack Overflow.

Ef það væru verðlaun fyrir verstu nafngiftarupplifunina væri þetta örugglega einn af keppendum. Hamming fjarlægðin á milli þessara nafna er svo lítil að hún ruglar jafnvel reynda verkfræðinga þar sem fingurnir skrifa eitt nafn á meðan höfuð þeirra er að hugsa um annað. Þetta eru vel meint áform sem mistakast hrapallega; þeir uppfylltu spádóminn um að gagnagrunnurinn myndi loga. Og ég er alls ekki að grínast. Sá sem kom með þetta nafnakerfi olli blóði, svita og tárum.

Pyrrhos sigur

Maður myndi halda að Firestore sé það skipti Firebase, afkomandi næstu kynslóðar, en það væri villandi. Ekki er tryggt að Firestore sé hentugur staðgengill fyrir Firebase. Það lítur út fyrir að einhver hafi klippt út allt áhugavert úr því og ruglað flestum öðrum á ýmsan hátt.

Hins vegar getur fljótleg sýn á vörurnar tvær ruglað þig: þær virðast gera það sama, í grundvallaratriðum í gegnum sömu API og jafnvel í sömu gagnagrunnslotunni. Munurinn er lúmskur og kemur aðeins í ljós með nákvæmri samanburðarrannsókn á víðtækum skjölum. Eða þegar þú ert að reyna að flytja kóða sem virkar fullkomlega á Firebase þannig að hann virki með Firestore. Jafnvel þá kemstu að því að gagnagrunnsviðmótið kviknar um leið og þú reynir að draga og sleppa með músinni í rauntíma. Ég endurtek, ég er ekki að grínast.

Firebase viðskiptavinurinn er kurteis í þeim skilningi að hann bætir breytingar og reynir sjálfkrafa aftur uppfærslur sem gefa síðustu skrifaðgerðinni forgang. Hins vegar hefur Firestore takmörk fyrir 1 skrifaðgerð á hvert skjal á hverja notanda á sekúndu og þessum takmörkunum er framfylgt af þjóninum. Þegar þú vinnur með það er það undir þér komið að finna leið í kringum það og innleiða uppfærsluhraðatakmörkun, jafnvel þegar þú ert bara að reyna að byggja upp forritið þitt. Það er að segja, Firestore er rauntímagagnagrunnur án rauntímabiðlara, sem líkist eins og einn sem notar API.

Hér byrjum við að sjá fyrstu merki um tilveru Firestore. Það kann að vera að ég hafi rangt fyrir mér, en mig grunar að einhver hátt uppi í stjórnendum Google hafi horft á Firebase eftir kaupin og sagt einfaldlega: „Nei, guð minn góður, nei. Þetta er óviðunandi. Bara ekki undir minni stjórn."

Hann birtist úr herbergjum sínum og sagði:

„Eitt stórt JSON skjal? Nei. Þú munt skipta gögnunum í aðskilin skjöl, sem hvert um sig verður ekki meira en 1 megabæti að stærð.“

Svo virðist sem slík takmörkun muni ekki lifa af fyrstu kynni við neinn nægilega áhugasaman notendahóp. Þú veist að það er. Í vinnunni erum við til dæmis með meira en eitt og hálft þúsund kynningar og þetta er fullkomlega eðlilegt.

Með þessari takmörkun neyðist þú til að samþykkja þá staðreynd að eitt "skjal" í gagnagrunninum mun ekki líkjast neinum hlutum sem notandi gæti kallað skjal.

„Fylki af fylkjum sem geta endurkvæmt innihaldið aðra þætti? Nei. Fylki munu aðeins innihalda hluti eða tölur með fastri lengd, eins og Guð ætlaði."

Svo ef þú varst að vonast til að setja GeoJSON inn í Firestore þinn, muntu komast að því að þetta er ekki mögulegt. Ekkert óeinvídd er ásættanlegt. Ég vona að þér líkar við Base64 og/eða JSON innan JSON.

"JSON innflutningur og útflutningur með HTTP, skipanalínuverkfærum eða stjórnborði? Nei. Þú munt aðeins geta flutt út og flutt inn gögn í Google Cloud Storage. Það heitir nú það held ég. Og þegar ég segi „þú“ er ég aðeins að ávarpa þá sem hafa heimildir fyrir verkeiganda. Allir aðrir geta farið og búið til miða.“

Eins og þú sérð er FireBase gagnalíkanið auðvelt að lýsa. Það inniheldur eitt risastórt JSON skjal sem tengir JSON lykla við vefslóðir. Ef þú skrifar með HTTP PUT в / FireBase er eftirfarandi:

{
  "hello": "world"
}

Þess vegna GET /hello kem aftur "world". Í grundvallaratriðum virkar það nákvæmlega eins og þú vilt búast við. Safn af FireBase hlutum /my-collection/:id jafngildir JSON orðabók {"my-collection": {...}} í rótinni, en innihald þeirra er fáanlegt í /my-collection:

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

Þetta virkar frábærlega ef hvert innlegg er með árekstralaust auðkenni sem kerfið er með staðlaða lausn fyrir.

Með öðrum orðum, gagnagrunnurinn er 100% JSON(*) samhæfður og virkar frábærlega með HTTP, eins og CouchDB. En í grundvallaratriðum notarðu það í gegnum rauntíma API sem tekur út veftengi, heimild og áskrift. Stjórnborðið hefur bæði möguleika, sem gerir bæði rauntíma klippingu og JSON innflutning/útflutning kleift. Ef þú gerir það sama í kóðanum þínum verðurðu hissa á hversu miklum sérhæfðum kóða mun fara til spillis þegar þú áttar þig á því að patch and diff JSON leysir 90% af venjubundnum verkefnum við að meðhöndla viðvarandi ástand.

Firestore gagnalíkanið er svipað og JSON, en er frábrugðið á mikilvægan hátt. Ég minntist þegar á skort á fylki innan fylki. Fyrirmynd undirsafna er að þau séu fyrsta flokks hugtök, aðskilin frá JSON skjalinu sem inniheldur þau. Þar sem engin tilbúin raðgreining er til fyrir þetta, þarf sérhæfða kóðaslóð til að sækja og skrifa gögn. Til að vinna úr eigin söfnum þarftu að skrifa eigin forskriftir og verkfæri. Stjórnborðið gerir þér aðeins kleift að gera litlar breytingar á einum reit í einu og hefur ekki inn-/útflutningsmöguleika.

Þeir tóku rauntíma NoSQL gagnagrunn og breyttu honum í hægan non-SQL með sjálfvirkri tengingu og aðskildum dálki sem ekki er JSON. Eitthvað eins og GraftQL.

Heitt Java

Ef Firestore átti að vera áreiðanlegra og skalanlegra, þá er kaldhæðnin sú að meðalframleiðandinn mun enda með óáreiðanlegri lausn en að velja FireBase úr kassanum. Sú tegund hugbúnaðar sem Grumpy gagnagrunnsstjórinn þarfnast krefst átaks og hæfileika sem er einfaldlega óraunhæft fyrir þann sess sem varan á að vera góð í. Þetta er svipað og HTML5 Canvas kemur alls ekki í staðinn fyrir Flash ef það eru engin þróunarverkfæri og spilari. Þar að auki er Firestore bundið í þrá eftir hreinleika gagna og dauðhreinsaða sannprófun sem er einfaldlega ekki í takt við það hvernig almennur viðskiptanotandi elskar að vinna: fyrir honum er allt valkvætt, því allt til loka er allt uppkast.

Helsti ókosturinn við FireBase er að viðskiptavinurinn var búinn til nokkrum árum á undan sinni samtíð, áður en flestir vefhönnuðir vissu um óbreytanleika. Vegna þessa gerir FireBase ráð fyrir því að þú breytir gögnunum og nýtir sér því ekki óbreytanleika sem notandi veitir. Að auki endurnýtir það ekki gögnin í skyndimyndunum sem það sendir til notandans, sem gerir mismuninn mun erfiðari. Fyrir stór skjöl er breytilegt diff-undirstaða viðskiptakerfi þess einfaldlega ófullnægjandi. Krakkar, við höfum nú þegar WeakMap í JavaScript. Það er þægilegt.

Ef þú gefur gögnunum viðeigandi lögun og gerir trén ekki of umfangsmikil, þá er hægt að sniðganga þetta vandamál. En ég er forvitinn hvort FireBase væri miklu áhugaverðara ef þróunaraðilarnir gáfu út mjög gott forritaskil viðskiptavinar sem notaði óbreytanleika ásamt alvarlegum hagnýtum ráðleggingum um gagnagrunnshönnun. Þess í stað virtust þeir reyna að laga það sem var ekki bilað og það gerði það verra.

Ég veit ekki alla rökfræðina á bak við stofnun Firestore. Vangaveltur um hvatirnar sem koma upp í svarta kassanum eru líka hluti af skemmtuninni. Þessi samsetning tveggja ákaflega svipaðra en ósambærilegra gagnagrunna er frekar sjaldgæf. Það er eins og einhver hafi hugsað: „Firebase er bara aðgerð sem við getum líkt eftir í Google Cloud“, en hefur ekki enn uppgötvað hugmyndina um að bera kennsl á raunverulegar kröfur eða búa til gagnlegar lausnir sem uppfylla allar þessar kröfur. „Leyfðu hönnuðunum að hugsa um það. Gerðu bara notendaviðmótið fallegt... Geturðu bætt við meiri eldi?“

Ég skil nokkra hluti um uppbyggingu gagna. Ég lít svo sannarlega á hugtakið „allt í einu stóru JSON-tré“ sem tilraun til að draga úr gagnagrunninum hvers kyns tilfinningu fyrir stórfelldri uppbyggingu. Það er einfaldlega geðveikt að búast við því að hugbúnaður ráði við hvers kyns vafasaman gagnauppbyggingarbrot. Ég þarf ekki einu sinni að ímynda mér hversu slæmt hlutirnir gætu verið, ég hef gert strangar kóðaúttektir og Ég sá hluti sem ykkur hafi aldrei dreymt um. En ég veit líka hvernig góð mannvirki líta út, hvernig á að nota þær и af hverju ætti þetta að vera gert. Ég get ímyndað mér heim þar sem Firestore virðist rökrétt og fólkið sem skapaði það myndi halda að þeir hafi staðið sig vel. En við lifum ekki í þessum heimi.

Fyrirspurnarstuðningur FireBase er lélegur miðað við hvaða staðla sem er og er nánast enginn. Það þarf örugglega úrbætur eða að minnsta kosti endurskoðun. En Firestore er ekki mikið betra vegna þess að það er takmarkað við sömu einvíddar vísitölur sem finnast í venjulegum SQL. Ef þú þarft fyrirspurnir sem fólk keyrir á óskipulegum gögnum þarftu fulltextaleit, fjölsviðssíur og sérsniðna notendaskilgreinda röðun. Við nánari skoðun eru virkni venjulegs SQL of takmörkuð ein og sér. Að auki eru einu SQL fyrirspurnirnar sem fólk getur keyrt í framleiðslu hraðar fyrirspurnir. Þú þarft sérsniðna flokkunarlausn með snjöllu gagnaskipulagi. Fyrir allt annað ætti að minnsta kosti að vera stigvaxandi map-reduce eða eitthvað álíka.

Ef þú leitar í Google Docs að upplýsingum um þetta, verður þér vonandi vísað í átt að einhverju eins og BigTable og BigQuery. Hins vegar fylgja allar þessar lausnir svo mikið þétt fyrirtækjasölumál að þú munt fljótt snúa til baka og fara að leita að einhverju öðru.

Það síðasta sem þú vilt með rauntíma gagnagrunni er eitthvað gert af og fyrir fólk á launakvörðum stjórnenda.

(*) Þetta er grín, það er ekkert sem heitir 100% JSON samhæft.

Um réttindi auglýsinga

Leita að VDS fyrir villuleitarverkefni, miðlara fyrir þróun og hýsingu? Þú ert svo sannarlega viðskiptavinur okkar 🙂 Dagleg verðlagning fyrir netþjóna með ýmsum stillingum, andstæðingur-DDoS og Windows leyfi eru nú þegar innifalin í verðinu.

Heimild: www.habr.com