Дазвольце мне расказаць тэхнічную гісторыю.
Шмат гадоў таму я распрацоўваў дадатак з убудаванымі ў яго функцыямі сумеснай працы. Гэта быў зручны эксперыментальны стэк, у якім выкарыстоўваўся поўны патэнцыял ранняга React і CouchDB. Ён у рэальным часе сінхранізаваў дадзеныя па JSON . Яго выкарыстоўвалі ва ўнутранай працы кампаніі, аднак шырокая дастасавальнасць і патэнцыял у іншых сферах былі відавочнымі.
Спрабуючы прадаць патэнцыйным кліентам гэтую тэхналогію, мы сутыкнуліся з нечаканай перашкодай. У дэманстрацыйным відэа нашая тэхналогія выглядала і працавала выдатна, тут ніякіх праблем. Відэа паказвала менавіта тое, як яно працуе, і ў ім нічога не імітавалася. Мы прыдумалі і закадзіравалі рэалістычны сцэнар прымянення праграмы.
Насамрэч гэта і стала праблемай. Наша дэма працавала менавіта так, як імітавалі працу сваіх прыкладанняў усе астатнія. Калі канкрэтна, то інфармацыя імгненна перадавалася ад А да Б, нават калі гэта вялікія мэдыяфайлы. Пасля ўваходу ў сістэму кожны карыстач бачыў новыя запісы. Пры дапамозе прыкладання розныя карыстачы маглі сумесна працаваць выразна над аднымі і тымі ж праектамі, нават у выпадку перарывістага Інтэрнэт-падлучэння дзе-небудзь у вёсцы. У няяўнай форме падобнае маецца на ўвазе ў любым нарэзаным у After Effects відэа аб прадукце.
Нягледзячы на тое, што ўсё ведалі, для чаго патрэбна кнопка Refresh, ніхто зусім не разумеў, што вэб-прыкладанні, якія яны просяць нас ствараць, звычайна схільныя сваім абмежаванням. І што калі яны больш не спатрэбяцца, то досвед карыстача будзе зусім іншым. У асноўным яны заўважалі, што можна "чаціцца", пакідаючы суразмоўцам нататкі, таму задаваліся пытаннем, чым гэта адрозніваецца, напрыклад ад Slack. Ух-ф-ф!
Дызайн паўсядзённых сінхранізацый
Калі ў вас ужо ёсць досвед распрацоўкі ПА, то вам павінна дзейнічаць на нервы неабходнасць памятаць, што большасць людзей не можа проста зірнуць на малюнак інтэрфейсу і зразумець, што ён будзе рабіць пры ўзаемадзеянні з ім. Не кажучы ўжо пра тое, што адбываецца ўнутры самой праграмы. Веды аб тым, што можа адбыцца - шмат у чым вынік ведаў таго, што не можа адбыцца і што не павінна адбывацца. Для гэтага патрабуецца не толькі таго, што робіць ПЗ, але і таго, як узгоднены і маюць зносіны паміж сабой асобныя яго часткі.
Класічным прыкладам гэтага з'яўляецца карыстач, на працягу дваццаці хвілін які глядзіць на spinner.gif, варожачы, калі ж нарэшце завершыцца праца. Распрацоўнік бы зразумеў, што працэс, верагодна, завіс, і што gif ніколі не знікне з экрана. Гэта анімацыя імітуе выкананне працы, але не злучана з яе станам. У падобных выпадках некаторыя тэхнары кахаюць закочваць вочы, дзівячыся ступені памылкі карыстачоў. Аднак заўважце, хто з іх паказвае на якія верцяцца гадзіны і кажа, што яны насамрэч стаяць нерухома?
У гэтым і заключаецца сутнасць каштоўнасці рэальнага часу. У нашы дні базы дадзеных рэальнага часу па-ранейшаму выкарыстоўваюцца вельмі мала, і многія ставяцца да іх з падазрэннем. Большасць такіх баз дадзеных актыўна схіляецца да стылю NoSQL, з-за чаго звычайна выкарыстоўваюць рашэнні на аснове Mongo, пра якія лепш забыцца. Аднак для мяне гэта азначае камфорт працы з CouchDB, а таксама вывучэнне праектавання структур, якія будзе здольны запаўняць дадзенымі не толькі які-небудзь чыноўнік. Думаю, што я марную свой час аптымальней.
Але сапраўдная тэма гэтай пасады - тое, што я выкарыстоўваю сёння. Не па свайму выбару, а з-за абыякава і слепа прымяняецца карпаратыўнай палітыкі. Таму я прывяду Цалкам Сумленнае і Бесстаронняе параўнанне двух цесна звязаных прадуктаў для працы з базамі дадзеных рэальнага часу Google.
У назвах абодвух ёсць слова Fire. Адно я ўспамінаю з пяшчотай. Другое для мяне - іншы выгляд агню. Я не спяшаюся казаць іх назвы, таму што як толькі я гэта зраблю, мы сутыкнемся з першай вялікай праблемай - імёнамі.
Першы называецца Firebase Real-Time Database, а другі - Firebase Cloud Firestore. Абодва яны з'яўляюцца прадуктамі з Firebase suite Google. Іх API называюцца, адпаведна, firebase.database(…) и firebase.firestore(…).
Так атрымалася таму, што Real-Time Database - гэта проста зыходны Firebase да яго пакупкі Google у 2014 годзе. Затым у Google вырашылі ў якасці раўналежнага прадукта стварыць копію Firebase на аснове big data кампаніі і назвалі яе Firestore with a cloud. Спадзяюся, вы яшчэ не заблыталіся. Калі ўсё-такі заблыталіся, не хвалюйцеся, я сам перапісваў гэтую частку артыкула дзесяць разоў.
Таму што трэба ўказваць Firebase у пытанні аб Firebase, і Вогнішча у пытанні аб Firebase, прынамсі, каб вас зразумелі некалькі гадоў назад на Stack Overflow.
Калі б існавала ўзнагарода за самы горшы нэймінг праграмных прадуктаў, то гэты выпадак стаў бы адным з прэтэндэнтаў. Адлегласць Хэмінга паміж гэтымі назвамі настолькі мала, што заблытвае нават дасведчаных інжынераў, чые пальцы друкуюць адну назву, хоць галава думае пра іншае. Гэта з трэскам праваленыя планы, прыдуманыя з самымі добрымі намерамі; яны выканалі прароцтва аб тым, што база дадзеных будзе ў агні. І я ані не жартую. Чалавек, які прыдумаў такую схему найменняў, стаў прычынай крыві, поту і слёз.
Пірава перамога
Можна было б падумаць, што Firestore – гэта замена Firebase, яго нашчадак наступнага пакалення, але гэта было б памылкай. Firestore гарантавана не падыходзіць на ролю замены Firebase. Падобна, хтосьці выразаў з яго ўсё цікавае, а большую частку таго, хто застаўся, заблытаў рознымі спосабамі.
Аднак збеглы погляд на два прадукта можа збіць вас з панталыку: здаецца, што яны робяць адно і тое ж, праз у асноўным аднолькавыя API і нават у адной і той жа сесіі баз дадзеных. Адрозненні малапрыкметныя і выяўляюцца толькі пры дбайным параўнальным вывучэнні вялізнай дакументацыі. Або калі спрабуеш партаваць ідэальна які працуе на Firebase код, каб ён працаваў з Firestore. Ужо тады ты высвятляеш, што інтэрфейс базы дадзеных загараецца, як толькі спрабуеш выканаць перацягванне мышшу ў рэальным часе. Паўтаруся, я не жартую.
Кліент Firebase ветлівы ў тым сэнсе, што ён буферызуе змены і выконвае аўтаматычны паўтор спроб абнаўлення, пры якіх прыярытэт аддаецца апошняй аперацыі запісу. Аднак Firestore мае абмежаванне ў 1 аперацыю запісу на дакумент на карыстальніка ў секунду, і гэтае абмежаванне накладаецца серверам. Пры працы з ім вы самі павінны знайсці спосаб абыйсці яго і рэалізаваць абмежавальнік частаты абнаўленняў, нават калі вы проста спрабуеце стварыць сваё прыкладанне. Гэта значыць Firestore - гэта база дадзеных рэальнага часу без кліента рэальнага часу, якая маскіруецца пад яго з дапамогай API.
На гэтым мы пачынаем бачыць першыя прыкметы сэнсу існавання Firestore. Магчыма, я памыляюся, але падазраю, што хтосьці высока ў кіраўніцтве Google паглядзеў пасля пакупкі на Firebase і проста сказаў: «Не, божа мой, не. Гэта непрымальна. Толькі не пад маім кіраўніцтвам».
Ён зьявіўся са сваіх пакояў і абвясьціў:
«Адзін вялікі дакумент JSON? Не. Вы падзеліце дадзеныя на асобныя дакументы, кожны з якіх будзе памерам не больш за 1 мегабайт».
Падобна, што такое абмежаванне не перажыве першага сутыкнення з любой дастаткова матываванай базай карыстальнікаў. Вы ведаеце, што гэта так. У нас на працы, напрыклад, ёсць паўтары з лішнім тысяч прэзентацый, і гэта Абсалютна Нармальна.
Пры такім абмежаванні вы будзеце змушаныя змірыцца з тым фактам, што адзін "дакумент" у базе дадзеных не будзе падобны ні на адзін аб'ект, які карыстач мог бы назваць дакументам.
«Масіўы масіваў, якія могуць рэкурсіўна змяшчаць іншыя элементы? Не. Масівы будуць утрымоўваць толькі аб'екты ці лікі фіксаванай даўжыні, як задумана Госпадам».
Таму калі вы спадзяваліся змясціць у сваю Firestore GeoJSON, то выявіце, што гэта немагчыма. Недапушчальна нічога неаднамернага. Спадзяюся, вы любіце Base64 і/або JSON ўнутры JSON.
«Імпарт і экспарт JSON па HTTP, інструменты каманднага радка ці панэль адміністратара? Не. Вы зможаце толькі экспартаваць і імпартаваць дадзеныя ў Google Cloud Storage. Так, здаецца, яно зараз называецца. І калі я кажу „вы“, то звяртаюся толькі да тых, хто мае паўнамоцтвы Project Owner. Усе астатнія могуць пайсці і стварыць цікеты.»
Як бачыце, мадэль дадзеных FireBase апісаць лёгка. Яна змяшчае адзін вялізны дакумент JSON, які злучае ключы JSON са шляхамі URL. Калі вы запішаце пры дапамозе 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 рэальнага часу, які абстрагуе websockets, аўтарызацыю і падпіскі. Панэль адміністратара мае абедзве магчымасці, дазваляючы і выконваць рэдагаванне ў рэальным часе, і імпарт/экспарт JSON. Калі ў сваім кодзе вы будзеце прытрымлівацца таго ж, то здзівіцеся, які аб'ём спецыялізаванага кода знікне, калі вы зразумееце, што patch і diff JSON дазваляюць вырашыць 90% руцінных задач па апрацоўцы сталага стану.
Мадэль дадзеных Firestore падобная на JSON, але адрозніваецца ад яго ў некаторых крытычна важных аспектах. Я ўжо згадваў адсутнасць масіваў усярэдзіне масіваў. Мадэль sub-collections складаецца ў тым, каб яны былі канцэпцыямі першага класа, асобнымі ад які змяшчае іх дакумента JSON. Паколькі для гэтага не існуе гатовай серыялізацыі, для атрымання і запісы дадзеных патрабуецца спецыялізаваны шлях выканання кода. Для апрацоўкі ўласных калекцый неабходна пісаць свае скрыпты і прылады. Панэль адміністратара дазваляе вам уносіць толькі невялікія змены па адным полі за раз, і не мае магчымасцяў імпарту/экспарту.
Яны ўзялі базу дадзеных NoSQL рэальнага часу і ператварылі яе ў павольную не-SQL з аўтааб'яднаннем і асобным слупком не-JSON. Нешта ў духу GraftQL.
Гарачы Java
Калі Firestore павінен быў стаць больш надзейным і які маштабуецца, то іронія ў тым, што сярэднестатыстычны распрацоўнік атрымае меней надзейнае рашэнне, чым пры выбары FireBase «са скрынкі». Тое ПЗ, якое неабходна Бурчліваму Адміністратару Базы Дадзеных, патрабуе такога ўзроўню намаганняў і калібру спецыялістаў, што гэта проста нерэалістычна для нішы, у якой, як мяркуецца, павінен быць добры прадукт. Гэта падобна на тое, як HTML5 Canvas зусім не з'яўляецца заменай Flash, калі няма прылад распрацоўкі і прайгравальніка. Больш за тое, Firestore загразла ў імкненні да чысціні дадзеных і стэрыльнай валідацыі, што проста не адпавядае таму, як сярэдні бізнэс-карыстач любіць працаваць: для яго ўсё неабавязкова, таму што да самага канца ўсё з'яўляецца чарнавіком.
Асноўны недахоп FireBase у тым, што кліент быў створаны на некалькі гадоў раней за свой тэрмін, яшчэ да таго, як большасць вэб-распрацоўшчыкаў даведалася аб імутабельнасці. З-за гэтага FireBase мяркуе, што вы будзеце змяняць дадзеныя, а таму не выкарыстоўвае перавагі якая забяспечваецца карыстачом імутабельнасці. Акрамя таго, ён не выкарыстоўвае дадзеныя паўторна ў перадаюцца карыстачу снэпшотах, з-за чаго выконваць diff нашмат складаней. Для буйных дакументаў яго механізм транзакцый на аснове змяняных diff проста неадэкватны. Рабяты, у нас бо ўжо ёсць WeakMap у JavaScript. Гэта зручна.
Калі надаць дадзеным патрэбную форму, і не рабіць дрэвы занадта аб'ёмнымі, то гэтую праблему можна абыйсці. Але мне цікава, стаў бы FireBase значна цікавей, калі б распрацоўнікі выпусцілі па-сапраўднаму добры кліенцкі API, які выкарыстоўвае імутабельнасць у спалучэнні з сур'ёзнай практычнай радай па структуры баз дадзеных. Замест гэтага яны, падобна, паспрабавалі паправіць тое, што не зламана, і ад гэтага стала горш.
Я не ведаю ўсёй логікі, якая ляжала ў аснове стварэння Firestore. Развагі аб матывах, якія ўзнікаюць усярэдзіне чорнай скрыні - гэта таксама частка забаўкі. Такое супрацьпастаўленне дзвюх надзвычай падобных, але непараўнальных баз даных сустракаецца даволі рэдка. Як быццам нехта падумаў: «Firebase – гэта проста функцыя, якую мы можам эмуляваць у Google Cloud», але пры гэтым яшчэ не адкрыў для сябе канцэпцыю вызначэння патрабаванняў рэальнага свету або стварэння карысных рашэнняў, якія задавальняюць усім гэтым патрабаванням. «Няхай пра гэта думаюць распрацоўшчыкі. Проста зрабіце UI прыгожым… А можна дадаць больш агню?
Я разумею пару рэчаў аб структурах дадзеных. Я сапраўды бачу, што канцэпцыя "ўсё ў адным вялікім дрэве JSON" - гэта спроба абстрагаваць з базы дадзеных любое адчуванне буйнамаштабнай структуры. Чакаць, што ПЗ проста зладзіцца з любым сумнеўным фрактал структуры структуры дадзеных - гэта проста вар'яцтва. Мне не трэба нават уяўляць, наколькі дрэнна ўсё можа быць, я праводзіў цвёрдыя аўдыты кода і бачыў такое, што вам, людзям, і не снілася. Але я таксама ведаю, як выглядаюць добрыя структуры, и . Я магу ўявіць свет, у якім Firestore здавалася б цалкам лагічнай, а якія стварылі яе людзі лічылі б, што прарабілі добрую працу. Але мы жывем не ў гэтым свеце.
Падтрымка пабудовы запытаў у FireBase дрэнная па любых стандартах, яе практычна не існуе. Яна вызначана патрабуе паляпшэння ці хаця б перагляду. Але Firestore ненашмат лепш, паколькі яна абмежавана тымі ж аднамернымі азначнікамі, якія ёсць у просты SQL. Калі вам патрэбныя запыты, якія людзі выконваюць з хаатычнымі дадзенымі, тое патрабуецца паўнатэкставы пошук, фільтры на некалькі дыяпазонаў і адвольны які задаецца карыстачом парадак. Пры ўважлівым вывучэнні функцыі простага SQL самі па сабе занадта абмежаваны. Акрамя таго, адзіныя SQL-запыты, якія людзі могуць выконваць у прадакшэне - гэта хуткія запыты. Вам спатрэбіцца спецыялізаванае рашэнне для індэксавання з прадуманымі структурамі даных. Для ўсяго астатняга, прынамсі, павінна быць інкрыментнае map-reduce ці нешта падобнае.
Калі вы пашукайце інфармацыю аб гэтым у дакументах Google, то вам, спадзяюся, пакажуць у напрамку чагосьці тыпу BigTable і BigQuery. Аднак усе гэтыя рашэнні суправаджаюцца такім аб'ёмам густога жаргону карпаратыўных продажаў, што вы хутка вернецеся назад і пачнеце шукаць нешта іншае.
Апошняе, што вам трэба ў выпадку базы дадзеных рэальнага часу - гэта нешта створанае людзьмі і для людзей, якія працуюць па шкале акладаў для кіраўніцтва.
(*) Гэта жарт, няма такога паняцця, як .
На правах рэкламы
Падшукваеце для адладкі праектаў, сервер для распрацоўкі і размяшчэнні? Вы сапраўды наш кліент 🙂 Посуточная тарыфікацыя сервераў самых розных канфігурацый, антыDDoS і ліцэнзіі Windows ужо ўключаны ў кошт.
Крыніца: habr.com