ProHoster > Blogs > Administrācija > Šī datubāze deg...

Šī datubāze deg...

Šī datubāze deg...

Ļaujiet man pastāstīt tehnisku stāstu.

Pirms daudziem gadiem es izstrādāju lietojumprogrammu ar tajā iebÅ«vētām sadarbÄ«bas funkcijām. Tas bija lietotājam draudzÄ«gs eksperimentāls steks, kas izmantoja visas agrÄ«nās React un CouchDB iespējas. Tas sinhronizēja datus reāllaikā, izmantojot JSON OT. Tas tika izmantots uzņēmuma iekÅ”ienē, taču tā plaŔā pielietojamÄ«ba un potenciāls citās jomās bija skaidra.

Mēģinot pārdot Å”o tehnoloÄ£iju potenciālajiem klientiem, mēs saskārāmies ar negaidÄ«tu Ŕķērsli. Demonstrācijas videoklipā mÅ«su tehnoloÄ£ija izskatÄ«jās un darbojās lieliski, bez problēmām. Video bija precÄ«zi parādÄ«ts, kā tas darbojas, un nekas netika atdarināts. Mēs izdomājām un iekodējām reālistisku programmas izmantoÅ”anas scenāriju.

Šī datubāze deg...
PatiesÄ«bā Ŕī kļuva par problēmu. MÅ«su demonstrācija darbojās tieÅ”i tā, kā visi citi simulēja savas lietojumprogrammas. Konkrēti, informācija tika nekavējoties pārsÅ«tÄ«ta no A uz B, pat ja tie bija lieli multivides faili. Pēc pieteikÅ”anās katrs lietotājs redzēja jaunus ierakstus. Izmantojot lietojumprogrammu, dažādi lietotāji varēja skaidri sadarboties pie viena un tā paÅ”a projekta, pat ja interneta pieslēgums kaut kur ciematā tika pārtraukts. Tas ir netieÅ”i norādÄ«ts jebkurā produkta videoklipā, kas izgriezts programmā After Effects.

Lai gan visi zināja, kam paredzēta poga Atsvaidzināt, neviens Ä«sti nesaprata, ka tÄ«mekļa lietojumprogrammas, kuras viņi lÅ«dza mums izveidot, parasti ir pakļautas saviem ierobežojumiem. Un, ja tie vairs nebÅ«s vajadzÄ«gi, lietotāja pieredze bÅ«s pavisam cita. Viņi galvenokārt pamanÄ«ja, ka var ā€œtērzētā€, atstājot piezÄ«mes cilvēkiem, ar kuriem viņi runā, tāpēc viņi prātoja, ar ko tas atŔķiras no, piemēram, Slack. Fu!

Ikdienas sinhronizāciju dizains

Ja jums ir pieredze programmatÅ«ras izstrādē, noteikti ir nervus kutinoÅ”i atcerēties, ka lielākā daļa cilvēku nevar vienkārÅ”i apskatÄ«t interfeisa attēlu un saprast, ko tas darÄ«s, mijiedarbojoties ar to. Nemaz nerunājot par to, kas notiek paŔā programmā. ZināŔanas par to var Tas lielā mērā ir rezultāts tam, ka ir zināms, kas nevar notikt un kam nevajadzētu notikt. Tas prasa mentālais modelis ne tikai programmatÅ«ras darbÄ«bas, bet arÄ« to, kā tās atseviŔķās daļas tiek koordinētas un sazinās savā starpā.

Klasisks piemērs tam ir lietotājs, kurÅ” skatās uz a spinner.gif, prātoju, kad beidzot darbs tiks pabeigts. Izstrādātājs bÅ«tu sapratis, ka process, iespējams, ir iestrēdzis un ka gif nekad nepazudÄ«s no ekrāna. Å Ä« animācija simulē darba izpildi, bet nav saistÄ«ta ar tā stāvokli. Šādos gadÄ«jumos dažiem tehniÄ·iem patÄ«k izlaist acis, jo viņi ir pārsteigti par lietotāju apmulsumu. Tomēr ievērojiet, cik daudzi no viņiem norāda uz rotējoÅ”o pulksteni un saka, ka tas patiesÄ«bā ir nekustÄ«gs?

Šī datubāze deg...
Tā ir reāllaika vērtÄ«bas bÅ«tÄ«ba. MÅ«sdienās reāllaika datu bāzes joprojām tiek izmantotas ļoti maz, un daudzi cilvēki tās raugās ar aizdomām. Lielākā daļa Å”o datu bāzu lielā mērā ir balstÄ«tas uz NoSQL stilu, tāpēc tās parasti izmanto Mongo balstÄ«tus risinājumus, kurus vislabāk aizmirst. Tomēr man tas nozÄ«mē ērti strādāt ar CouchDB, kā arÄ« iemācÄ«ties veidot struktÅ«ras, kuras ar datiem var aizpildÄ«t ne tikai kāds birokrāts. Es domāju, ka es izmantoju savu laiku labāk.

Bet Ŕī ieraksta patiesā tēma ir tas, ko es izmantoju Å”odien. Ne jau pēc izvēles, bet vienaldzÄ«gi un akli pielietotas korporatÄ«vās politikas dēļ. Tāpēc es sniegÅ”u pilnÄ«gi godÄ«gu un objektÄ«vu divu cieÅ”i saistÄ«tu Google reāllaika datu bāzes produktu salÄ«dzinājumu.

Šī datubāze deg...
Abu nosaukumos ir vārds Uguns. Vienu lietu atceros ar prieku. Otra lieta man ir cita veida uguns. Es nesteidzos nosaukt viņu vārdus, jo, tiklÄ«dz to izdarÄ«Å”u, mēs saskarsimies ar pirmo lielo problēmu: nosaukumiem.

Pirmo sauc Firebase reāllaika datu bāzeun, otrkārt, Firebase Cloud Firestore. Abi tie ir produkti no Firebase komplekts Google. Viņu API tiek attiecÄ«gi sauktas firebase.database(ā€¦) Šø firebase.firestore(ā€¦).

Tas notika tāpēc, Reāllaika datu bāze - tas ir tikai oriÄ£ināls Firebase pirms to iegādājās Google 2014. gadā. Tad Google nolēma izveidot kā paralēlu produktu kopija Firebase, kuras pamatā ir lielo datu uzņēmums, un to nosauca par Firestore ar mākoni. Es ceru, ka jÅ«s vēl neesat apjukuÅ”i. Ja jÅ«s joprojām esat apmulsis, neuztraucieties, es pats pārrakstÄ«ju Å”o raksta daļu desmit reizes.

Jo jānorāda Firebase Firebase jautājumā un Firestore jautājumā par Firebase, vismaz lai jūs saprastu pirms dažiem gadiem pakalpojumā Stack Overflow.

Ja bÅ«tu balva par sliktāko programmatÅ«ras nosaukumu pieŔķirÅ”anas pieredzi, Å”is noteikti bÅ«tu viens no pretendentiem. Haminga attālums starp Å”iem nosaukumiem ir tik mazs, ka mulsina pat pieredzējuÅ”us inženierus, kuru pirksti raksta vienu vārdu, bet galva domā par citu. Tie ir labi iecerēti plāni, kas smagi izgāžas; viņi piepildÄ«ja pareÄ£ojumu, ka datubāze degs. Un es nemaz nejokoju. Persona, kas izdomāja Å”o nosaukÅ”anas shēmu, izraisÄ«ja asinis, sviedrus un asaras.

Šī datubāze deg...

Pirra uzvara

Varētu domāt, ka Firestore ir aizstāŔana Firebase, tās nākamās paaudzes pēctecis, taču tas bÅ«tu maldinoÅ”i. Firestore netiek garantēts kā piemērots Firebase aizstājējs. Izskatās, ka kāds no tā izgriezis visu interesanto, bet lielāko daļu pārējo dažādos veidos sajaucis.

Tomēr ātrs skatiens uz abiem produktiem var jÅ«s mulsināt: Ŕķiet, ka tie dara vienu un to paÅ”u, izmantojot bÅ«tÄ«bā tās paÅ”as API un pat tajā paŔā datu bāzes sesijā. AtŔķirÄ«bas ir smalkas, un tās atklāj tikai rÅ«pÄ«ga plaÅ”as dokumentācijas salÄ«dzinoÅ”a izpēte. Vai arÄ« mēģināt portēt kodu, kas lieliski darbojas platformā Firebase, lai tas darbotos ar Firestore. Pat tad jÅ«s uzzināsit, ka datu bāzes saskarne iedegas, tiklÄ«dz jÅ«s mēģināt vilkt un nomest ar peli reāllaikā. Es atkārtoju, es nejokoju.

Firebase klients ir pieklājÄ«gs tādā ziņā, ka tas buferē izmaiņas un automātiski mēģina atkārtoti veikt atjauninājumus, kas pieŔķir prioritāti pēdējai rakstÄ«Å”anas darbÄ«bai. Tomēr Firestore ierobežo 1 rakstÄ«Å”anas darbÄ«bu vienam dokumentam vienam lietotājam sekundē, un Å”o ierobežojumu piemēro serveris. Strādājot ar to, jums ir jāatrod veids, kā to apiet un ieviest atjaunināŔanas ātruma ierobežotāju, pat ja jÅ«s tikai mēģināt izveidot savu lietojumprogrammu. Tas nozÄ«mē, ka Firestore ir reāllaika datu bāze bez reāllaika klienta, kas maskējas kā tāds, kas izmanto API.

Å eit mēs sākam redzēt pirmās Firestore raison d'ĆŖtre pazÄ«mes. Iespējams, es kļūdos, bet man ir aizdomas, ka kāds Google vadÄ«bas pārstāvis pēc pirkuma paskatÄ«jās uz Firebase un vienkārÅ”i teica: ā€œNē, ak Dievs, nē. Tas ir nepieņemami. Tikai ne manā vadÄ«bā."

Šī datubāze deg...
ViņŔ iznāca no saviem kambariem un paziņoja:

ā€œViens liels JSON dokuments? Nē. JÅ«s sadalÄ«sit datus atseviŔķos dokumentos, no kuriem katrs bÅ«s ne lielāks par 1 megabaitu.

Å Ä·iet, ka Ŕāds ierobežojums nepārdzÄ«vos pirmo tikÅ”anos ar kādu pietiekami motivētu lietotāju bāzi. JÅ«s zināt, ka tā ir. Piemēram, darbā mums ir vairāk nekā pusotrs tÅ«kstotis prezentāciju, un tas ir pilnÄ«gi normāli.

Ar Å”o ierobežojumu jÅ«s bÅ«siet spiesti samierināties ar faktu, ka viens "dokuments" datubāzē nelÄ«dzinās nevienam objektam, ko lietotājs varētu nosaukt par dokumentu.

"Masīvu masīvi, kas var rekursīvi saturēt citus elementus? Nē. Masīvi saturēs tikai fiksēta garuma objektus vai skaitļus, kā Dievs bija iecerējis."

Tātad, ja jūs cerējāt ievietot GeoJSON savā Firestore, jūs atklāsiet, ka tas nav iespējams. Nekas, kas nav viendimensionāls, nav pieņemams. Ceru, ka jums patīk Base64 un/vai JSON JSON ietvaros.

ā€œJSON importÄ“Å”ana un eksportÄ“Å”ana, izmantojot HTTP, komandrindas rÄ«kus vai administratora paneli? Nē. JÅ«s varēsiet eksportēt un importēt datus tikai pakalpojumā Google Cloud Storage. Tā to tagad sauc, manuprāt. Un, kad es saku ā€œtuā€, es uzrunāju tikai tos, kuriem ir projekta Ä«paÅ”nieka akreditācijas dati. Visi pārējie var iet un izveidot biļetes."

Kā redzat, FireBase datu modeli ir viegli aprakstÄ«t. Tajā ir viens milzÄ«gs JSON dokuments, kas saista JSON atslēgas ar URL ceļiem. Ja tu raksti ar HTTP PUT Š² / FireBase ir Ŕāda:

{
  "hello": "world"
}

The GET /hello atgriezÄ«sies "world". BÅ«tÄ«bā tas darbojas tieÅ”i tā, kā jÅ«s gaidÄ«jāt. FireBase objektu kolekcija /my-collection/:id lÄ«dzvērtÄ«gs JSON vārdnÄ«cai {"my-collection": {...}} saknē, kuras saturs ir pieejams /my-collection:

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

Tas darbojas labi, ja katram ieliktnim ir bez sadursmes ID, kam sistēmai ir standarta risinājums.

Citiem vārdiem sakot, datu bāze ir 100% saderÄ«ga ar JSON(*) un lieliski darbojas ar HTTP, piemēram, CouchDB. Bet pamatā jÅ«s to izmantojat, izmantojot reāllaika API, kas apkopo tÄ«mekļa ligzdas, autorizāciju un abonementus. Administratora panelim ir abas iespējas, kas ļauj gan rediģēt reāllaikā, gan JSON importēt/eksportēt. Ja darÄ«sit to paÅ”u savā kodā, jÅ«s bÅ«siet pārsteigts, cik daudz specializētā koda tiks iztērēts, kad sapratÄ«sit, ka ielāpu un diferenciācijas JSON atrisina 90% no pastāvÄ«gā stāvokļa apstrādes ikdienas uzdevumiem.

Firestore datu modelis ir lÄ«dzÄ«gs JSON, taču atŔķiras dažos bÅ«tiskos veidos. Es jau minēju masÄ«vu trÅ«kumu masÄ«vos. ApakÅ”kolekciju modelis ir paredzēts, lai tie bÅ«tu pirmās klases jēdzieni, kas ir atseviŔķi no JSON dokumenta, kurā tie ir ietverti. Tā kā Å”im nolÅ«kam nav gatavas serializācijas, datu izgÅ«Å”anai un rakstÄ«Å”anai ir nepiecieÅ”ams specializēts koda ceļŔ. Lai apstrādātu savas kolekcijas, jums ir jāraksta savi skripti un rÄ«ki. AdministrÄ“Å”anas panelis ļauj veikt nelielas izmaiņas tikai vienā laukā vienlaikus, un tam nav importÄ“Å”anas/eksportÄ“Å”anas iespēju.

Viņi izmantoja reāllaika NoSQL datu bāzi un pārvērta to par lēnu ne-SQL ar automātisku pievienoÅ”anos un atseviŔķu kolonnu, kas nav JSON. Kaut kas lÄ«dzÄ«gs GraftQL.

Šī datubāze deg...

Karstā Java

Ja Firestore vajadzēja bÅ«t uzticamākai un mērogojamākai, tad ironija ir tāda, ka vidusmēra izstrādātājs galu galā atradÄ«s mazāk uzticamu risinājumu nekā FireBase izvēle. ProgrammatÅ«rai, kas nepiecieÅ”ama Grumpy datu bāzes administratoram, ir vajadzÄ«gas tādas pÅ«les un talanta lÄ«menis, kas ir vienkārÅ”i nereāls tai niÅ”ai, kurā produktam ir jābÅ«t labam. Tas ir lÄ«dzÄ«gi tam, kā HTML5 Canvas nemaz neaizstāj Flash, ja nav izstrādes rÄ«ku un atskaņotāja. Turklāt Firestore ir iegrimis vēlmē pēc datu tÄ«rÄ«bas un sterilas validācijas, kas vienkārÅ”i neatbilst parastam biznesa lietotājam. patÄ«k strādāt: viņam viss nav obligāti, jo lÄ«dz paŔām beigām viss ir melnraksts.

Galvenais FireBase trÅ«kums ir tas, ka klients tika izveidots vairākus gadus pirms sava laika, pirms lielākā daļa tÄ«mekļa izstrādātāju zināja par nemainÄ«gumu. Å Ä« iemesla dēļ FireBase pieņem, ka jÅ«s mainÄ«sit datus, un tāpēc neizmanto lietotāja nodroÅ”ināto nemainÄ«gumu. Turklāt tas atkārtoti neizmanto datus momentuzņēmumos, ko tas nodod lietotājam, kas padara diferenciāciju daudz grÅ«tāku. Lieliem dokumentiem tā mainÄ«go diferenciālo darÄ«jumu mehānisms ir vienkārÅ”i nepietiekams. PuiÅ”i, mums jau ir WeakMap JavaScript. Tas ir ērti.

Ja pieŔķirat datiem vēlamo formu un nepadara kokus pārāk apjomÄ«gus, tad Å”o problēmu var apiet. Bet man ir interese, vai FireBase bÅ«tu daudz interesantāks, ja izstrādātāji izdotu patieŔām labu klienta API, kas izmantotu nemainÄ«gumu apvienojumā ar nopietniem praktiskiem padomiem par datu bāzes dizainu. Tā vietā viņi, Ŕķiet, mēģināja salabot to, kas nebija salauzts, un tas pasliktināja situāciju.

Es nezinu visu Firestore izveides loÄ£iku. Spekulācijas par motÄ«viem, kas rodas melnās kastes iekÅ”pusē, arÄ« ir daļa no jautrÄ«bas. Šāda divu ārkārtÄ«gi lÄ«dzÄ«gu, bet nesalÄ«dzināmu datu bāzu pretnostatÄ«Å”ana notiek diezgan reti. Tas ir tā, it kā kāds bÅ«tu domājis: "Firebase ir tikai funkcija, kuru mēs varam lÄ«dzināties pakalpojumā Google Cloud", taču vēl nav atklājis jēdzienu, kā noteikt reālās pasaules prasÄ«bas vai radÄ«t noderÄ«gus risinājumus, kas atbilst visām Ŕīm prasÄ«bām. "Ä»aujiet izstrādātājiem par to padomāt. VienkārÅ”i padariet lietotāja interfeisu skaistu... Vai varat pievienot vairāk uguns?ā€

Es saprotu dažas lietas par datu struktÅ«rām. Es noteikti uztveru jēdzienu "viss vienā lielā JSON kokā" kā mēģinājumu no datu bāzes abstrahēt jebkādu liela mēroga struktÅ«ras sajÅ«tu. GaidÄ«t, ka programmatÅ«ra vienkārÅ”i tiks galā ar jebkuru apÅ”aubāmu datu struktÅ«ras fraktāli, ir vienkārÅ”i neprātÄ«gi. Man pat nav jāiedomājas, cik slikti lietas varētu bÅ«t, esmu veicis stingrus kodu auditus un Es redzēju lietas, par kurām jÅ«s, cilvēki, nekad neesat sapņojuÅ”i. Bet es arÄ« zinu, kā izskatās labas struktÅ«ras, kā tos lietot Šø kāpēc tas bÅ«tu jādara. Es varu iedomāties pasauli, kurā Firestore Ŕķiet loÄ£iska un cilvēki, kas to izveidoja, domātu, ka ir paveikuÅ”i labu darbu. Bet mēs nedzÄ«vojam Å”ajā pasaulē.

FireBase vaicājumu atbalsts pēc jebkura standarta ir vājÅ” un praktiski neeksistē. Tas noteikti ir jāuzlabo vai vismaz jāpārskata. Bet Firestore nav daudz labāks, jo tas ir ierobežots ar tiem paÅ”iem viendimensijas indeksiem, kas atrodami vienkārŔā SQL. Ja jums ir nepiecieÅ”ami vaicājumi, kurus cilvēki izpilda, izmantojot haotiskus datus, jums ir nepiecieÅ”ama pilna teksta meklÄ“Å”ana, vairāku diapazonu filtri un pielāgota lietotāja definēta secÄ«ba. RÅ«pÄ«gāk pārbaudot, vienkārŔā SQL funkcijas paÅ”as par sevi ir pārāk ierobežotas. Turklāt vienÄ«gie SQL vaicājumi, ko cilvēki var izpildÄ«t ražoÅ”anā, ir ātrie vaicājumi. Jums bÅ«s nepiecieÅ”ams pielāgots indeksÄ“Å”anas risinājums ar viedām datu struktÅ«rām. Visam pārējam vajadzētu bÅ«t vismaz pakāpeniskai kartes samazināŔanai vai kaut kam lÄ«dzÄ«gam.

Ja meklējat informāciju par Å”o informāciju pakalpojumā Google dokumenti, jÅ«s, cerams, tiksit novirzÄ«ts uz kaut ko lÄ«dzÄ«gu BigTable un BigQuery. Tomēr visus Å”os risinājumus pavada tik blÄ«vs korporatÄ«vās pārdoÅ”anas žargons, ka jÅ«s ātri atgriezÄ«sities un sāksit meklēt kaut ko citu.

Pēdējā lieta, ko vēlaties, izmantojot reāllaika datu bāzi, ir kaut kas, ko ir izstrādājuÅ”i cilvēki, kas atrodas vadÄ«bas atalgojuma skalās.

(*) Tas ir joks, tāda nav 100% saderīgs ar JSON.

Par reklāmas tiesībām

Meklēju VDS atkļūdoÅ”anas projektiem, serveris izstrādei un hostingam? JÅ«s noteikti esat mÅ«su klients šŸ™‚ Dienas cenas dažādu konfigurāciju serveriem, anti-DDoS un Windows licences jau ir iekļautas cenā.

Šī datubāze deg...

Avots: www.habr.com

Pievieno komentāru