Техникалық оқиғаны айтайын.
Көптеген жылдар бұрын мен оған кіріктірілген ынтымақтастық мүмкіндіктері бар қосымшаны әзірледім. Бұл ерте React және CouchDB мүмкіндіктерін толық пайдаланған пайдаланушыға ыңғайлы эксперименттік стек болды. Ол JSON арқылы нақты уақытта деректерді үндестірді . Ол компания ішінде қолданылды, бірақ оның басқа салаларда кең қолданылуы мен әлеуеті анық болды.
Бұл технологияны әлеуетті клиенттерге сатуға тырысқанда, біз күтпеген кедергіге тап болдық. Демонстрациялық бейнеде біздің технология керемет көрінді және жұмыс істеді, онда ешқандай проблемалар жоқ. Бейне оның қалай жұмыс істейтінін нақты көрсетті және ештеңеге еліктемейді. Біз бағдарламаны пайдаланудың нақты сценарийін ойлап таптық және кодтадық.
Іс жүзінде бұл мәселеге айналды. Біздің демонстрация басқалар өз қолданбаларын модельдейтіндей жұмыс істеді. Атап айтқанда, ақпарат үлкен медиа файлдар болса да, А-дан В-ге бірден тасымалданды. Жүйеге кіргеннен кейін әрбір пайдаланушы жаңа жазбаларды көрді. Қолданбаны пайдалана отырып, әртүрлі пайдаланушылар ауылдың бір жерінде интернет байланысы үзілсе де, бір жобаларда бірге жұмыс істей алады. Бұл After Effects қолданбасында кесілген кез келген өнім бейнесінде жанама түрде айтылады.
Барлығы «Жаңарту» түймесі не үшін қажет екенін білсе де, бізден құрастыруды сұраған веб-қосымшалардың әдетте өздерінің шектеулері бар екенін ешкім түсінбеді. Ал егер олар қажет болмаса, пайдаланушы тәжірибесі мүлдем басқаша болады. Олар көбінесе сөйлесіп жатқан адамдар үшін жазбалар қалдыру арқылы «сұхбаттасуға» болатынын байқады, сондықтан олар мұның, мысалы, Slack-тен айырмашылығы бар екеніне таң қалды. Уф!
Күнделікті синхрондау дизайны
Егер сізде бағдарламалық жасақтаманы әзірлеуде тәжірибеңіз болса, көптеген адамдар интерфейстің суретіне қарап, онымен әрекеттесу кезінде оның не істейтінін түсініп қана қоймайтынын есте сақтау жүйкені жұқартуы керек. Бағдарламаның өзінде не болатынын айтпағанның өзінде. Соны біл болады орын алу көбінесе ненің болмайтынын және ненің болмауы керектігін білудің нәтижесі болып табылады. Бұл талап етеді бағдарламалық жасақтаманың не істейтінін ғана емес, сонымен қатар оның жеке бөліктерінің бір-бірімен қалай үйлестірілгенін және байланысуын да анықтайды.
Мұның классикалық мысалы - a-ға қарап тұрған пайдаланушы spinner.gif, жұмыс қашан аяқталады деген ойда. Әзірлеуші процестің тоқтап қалғанын және GIF ешқашан экраннан жоғалып кетпейтінін түсінген болар еді. Бұл анимация тапсырманың орындалуын имитациялайды, бірақ оның күйіне қатысы жоқ. Мұндай жағдайларда кейбір техниктер пайдаланушының шатасуы дәрежесіне таң қалып, көздерін айналдыруды ұнатады. Дегенмен, олардың қаншасы айналмалы сағатты көрсетіп, оның шын мәнінде қозғалмайтынын айтады?
Бұл нақты уақыт құнының мәні. Бұл күндері нақты уақыттағы дерекқорлар әлі де өте аз пайдаланылады және көптеген адамдар оларға күдікпен қарайды. Бұл дерекқорлардың көпшілігі NoSQL стиліне сүйенеді, сондықтан олар әдетте ұмытылған Mongo негізіндегі шешімдерді пайдаланады. Дегенмен, мен үшін бұл CouchDB-пен ыңғайлы жұмыс істеуді, сондай-ақ кейбір бюрократтардың деректермен толтыра алатын құрылымдарын жобалауды үйренуді білдіреді. Уақытымды тиімді пайдаланамын деп ойлаймын.
Бірақ бұл жазбаның нақты тақырыбы - мен бүгін қолданатын нәрсе. Таңдау бойынша емес, немқұрайлы және соқыр қолданылатын корпоративтік саясаттың арқасында. Сондықтан мен Google нақты уақыттағы дерекқордың бір-бірімен тығыз байланысты екі өнімін толығымен әділ және бейтарап салыстыруды ұсынамын.
Екеуінің де есімдерінде От сөзі бар. Бір нәрсе қатты есімде. Мен үшін екінші нәрсе - оттың басқа түрі. Мен олардың есімдерін айтуға асықпаймын, өйткені мен айтқаннан кейін біз бірінші үлкен мәселеге тап боламыз: атаулар.
Біріншісі деп аталады Firebase нақты уақыттағы дерекқоры, ал екінші - Firebase Cloud Firestore. Олардың екеуі де фирманың өнімдері Firebase жиынтығы Google. Олардың API интерфейстері сәйкесінше аталады firebase.database(…) и firebase.firestore(…).
Бұл болды, өйткені Нақты уақыттағы деректер қоры - бұл тек түпнұсқасы Firebase Google оны 2014 жылы сатып алғанға дейін. Содан кейін Google параллель өнім ретінде жасауды шешті көшірмесі Firebase үлкен деректер компаниясына негізделген және оны бұлтпен Firestore деп атады. Сіз әлі шатасып кетпедіңіз деп үміттенемін. Егер сіз әлі де шатастырсаңыз, уайымдамаңыз, мен мақаланың осы бөлігін он рет қайта жаздым.
Өйткені көрсету керек Firebase Firebase сұрағында және Firestore Firebase туралы сұрақта, кем дегенде, бірнеше жыл бұрын Stack Overflow туралы түсіну үшін.
Егер бағдарламалық жасақтаманы атаудағы ең нашар тәжірибе үшін марапат болса, бұл сөзсіз үміткерлердің бірі болар еді. Бұл атаулардың арасындағы Хамминг қашықтығы соншалық, тіпті тәжірибелі инженерлерді де шатастырады, ал саусақтары бір атауды басады, ал бастары басқа туралы ойлайды. Бұл сәтсіздікке ұшыраған жақсы ниетті жоспарлар; олар мәліметтер базасы өртенеді деген болжамды орындады. Ал мен мүлде қалжыңдамаймын. Бұл атау схемасын ойлап тапқан адам қан, тер, көз жасын тудырды.
Пирикалық жеңіс
Біреу Firestore деп ойлауы мүмкін ауыстыру Firebase, оның келесі ұрпақ ұрпағы, бірақ бұл жаңылыстырушы болар еді. Firestore Firebase үшін қолайлы алмастыруға кепілдік бермейді. Біреу одан қызықтының бәрін қиып алып, қалғандарының көпшілігін түрлі жолдармен шатастырған сияқты.
Дегенмен, екі өнімге жылдам қарау сізді шатастыруы мүмкін: олар бірдей API арқылы және тіпті бір дерекқор сеансында бірдей нәрсені жасайтын сияқты. Айырмашылықтар нәзік және тек ауқымды құжаттаманы мұқият салыстырмалы зерттеу арқылы анықталады. Немесе Firestore-мен жұмыс істеу үшін Firebase-де тамаша жұмыс істейтін кодты портқа шығаруға тырысқанда. Сонда да сіз нақты уақытта тінтуірмен сүйреп апаруға тырысқанда, дерекқор интерфейсі жанып тұратынын білесіз. Қайталап айтамын, мен қалжыңдамаймын.
Firebase клиенті өзгерістерді буферлейді және соңғы жазу әрекетіне басымдық беретін жаңартуларды автоматты түрде қайталайды деген мағынада сыпайы. Дегенмен, Firestore-да әр пайдаланушыға секундына құжатқа 1 жазу әрекетінің шегі бар және бұл шектеу сервермен орындалады. Онымен жұмыс істегенде, оны айналып өту жолын табу және жаңарту жылдамдығын шектегішті енгізу, тіпті қолданбаңызды құруға тырыссаңыз да, сізге байланысты. Яғни, Firestore нақты уақыттағы клиентсіз нақты уақыттағы дерекқор болып табылады, ол API көмегімен бір реттік болып көрінеді.
Мұнда біз Firestore компаниясының бар болу себебінің алғашқы белгілерін көре бастаймыз. Мен қателескен шығармын, бірақ мен Google басшылығындағы біреу сатып алғаннан кейін Firebase-ге қарап, жай ғана: «Жоқ, Құдайым, жоқ. Бұл қабылданбайды. Тек менің басшылығымда емес».
Ол өз бөлмесінен шығып, былай деді:
«Бір үлкен JSON құжаты? Жоқ. Деректерді әрқайсысының өлшемі 1 мегабайттан аспайтын бөлек құжаттарға бөлесіз».
Мұндай шектеу кез келген жеткілікті мотивацияланған пайдаланушы базасымен бірінші кездесуден аман қалмайтын сияқты. Сіз мұны білесіз. Жұмыста, мысалы, бізде бір жарым мыңнан астам презентациялар бар және бұл мүлдем қалыпты жағдай.
Бұл шектеумен сіз дерекқордағы бір «құжат» пайдаланушы құжат деп атайтын кез келген нысанға ұқсамайтынын қабылдауға мәжбүр боласыз.
«Басқа элементтерді рекурсивті түрде қамтуы мүмкін массивтер массивтері? Жоқ. Массивтерде Құдай қалағандай тек тұрақты ұзындықтағы нысандар немесе сандар болады».
Егер сіз GeoJSON-ды Firestore-ға орналастырғыңыз келсе, бұл мүмкін емес екенін көресіз. Бір өлшемді емес ештеңе қабылданбайды. Сізге JSON ішіндегі Base64 және/немесе JSON ұнайды деп үміттенемін.
«HTTP, пәрмен жолы құралдары немесе басқару тақтасы арқылы JSON импорттау және экспорттау? Жоқ. Деректерді тек Google Cloud Storage қызметіне экспорттай және импорттай аласыз. Қазір солай аталады, меніңше. Мен «сіз» деп айтқанда, мен тек Жоба иесінің тіркелгі деректері бар адамдарға жүгінемін. Қалғандардың барлығы барып, билеттерді жасай алады ».
Көріп отырғаныңыздай, FireBase деректер үлгісін сипаттау оңай. Онда JSON кілттерін URL жолдарымен байланыстыратын бір үлкен JSON құжаты бар. Егер сіз онымен жазсаңыз HTTP PUT в / FireBase келесідей:
{
"hello": "world"
}
The GET /hello қайтады "world". Негізінде ол сіз күткендей жұмыс істейді. FireBase нысандарының жинағы /my-collection/:id JSON сөздігіне баламалы {"my-collection": {...}} мазмұны қол жетімді түбірде /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Әрбір кірістіру жүйеде стандартты шешімі бар соқтығыспайтын идентификаторы болса, бұл жақсы жұмыс істейді.
Басқаша айтқанда, дерекқор 100% JSON(*) үйлесімді және CouchDB сияқты HTTP-мен тамаша жұмыс істейді. Бірақ негізінен сіз оны веб-розеткалар, авторизация және жазылымдарды абстракциялайтын нақты уақыттағы 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 Cloud жүйесінде эмуляциялай алатын жай ғана функция», бірақ нақты әлемдегі талаптарды анықтау немесе осы талаптардың барлығына жауап беретін пайдалы шешімдер жасау тұжырымдамасы әлі ашылған жоқ. «Бұл туралы әзірлеушілер ойлансын. Тек UI әдемі болсын... Сіз көбірек от қоса аласыз ба?»
Деректер құрылымдары туралы бірнеше нәрсені түсінемін. Мен «бәрі бір үлкен JSON ағашындағы» тұжырымдамасын дерекқордан ауқымды құрылымның кез келген мағынасын абстракциялау әрекеті ретінде көремін. Бағдарламалық жасақтаманың кез келген күмәнді деректер құрылымы фракталымен оңай күресетінін күту жай ғана ақылсыздық. Маған нәрселердің қаншалықты жаман болуы мүмкін екенін елестетудің қажеті жоқ, мен қатаң кодтық аудиттер жасадым және Мен сіздердің адамдарыңыз ешқашан армандамаған нәрселерді көрдім. Бірақ мен жақсы құрылымдардың қандай болатынын білемін, и . Мен Firestore қисынды болып көрінетін және оны жасаған адамдар жақсы жұмыс жасады деп ойлайтын әлемді елестете аламын. Бірақ біз бұл дүниеде өмір сүрмейміз.
FireBase сұранысын қолдау кез келген стандарт бойынша нашар және іс жүзінде жоқ. Ол сөзсіз жақсартуды немесе кем дегенде қайта қарауды қажет етеді. Бірақ Firestore әлдеқайда жақсырақ емес, себебі ол қарапайым SQL-де табылған бір өлшемді индекстермен шектелген. Адамдар ретсіз деректерде орындайтын сұраулар қажет болса, сізге толық мәтінді іздеу, көп ауқымды сүзгілер және пайдаланушы анықтайтын реттелетін тапсырыс қажет. Жақынырақ тексеру кезінде қарапайым SQL функциялары өздігінен тым шектеулі. Сонымен қатар, адамдар өндірісте орындай алатын жалғыз SQL сұраулары жылдам сұраулар болып табылады. Сізге ойластырылған деректер құрылымдары бар теңшелетін индекстеу шешімі қажет. Барлық қалғандары үшін, кем дегенде, картаны азайту немесе ұқсас нәрсе болуы керек.
Бұл туралы ақпаратты Google Docs ішінен іздесеңіз, сізге BigTable және BigQuery сияқты нәрсенің бағыты көрсетіледі деп үміттенеміз. Дегенмен, бұл шешімдердің барлығы корпоративтік сату жаргондарымен бірге жүреді, сондықтан сіз тез оралып, басқа нәрсені іздей бастайсыз.
Нақты уақыттағы дерекқормен сізге қажет соңғы нәрсе - бұл басқарушы жалақы таразысындағы адамдар үшін жасалған нәрсе.
(*) Бұл әзіл, ондай нәрсе жоқ .
Жарнама құқықтары туралы
Іздеп тұру жөндеу жобалары үшін, әзірлеуге және хостингке арналған сервер? Сіз сөзсіз біздің клиентсіз 🙂 Әртүрлі конфигурациядағы серверлердің күнделікті бағасы, анти-DDoS және Windows лицензиялары қазірдің өзінде бағаға енгізілген.
Ақпарат көзі: www.habr.com