Техникалык окуяны айтып берейин.
Көп жыл мурун, мен ага орнотулган кызматташуу функциялары бар тиркемени иштеп чыккам. Бул алгачкы React жана CouchDB потенциалын толук пайдаланган колдонуучуга ыңгайлуу эксперименталдык стек болгон. Бул JSON аркылуу реалдуу убакытта маалыматтарды синхрондоштуруу . Бул компаниянын ичинде колдонулган, бирок анын кеңири колдонулушу жана башка аймактарда потенциалы ачык эле.
Бул технологияны потенциалдуу кардарларга сатууга аракет кылып жатып, биз күтүлбөгөн тоскоолдукка туш болдук. Демо видеодо биздин технология сонун көрүндү жана иштеди, эч кандай көйгөйлөр жок. Видеодо анын кантип иштээри так көрсөтүлгөн жана эч нерсени туураган эмес. Биз программаны колдонуунун реалдуу сценарийин ойлоп таптык жана коддодук.
Чынында, бул көйгөй болуп калды. Биздин демо башкалар өз колдонмолорун окшоштургандай иштеди. Тактап айтканда, маалымат чоң медиа файлдар болсо да, ошол замат Адан Бга өткөрүлүп берилди. Киргенден кийин, ар бир колдонуучу жаңы жазууларды көрдү. Тиркемени колдонуу менен, айылдын кайсы бир жеринде интернет байланышы үзгүлтүккө учураса дагы, ар кандай колдонуучулар бир эле долбоорлордун үстүндө чогуу иштей алышкан. Бул After Effects'те кесилген ар кандай продукт видеосунда кыйыр түрдө көрсөтүлөт.
Жаңылоо баскычы эмне үчүн экенин баары билсе да, алар бизден курууну суранган веб тиркемелери адатта өздөрүнүн чектөөлөрүнө дуушар болорун эч ким түшүнгөн эмес. Жана алар керек болбой калса, колдонуучунун тажрыйбасы такыр башкача болот. Көбүнчө алар сүйлөшүп жаткан адамдар үчүн жазууларды калтыруу менен "чат" ала аларын байкашкан, андыктан мунун, мисалы, Slackтен эмнеси менен айырмаланат деп таң калышты. Фу!
Күнүмдүк синхрондоштуруунун дизайны
Эгерде сизде программалык камсыздоону иштеп чыгууда тажрыйбаңыз болсо, көпчүлүк адамдар интерфейстин сүрөтүн карап, аны менен иштешкенде анын эмне кыларын түшүнө албастыгын эстен чыгарбоо нервди бузду. Программанын ичинде эмне болуп жатканын айтпай эле коёлу. Ошону бил алат эмне болушу мүмкүн эмес экенин жана эмне болбошу керектигин билүүнүн натыйжасы болуп саналат. Бул талап кылат программалык камсыздоо эмне кылып жатканын гана эмес, ошондой эле анын айрым бөлүктөрү кантип координацияланып, бири-бири менен байланышып жатканын.
Мунун классикалык мисалы - а тиктеген колдонуучу spinner.gif, иштин акыры качан бүтөөрүнө кызык. Иштеп чыгуучу процесстин тыгылып калганын жана gif эч качан экрандан жок болуп кетпей турганын түшүнмөк. Бул анимация жумуштун аткарылышын симуляциялайт, бирок анын абалына байланыштуу эмес. Мындай учурларда, кээ бир техниктер колдонуучулардын башаламандыгына таң калып, көздөрүн айлантканды жакшы көрүшөт. Бирок, алардын канчасы айланып турган саатты көрсөтүп, ал чындыгында кыймылсыз деп айтышат.
Бул реалдуу убакыт наркынын маңызы. Бул күндөрү, реалдуу убакыт маалымат базалары дагы эле өтө аз колдонулат жана көп адамдар шектенүү менен карап жатышат. Бул маалымат базаларынын көбү NoSQL стилине ыкташат, ошондуктан алар көбүнчө Mongo негизиндеги чечимдерди колдонушат, алар унутулуп калган. Бирок, мен үчүн бул CouchDB менен ыңгайлуу иштөөнү, ошондой эле кээ бир бюрократтардын маалыматтары менен толтура турган структураларды долбоорлоону үйрөнүүнү билдирет. Мен убакытты жакшыраак пайдаланып жатам деп ойлойм.
Бирок бул посттун чыныгы темасы мен бүгүн колдонуп жаткан нерсем. Тандоо менен эмес, кайдыгер жана сокур колдонулган корпоративдик саясаттын айынан. Ошентип, мен Google реалдуу убакыттагы маалымат базасынын бири-бирине тыгыз байланышкан эки продуктуну Толугу менен Адилет жана калыс салыштыруу менен камсыз кылам.
Экөөнүн тең атында От деген сөз бар. Бир нерсени жакшы эстейм. Мен үчүн экинчи нерсе - оттун башка түрү. Мен алардын атын айтууга шашпайм, анткени мен айткандан кийин биз биринчи чоң көйгөйгө туш болобуз: ысымдар.
Биринчиси деп аталат Firebase реалдуу убакыт маалымат базасы, экинчиси - Firebase Cloud Firestore. Экөө тең фирманын продукциясы Firebase топтому Гугл. Алардын API'лери тиешелүү түрдө деп аталат firebase.database(…) и firebase.firestore(…).
Бул себеп болду реалдуу убакыт базасы - бул жөн гана оригинал Firebase 2014-жылы Google тарабынан сатып алынганга чейин. Андан кийин Google параллелдүү продукт катары түзүүнү чечти көчүрмөсү Firebase чоң маалымат компаниясына негизделген жана аны булут менен Firestore деп атады. Мен сиз дагы баш аламандык жок деп үмүттөнөм. Эгер сиз дагы эле баш аламан болсоңуз, кабатыр болбоңуз, мен макаланын бул бөлүгүн он жолу кайра жаздым.
Анткени көрсөтүү керек Firebase Firebase суроосунда жана Firestore Firebase жөнүндө суроодо, жок дегенде, бир нече жыл мурун Stack Overflow жөнүндө түшүнүү үчүн.
Эң начар программалык камсыздоону атоо тажрыйбасы үчүн сыйлык болсо, бул, албетте, талапкерлердин бири болмок. Бул ысымдардын ортосундагы Хамминг аралык ушунчалык кичинекей болгондуктан, манжалары бир ысымды терип, баштары башканы ойлоп жаткан тажрыйбалуу инженерлерди да чаташтырат. Бул жакшы ниеттенген пландар, алар ийгиликсиз аяктайт; база янгын боляр диен айдышы ерине етирдилер. А мен такыр тамашалаган жокмун. Бул ат коюу схемасын ойлоп тапкан адам кан, терди жана көз жашты жаратты.
Пирлик жеңиш
Кимдир бирөө Firestore деп ойлошу мүмкүн ордуна иштөө Firebase, анын кийинки мууну, бирок бул жаңылыштык болот. Firestore Firebase үчүн ылайыктуу алмаштырууга кепилдик жок. Кимдир бирөө андан кызыктуу нерселердин баарын кесип алып, калгандарынын көбүн ар кандай жолдор менен чаташтырган окшойт.
Бирок, эки өнүмгө тез көз чаптыруу сизди чаташтырышы мүмкүн: алар бир эле нерсени, негизинен, бир эле API аркылуу, атүгүл бир эле маалымат базасы сессиясында жасашат окшойт. Айырмачылыктар тымызын жана кеңири документтерди кылдаттык менен салыштырып изилдөө менен гана ачылат. Же сиз Firebase'де мыкты иштеген кодду порттоого аракет кылып жатканда, ал Firestore менен иштеши үчүн. Ошондо да сиз реалдуу убакыт режиминде чычкан менен сүйрөп барып таштоого аракет кылганыңызда маалымат базасынын интерфейси күйүп жатканын билесиз. Дагы кайталайм, мен тамашалап жаткан жокмун.
Firebase кардары сылык мамиледе, анткени ал өзгөрүүлөрдү буферлейт жана акыркы жазуу операциясына артыкчылык берген жаңыртууларды автоматтык түрдө кайра сынайт. Бирок, Firestore бир колдонуучуга секундасына бир документке 1 жазуу операциясынын чеги бар жана бул чек сервер тарабынан аткарылат. Аны менен иштөөдө, сиз колдонмоңузду түзүүгө аракет кылып жатсаңыз да, аны айланып өтүү жана жаңыртуу ылдамдыгын чектегичти ишке ашыруу сизге көз каранды. Башкача айтканда, Firestore - бул реалдуу убакыттагы кардары жок, API колдонуучудай көрүнгөн маалымат базасы.
Бул жерде биз Firestore'дун raison d'être биринчи белгилерин көрө баштайбыз. Мен жаңылып жаткандырмын, бирок мен Google'дун жогорку даражадагы бирөө сатып алгандан кийин Firebase'ти карап, жөн гана: "Жок, оо, Кудайым, жок. Бул кабыл алынгыс нерсе. Жөн гана менин жетекчилигимде эмес».
Ал өз бөлмөсүнөн чыгып, мындай деди:
"Бир чоң JSON документи? Жок. Сиз маалыматтарды өзүнчө документтерге бөлөсүз, алардын ар биринин көлөмү 1 мегабайттан ашпайт».
Мындай чектөө кандайдыр бир жетиштүү жүйөлүү колдонуучу базасы менен биринчи жолукканда аман калбайт окшойт. Сиз билесиз. Мисалы, жумушта бизде бир жарым миңден ашык презентациялар бар жана бул толугу менен нормалдуу көрүнүш.
Бул чектөө менен сиз маалымат базасындагы бир "документ" колдонуучу документ деп атай турган эч бир объектке окшошпой тургандыгын кабыл алууга мажбур болосуз.
"Башка элементтерди рекурсивдүү түрдө камтый турган массивдердин массивдери? Жок. Массивдер Кудай каалагандай, туруктуу узундуктагы объекттерди же сандарды гана камтыйт."
Демек, сиз GeoJSON-ду Firestore-га киргизем деп үмүттөнсөңүз, бул мүмкүн эмес экенин көрөсүз. Бир өлчөмдүү эмес эч нерсе кабыл алынбайт. Сизге JSON ичиндеги Base64 жана/же JSON жагат деп үмүттөнөм.
"JSON HTTP аркылуу импорттоо жана экспорттоо, буйрук сабы куралдары же администратор панели? Жок. Сиз Google Булут сактагычына дайындарды экспорттой жана импорттой аласыз. Менимче, азыр ошондой аталат. Жана мен "сиз" деп айтканда, мен Долбоордун Ээсинин грамотасы барларга гана кайрылып жатам. Калгандардын баары барып, билеттерди түзө алышат."
Көрүнүп тургандай, FireBase маалымат моделин сүрөттөө оңой. Ал JSON ачкычтарын URL жолдору менен байланыштырган бир чоң JSON документин камтыйт. менен жазсаңыз HTTP PUT в / FireBase төмөнкүдөй:
{
"hello": "world"
}
жана GET /hello кайра келет "world". Негизинен ал сиз күткөндөй иштейт. FireBase объекттеринин коллекциясы /my-collection/:id JSON сөздүгүнө барабар {"my-collection": {...}} тамырында, анын мазмуну жеткиликтүү /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Бул ар бир кыстарма системанын стандарттуу чечими бар кагылышпаган ID'ге ээ болсо жакшы иштейт.
Башка сөз менен айтканда, маалымат базасы 100% JSON(*) шайкеш келет жана HTTP менен сонун иштейт, мисалы, CouchDB. Бирок, негизинен, сиз аны веб-сокеттерди, авторизацияны жана жазылууларды абстракциялаган реалдуу убакыт API аркылуу колдоносуз. Администратор панелинин эки мүмкүнчүлүктөрү бар, алар реалдуу убакыт режиминде түзөтүүгө жана JSON импортуна/экспортуна мүмкүнчүлүк берет. Эгер сиз кодуңузда да ушундай кылсаңыз, патч жана дифференция JSON туруктуу абалды башкаруу боюнча күнүмдүк тапшырмалардын 90% чечээрин түшүнгөндө, канча адистештирилген код ысырап болоруна таң каласыз.
Firestore маалыматтар модели JSON окшош, бирок кээ бир маанилүү жолдор менен айырмаланат. Мен буга чейин массивдердин ичиндеги массивдердин жоктугун айттым. Суб-коллекциялардын модели аларды камтыган JSON документинен өзүнчө, биринчи класстагы түшүнүктөр болушу керек. Бул үчүн даяр сериялаштыруу жок болгондуктан, маалыматтарды алуу жана жазуу үчүн атайын код жолу талап кылынат. Өз коллекцияларыңызды иштетүү үчүн өзүңүздүн сценарийлериңизди жана куралдарыңызды жазышыңыз керек. Администратор панели бир эле учурда бир талаага майда өзгөртүүлөрдү киргизүүгө гана мүмкүндүк берет жана импорт/экспорт мүмкүнчүлүктөрү жок.
Алар реалдуу убакыттагы NoSQL маалымат базасын алып, аны автоматтык түрдө кошулуу жана JSON эмес өзүнчө тилке менен жай эмес SQLге айландырышты. GraftQL сыяктуу бир нерсе.
Ысык Java
Эгерде Firestore ишенимдүү жана масштабдуураак болушу керек болсо, анда таң калыштуусу, орточо иштеп чыгуучу FireBaseди кутудан тандап алганга караганда анча ишенимдүү чечимге ээ болот. Grumpy маалымат базасынын администраторуна керек болгон программалык камсыздоонун түрү күч-аракетти жана таланттын калибринин деңгээлин талап кылат, бул продукт жакшы болушу керек болгон орун үчүн реалдуу эмес. Бул HTML5 Canvas кандайча иштеп чыгуу куралдары жана ойноткуч жок болсо, Flash үчүн такыр эле алмаштырылбаганына окшош. Мындан тышкары, Firestore маалыматтардын тазалыгына жана стерилдүү валидацияга болгон каалоосу менен камтылган, бул жөнөкөй бизнес колдонуучуга туура келбейт. иштегенди жакшы көрөт: ал үчүн баары ыктыярдуу, анткени акырына чейин баары долбоор.
FireBase'дин негизги кемчилиги - кардар өз убагында, көпчүлүк веб-иштеп чыгуучулар өзгөрүлбөстүк жөнүндө билгенге чейин түзүлгөн. Ушундан улам, FireBase сиз дайындарды өзгөртөсүз деп ойлойт жана ошондуктан колдонуучу берген өзгөрүлбөстүктү колдонбойт. Кошумчалай кетсек, ал колдонуучуга өткөрүп берген сүрөттөрдөгү маалыматтарды кайра колдонбойт, бул айырмачылыкты бир топ кыйындатат. Чоң документтер үчүн анын өзгөрмөлүү айырмага негизделген транзакция механизми жөн эле жетишсиз. Балдар, бизде мурунтан эле бар WeakMap JavaScript'те. Бул ыңгайлуу.
Эгерде сиз маалыматка керектүү форманы берсеңиз жана бак-дарактарды өтө көлөмдүү кылбасаңыз, анда бул көйгөйдү айланып өтүүгө болот. Бирок, эгер иштеп чыгуучулар өзгөрүлбөстүктү колдонгон чындап эле жакшы кардар APIин чыгарса, FireBase алда канча кызыктуураак болмок беле, мага кызык. Тескерисинче, алар бузулбаган нерсени оңдоого аракет кылып жаткандай көрүндү жана бул аны ого бетер начарлатты.
Мен Firestore түзүлүшүнүн логикасын билбейм. Кара кутунун ичинде пайда болгон мотивдер жөнүндө ой жүгүртүү да көңүл ачуунун бир бөлүгү. Бул эки өтө окшош, бирок теңдешсиз маалымат базаларынын бири-бирине карама-каршы келиши өтө сейрек кездешет. Кимдир бирөө ойлогондой: "Firebase бул жөн гана биз Google Булутта эмуляция кыла турган функция", бирок реалдуу талаптарды аныктоо же ошол талаптардын баарына жооп берген пайдалуу чечимдерди түзүү концепциясын ача элек. «Бул жөнүндө иштеп чыгуучулар ойлонушсун. Жөн гана UI сулуу болсун... Сиз дагы от кошо аласызбы?”
Мен маалымат структуралары жөнүндө бир нече нерсени түшүнөм. Мен сөзсүз түрдө "баары бир чоң JSON дарагында" концепциясын маалымат базасынан масштабдуу структуранын кандайдыр бир маанисин абстракциялоо аракети катары көрөм. Программалык камсыздоону жөн гана кандайдыр бир шектүү маалыматтар түзүмү фракталы менен күрөшүүгө күтүү жөн эле акылсыздык. Кандай жаман нерселер болорун элестетүүнүн кереги жок, мен катаал коддук текшерүүлөрдү жасадым жана Мен силердин түшүнө кирбеген нерселерди көрдүм. Бирок мен жакшы структуралар кандай болорун билем, и . Мен Firestore логикалык көрүнгөн дүйнөнү элестете алам жана аны жараткан адамдар жакшы иш кылды деп ойлошот. Бирок биз бул дүйнөдө жашабайбыз.
FireBase сурамдарын колдоо кандайдыр бир стандарт боюнча начар жана иш жүзүндө жок. Ал сөзсүз түрдө жакшыртууга же жок дегенде кайра карап чыгууга муктаж. Бирок Firestore анча жакшы эмес, анткени ал жөнөкөй SQLде табылган бир өлчөмдүү индекстер менен чектелген. Эгер сизге адамдар башаламан маалыматтарда иштеген сурамдар керек болсо, сизге толук тексттик издөө, көп диапазондук чыпкалар жана колдонуучу аныктаган буйрутма керек. Жакшыраак текшерүүдөн кийин, жөнөкөй SQL функциялары өз алдынча өтө эле чектелген. Кошумчалай кетсек, адамдар өндүрүштө иштете алган жалгыз SQL сурамдары - бул тез сурамдар. Сиз акылдуу маалымат структуралары менен ыңгайлаштырылган индекстөө чечими керек болот. Бардык башка нерселер үчүн, жок эле дегенде, кошумча картаны азайтуу же ушул сыяктуу нерсе болушу керек.
Бул тууралуу маалымат алуу үчүн Google Документтеринен издесеңиз, сиз BigTable жана BigQuery сыяктуу бир нерсеге багыт аласыз деп үмүттөнөбүз. Бирок, бул чечимдердин бардыгы ушунчалык тыгыз корпоративдик сатуу жаргону менен коштолуп, сиз тез эле артка кайрылып, башка нерсени издей баштайсыз.
Реалдуу убакыттагы маалымат базасы менен сиз эң акыркы нерсе - бул башкаруунун айлык акы таразасындагы адамдар тарабынан жасалган нерсе.
(*) Бул тамаша, андай нерсе жок .
жарнама катары
Издөө мүчүлүштүктөрдү оңдоо долбоорлору үчүн, иштеп чыгуу жана хостинг үчүн сервер? Сиз, албетте, биздин кардарсыз 🙂 Ар кандай конфигурациядагы серверлердин күнүмдүк баасы, анти-DDoS жана Windows лицензиялары баага киргизилген.
Source: www.habr.com