Ова база података је у пламену...

Дозволите ми да испричам техничку причу.

Пре много година, развијао сам апликацију са уграђеним функцијама за сарадњу. Био је то експериментални стек прилагођен кориснику који је искористио пуни потенцијал раних Реацт-а и ЦоуцхДБ-а. Синхронизовао је податке у реалном времену преко ЈСОН-а OT. Коришћен је интерно у компанији, али је била јасна његова широка примена и потенцијал у другим областима.

Покушавајући да ову технологију продамо потенцијалним клијентима, наишли смо на неочекивану препреку. У демо видеу, наша технологија је изгледала и радила одлично, ту није било проблема. Видео је тачно показао како то функционише и ништа није имитирао. Осмислили смо и кодирали реалистичан сценарио за коришћење програма.


У ствари, ово је постао проблем. Наш демо је функционисао тачно онако како су сви остали симулирали своје апликације. Конкретно, информације су тренутно пренете од А до Б, чак и ако су то биле велике медијске датотеке. Након пријављивања, сваки корисник је видео нове уносе. Користећи апликацију, различити корисници су могли јасно да раде заједно на истим пројектима, чак и ако је интернет веза прекинута негде у селу. Ово се имплицитно подразумева у било ком видео снимку производа исеченом у Афтер Еффецтс.

Иако су сви знали чему служи дугме за освежавање, нико није разумео да су веб апликације које су тражили од нас да направимо обично подложне њиховим ограничењима. И да ће, ако више не буду потребни, корисничко искуство бити потпуно другачије. Углавном су приметили да могу да „ћаскају” остављајући белешке људима са којима разговарају, па су се питали како се то разликује од, на пример, Слацк-а. Фуј!

Дизајн свакодневних синхронизација

Ако имате искуства у развоју софтвера, мора да је узнемирујуће сетити се да већина људи не може само да погледа слику интерфејса и разуме шта ће он радити када буде у интеракцији са њим. Да не спомињем шта се дешава унутар самог програма. Знање о томе моћи десити је у великој мери резултат сазнања шта се не може догодити, а шта не би требало да се деси. Ово захтева ментални модел не само шта софтвер ради, већ и како су његови појединачни делови координисани и међусобно комуницирају.

Класичан пример овога је корисник који буљи у а спиннер.гиф, питајући се када ће посао коначно бити завршен. Програмер би схватио да је процес вероватно заглављен и да гиф никада неће нестати са екрана. Ова анимација симулира извршење посла, али није повезана са његовим стањем. У таквим случајевима, неки техничари воле да преврћу очима, задивљени степеном збуњености корисника. Међутим, приметите колико њих показује на ротирајући сат и каже да он заправо мирује?

Ово је суштина вредности у реалном времену. Данас се базе података у реалном времену још увек веома мало користе и многи их гледају са сумњом. Већина ових база података се у великој мери ослања на НоСКЛ стил, због чега обично користе решења заснована на Монго, која се најбоље забораве. Међутим, за мене ово значи да се осећам удобно у раду са ЦоуцхДБ-ом, као и да научим да дизајнирам структуре које више од обичног бирократа може да испуни подацима. Мислим да боље користим своје време.

Али права тема овог поста је оно што данас користим. Не по избору, већ због индиферентно и слепо примењене корпоративне политике. Зато ћу дати потпуно поштено и непристрасно поређење два блиско повезана Гоогле производа базе података у реалном времену.

И једни и други имају реч Ватра у свом имену. Једне ствари се радо сећам. Друга ствар за мене је другачија врста ватре. Не журим да кажем њихова имена, јер када то учиним, наићи ћемо на први велики проблем: имена.

Први се зове Фиребасе база података у реалном времену, и друго - Фиребасе Цлоуд Фиресторе. Оба су производи из Фиребасе апартман Гоогле. Њихови АПИ-ји се позивају респективно firebase.database(…) и firebase.firestore(…).

Ово се десило јер База података у реалном времену - то је само оригинал Фиребасе пре него што га је Гоогле купио 2014. Тада је Гоогле одлучио да направи паралелни производ копија Фиребасе је заснован на компанији за велике податке и назвао га Фиресторе са облаком. Надам се да се још нисте збунили. Ако сте још увек збуњени, не брините, ја сам лично преписао овај део чланка десет пута.

Зато што треба да назначите Фиребасе у Фиребасе питању, и Фиресторе у питању о Фиребасе-у, барем да бисте разумели пре неколико година на Стацк Оверфлов-у.

Да постоји награда за најгоре искуство именовања софтвера, ово би дефинитивно био један од кандидата. Хемингово растојање између ових имена је толико мало да збуњује чак и искусне инжењере чији прсти куцају једно име док главама размишљају о другом. Ово су добронамерни планови који несрећно пропадају; испунили су пророчанство да ће база података бити у пламену. И уопште се не шалим. Особа која је смислила ову шему именовања изазвала је крв, зној и сузе.

Пирова победа

Човек би помислио да је Фиресторе замена Фиребасе, његов потомак следеће генерације, али то би било погрешно. Није гарантовано да ће Фиресторе бити одговарајућа замена за Фиребасе. Изгледа да је неко из њега исекао све занимљиво, а већину осталог збунио на разне начине.

Међутим, брз поглед на ова два производа може да вас збуни: чини се да раде исту ствар, преко у основи истих АПИ-ја, па чак и у истој сесији базе података. Разлике су суптилне и откривају се само пажљивим упоредним проучавањем обимне документације. Или када покушавате да пренесете код који савршено функционише на Фиребасе-у тако да ради са Фиресторе-ом. Чак и тада сазнате да се интерфејс базе података упали чим покушате да превучете и испустите мишем у реалном времену. Понављам, не шалим се.

Фиребасе клијент је љубазан у смислу да баферује промене и аутоматски поново покушава ажурирања која дају приоритет последњој операцији писања. Међутим, Фиресторе има ограничење од 1 операције писања по документу по кориснику у секунди, а ово ограничење примењује сервер. Када радите са њим, на вама је да пронађете начин да га заобиђете и примените ограничавач брзине ажурирања, чак и када само покушавате да направите своју апликацију. То јест, Фиресторе је база података у реалном времену без клијента у реалном времену, који се маскира као један користећи АПИ.

Овде почињемо да видимо прве знаке разлога постојања Фиресторе-а. Можда грешим, али сумњам да је неко високо у Гоогле-овом менаџменту погледао Фиребасе након куповине и једноставно рекао: „Не, о мој Боже, не. Ово је неприхватљиво. Само не под мојим вођством."

Појавио се из својих одаја и изјавио:

„Један велики ЈСОН документ? Не. Податке ћете поделити у засебне документе, од којих сваки неће бити већи од 1 мегабајта.”

Чини се да такво ограничење неће преживети први сусрет са било којом довољно мотивисаном корисничком базом. Знате да јесте. На послу, на пример, имамо више од хиљаду и по презентација, а ово је потпуно нормално.

Уз ово ограничење, бићете приморани да прихватите чињеницу да један „документ“ у бази података неће личити на ниједан објекат који би корисник могао назвати документом.

„Низови низова који могу рекурзивно да садрже друге елементе? Не. Низови ће садржати само објекте или бројеве фиксне дужине, како је Бог замислио."

Дакле, ако сте се надали да ставите ГеоЈСОН у свој Фиресторе, открићете да то није могуће. Ништа што није једнодимензионално није прихватљиво. Надам се да вам се свиђа Басе64 и/или ЈСОН унутар ЈСОН-а.

„ЈСОН увоз и извоз преко ХТТП-а, алата командне линије или административног панела? Не. Моћи ћете да извозите и увозите податке само у Гоогле Цлоуд Стораге. Тако се то сада зове, мислим. А када кажем „ви“, обраћам се само онима који имају акредитиве власника пројекта. Сви остали могу да оду и креирају карте."

Као што видите, ФиреБасе модел података је лако описати. Садржи један огроман ЈСОН документ који повезује ЈСОН кључеве са УРЛ путањама. Ако пишете са HTTP PUT в / ФиреБасе је следећи:

{
  "hello": "world"
}

Тхе GET /hello ће се вратити "world". У основи ради тачно онако како бисте очекивали. Колекција ФиреБасе објеката /my-collection/:id еквивалентно ЈСОН речнику {"my-collection": {...}} у корену чији је садржај доступан у /my-collection:

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

Ово добро функционише ако сваки уметак има ИД без судара, за који систем има стандардно решење.

Другим речима, база података је 100% ЈСОН(*) компатибилна и одлично ради са ХТТП-ом, као што је ЦоуцхДБ. Али у основи га користите преко АПИ-ја у реалном времену који апстрахује веб-соцкете, ауторизацију и претплате. Административни панел има обе могућности, омогућавајући и уређивање у реалном времену и ЈСОН увоз/извоз. Ако урадите исто у свом коду, бићете изненађени колико ће специјализованог кода бити потрошено када схватите да ЈСОН закрпе и разлике решавају 90% рутинских задатака руковања сталним стањем.

Модел података Фиресторе је сличан ЈСОН-у, али се разликује на неке критичне начине. Већ сам поменуо недостатак низова унутар низова. Модел за подколекције је да буду првокласни концепти, одвојени од ЈСОН документа који их садржи. Пошто за ово не постоји готова серијализација, потребна је специјализована путања кода за преузимање и писање података. Да бисте обрађивали сопствене колекције, потребно је да напишете сопствене скрипте и алате. Административни панел вам омогућава да уносите мале измене само једно по једно поље и нема могућности увоза/извоза.

Узели су НоСКЛ базу података у реалном времену и претворили је у спору не-СКЛ базу података са аутоматским придруживањем и засебном колоном која није ЈСОН. Нешто као ГрафтКЛ.

Хот Јава

Ако је Фиресторе требало да буде поузданији и скалабилнији, онда је иронија у томе што ће просечан програмер на крају имати мање поуздано решење од одабира ФиреБасе-а из кутије. Врста софтвера која је потребна Мрзовољном администратору базе података захтева ниво труда и калибар талента који је једноставно нереалан за нишу у којој би производ требало да буде добар. Ово је слично томе како ХТМЛ5 Цанвас уопште није замена за Фласх ако нема развојних алата и плејера. Штавише, Фиресторе је заробљен у жељи за чистоћом података и стерилном валидацијом која једноставно није у складу са начином на који просечни пословни корисник воли да ради: за њега је све опционо, јер је до самог краја све нацрт.

Главни недостатак ФиреБасе-а је тај што је клијент креиран неколико година пре свог времена, пре него што је већина веб програмера знала за непроменљивост. Због тога, ФиреБасе претпоставља да ћете променити податке и стога не користи предности непроменљивости коју обезбеђује корисник. Поред тога, не користи поново податке у снимцима које прослеђује кориснику, што чини разлику много тежим. За велике документе, његов променљиви механизам трансакције заснован на дифф је једноставно неадекватан. Момци, већ имамо WeakMap у ЈаваСцрипт-у. То је удобно.

Ако подацима дате жељени облик и не учините стабла превише обимним, онда се овај проблем може заобићи. Али радознао сам да ли би ФиреБасе био много интересантнији да су програмери објавили заиста добар клијентски АПИ који је користио непроменљивост у комбинацији са неким озбиљним практичним саветима о дизајну базе података. Уместо тога, чинило се да покушавају да поправе оно што није покварено, а то је погоршало ситуацију.

Не знам сву логику иза стварања Фиресторе-а. Нагађање о мотивима који се појављују унутар црне кутије такође је део забаве. Ова јукстапозиција две изузетно сличне, али неупоредиве базе података је прилично ретка. Као да је неко помислио: „Фиребасе је само функција коју можемо да опонашамо у Гоогле Цлоуд-у“, али још увек није открио концепт идентификовања захтева из стварног света или креирања корисних решења која испуњавају све те захтеве. „Нека програмери размисле о томе. Само учините кориснички интерфејс лепим... Можете ли додати још ватре?“

Разумем пар ствари о структурама података. Дефинитивно видим концепт „све у једном великом ЈСОН стаблу“ као покушај да се апстрахује било какав осећај структуре великих размера из базе података. Очекивати да се софтвер једноставно носи са било којим сумњивим фракталом структуре података је једноставно сулудо. Не морам ни да замишљам колико лоше ствари могу бити, урадио сам ригорозне ревизије кода и Видео сам ствари о којима ви људи нисте ни сањали. Али такође знам како изгледају добре структуре, како их користити и зашто би то требало да се ради. Могу да замислим свет у коме би Фиресторе изгледао логично, а људи који су га створили би мислили да су урадили добар посао. Али ми не живимо у овом свету.

ФиреБасе-ова подршка за упите је лоша по било ком стандарду и практично не постоји. Дефинитивно је потребно побољшање или бар ревизија. Али Фиресторе није много бољи јер је ограничен на исте једнодимензионалне индексе који се налазе у обичном СКЛ-у. Ако су вам потребни упити које људи покрећу на хаотичним подацима, потребна вам је претрага целог текста, филтери за више опсега и прилагођени кориснички дефинисани редослед. Након детаљнијег прегледа, функције обичног СКЛ-а су саме по себи превише ограничене. Поред тога, једини СКЛ упити који људи могу да извршавају у производњи су брзи упити. Требаће вам прилагођено решење за индексирање са паметним структурама података. За све остало, требало би да постоји барем инкрементално смањење мапе или нешто слично.

Ако тражите информације о овоме у Гоогле документима, надамо се да ћете бити усмерени ка нечему као што су БигТабле и БигКуери. Међутим, сва ова решења су праћена толико густим корпоративним продајним жаргоном да ћете се брзо вратити и почети да тражите нешто друго.

Последња ствар коју желите са базом података у реалном времену је нешто што су направили људи на платној скали менаџмента и за њих.

(*) Ово је шала, не постоји таква ствар 100% ЈСОН компатибилан.

О правима оглашавања

Тражити ВДС за отклањање грешака у пројектима, сервер за развој и хостинг? Ви сте дефинитивно наш клијент 🙂 Дневне цене за сервере различитих конфигурација, анти-ДДоС и Виндовс лиценце су већ укључене у цену.

Извор: ввв.хабр.цом