Тази база данни гори...

Нека разкажа една техническа история.

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

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


Всъщност това се превърна в проблема. Нашата демонстрация работи точно по начина, по който всички останали симулираха своите приложения. По-конкретно, информацията беше незабавно прехвърлена от А към Б, дори ако бяха големи медийни файлове. След като влезе, всеки потребител видя нови записи. Използвайки приложението, различни потребители могат да работят заедно ясно по едни и същи проекти, дори ако интернет връзката е прекъсната някъде в селото. Това имплицитно се подразбира във всяко продуктово изрязване на видеоклипове в After Effects.

Въпреки че всички знаеха за какво служи бутонът Refresh, никой наистина не разбра, че уеб приложенията, които ни помолиха да създадем, обикновено са предмет на техните собствени ограничения. И че ако вече не са необходими, потребителското изживяване ще бъде напълно различно. Най-вече забелязаха, че могат да „чатят“, като оставят бележки за хората, с които разговарят, така че се чудеха как това е различно от, например, Slack. уф!

Дизайн на ежедневни синхронизации

Ако имате опит в разработката на софтуер, трябва да ви е нервно да запомните, че повечето хора не могат просто да погледнат снимка на интерфейс и да разберат какво ще прави, когато взаимодействат с него. Да не говорим какво се случва вътре в самата програма. Знанието, че мога случи до голяма степен е резултат от знанието какво не може да се случи и какво не трябва да се случва. Това изисква ментален модел не само какво прави софтуерът, но и как отделните му части са координирани и комуникират помежду си.

Класически пример за това е потребител, който се взира в a spinner.gif, чудейки се кога най-накрая работата ще бъде завършена. Разработчикът щеше да разбере, че процесът вероятно е блокирал и че gif никога няма да изчезне от екрана. Тази анимация симулира изпълнението на задача, но не е свързана с нейното състояние. В такива случаи някои техници обичат да въртят очи, изумени от степента на объркване на потребителите. Забележете обаче колко от тях сочат към въртящия се часовник и казват, че той всъщност е неподвижен?

Това е същността на стойността в реално време. В наши дни базите данни в реално време все още се използват много малко и много хора ги гледат с подозрение. Повечето от тези бази данни клонят силно към стила NoSQL, поради което обикновено използват базирани на Mongo решения, които е най-добре да забравите. За мен обаче това означава да се чувствам комфортно да работя с CouchDB, както и да се науча да проектирам структури, които не само някой бюрократ може да запълни с данни. Мисля, че използвам времето си по-добре.

Но истинската тема на тази публикация е това, което използвам днес. Не по избор, а заради безразлично и сляпо прилагана корпоративна политика. Така че ще предоставя напълно справедливо и безпристрастно сравнение на два тясно свързани продукта на Google за бази данни в реално време.

И двете имат думата Fire в имената си. Едно нещо си спомням с умиление. Второто нещо за мен е различен тип огън. Не бързам да казвам имената им, защото щом го направя, ще се натъкнем на първия голям проблем: имената.

Първият се нарича 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 и дори в една и съща сесия на база данни. Разликите са фини и се разкриват само чрез внимателно сравнително проучване на обширна документация. Или когато се опитвате да пренесете код, който работи перфектно на Firebase, така че да работи с Firestore. Дори тогава установявате, че интерфейсът на базата данни светва веднага щом опитате да плъзнете и пуснете с мишката в реално време. Повтарям, не се шегувам.

Клиентът на Firebase е учтив в смисъл, че буферира промените и автоматично опитва повторно актуализации, които дават приоритет на последната операция за запис. Firestore обаче има ограничение от 1 операция за запис на документ на потребител в секунда и това ограничение се налага от сървъра. Когато работите с него, от вас зависи да намерите начин да го заобиколите и да приложите ограничител на скоростта на актуализиране, дори когато просто се опитвате да създадете вашето приложение. Тоест Firestore е база данни в реално време без клиент в реално време, който се маскира като такъв, използващ API.

Тук започваме да виждаме първите признаци на raison d'être на 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.

Гореща Java

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

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

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

Не знам цялата логика зад създаването на Firestore. Спекулирането относно мотивите, които възникват в черната кутия, също е част от забавлението. Това съпоставяне на две изключително сходни, но несравними бази данни е доста рядко. Сякаш някой си помисли: „Firebase е просто функция, която можем да емулираме в Google Cloud“, но все още не е открил концепцията за идентифициране на изискванията в реалния свят или създаване на полезни решения, които отговарят на всички тези изисквания. „Нека разработчиците помислят за това. Просто направете потребителския интерфейс красив... Можете ли да добавите още огън?“

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

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

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

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

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

Относно правата на рекламата

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

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