ဤဒေတာဘေ့စ်မီးလောင်နေသည်...

နည်းပညာဆိုင်ရာ ဇာတ်လမ်းတစ်ပုဒ် ပြောပြပါရစေ။

လွန်ခဲ့သောနှစ်များစွာက၊ ကျွန်ုပ်သည် ၎င်းတွင်တည်ဆောက်ထားသော ပူးပေါင်းလုပ်ဆောင်မှုအင်္ဂါရပ်များဖြင့် အက်ပ်တစ်ခုကို တီထွင်နေပါသည်။ ၎င်းသည် အစောပိုင်း React နှင့် CouchDB ၏ အပြည့်အဝ အလားအလာကို အခွင့်ကောင်းယူ၍ အသုံးပြုရလွယ်ကူသော စမ်းသပ်မှုအစုတစ်ခုဖြစ်သည်။ ၎င်းသည် JSON မှတစ်ဆင့် ဒေတာများကို အချိန်နှင့်တပြေးညီ ထပ်တူပြုပါသည်။ OT. ၎င်းကို ကုမ္ပဏီအတွင်း၌ အသုံးပြုခဲ့သော်လည်း အခြားနယ်ပယ်များတွင် ၎င်း၏ကျယ်ပြန့်စွာ အသုံးချနိုင်မှုနှင့် အလားအလာမှာ ရှင်းပါသည်။

ဤနည်းပညာကို အလားအလာရှိသော ဖောက်သည်များထံ ရောင်းချရန် ကြိုးစားစဉ်တွင် ကျွန်ုပ်တို့သည် မမျှော်လင့်ထားသော အတားအဆီးတစ်ခုနှင့် ကြုံတွေ့ခဲ့ရသည်။ သရုပ်ပြဗီဒီယိုတွင်၊ ကျွန်ုပ်တို့၏နည်းပညာသည် ကောင်းမွန်စွာလုပ်ဆောင်နိုင်ပြီး ပြဿနာမရှိပါ။ ဗီဒီယိုသည် ၎င်းအလုပ်လုပ်ပုံကို အတိအကျပြသခဲ့ပြီး မည်သည့်အရာကိုမျှ တုပခြင်းမရှိပေ။ ကျွန်ုပ်တို့သည် ပရိုဂရမ်ကို အသုံးပြုရန်အတွက် လက်တွေ့ကျသော မြင်ကွင်းတစ်ခုကို ဖန်တီးပြီး ကုဒ်လုပ်ထားသည်။


တကယ်တော့ ဒါက ပြဿနာဖြစ်လာတယ်။ ကျွန်ုပ်တို့၏ ဒီမိုသည် အခြားသူများ၏ အပလီကေးရှင်းများကို အတုယူသည့်ပုံစံအတိုင်း လုပ်ဆောင်ခဲ့သည်။ အတိအကျအားဖြင့်၊ ၎င်းသည် ကြီးမားသော မီဒီယာဖိုင်များဖြစ်လျှင်ပင် အချက်အလက် A မှ B သို့ ချက်ခြင်း လွှဲပြောင်းခဲ့သည်။ လော့ဂ်အင်ဝင်ပြီးနောက်၊ အသုံးပြုသူတိုင်းသည် အသစ်ထည့်သွင်းမှုများကို တွေ့ခဲ့ကြသည်။ အပလီကေးရှင်းကို အသုံးပြု၍ ကျေးရွာရှိ အင်တာနက်ချိတ်ဆက်မှု ပြတ်တောက်သွားသည့်တိုင် မတူကွဲပြားသော သုံးစွဲသူများသည် တူညီသော ပရောဂျက်များတွင် ရှင်းရှင်းလင်းလင်း လက်တွဲလုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ ၎င်းသည် After Effects ရှိ မည်သည့်ထုတ်ကုန်ဗီဒီယိုတွင်မဆို သွယ်ဝိုက်သောအဓိပ္ပာယ်သက်ရောက်သည်။

Refresh ခလုတ်ကို လူတိုင်းသိကြသော်လည်း၊ ၎င်းတို့တည်ဆောက်ရန် တောင်းဆိုထားသော ဝဘ်အက်ပလီကေးရှင်းများသည် များသောအားဖြင့် ၎င်းတို့၏ ကန့်သတ်ချက်များနှင့် သက်ဆိုင်ကြောင်း မည်သူမျှ နားမလည်ကြပေ။ ၎င်းတို့ကို မလိုအပ်တော့ပါက အသုံးပြုသူအတွေ့အကြုံသည် လုံးဝကွဲပြားသွားမည်ဖြစ်သည်။ သူတို့စကားပြောနေသူများအတွက် မှတ်စုများချန်ထားခြင်းဖြင့် ၎င်းတို့သည် “ချတ်” လုပ်နိုင်သည်ကို အများစုသတိပြုမိသောကြောင့်၊ ဥပမာ၊ Slack နှင့် မည်သို့ကွာခြားသည်ကို သိချင်ကြသည်။ ဝူး!

နေ့စဉ် ထပ်တူပြုခြင်း ဒီဇိုင်း

အကယ်၍ သင့်တွင် software development တွင် အတွေ့အကြုံတစ်ခုခုရှိပါက၊ လူအများစုသည် အင်တာဖေ့စ်ပုံတစ်ပုံကို ကြည့်ရုံမျှမက ၎င်းနှင့် ထိတွေ့ဆက်ဆံသည့်အခါတွင် ၎င်းလုပ်ဆောင်ရမည့်အရာများကို နားလည်နိုင်သည်ကိုလည်း သတိရရန်မှာ စိတ်ရှုပ်စရာဖြစ်ရပါမည်။ ပရိုဂရမ်အတွင်း ဘာတွေဖြစ်မလဲဆိုတာ မပြောတတ်ပါဘူး။ အဲဒါကို ဗဟုသုတ နိုင် ဖြစ်ပျက်ခြင်း သည် ဖြစ်ပျက်ခြင်း နှင့် မဖြစ်သင့်သောအရာကို သိခြင်း၏ ရလဒ်ဖြစ်သည်။ လိုအပ်သည်။ စိတ်ပိုင်းဆိုင်ရာမော်ဒယ် ဆော့ဖ်ဝဲလ်က ဘာတွေလုပ်ရုံတင်မကဘဲ သူ့ရဲ့ အစိတ်အပိုင်းတစ်ခုချင်းကို ညှိနှိုင်းပြီး တစ်ခုနဲ့တစ်ခု ဆက်သွယ်ပုံလည်း ပါပါတယ်။

ဤအရာ၏ ဂန္တဝင်ဥပမာတစ်ခုသည် သုံးစွဲသူတစ်ဦးအား စိုက်ကြည့်နေသည်။ spinner.gifအလုပ်က ဘယ်တော့ ပြီးမလဲလို့ တွေးနေတယ်။ လုပ်ငန်းစဉ်သည် ပိတ်မိနေနိုင်ပြီး gif သည် ဖန်သားပြင်မှ ဘယ်တော့မှ ပျောက်ကွယ်သွားမည်မဟုတ်ကြောင်း developer မှ သဘောပေါက်မည်ဖြစ်သည်။ ဤကာတွန်းသည် အလုပ်တစ်ခု၏လုပ်ဆောင်မှုကို တုပထားသော်လည်း ၎င်း၏အခြေအနေနှင့် မသက်ဆိုင်ပါ။ ထိုသို့သော အခြေအနေမျိုးတွင်၊ အချို့သော နည်းပညာရှင်များသည် သုံးစွဲသူ၏ စိတ်ရှုပ်ထွေးမှုအတိုင်းအတာကို အံ့အားသင့်စေကာ ၎င်းတို့၏မျက်လုံးများကို လှိမ့်ကြည့်လိုကြသည်။ သို့သော်၊ လှည့်နေသောနာရီကို မည်မျှညွှန်ပြသည်ကို သတိပြုမိပြီး ၎င်းသည် အမှန်တကယ်ပင် ငုတ်လျှိုးနေပြီဖြစ်ကြောင်း ပြောပါ။

ဤသည်မှာ အချိန်နှင့်တပြေးညီတန်ဖိုး၏ အနှစ်သာရဖြစ်သည်။ ယနေ့ခေတ်တွင်၊ အချိန်နှင့်တစ်ပြေးညီ ဒေတာဘေ့စ်များကို အလွန်အသုံးနည်းနေသေးပြီး လူအများက ၎င်းတို့အား သံသယဖြင့် ကြည့်ရှုကြသည်။ ဤဒေတာဘေ့စ်အများစုသည် NoSQL စတိုင်ဆီသို့ ကြီးကြီးမားမား မှီခိုအားထားသောကြောင့် ၎င်းတို့သည် အများအားဖြင့် မေ့ပျောက်နိုင်သော Mongo-based ဖြေရှင်းချက်များကို အသုံးပြုကြသည်။ သို့သော်လည်း၊ ကျွန်ုပ်အတွက်၊ ၎င်းသည် CouchDB နှင့် အဆင်ပြေစွာ လုပ်ဆောင်နိုင်သည့်အပြင် ဗျူရိုကရက်အချို့က အချက်အလက်များဖြင့် ဖြည့်စွမ်းနိုင်သော ဗျူရိုကရက်များထက် ပိုသော ဖွဲ့စည်းပုံများကို ဒီဇိုင်းဆွဲရန် သင်ယူခြင်းတို့ကို ဆိုလိုသည်။ ငါ့ရဲ့အချိန်တွေကို ပိုကောင်းမယ်ထင်တယ်။

ဒါပေမယ့် ဒီပို့စ်ရဲ့ တကယ့်အကြောင်းအရာကတော့ ဒီနေ့ ကျွန်တော်သုံးနေတဲ့ အကြောင်းအရာပါ။ ရွေးချယ်မှုဖြင့်မဟုတ်ဘဲ လျစ်လျူရှုပြီး မျက်စိစုံမှိတ် ကော်ပိုရိတ်မူဝါဒများကို ကျင့်သုံးခြင်းကြောင့်ဖြစ်သည်။ ထို့ကြောင့် ကျွန်ုပ်သည် ဆက်စပ်နေသည့် Google real-time database ထုတ်ကုန်နှစ်ခု၏ လုံးဝမျှတပြီး ဘက်မလိုက်သော နှိုင်းယှဉ်မှုကို ပေးပါမည်။

နှစ်ခုစလုံးတွင် Fire ဟူသော စကားလုံးရှိသည်။ မြတ်နိုးစွာ သတိရမိတာလေးတစ်ခု။ ငါ့အတွက် ဒုတိယအချက်က မီးအမျိုးအစားမတူဘူး။ သူတို့နာမည်တွေကို ပြောဖို့ အလျင်စလိုမဖြစ်ပါဘူး၊ ဘာဖြစ်လို့လဲဆိုတော့ ကျွန်တော် တစ်ခါတည်း ပထမဆုံး ပြဿနာကြီးတစ်ခုဖြစ်တဲ့ နာမည်တွေကို ရောက်သွားမယ်။

ပထမတစ်မျိုးဟုခေါ်သည်။ Firebase သည် အချိန်နှင့်တပြေးညီ ဒေတာဘေ့စ်နှင့်ဒုတိယ - Firebase Cloud Firestore. သူတို့နှစ်ယောက်လုံးက ထုတ်ကုန်တွေပါ။ Firebase အစုံ Google ၎င်းတို့၏ API များကို အသီးသီး ခေါ်ဝေါ်ကြသည်။ firebase.database(…) и firebase.firestore(…).

ဒီလိုဖြစ်တာ အချိန်နှင့်တပြေးညီ ဒေတာဘေ့စ် - အဲဒါက မူရင်းပဲလေ။ Firebase 2014 ခုနှစ်တွင် Google မှမဝယ်ယူမီ။ ထို့နောက် Google သည် အပြိုင်ထုတ်ကုန်တစ်ခုအဖြစ် ဖန်တီးရန် ဆုံးဖြတ်ခဲ့သည်။ ကူးယူပါ ဒေတာကုမ္ပဏီကြီးတစ်ခုကို အခြေခံပြီး Firebase က ၎င်းကို Firestore ဟုခေါ်သည်။ မရှုပ်သေးဘူးလို့ မျှော်လင့်ပါတယ်။ စိတ်ရှုပ်နေသေးရင် စိတ်မပူပါနဲ့၊ ငါကိုယ်တိုင် ဒီဆောင်းပါးရဲ့ အပိုင်းကို ဆယ်ခါပြန်ရေးတယ်။

ညွှန်ပြလိုသောကြောင့်ဖြစ်သည်။ Firebase Firebase မေးခွန်းနှင့် မီးသတ်ဆိုင် Firebase နှင့် ပတ်သက်သော မေးခွန်းတစ်ခုတွင်၊ အနည်းဆုံး လွန်ခဲ့သော နှစ်အနည်းငယ်က Stack Overflow အကြောင်းကို သင်နားလည်စေရန်။

အကယ်၍ အဆိုးရွားဆုံး ဆော့ဖ်ဝဲလ်အမည်ပေးခြင်း အတွေ့အကြုံအတွက် ဆုတစ်ခု ရှိခဲ့ပါက၊ ၎င်းသည် ပြိုင်ဖက်များထဲမှ တစ်ခု ဖြစ်လာမည်မှာ သေချာပါသည်။ ဤအမည်များကြားရှိ ဟမ်းမင့်အကွာအဝေးသည် အလွန်သေးငယ်သောကြောင့် ခေါင်းတစ်ပိုင်းမှ အခြားတစ်ခုအကြောင်း စဉ်းစားနေချိန်တွင် လက်ချောင်းတစ်ချောင်းရိုက်သည့် အတွေ့အကြုံရှိသော အင်ဂျင်နီယာများပင် စိတ်ရှုပ်ထွေးစေပါသည်။ ဤအရာများသည် စိတ်အားထက်သန်စွာ ပျက်ကွက်သော ရည်ရွယ်ချက်ကောင်းများ ဖြစ်ကြသည်။ ဒေတာဘေ့စ်မီးလောင်တော့မည်ဟူသော ပရောဖက်ပြုချက်ကို ဖြည့်ဆည်းပေးခဲ့သည်။ ပြီးတော့ ကျွန်တော် လုံးဝနောက်နေတာမဟုတ်ဘူး။ ဤအမည်ပေးရေးအစီအစဥ်ကို တီထွင်ခဲ့သူသည် သွေး၊ ချွေးနှင့် မျက်ရည်တို့ကို ဖြစ်ပေါ်စေခဲ့သည်။

Pyrhic အောင်ပွဲ

Firestore လို့ပဲ ထင်ကြလိမ့်မယ်။ အစားထိုး Firebase သည် ၎င်း၏ မျိုးဆက်သစ် မျိုးဆက်သစ်များ ဖြစ်သော်လည်း ၎င်းသည် လှည့်စားခြင်း ဖြစ်လိမ့်မည်။ Firestore သည် Firebase အတွက် သင့်လျော်သော အစားထိုးတစ်ခုအဖြစ် အာမခံချက်မရှိပါ။ တစ်စုံတစ်ယောက်သည် ၎င်းမှ စိတ်ဝင်စားစရာအားလုံးကို ဖြတ်တောက်လိုက်ပုံရပြီး ကျန်အများစုကို နည်းအမျိုးမျိုးဖြင့် စိတ်ရှုပ်ထွေးနေပုံရသည်။

သို့သော်၊ ထုတ်ကုန်နှစ်ခုကို တစ်ချက်ကြည့်လိုက်ခြင်းဖြင့် သင့်အား စိတ်ရှုပ်ထွေးစေလိမ့်မည်- ၎င်းတို့သည် အခြေခံအားဖြင့် တူညီသော APIs များနှင့် တူညီသောဒေတာဘေ့စ်စက်ရှင်များတွင်ပင် ၎င်းတို့သည် တူညီသောအရာကို လုပ်ဆောင်ပုံရသည်။ ကွဲပြားမှုများသည် သိမ်မွေ့ပြီး ကျယ်ပြောလှသော စာရွက်စာတမ်းများကို ဂရုတစိုက် နှိုင်းယှဉ်လေ့လာခြင်းဖြင့်သာ ထင်ရှားပါသည်။ ဒါမှမဟုတ် Firestore နဲ့ အလုပ်လုပ်နိုင်အောင် Firebase မှာ ပြီးပြည့်စုံတဲ့ ကုဒ်ကို ပို့ဖို့ ကြိုးစားနေချိန်။ မောက်စ်ဖြင့် အချိန်နှင့်တပြေးညီ ဆွဲယူချရန် ကြိုးစားသည်နှင့်အမျှ ဒေတာဘေ့စ်အင်တာဖေ့စ်သည် မီးလင်းလာသည်ကိုပင် သင်တွေ့ရှိနိုင်သည်။ နောက်နေတာမဟုတ်ဘူးလို့ ထပ်ပြောတယ် ။

Firebase ကလိုင်းယင့်သည် အပြောင်းအလဲများကို ကြားခံလုပ်ဆောင်ပြီး နောက်ဆုံးရေးသည့်လုပ်ဆောင်ချက်ကို ဦးစားပေးသည့် အပ်ဒိတ်များကို အလိုအလျောက်ပြန်လုပ်ပေးသည့်သဘောဖြင့် ယဉ်ကျေးသိမ်မွေ့ပါသည်။ သို့သော်၊ Firestore တွင် အသုံးပြုသူတစ်ဦးလျှင် တစ်စက္ကန့်လျှင် စာရွက်စာတမ်းတစ်ခုလျှင် ရေးရန် 1 ကန့်သတ်ချက်ရှိပြီး ဤကန့်သတ်ချက်ကို ဆာဗာမှ ပြဌာန်းထားသည်။ ၎င်းနှင့်အလုပ်လုပ်သောအခါ၊ သင့်အပလီကေးရှင်းကိုတည်ဆောက်ရန်ကြိုးစားနေချိန်၌ပင် ၎င်းကိုပတ်လမ်းရှာဖွေပြီး အပ်ဒိတ်နှုန်းကန့်သတ်ချက်ကိုအကောင်အထည်ဖော်ရန် သင့်တွင်မူတည်ပါသည်။ ဆိုလိုသည်မှာ Firestore သည် API ကိုအသုံးပြု၍ ဟန်ဆောင်ထားသည့် real-time client မပါဘဲ အချိန်နှင့်တစ်ပြေးညီဒေတာဘေ့စ်တစ်ခုဖြစ်သည်။

ဤတွင် Firestore ၏ raison d'être ၏ပထမဆုံးလက္ခဏာများကိုကျွန်ုပ်တို့စတင်တွေ့မြင်ရသည်။ ကျွန်ုပ်မှားနိုင်သည်၊ သို့သော် ဝယ်ယူပြီးနောက် Google ၏ စီမံခန့်ခွဲမှုတွင် မြင့်မားသော တစ်စုံတစ်ယောက်သည် Firebase ကို ကြည့်ရှုပြီး “မဟုတ်ဘူး၊ အို ဘုရားသခင်၊ မဟုတ်ဘူး၊ ဒါကို လက်မခံနိုင်ပါ။ ငါ့ရဲ့ ဦးဆောင်မှုအောက်မှာ မဟုတ်ဘူး"

အခန်းများမှ ပေါ်လာပြီး မိန့်တော်မူသည်ကား၊

"ကြီးမားတဲ့ JSON စာရွက်စာတမ်းတစ်ခုလား။ မရှိ သင်သည် ဒေတာများကို သီးခြားစာရွက်စာတမ်းများအဖြစ် ပိုင်းခြားမည်ဖြစ်ပြီး၊ တစ်ခုစီသည် အရွယ်အစား 1 megabyte ထက်မပိုပါ။"

ထိုသို့သောကန့်သတ်ချက်သည် လုံလောက်သော လှုံ့ဆော်မှုရှိသော အသုံးပြုသူအခြေခံနှင့် ပထမဆုံးတွေ့ဆုံခြင်းတွင် ရှင်သန်နိုင်မည်မဟုတ်ပေ။ အဲဒါကို သိလား။ ဥပမာ၊ အလုပ်တွင်၊ ကျွန်ုပ်တို့တွင် တင်ပြချက်ပေါင်း တစ်ထောင်ခွဲကျော်ရှိပြီး ၎င်းသည် လုံးဝပုံမှန်ဖြစ်သည်။

ဤကန့်သတ်ချက်ဖြင့်၊ ဒေတာဘေ့စ်ရှိ "စာရွက်စာတမ်း" တစ်ခုသည် အသုံးပြုသူတစ်ဦးသည် စာရွက်စာတမ်းဟုခေါ်ဆိုနိုင်သည့် မည်သည့်အရာနှင့်မျှ ဆင်တူမည်မဟုတ်ကြောင်းကို သင်လက်ခံရတော့မည်ဖြစ်သည်။

"အခြားဒြပ်စင်များ ထပ်တလဲလဲ ပါ၀င်နိုင်သော arrays များ။ မရှိ အခင်းများတွင် ဘုရားသခင် ရည်မှန်းထားသည့်အတိုင်း ပုံသေ အလျားရှိသော အရာဝတ္ထု သို့မဟုတ် နံပါတ်များသာ ပါဝင်ပါမည်။"

ထို့ကြောင့် သင်သည် GeoJSON ကို သင်၏ Firestore တွင် ထည့်ရန် မျှော်လင့်ပါက၊ ၎င်းသည် မဖြစ်နိုင်ကြောင်း သင်တွေ့ရှိလိမ့်မည်။ တစ်ဘက်သတ်မဟုတ်သော မည်သည့်အရာကိုမျှ လက်ခံနိုင်စရာမရှိပါ။ JSON အတွင်းရှိ Base64 နှင့်/သို့မဟုတ် JSON ကို သင်နှစ်သက်မည်ဟု မျှော်လင့်ပါသည်။

“HTTP၊ အမိန့်ပေးစာလိုင်းကိရိယာများ သို့မဟုတ် စီမံခန့်ခွဲသူအကန့်မှတစ်ဆင့် JSON တင်သွင်းခြင်းနှင့် တင်ပို့ခြင်းလား။ မရှိ သင်သည် ဒေတာများကို Google Cloud Storage သို့သာ ထုတ်ယူနိုင်ပြီး တင်သွင်းနိုင်မည်ဖြစ်သည်။ အဲဒါကို အခုခေါ်တာလို့ ထင်ပါတယ်။ "မင်း" လို့ ပြောတဲ့အခါ၊ Project Owner အထောက်အထားတွေရှိတဲ့သူတွေကိုပဲ ပြောပြတာပါ။ တခြားလူတိုင်း လက်မှတ်တွေ ဖန်တီးလို့ရတယ်။"

သင်တွေ့မြင်ရသည့်အတိုင်း FireBase ဒေတာမော်ဒယ်သည် ဖော်ပြရန်လွယ်ကူသည်။ ၎င်းတွင် JSON ကီးများကို URL လမ်းကြောင်းများနှင့် ဆက်စပ်ပေးသည့် JSON စာရွက်စာတမ်းကြီးတစ်ခုပါရှိသည်။ စာနဲ့ရေးရင် HTTP PUT в / FireBase သည် အောက်ပါအတိုင်းဖြစ်သည်-

{
  "hello": "world"
}

အဆိုပါ GET /hello ပြန်လာကြလိမ့်မည် "world". အခြေခံအားဖြင့် ၎င်းသည် သင်မျှော်လင့်ထားသည့်အတိုင်း အလုပ်ဖြစ်သည်။ FireBase အရာဝတ္ထုများ စုစည်းမှု /my-collection/:id JSON အဘိဓာန်နှင့် ညီမျှသည်။ {"my-collection": {...}} root တွင် ရရှိနိုင်သော အကြောင်းအရာများ /my-collection:

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

ထည့်သွင်းမှုတစ်ခုစီတွင် စနစ်အတွက် စံဖြေရှင်းချက်တစ်ခုပါရှိသော တိုက်မိမှုကင်းသော ID ရှိပါက ၎င်းသည် ကောင်းမွန်စွာအလုပ်လုပ်ပါသည်။

တစ်နည်းဆိုရသော် ဒေတာဘေ့စ်သည် 100% JSON(*) သဟဇာတဖြစ်ပြီး CouchDB ကဲ့သို့သော HTTP နှင့် ကောင်းမွန်စွာအလုပ်လုပ်သည်။ သို့သော် အခြေခံအားဖြင့် သင်သည် ၎င်းကို abstract websockets၊ authorization နှင့် subscriptions များကို ထုတ်ပေးသည့် real-time API မှတဆင့် သင်အသုံးပြုပါသည်။ စီမံခန့်ခွဲသူအကန့်တွင် အချိန်နှင့်တပြေးညီတည်းဖြတ်ခြင်းနှင့် JSON တင်သွင်းခြင်း/ထုတ်ယူခြင်းတို့ကို ခွင့်ပြုပေးသည့် စွမ်းရည်နှစ်မျိုးစလုံးရှိသည်။ သင့်ကုဒ်တွင် အလားတူလုပ်ဆောင်ပါက၊ patch နှင့် Diff JSON သည် persistent state ကို ကိုင်တွယ်ခြင်း၏ 90% လုပ်ရိုးလုပ်စဉ်များကို ဖြေရှင်းပေးကြောင်း သင်သဘောပေါက်သောအခါ အထူးပြုကုဒ်မည်မျှ ဖြုန်းတီးမည်ကို အံ့သြမိပါလိမ့်မည်။

Firestore ဒေတာမော်ဒယ်သည် JSON နှင့် ဆင်တူသော်လည်း အချို့သောနည်းလမ်းများဖြင့် ကွဲပြားသည်။ arrays အတွင်းမှာ array တွေ မရှိတာကို ကျွန်တော် ပြောထားပြီးသားပါ။ စုစည်းမှုခွဲများအတွက် မော်ဒယ်သည် ၎င်းတို့ပါရှိသော JSON စာရွက်စာတမ်းမှ ခွဲထွက်ကာ ပထမတန်းစား အယူအဆများဖြစ်သည်။ ၎င်းအတွက် အဆင်သင့်လုပ်ထားသော အမှတ်စဉ်များ မရှိပါက ဒေတာများကို ပြန်လည်ရယူရန်နှင့် ရေးသားရန်အတွက် အထူးပြုကုဒ်လမ်းကြောင်းတစ်ခု လိုအပ်ပါသည်။ သင်၏ကိုယ်ပိုင်စုဆောင်းမှုများကိုလုပ်ဆောင်ရန်၊ သင်သည်သင်၏ကိုယ်ပိုင် script များနှင့်ကိရိယာများကိုရေးရန်လိုအပ်သည်။ စီမံခန့်ခွဲသူအကန့်သည် သင့်အား တစ်ကြိမ်လျှင် အကွက်တစ်ခုသို့ သေးငယ်သောပြောင်းလဲမှုများကိုသာ ပြုလုပ်နိုင်စေပြီး တင်သွင်း/တင်ပို့နိုင်မှု မရှိပါ။

၎င်းတို့သည် အချိန်နှင့်တပြေးညီ NoSQL ဒေတာဘေ့စ်ကို ယူကာ အလိုအလျောက်ချိတ်ဆက်ခြင်းနှင့် သီးခြားမဟုတ်သော JSON ကော်လံပါသော နှေးကွေးသော SQL မဟုတ်သော SQL အဖြစ်သို့ ပြောင်းလဲခဲ့ကြသည်။ GraftQL ကဲ့သို့ တစ်ခုခု.

ဟော့ဂျာဗား

Firestore သည် ပိုမိုယုံကြည်စိတ်ချရပြီး အရွယ်အစားပိုကြီးနိုင်သည်ဟု ယူဆပါက၊ ပျမ်းမျှ developer သည် FireBase ကို ဘောက်စ်ထဲမှ ရွေးချယ်ခြင်းထက် ယုံကြည်စိတ်ချရမှုနည်းသော ဖြေရှင်းချက်ဖြင့် အဆုံးသတ်သွားမည်ဖြစ်သည်။ Grumpy Database Administrator မှ လိုအပ်သော ဆော့ဖ်ဝဲလ်မျိုးသည် ထုတ်ကုန်၏ နယ်ပယ်အတွက် လက်တွေ့မဆန်သော လက်တွေ့မကျသော စွမ်းရည်အဆင့်တစ်ခု လိုအပ်ပါသည်။ ၎င်းသည် HTML5 Canvas သည် ဖွံ့ဖြိုးတိုးတက်ရေးကိရိယာများနှင့် ပလေယာမရှိပါက Flash အတွက် လုံးဝအစားထိုးမည်မဟုတ်သည့်ပုံစံနှင့် ဆင်တူသည်။ ထို့အပြင်၊ Firestore သည် ပျမ်းမျှစီးပွားရေးအသုံးပြုသူနှင့် ရိုးရိုးရှင်းရှင်းမလိုက်လျောညီထွေဖြစ်စေသော ဒေတာသန့်ရှင်းမှုနှင့် ပိုးမွှားစစ်ဆေးခြင်းအတွက် ဆန္ဒရှိနေသည်။ အလုပ်လုပ်ရတာကို နှစ်သက်တယ်။: သူ့အတွက် အရာအားလုံးက စိတ်ကြိုက်ဖြစ်တာမို့ အရာအားလုံးက အကြမ်းပါပဲ။

FireBase ၏ အဓိကအားနည်းချက်မှာ ဝဘ်ဆော့ဖ်ဝဲရေးသားသူအများစုသည် မပြောင်းလဲနိုင်ခြင်းအကြောင်းကို မသိမီတွင် သုံးစွဲသူအား ၎င်း၏အချိန်မတိုင်မီ နှစ်အတော်ကြာအောင် ဖန်တီးထားခြင်းဖြစ်သည်။ ထို့အတွက်ကြောင့် FireBase သည် သင်ဒေတာကို ပြောင်းလဲမည်ဟု ယူဆသောကြောင့် သုံးစွဲသူမှပေးသော မပြောင်းလဲနိုင်မှုအား အခွင့်ကောင်းမယူပါ။ ထို့အပြင်၊ ၎င်းသည် အသုံးပြုသူထံသို့ ပေးပို့သော လျှပ်တစ်ပြက်အတွင်း ဒေတာကို ပြန်လည်အသုံးမပြုတော့ဘဲ ကွဲပြားမှုကို ပိုမိုခက်ခဲစေသည်။ ကြီးမားသောစာရွက်စာတမ်းများအတွက်၊ ၎င်း၏ပြောင်းလဲနိုင်သောကွဲပြားမှုကိုအခြေခံသည့်ငွေပေးငွေယူယန္တရားသည်ရိုးရှင်းစွာမလုံလောက်ပါ။ ယောက်ျားတွေ ငါတို့မှာ ရှိပြီးသား WeakMap JavaScript တွင် အဆင်ပြေတယ်။

ဒေတာကို လိုချင်သောပုံသဏ္ဍာန်ပေး၍ သစ်ပင်များကို တောက်ပလွန်းအောင် မလုပ်ပါက၊ ဤပြဿနာကို ကျော်လွှားနိုင်သည်။ ဒါပေမယ့် ဒေတာဘေ့စ်ဒီဇိုင်းဆိုင်ရာ လေးနက်တဲ့ လက်တွေ့ကျတဲ့ အကြံဉာဏ်အချို့နဲ့ ပေါင်းစပ်ထားတဲ့ မပြောင်းလဲနိုင်မှုကို အသုံးပြုထားတဲ့ developer တွေက တကယ်ကောင်းတဲ့ client API ကို ထုတ်ပြန်ခဲ့မယ်ဆိုရင် FireBase က ပိုပြီး စိတ်ဝင်စားဖို့ကောင်းလာမလားဆိုတာ ကျွန်တော် သိချင်နေပါတယ်။ ယင်းအစား၊ ၎င်းတို့သည် မပျက်စီးသေးသောအရာကို ပြုပြင်ရန် ကြိုးစားပုံရပြီး ပိုဆိုးသွားစေသည်။

Firestore ဖန်တီးခြင်းရဲ့နောက်ကွယ်က ယုတ္တိအားလုံးကို ကျွန်တော်မသိဘူး။ အနက်ရောင်သေတ္တာအတွင်း ဖြစ်ပေါ်လာသည့် စေ့ဆော်ချက်များကို ခန့်မှန်းခြင်းသည်လည်း ပျော်ရွှင်မှု၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည်။ အလွန်ဆင်တူသော်လည်း နှိုင်းယှဉ်၍မရနိုင်သော ဒေတာဘေ့စ်နှစ်ခု၏ ဆက်စပ်မှုမှာ အလွန်ရှားပါသည်။ တစ်စုံတစ်ယောက်ထင်သလိုမျိုး၊ "Firebase သည် Google Cloud တွင် ကျွန်ုပ်တို့ အတုယူနိုင်သော လုပ်ဆောင်ချက်တစ်ခုသာဖြစ်သည်"သို့သော် လက်တွေ့ကမ္ဘာလိုအပ်ချက်များကို ခွဲခြားသတ်မှတ်ခြင်း သို့မဟုတ် ထိုလိုအပ်ချက်များအားလုံးနှင့် ကိုက်ညီသော အသုံးဝင်သောဖြေရှင်းနည်းများ ဖန်တီးခြင်းဆိုင်ရာ သဘောတရားကို မတွေ့ရှိသေးပါ။ “ developer တွေ စဉ်းစားကြည့်ရအောင်။ UI ကို လှပအောင်လုပ်ပါ... မီးထပ်ထည့်လို့ရမလား"

ဒေတာတည်ဆောက်ပုံများအကြောင်း အရာအချို့ကို ကျွန်ုပ်နားလည်ပါသည်။ ဒေတာဘေ့စ်မှ အကြီးစားဖွဲ့စည်းပုံ၏ အာရုံခံစားမှုမှန်သမျှကို စိတ်ကူးယဉ်ကြည့်ရန် "JSON သစ်ပင်ကြီးတစ်ပင်ရှိ အရာအားလုံး" အယူအဆကို ကျွန်ုပ်သေချာပေါက်မြင်သည်။ သံသယရှိသောဒေတာဖွဲ့စည်းပုံ Fractal ကိုရိုးရှင်းစွာဖြေရှင်းရန်ဆော့ဖ်ဝဲကိုမျှော်လင့်ခြင်းသည်ရိုးရှင်းပါသည်။ ဆိုးရွားတဲ့ ကုဒ်တွေကို စစ်ဆေးမှုတွေ ပြုလုပ်ပြီးပြီ ဆိုတာကို တွေးကြည့်ဖို့တောင် မလိုပါဘူး။ မင်းလူတွေ အိပ်မက်မမက်ဖူးတဲ့ အရာတွေကို ငါမြင်ဖူးတယ်။. ဒါပေမယ့် ဘယ်လိုပုံစံကောင်းလဲဆိုတာကိုလည်း သိပါတယ်၊ အဲဒါတွေကို ဘယ်လိုသုံးမလဲ။ и ဒါကိုဘာကြောင့်လုပ်သင့်တာလဲ။. Firestore ဟာ ယုတ္တိရှိပုံပေါ်ပြီး ဖန်တီးသူတွေဟာ ကောင်းမွန်တဲ့အလုပ်လို့ ထင်မြင်ယူဆနိုင်တဲ့ ကမ္ဘာတစ်ခုကို ပုံဖော်ကြည့်နိုင်ပါတယ်။ ဒါပေမယ့် ငါတို့က ဒီကမ္ဘာမှာ မနေရဘူး။

FireBase ၏မေးမြန်းချက်ပံ့ပိုးမှုသည် မည်သည့်စံနှုန်းဖြင့်မဆို ညံ့ဖျင်းပြီး လက်တွေ့တွင် မရှိပါ။ တိုးတက်မှု သို့မဟုတ် အနည်းဆုံး ပြန်လည်ပြင်ဆင်မှု လိုအပ်သည်မှာ သေချာပါသည်။ သို့သော် Firestore သည် ရိုးရှင်းသော SQL တွင်တွေ့ရသော တူညီသောတစ်ဖက်မြင်အညွှန်းကိန်းများကို ကန့်သတ်ထားသောကြောင့် ပိုကောင်းမည်မဟုတ်ပေ။ ရှုပ်ယှက်ခတ်နေသော ဒေတာများပေါ်တွင် လူများလုပ်ဆောင်သည့် စုံစမ်းမေးမြန်းမှုများကို လိုအပ်ပါက၊ သင်သည် စာသားအပြည့်အစုံရှာဖွေမှု၊ အမျိုးအစားပေါင်းစုံ စစ်ထုတ်မှုများနှင့် စိတ်ကြိုက်အသုံးပြုသူသတ်မှတ်ထားသော မှာယူမှု လိုအပ်ပါသည်။ ပိုမိုနီးကပ်စွာစစ်ဆေးသောအခါတွင် ရိုးရိုး SQL ၏လုပ်ဆောင်ချက်များသည် ၎င်းတို့ဘာသာအတွက် အကန့်အသတ်များရှိသည်။ ထို့အပြင်၊ ထုတ်လုပ်မှုတွင်လူများလုပ်ဆောင်နိုင်သည့်တစ်ခုတည်းသော SQL queries များသည်မြန်ဆန်သောမေးခွန်းများဖြစ်သည်။ တွေးခေါ်မြော်မြင်နိုင်သော ဒေတာဖွဲ့စည်းပုံများနှင့်အတူ စိတ်ကြိုက် အညွှန်းရေးခြင်းဆိုင်ရာ ဖြေရှင်းချက်တစ်ခု လိုအပ်ပါမည်။ အခြားအရာအားလုံးအတွက်၊ အနည်းဆုံး တိုးမြင့်မြေပုံ-လျှော့ချခြင်း သို့မဟုတ် အလားတူအရာတစ်ခု ရှိသင့်သည်။

၎င်းနှင့်ပတ်သက်သည့် အချက်အလက်အတွက် Google Docs ကို သင်ရှာဖွေပါက၊ သင်သည် BigTable နှင့် BigQuery ကဲ့သို့သော အရာများ၏ ဦးတည်ရာသို့ ညွှန်ပြလိမ့်မည်ဟု မျှော်လင့်ပါသည်။ သို့သော်၊ ဤဖြေရှင်းချက်အားလုံးသည် အလွန်သိပ်သည်းသော ကော်ပိုရိတ်အရောင်းဆိုင်ရာ ဗန်းစကားများဖြင့် လိုက်ပါသွားသဖြင့် သင်သည် လျင်မြန်စွာ နောက်ကြောင်းပြန်လှည့်ကာ အခြားအရာတစ်ခုကို စတင်ရှာတော့မည်ဖြစ်သည်။

အချိန်နှင့်တစ်ပြေးညီ ဒေတာဘေ့စ်တစ်ခုဖြင့် သင်လိုချင်သည့် နောက်ဆုံးအရာမှာ စီမံခန့်ခွဲမှု လစာစကေးရှိ လူများအတွက် ဖန်တီးထားသည့် အရာဖြစ်သည်။

(*) ဒါဟာသရယ်လို့တော့ မရှိပါဘူး။ 100% JSON နှင့် တွဲဖက်အသုံးပြုနိုင်သည်။.

ကြော်ငြာအဖြစ်

ကိုလိုက်ရှာသည် VDS အမှားရှာပြင်ခြင်းပရောဂျက်များအတွက်၊ ဖွံ့ဖြိုးတိုးတက်မှုနှင့် hosting အတွက်ဆာဗာတစ်ခုလား။ သင်သည် ကျိန်းသေပင် ကျွန်ုပ်တို့၏ client ဖြစ်သည် 🙂 အမျိုးမျိုးသော configurations ဆာဗာများအတွက် နေ့စဥ်စျေးနှုန်း၊ anti-DDoS နှင့် Windows လိုင်စင်များကို စျေးနှုန်းတွင် ထည့်သွင်းထားပြီးဖြစ်သည်။

source: www.habr.com