Тази база данни е в огън...

Позволете ми да разкажа техническа история.

Пред много години разработвах приложение с вградени функции за съвместна работа. Това беше удобен експериментален стек, в който се използваше пълният потенциал на ранен React и CouchDB. То синхронизираше данни в реално време по JSON. OT. Това приложение беше използвано за вътрешната работа на компанията, но широката приложимост и потенциалът му в други области бяха очевидни.

Опитвайки се да продадем тази технология на потенциални клиенти, се сблъскахме с неочаквана пречка. В демонстрационното видео нашата технология изглеждаше и работеше отлично, тук нямаше проблеми. Видео показваше точно как работи и в него нямаше нищо накарано. Създадохме и кодирахме реалистичен сценарий за използването на програмата.


Всъщност това стана проблем. Нашето демо работеше точно както имитираха работата на приложенията си всички останали. Конкретно, информацията се предаваше мигновено от А до Б, дори ако ставаше въпрос за големи медийни файлове. След като влязоха в системата, всеки потребител виждаше нови записи. С приложението различни потребители можеха да работят съвместно по едни и същи проекти, дори при прекъсваща интернет връзка някъде в селото. Подобно неявно се подразбира в каквото и да е видео за продукт, нарязано в 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 на основата на големи данни на компанията и го нарекоха Firestore with a cloud. Надявам се, че все още не сте се заплели. Ако все пак сте се заплели, не се притеснявайте, самият аз написах тази част от статията десет пъти.

Защото трябва да се посочи Firebase по въпроса за Firebase, и Firestore по въпроса за Firebase, понеже да разберете преди няколко години в Stack Overflow.

Ако имаше награда за най-лошо именуване на софтуерни продукти, този случай определено щеше да бъде един от претендентите. Разстоянието на Хемингу между тези имена е толкова малко, че обърква дори опитни инженери, чиито пръсти пишат едно име, докато умът мисли за друго. Това са планове, които със скърцане се провалиха, измислени с най-добри намерения; те изпълнили пророчеството, че базата данни ще бъде в огън. И не се шегувам. Човекът, измислил такава схема за именуване, стана причина за кръв, пот и сълзи.

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

Може да се помисли, че Firestore е замяна на 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. Така, изглежда, сега се нарича. И когато казвам „вие“, адресирам само тези, които имат правомощия 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, но се различава от него в някои критични аспекти. Вече споменах отсъствието на масиви в масиви. Моделът на подколекции е концепция от първи клас, отделна от съдържащия я JSON документ. Тъй като за това не съществува готова сериализация, за получаване и запис на данни е необходим специализиран код. За обработка на собствените колекции е необходимо да се пишат собствени скриптове и инструменти. Административният панел позволява да се извършват само малки промени по едно поле едновременно и няма възможности за импорт/експорт.

Те взеха база данни NoSQL в реално време и я превърнаха в бавна не-SQL с автоматично обединение и отделна колона не-JSON. Нещо като GraftQL.

Горещ Java

Ако Firestore трябваше да стане по-надежден и мащабируем, иронията е, че средностатистическият разработчик получава по-малко надеждно решение в сравнение с FireBase "извън кутията". Това софтуер, който е нужен на Проблемния Администратор на Базата Данни, изисква такова ниво на усилия и специалисти, което е просто нереалистично за нишата, в която предполагаемо трябва да има добър продукт. Това е подобно на факта, че HTML5 Canvas изобщо не е заместител на Flash, ако няма инструменти за разработка и плейър. Освен това, Firestore е заседнала във стремежа си към чистота на данните и стерилна валидация, което просто не отговаря на начина, по който средният бизнес-потребител обича да работи: за него всичко не е задължително, защото до самия край всичко е чернова.

Основният недостатък на FireBase е, че клиентът е създаден много години преди времето си, още преди повечето уеб разработчици да разберат за имутируемостта. Поради това FireBase предполага, че ще променяте данните и следователно не използва предимствата на осигурената от потребителя имутируемост. Освен това не използва данните повторно в предоставените на потребителя моментни снимки, което прави извършването на диференциране много по-трудно. За големи документи механизмът на транзакции, основан на изменяеми диференци, просто не е адекватен. Хора, ние вече имаме WeakMap в JavaScript. Това е удобно.

Ако придадете на данните необходимата форма и не правите дърветата твърде обемисти, можете да заобиколите този проблем. Но ми е любопитно, би ли станал FireBase много по-интересен, ако разработчиците пуснат наистина добро клиентско API, което използва имутируемост в комбинация с сериозни практически съвети за структурата на бази данни. Вместо това изглежда, че те са се опитали да поправят нещо, което не е счупено, и от това стана по-зле.

Не знам цялата логика, стояща зад създаването на Firestore. Разсъжденията за мотивите, възникващи вътре в черната кутия, също са част от развлечението. Такова противопоставяне на две изключително подобни, но несравними бази данни се среща доста рядко. Все едно някой е помислил: «Firebase е просто функция, която можем да емулираме в Google Cloud», но все пак все още не е открил концепцията за определяне на изисквания от реалния свят или създаване на полезни решения, които да отговорят на всички тези изисквания. «Нека разработчиците да мислят за това. Просто направете UI красив… А може ли да добавим повече огън?»

Разбирам няколко неща за структури от данни. Ясно виждам, че концепцията «всичко в едно голямо JSON дърво» е опит за абстрахиране от базата данни на всякакво усещане за мащабна структура. Да очакваш, че софтуерът просто ще се справи с всякакъв съмнителен фрактал на структура от данни, е просто лудост. Не ми трябва дори да си представям колко зле може да е всичко, провеждал съм стриктни кодови одити и съм виждал неща, за които на вас, хората, и не ви е идвало наум. Но също така знам как изглеждат добрите структури, как да ги използвате и защо трябва да го направите. Мога да си представя свят, в който Firestore би изглеждала напълно логично, а хората, които я създадоха, биха смятали, че са свършили добра работа. Но не живеем в този свят.

Поддръжката за изграждане на заявки в FireBase е слаба по всички стандарти, практически не съществува. Определено изисква подобрение или поне преразглеждане. Но Firestore не е много по-добра, тъй като е ограничена от същите едномерни индекси, които срещаме в проста SQL. Ако имате нужда от заявки, които хората изпълняват с хаотични данни, ще ви е необходим пълнотекстов търсене, филтри за няколко диапазона и произволен ред, зададен от потребителя. При внимателно разглеждане, функциите на простата SQL сами по себе си са твърде ограничени. Освен това единствените SQL заявки, които хората могат да извършват в продукция, са бързи заявки. Ще ви трябва специализирано решение за индексиране с добре обмислени структури от данни. За всичко останало поне трябва да има инкрементално map-reduce или нещо подобно.

Ако потърсите информация за това в документацията на Google, се надявам да ви насочат към нещо като BigTable и BigQuery. Но всички тези решения са придружени от такова количество плътен корпоративен жаргон, че бързо ще се върнете назад и ще започнете да търсите нещо друго.

Последното нещо, от което се нуждаете в случай на база данни в реално време, е нещо, създадено от хора и за хора, работещи на чрез заплатите за ръководство.

(*) Това е шега, няма такова понятие като 100% съвместимост с JSON.

Реклама

Търсите VDS за отстраняване на грешки в проекти, сървър за разработка и хостинг? Вие определено сте нашият клиент 🙂 Заплащане на ден за сървъри с различни конфигурации, антиDDoS и лицензии Windows вече са включени в цената.

Източник: habr.com