Дозволете ми да кажам техничка приказна.
Пред многу години, развивав апликација со вградени функции за соработка. Тоа беше експериментален оџак лесен за корисникот што го искористи целосниот потенцијал на раните React и CouchDB. Ги синхронизираше податоците во реално време преку JSON . Се користеше внатрешно во рамките на компанијата, но неговата широка применливост и потенцијал во други области беа јасни.
Додека се обидувавме да ја продадеме оваа технологија на потенцијални клиенти, наидовме на неочекувана пречка. Во демо видеото, нашата технологија изгледаше и работеше одлично, без проблеми. Видеото покажа како точно функционира и не имитира ништо. Смисливме и кодиравме реално сценарио за користење на програмата.
Всушност, ова стана проблем. Нашето демо функционираше токму на начинот на кој сите други ги симулираа своите апликации. Поточно, информациите беа веднаш префрлени од А во Б, дури и ако беа големи медиумски датотеки. Откако се најави, секој корисник виде нови записи. Користејќи ја апликацијата, различни корисници можеа јасно да работат заедно на исти проекти, дури и ако интернет-врската беше прекината некаде во селото. Ова е имплицитно имплицирано во кое било видео за производ исечено во After Effects.
Иако сите знаеја за што служи копчето Освежи, никој навистина не разбра дека веб-апликациите што бараа од нас да ги изградиме обично подлежат на нивните сопствени ограничувања. И дека ако повеќе не се потребни, корисничкото искуство ќе биде сосема поинакво. Тие главно забележале дека можат да „чатат“ оставајќи белешки за луѓето со кои разговараат, па се прашувале како ова се разликува од, на пример, Slack. Пуф!
Дизајн на секојдневни синхронизирања
Ако имате искуство во развој на софтвер, мора да ви ги наруши нервите да запомните дека повеќето луѓе не можат само да гледаат слика на интерфејс и да разберат што ќе направи кога ќе комуницираат со него. Да не зборуваме што се случува внатре во самата програма. Знај го тоа може да се случи во голема мера е резултат на знаењето што не може да се случи, а што не треба да се случи. Ова бара не само што работи софтверот, туку и како неговите поединечни делови се координирани и комуницираат едни со други.
Класичен пример за ова е корисник кој зјапа во a спинер.gif, прашувајќи се кога конечно ќе биде завршена работата. Програмерот би сфатил дека процесот веројатно е заглавен и дека гифот никогаш нема да исчезне од екранот. Оваа анимација симулира извршување на задача, но не е поврзана со нејзината состојба. Во такви случаи, некои техничари сакаат да ги превртуваат очите, изненадени од степенот на конфузија на корисниците. Сепак, забележете колку од нив покажуваат кон ротирачкиот часовник и велат дека тој всушност е неподвижен?
Ова е суштината на вредноста во реално време. Овие денови, базите на податоци во реално време сè уште се многу малку користени и многу луѓе ги гледаат со сомнеж. Повеќето од овие бази на податоци во голема мера се наклонети кон стилот NoSQL, поради што тие обично користат решенија базирани на Монго, кои најдобро се забораваат. Сепак, за мене ова значи да се чувствувам удобно да работам со CouchDB, како и да научам да дизајнирам структури кои повеќе од само некој бирократ може да ги пополни со податоци. Мислам дека подобро го користам времето.
Но, вистинската тема на овој пост е она што јас го користам денес. Не по избор, туку поради рамнодушно и слепо применети корпоративни политики. Така, ќе дадам целосно правична и непристрасна споредба на два тесно поврзани производи на базата на податоци на Google во реално време.
И двете го имаат зборот Оган во нивните имиња. Една работа со задоволство се сеќавам. Втората работа за мене е различен тип на оган. Не брзам да ги кажам нивните имиња, бидејќи штом го кажам, ќе наидеме на првиот голем проблем: имињата.
Првиот се вика Firebase База на податоци во реално време, и второ - Firebase Cloud Firestore. И двете се производи од Firebase пакет Google. Нивните API се нарекуваат соодветно firebase.database(…) и firebase.firestore(…).
Ова се случи затоа што База на податоци во реално време - тоа е само оригиналот Firebase пред неговото купување од Google во 2014 година. Тогаш Google одлучи да креира како паралелен производ копирајте Firebase базирана на компанија за големи податоци и ја нарече Firestore со облак. Се надевам дека сеуште не сте збунети. Ако сè уште сте збунети, не грижете се, јас самиот го препишував овој дел од статијата десет пати.
Затоа што треба да наведете Firebase во прашањето Firebase, и Противпожарна продавница во прашање за Firebase, барем да ве разберат пред неколку години на Stack Overflow.
Ако имаше награда за најлошо искуство за именување на софтвер, ова дефинитивно ќе беше еден од претендентите. Растојанието на Хамин помеѓу овие имиња е толку мало што ги збунува дури и искусните инженери, чии прсти пишуваат едно име додека нивните глави размислуваат за друго. Тоа се добронамерни планови кои мизерно пропаѓаат; тие го исполнија пророштвото дека базата на податоци ќе биде запалена. И воопшто не се шегувам. Лицето кое ја смислило оваа шема за именување предизвикало крв, пот и солзи.
Пирова победа
Некој би помислил дека Firestor е замена Firebase, неговиот потомок од следната генерација, но тоа би било погрешно. Не се гарантира дека Firestore ќе биде соодветна замена за Firebase. Изгледа некој отсекол сè интересно од него, а повеќето останати ги збунил на различни начини.
Сепак, брз поглед на двата производи може да ве збуни: се чини дека тие го прават истото, во основа на истите API, па дури и во истата сесија на база на податоци. Разликите се суптилни и се откриваат само со внимателна компаративна студија на обемна документација. Или кога се обидувате да пренесете код кој функционира совршено на Firebase за да работи со Firestore. Дури и тогаш ќе дознаете дека интерфејсот на базата на податоци се пали веднаш штом ќе се обидете да влечете и пуштите со глувчето во реално време. Повторувам, не се шегувам.
Клиентот на Firebase е љубезен во смисла дека ги тампонира промените и автоматски ги повторува ажурирањата што даваат приоритет на последната операција за запишување. Сепак, Firestore има ограничување од 1 операција за пишување по документ по корисник во секунда, и ова ограничување го спроведува серверот. Кога работите со него, од вас зависи да најдете начин да го заобиколите и да имплементирате ограничувач на брзината на ажурирање, дури и кога само се обидувате да ја изградите вашата апликација. Односно, Firestore е база на податоци во реално време без клиент во реално време, кој се маскира како таков што користи API.
Овде почнуваме да ги гледаме првите знаци на причината за постоењето на Firestore. Можеби грешам, но се сомневам дека некој од високото раководство на Google погледнал во Firebase по купувањето и едноставно рекол: „Не, о Боже, не. Ова е неприфатливо. Само не под мое водство“.
Тој се појави од своите одаи и изјави:
„Еден голем JSON документ? бр. Ќе ги поделите податоците во посебни документи, од кои секој нема да биде со големина од не повеќе од 1 мегабајт“.
Се чини дека таквото ограничување нема да ја преживее првата средба со која било доволно мотивирана корисничка база. Знаеш дека е. На работа, на пример, имаме повеќе од илјада и пол презентации, и ова е сосема нормално.
Со ова ограничување, ќе бидете принудени да го прифатите фактот дека еден „документ“ во базата на податоци нема да личи на ниту еден објект што корисникот може да го нарече документ.
„Низи од низи кои можат рекурзивно да содржат други елементи? бр. Низите ќе содржат само објекти или броеви со фиксна должина, како што сакал Бог“.
Значи, ако се надевавте дека ќе го ставите GeoJSON во вашиот Firestore, ќе откриете дека тоа не е можно. Ништо нееднодимензионално не е прифатливо. Се надевам дека ви се допаѓа Base64 и/или JSON во JSON.
„Увоз и извоз на JSON преку HTTP, алатки за командна линија или административен панел? бр. Ќе може да извезувате и увезувате податоци само во Google Cloud Storage. Така се вика сега мислам. И кога велам „ти“, им се обраќам само на оние кои имаат ингеренции за сопственик на проектот. Сите други можат да одат и да креираат билети“.
Како што можете да видите, моделот на податоци на 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 во реално време што ги апстрахира веб-сокетите, овластувањата и претплатите. Административниот панел ги има двете можности, овозможувајќи и уредување во реално време и увоз/извоз на JSON. Ако го сторите истото во вашиот код, ќе се изненадите колку специјализиран код ќе се потроши кога ќе сфатите дека закрпата и разликата JSON решава 90% од рутинските задачи за справување со постојана состојба.
Моделот на податоци Firestore е сличен на JSON, но се разликува на некои критични начини. Веќе го спомнав недостатокот на низи во низи. Моделот за подколекциите е тие да бидат концепти од прва класа, одвоени од документот JSON што ги содржи. Бидејќи не постои готова серијализација за ова, потребна е специјализирана патека на кодот за преземање и запишување податоци. За да ги обработите вашите сопствени колекции, треба да напишете свои скрипти и алатки. Административниот панел ви дозволува само да правите мали промени едно поле во исто време и нема можности за увоз/извоз.
Тие зедоа NoSQL база на податоци во реално време и ја претворија во бавна не-SQL со автоматско приклучување и посебна колона што не е JSON. Нешто како GraftQL.
Жешка Јава
Ако Firestore требаше да биде посигурен и поскалабилен, тогаш иронијата е што просечниот програмер ќе заврши со помалку веродостојно решение од изборот на FireBase надвор од кутијата. Видот на софтвер што му е потребен на администраторот на базата на податоци Grumpy бара ниво на напор и калибар на талент што е едноставно нереално за нишата во која производот треба да биде добар. Ова е слично на тоа како HTML5 Canvas воопшто не е замена за Flash ако нема развојни алатки и плеер. Покрај тоа, Firestore е заглавен во желба за чистота на податоците и стерилна валидација што едноставно не се усогласува со тоа како просечниот деловен корисник сака да работи: За него се е по избор, бидејќи до самиот крај се е нацрт.
Главниот недостаток на FireBase е тоа што клиентот е создаден неколку години пред своето време, пред повеќето веб-програмери да знаат за непроменливоста. Поради ова, FireBase претпоставува дека ќе ги промените податоците и затоа не ја користи предноста од непроменливоста обезбедена од корисникот. Дополнително, не ги користи повторно податоците во снимките што му ги пренесува на корисникот, што ги отежнува разликите. За големи документи, неговиот променлив механизам за трансакција базиран на разлики е едноставно несоодветен. Момци, веќе имаме WeakMap во JavaScript. Удобно е.
Ако на податоците им ја дадете посакуваната форма и не ги направите дрвјата премногу обемни, тогаш овој проблем може да се заобиколи. Но, љубопитен сум дали FireBase би бил многу поинтересен доколку програмерите издадат навистина добар клиент API што користи непроменливост во комбинација со некои сериозни практични совети за дизајнот на базата на податоци. Наместо тоа, се чинеше дека се обидуваа да го поправат она што не беше скршено, а тоа го влоши.
Не ја знам целата логика зад создавањето на Firestor. Шпекулирањето за мотивите што се појавуваат во црната кутија е исто така дел од забавата. Оваа спојување на две екстремно слични, но неспоредливи бази на податоци е доста ретка. Тоа е како некој да мислел: „Firebase е само функција што можеме да ја имитираме во Google Cloud“, но сè уште не го открил концептот за идентификување на барањата од реалниот свет или создавање корисни решенија кои ги исполнуваат сите тие барања. „Да размислат за тоа програмерите. Само направете го интерфејсот убав... Можете ли да додадете повеќе оган?“
Разбирам неколку работи за структурите на податоци. Дефинитивно го гледам концептот „сè во едно големо JSON дрво“ како обид да се апстрахира каква било смисла за структура од големи размери од базата на податоци. Да се очекува софтверот едноставно да се справи со кој било сомнителен фрактал на структурата на податоци е едноставно лудо. Не мора ни да замислам колку лоши би можеле да бидат работите, направив ригорозни ревизии на кодови и Видов работи за кои вие луѓе не сте сонувале. Но, знам и како изгледаат добрите структури, и . Можам да замислам свет каде Firestore ќе изгледа логично и луѓето што го создадоа ќе мислат дека завршиле добра работа. Но, ние не живееме на овој свет.
Поддршката за пребарување на FireBase е слаба според кој било стандард и практично не постои. Дефинитивно треба подобрување или барем ревизија. Но, Firestore не е многу подобар бидејќи е ограничен на истите еднодимензионални индекси кои се наоѓаат во обичниот SQL. Ако ви требаат прашања што луѓето ги извршуваат на хаотични податоци, потребно ви е пребарување на целосен текст, филтри со повеќе опсег и прилагодено нарачување дефинирано од корисникот. По поблиска проверка, функциите на обичниот SQL се премногу ограничени сами по себе. Дополнително, единствените SQL прашања што луѓето можат да ги извршат во производството се брзите прашања. Ќе ви треба прилагодено решение за индексирање со внимателни структури на податоци. За се друго барем да има постепено намалување на картата или нешто слично.
Ако пребарувате во Google Docs за информации за ова, се надеваме дека ќе ви биде насочено кон нешто како BigTable и BigQuery. Сепак, сите овие решенија се придружени со толку многу густ корпоративен жаргон за продажба што брзо ќе се вратите назад и ќе почнете да барате нешто друго.
Последното нешто што го сакате со базата на податоци во реално време е нешто направено од и за луѓе на менаџерски платежни скали.
(*) Ова е шега, не постои такво нешто .
За правата на рекламирање
Барате за проекти за дебагирање, сервер за развој и хостирање? Дефинитивно сте наш клиент 🙂 Дневните цени за сервери со различни конфигурации, лиценците за анти-DDoS и Windows се веќе вклучени во цената.
Извор: www.habr.com