Keling, texnik voqeani aytib beraman.
Ko'p yillar oldin, men unga o'rnatilgan hamkorlik xususiyatlariga ega ilovani ishlab chiqdim. Bu erta React va CouchDB imkoniyatlaridan foydalangan foydalanuvchilarga qulay eksperimental stek edi. JSON orqali real vaqtda ma'lumotlarni sinxronlashtirdi . U kompaniya ichida ishlatilgan, ammo uning keng qo'llanilishi va boshqa sohalarda salohiyati aniq edi.
Ushbu texnologiyani potentsial mijozlarga sotishga harakat qilar ekanmiz, biz kutilmagan to'siqga duch keldik. Demo videoda bizning texnologiyamiz ajoyib ko'rindi va ishladi, u erda hech qanday muammo yo'q. Videoda uning qanday ishlashi aniq ko'rsatilgan va hech narsaga taqlid qilmagan. Biz dasturdan foydalanish uchun real stsenariyni o'ylab topdik va kodladik.
Aslida, bu muammoga aylandi. Bizning demomiz xuddi boshqalar o'z ilovalarini simulyatsiya qilganidek ishladi. Xususan, axborot bir zumda A dan B ga uzatildi, hatto u katta media fayllar bo'lsa ham. Tizimga kirgandan so'ng, har bir foydalanuvchi yangi yozuvlarni ko'rdi. Ilovadan foydalanib, turli foydalanuvchilar qishloqning biron bir joyida Internet aloqasi uzilib qolgan bo'lsa ham, bir xil loyihalarda aniq birgalikda ishlashlari mumkin edi. Bu After Effects-da kesilgan har qanday mahsulot videosida bilvosita nazarda tutilgan.
Yangilash tugmasi nima uchun ekanligini hamma bilgan bo'lsa ham, bizdan yaratishni so'ragan veb-ilovalar odatda o'z cheklovlariga bo'ysunishini hech kim tushunmadi. Va agar ular endi kerak bo'lmasa, foydalanuvchi tajribasi butunlay boshqacha bo'ladi. Ular asosan suhbatdoshlari uchun eslatma qoldirish orqali "suhbat" qilishlari mumkinligini payqashdi, shuning uchun ular, masalan, Slack-dan qanday farq qilishiga hayron bo'lishdi. Voy!
Kundalik sinxronizatsiya dizayni
Agar sizda dasturiy ta'minotni ishlab chiqishda tajribangiz bo'lsa, ko'pchilik shunchaki interfeys rasmiga qarab, u bilan o'zaro aloqada bo'lganda nima qilishini tushunib yeta olmasligini esdan chiqarmaslik asabiylashadi. Dasturning o'zida nima sodir bo'lishini eslatib o'tmaslik kerak. Buni biling Jon sodir bo'lishi, asosan, nima bo'lmasligi va nima bo'lmasligi kerakligini bilish natijasidir. Bu talab qiladi nafaqat dasturiy ta'minot nima qiladi, balki uning alohida qismlari qanday muvofiqlashtirilganligi va bir-biri bilan aloqa qilishi.
Buning klassik misoli a ga tikilib turgan foydalanuvchidir spinner.gif, ish nihoyat qachon tugashiga hayron. Ishlab chiquvchi jarayonning tiqilib qolganini va gif hech qachon ekrandan yo'qolmasligini tushungan bo'lardi. Ushbu animatsiya ishning bajarilishini simulyatsiya qiladi, lekin uning holatiga bog'liq emas. Bunday hollarda, ba'zi texniklar foydalanuvchilarning chalkashliklari darajasidan hayratga tushib, ko'zlarini yumishni yaxshi ko'radilar. Biroq, ularning qanchasi aylanuvchi soatga ishora qilganiga e'tibor bering va u aslida harakatsiz ekanligini aytishadi?
Bu real vaqt qiymatining mohiyatidir. Hozirgi kunda real vaqtda ma'lumotlar bazalari hali ham juda kam qo'llaniladi va ko'pchilik ularga shubha bilan qarashadi. Ushbu ma'lumotlar bazalarining aksariyati NoSQL uslubiga to'g'ri keladi, shuning uchun ular odatda unutilgan Mongo-ga asoslangan echimlardan foydalanadilar. Biroq, men uchun bu CouchDB bilan qulay ishlashni, shuningdek, ba'zi bir byurokrat ma'lumotlar bilan to'ldirishi mumkin bo'lgan tuzilmalarni loyihalashni o'rganishni anglatadi. Vaqtimdan yaxshiroq foydalanayapman deb o'ylayman.
Lekin bu postning asl mavzusi men bugun foydalanadigan narsadir. O'z xohishiga ko'ra emas, balki befarq va ko'r-ko'rona qo'llaniladigan korporativ siyosat tufayli. Shunday qilib, men Google real vaqtda maʼlumotlar bazasining bir-biriga yaqin boʻlgan ikkita mahsulotini toʻliq adolatli va xolis taqqoslashni taqdim etaman.
Ikkalasining ham ismlarida olov so'zi bor. Bir narsani yaxshi eslayman. Men uchun ikkinchi narsa - boshqa turdagi olov. Men ularning ismlarini aytishga shoshilmayman, chunki aytsam, biz birinchi katta muammoga duch kelamiz: ismlar.
Birinchisi deyiladi Firebase real vaqtda ma'lumotlar bazasiva ikkinchi - Firebase Cloud Firestore. Ularning ikkalasi ham ishlab chiqarilgan mahsulotlardir Firebase to'plami Google. Ularning API'lari mos ravishda chaqiriladi firebase.database(…) и firebase.firestore(…).
Bu sodir bo'ldi, chunki Haqiqiy vaqtda ma'lumotlar bazasi - bu shunchaki asl nusxa Firebase 2014 yilda Google tomonidan sotib olinishidan oldin. Keyin Google parallel mahsulot sifatida yaratishga qaror qildi bir nusxa Firebase katta ma'lumotlar kompaniyasiga asoslangan va uni bulutli Firestore deb atagan. Umid qilamanki, siz hali ham adashmagansiz. Agar siz hali ham sarosimaga tushsangiz, xavotir olmang, men o'zim maqolaning ushbu qismini o'n marta qayta yozdim.
Chunki ko'rsatish kerak Firebase Firebase savolida va Firestore Firebase haqidagi savolda, hech bo'lmaganda bir necha yil oldin Stack Overflow-da tushunishingiz uchun.
Agar dasturiy ta'minotni nomlashning eng yomon tajribasi uchun mukofot bo'lsa, bu, albatta, da'vogarlardan biri bo'lar edi. Bu nomlar orasidagi Xemming masofasi shunchalik kichikki, hatto boshlari boshqasi haqida o'ylayotganda barmoqlari bir ism yozadigan tajribali muhandislarni ham chalkashtirib yuboradi. Bu yaxshi niyatli rejalar bo'lib, ular muvaffaqiyatsizlikka uchradi; ular ma'lumotlar bazasi yonib ketishi haqidagi bashoratni amalga oshirdilar. Men esa umuman hazillashmayman. Ushbu nomlash sxemasini o'ylab topgan odam qon, ter va ko'z yoshlarini keltirib chiqardi.
Pirik g'alaba
Firestore deb o'ylash mumkin almashtirish Firebase, uning keyingi avlod avlodi, ammo bu noto'g'ri bo'lar edi. Firestore Firebase uchun mos o'rinbosar bo'lishi kafolatlanmaydi. Kimdir undan qiziqarli narsalarni kesib tashlaganga o'xshaydi va qolganlarning ko'pini turli yo'llar bilan aralashtirib yubordi.
Biroq, ikkita mahsulotga tez qarash sizni chalkashtirib yuborishi mumkin: ular bir xil API-lar orqali va hatto bir xil ma'lumotlar bazasi sessiyasida ham xuddi shunday qiladi. Farqlar juda nozik va faqat keng qamrovli hujjatlarni sinchkovlik bilan qiyosiy o'rganish orqali aniqlanadi. Yoki siz Firestore bilan ishlashi uchun Firebase-da mukammal ishlaydigan kodni portlashga urinayotganingizda. Shunda ham siz real vaqtda sichqonchani sudrab olib tashlashga harakat qilganingizdan so'ng ma'lumotlar bazasi interfeysi yonib turishini bilib olasiz. Takror aytaman, hazillashmayman.
Firebase mijozi o'zgarishlarni buferlashi va oxirgi yozish operatsiyasiga ustunlik beradigan yangilanishlarni avtomatik ravishda qaytadan sinab ko'rish ma'nosida xushmuomaladir. Biroq, Firestore-da har bir foydalanuvchi uchun soniyada bir hujjat uchun 1 ta yozish operatsiyasi chegarasi mavjud va bu cheklov server tomonidan amalga oshiriladi. U bilan ishlashda, hatto ilovangizni yaratmoqchi bo'lsangiz ham, uni aylanib o'tish yo'lini topish va yangilanish tezligini cheklovchini qo'llash sizga bog'liq. Ya'ni, Firestore - bu real vaqt rejimidagi mijozi bo'lmagan real vaqtda ma'lumotlar bazasi bo'lib, u API-dan foydalangan holda maskarad qiladi.
Bu erda biz Firestore raison d'êtrening birinchi belgilarini ko'rishni boshlaymiz. Men noto‘g‘ri bo‘lishim mumkin, lekin Google boshqaruvidagi kimdir xariddan so‘ng Firebase’ga qarab, shunchaki: “Yo‘q, ey Xudoyim, yo‘q. Bu qabul qilinishi mumkin emas. Faqat mening rahbarligim ostida emas."
U o'z xonasidan paydo bo'lib, shunday dedi:
“Bitta katta JSON hujjati? Yo'q. Siz ma'lumotlarni alohida hujjatlarga bo'lasiz, ularning har biri 1 megabaytdan oshmaydi.
Ko'rinib turibdiki, bunday cheklov har qanday etarlicha motivatsiyalangan foydalanuvchi bazasi bilan birinchi uchrashuvdan omon qolmaydi. Buni bilasiz. Masalan, ish joyida bizda bir yarim mingdan ortiq taqdimot mavjud va bu mutlaqo normal holat.
Ushbu cheklov bilan siz ma'lumotlar bazasidagi bitta "hujjat" foydalanuvchi hujjat deb ataydigan ob'ektga o'xshamasligi haqiqatini qabul qilishga majbur bo'lasiz.
"Rekursiv ravishda boshqa elementlarni o'z ichiga olishi mumkin bo'lgan massivlar massivlari? Yo'q. Massivlar, Xudo niyat qilganidek, faqat qattiq uzunlikdagi ob'ektlar yoki raqamlarni o'z ichiga oladi."
Shunday qilib, agar siz GeoJSON-ni Firestore-ga joylashtirmoqchi bo'lsangiz, bu mumkin emasligini bilib olasiz. Bir o'lchovli bo'lmagan hech narsa qabul qilinmaydi. Umid qilamanki, sizga Base64 va/yoki JSON ichida JSON yoqadi.
“JSON HTTP, buyruq qatori vositalari yoki boshqaruv paneli orqali import va eksport? Yo'q. Siz faqat Google Cloud Storage xizmatiga maʼlumotlarni eksport va import qilishingiz mumkin boʻladi. Hozir shunday deyiladi, menimcha. Va men "siz" deganimda, men faqat Loyiha egasining hisob ma'lumotlariga ega bo'lganlarga murojaat qilaman. Qolganlarning hammasi borib chiptalar yaratishi mumkin”.
Ko'rib turganingizdek, FireBase ma'lumotlar modelini tasvirlash oson. Unda JSON kalitlarini URL yo'llari bilan bog'laydigan bitta katta JSON hujjati mavjud. Agar bilan yozsangiz HTTP PUT в / FireBase quyidagilardan iborat:
{
"hello": "world"
}
Ushbu GET /hello qaytadi "world". Asosan, u siz kutganingizdek ishlaydi. FireBase ob'ektlari to'plami /my-collection/:id JSON lug'atiga teng {"my-collection": {...}} tarkibi mavjud bo'lgan ildizda /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Agar har bir qo'shimchada tizim standart yechimiga ega bo'lgan to'qnashuvsiz identifikatorga ega bo'lsa, bu yaxshi ishlaydi.
Boshqacha qilib aytganda, ma'lumotlar bazasi 100% JSON(*) bilan mos keladi va CouchDB kabi HTTP bilan ajoyib ishlaydi. Lekin, asosan, siz uni veb-rozetkalar, avtorizatsiya va obunalarni abstraktlashtiradigan real vaqtda API orqali ishlatasiz. Administrator paneli real vaqtda tahrirlash va JSON import/eksport qilish imkonini beruvchi ikkala imkoniyatga ega. Agar siz kodingizda xuddi shunday qilsangiz, yamoq va farq JSON doimiy holatni boshqarish bo'yicha odatiy vazifalarning 90 foizini hal qilishini tushunganingizda, qancha ixtisoslashgan kod behuda ketishiga hayron qolasiz.
Firestore ma'lumotlar modeli JSONga o'xshaydi, lekin ba'zi muhim jihatlari bilan farq qiladi. Men massivlar ichida massivlarning etishmasligi haqida allaqachon aytib o'tdim. Kichik to'plamlar modeli ularni o'z ichiga olgan JSON hujjatidan alohida birinchi darajali tushunchalar bo'lishidir. Buning uchun tayyor ketma-ketlashtirish mavjud emasligi sababli, ma'lumotlarni olish va yozish uchun maxsus kod yo'li talab qilinadi. O'z kollektsiyalaringizni qayta ishlash uchun siz o'zingizning skriptlar va vositalaringizni yozishingiz kerak. Administrator paneli bir vaqtning o'zida faqat bitta maydonda kichik o'zgarishlar qilish imkonini beradi va import/eksport imkoniyatlariga ega emas.
Ular real vaqtda NoSQL ma'lumotlar bazasini oldilar va uni avtomatik qo'shilish va alohida JSON bo'lmagan ustun bilan sekin bo'lmagan SQLga aylantirdilar. GraftQL kabi narsa.
Issiq Java
Agar Firestore yanada ishonchli va kengaytiriladigan bo'lishi kerak bo'lsa, istehzo shundaki, oddiy ishlab chiquvchi FireBase-ni qutidan tanlashdan ko'ra kamroq ishonchli echimga ega bo'ladi. Grumpy ma'lumotlar bazasi ma'muriga kerak bo'lgan dasturiy ta'minot mahsulot yaxshi bo'lishi kerak bo'lgan joy uchun shunchaki haqiqiy bo'lmagan kuch va qobiliyat darajasini talab qiladi. Bu HTML5 Canvas, agar ishlab chiqish vositalari va pleer bo'lmasa, umuman Flash o'rnini bosmasligiga o'xshaydi. Bundan tashqari, Firestore ma'lumotlarning tozaligi va steril tekshirish istagida bo'lib, bu oddiy biznes foydalanuvchisi bilan mos kelmaydi. ishlashni yaxshi ko'radi: uning uchun hamma narsa ixtiyoriy, chunki oxirigacha hamma narsa qoralama.
FireBase-ning asosiy kamchiligi shundaki, mijoz o'z vaqtidan bir necha yil oldin yaratilgan, ko'pchilik veb-ishlab chiquvchilar o'zgarmasligi haqida bilishgan. Shu sababli, FireBase siz ma'lumotlarni o'zgartirasiz deb taxmin qiladi va shuning uchun foydalanuvchi tomonidan taqdim etilgan o'zgarmaslikdan foydalanmaydi. Bundan tashqari, u foydalanuvchiga uzatilgan suratlardagi ma'lumotlarni qayta ishlatmaydi, bu farqni ancha qiyinlashtiradi. Katta hujjatlar uchun uning o'zgaruvchan farqga asoslangan tranzaksiya mexanizmi shunchaki etarli emas. Bolalar, bizda allaqachon bor WeakMap JavaScript-da. Bu qulay.
Agar siz ma'lumotlarga kerakli shaklni bersangiz va daraxtlarni juda hajmli qilmasangiz, bu muammoni chetlab o'tish mumkin. Ammo, agar ishlab chiquvchilar o'zgarmaslikdan foydalanadigan va ma'lumotlar bazasi dizayni bo'yicha jiddiy amaliy maslahatlar bilan birlashtirilgan haqiqatdan ham yaxshi mijoz API-ni chiqarsalar, FireBase yanada qiziqarliroq bo'larmidi, deb qiziqaman. Buning o'rniga, ular buzilmagan narsalarni tuzatishga harakat qilishdi va bu uni yanada yomonlashtirdi.
Men Firestore yaratilishi ortidagi barcha mantiqni bilmayman. Qora quti ichida paydo bo'ladigan motivlar haqida taxmin qilish ham o'yin-kulgining bir qismidir. Ikkita juda o'xshash, ammo solishtirib bo'lmaydigan ma'lumotlar bazasining bunday qo'shilishi juda kam uchraydi. Bu kimdir o'ylagandek: "Firebase - bu biz Google Cloud-da taqlid qilishimiz mumkin bo'lgan funksiya", lekin haqiqiy dunyo talablarini aniqlash yoki ushbu talablarning barchasiga javob beradigan foydali echimlarni yaratish kontseptsiyasini hali kashf qilmagan. “Ishlab chiquvchilar bu haqda o'ylashsin. Shunchaki foydalanuvchi interfeysini chiroyli qiling... Yana olov qo‘sha olasizmi?”
Ma'lumotlar tuzilmalari haqida bir nechta narsani tushunaman. Men, albatta, "hamma narsa bitta katta JSON daraxtida" tushunchasini ma'lumotlar bazasidan keng ko'lamli tuzilmaning har qanday ma'nosini mavhumlashtirishga urinish sifatida ko'raman. Dasturiy ta'minotning har qanday shubhali ma'lumotlar tuzilmasi fraktalini oddiygina engishini kutish aqldan ozishdir. Ishlar qanchalik yomon bo'lishini tasavvur qilishim shart emas, men qattiq kod tekshiruvlarini o'tkazdim va Men sizlar orzu qilmagan narsalarni ko'rdim. Lekin men yaxshi tuzilmalar qanday ko'rinishini ham bilaman, и . Men Firestore mantiqiy ko'rinadigan va uni yaratgan odamlar yaxshi ish qilgan deb o'ylaydigan dunyoni tasavvur qila olaman. Ammo biz bu dunyoda yashamaymiz.
FireBase so'rovlarini qo'llab-quvvatlash har qanday standart bo'yicha yomon va amalda mavjud emas. Bu, albatta, takomillashtirish yoki hech bo'lmaganda qayta ko'rib chiqishga muhtoj. Ammo Firestore unchalik yaxshi emas, chunki u oddiy SQL-da topilgan bir o'lchovli indekslar bilan cheklangan. Agar sizga odamlar xaotik ma'lumotlarda ishlaydigan so'rovlar kerak bo'lsa, sizga to'liq matnli qidiruv, ko'p diapazonli filtrlar va foydalanuvchi tomonidan belgilangan buyurtma kerak. Yaqinroq tekshirilganda, oddiy SQL funktsiyalari o'z-o'zidan juda cheklangan. Bundan tashqari, odamlar ishlab chiqarishda ishlatishi mumkin bo'lgan yagona SQL so'rovlari tezkor so'rovlardir. Sizga o'ylangan ma'lumotlar tuzilmalari bilan maxsus indekslash yechimi kerak bo'ladi. Boshqa hamma narsa uchun, hech bo'lmaganda, xaritani kamaytirish yoki shunga o'xshash narsa bo'lishi kerak.
Agar siz bu haqda ma'lumot olish uchun Google Docs-dan qidirsangiz, sizni BigTable va BigQuery kabi yo'nalishga yo'naltirishlariga umid qilaman. Biroq, bu yechimlarning barchasi shu qadar zich korporativ savdo jargonlari bilan birga keladiki, siz tezda orqaga qaytib, boshqa narsalarni qidira boshlaysiz.
Haqiqiy vaqt rejimidagi ma'lumotlar bazasi bilan siz istagan oxirgi narsa - bu menejment ish haqi shkalasidagi odamlar tomonidan yaratilgan narsadir.
(*) Bu hazil, bunday narsa yo'q .
Reklama huquqlari to'g'risida
Ni axtarish nosozliklarni tuzatish loyihalari, ishlab chiqish va hosting uchun server? Siz, albatta, bizning mijozimizsiz 🙂 Har xil konfiguratsiyadagi serverlar uchun kunlik narxlar, anti-DDoS va Windows litsenziyalari allaqachon narxga kiritilgan.
Manba: www.habr.com