Opowiem historię techniczną.
Wiele lat temu tworzyłem aplikację z wbudowanymi funkcjami współpracy. Był to przyjazny dla użytkownika eksperymentalny stos, który wykorzystywał pełny potencjał wczesnego Reacta i CouchDB. Synchronizował dane w czasie rzeczywistym za pośrednictwem JSON . Był on stosowany wewnętrznie w firmie, ale widoczne było jego szerokie zastosowanie i potencjał w innych obszarach.
Próbując sprzedać tę technologię potencjalnym klientom, napotkaliśmy nieoczekiwaną przeszkodę. Na filmie demonstracyjnym nasza technologia wyglądała i działała świetnie, nie było żadnych problemów. Film dokładnie pokazywał jak to działa i niczego nie imitował. Wymyśliliśmy i zakodowaliśmy realistyczny scenariusz wykorzystania programu.
W rzeczywistości to stało się problemem. Nasze demo działało dokładnie tak, jak wszyscy inni symulowali swoje aplikacje. W szczególności informacje były natychmiast przesyłane z punktu A do B, nawet jeśli były to duże pliki multimedialne. Po zalogowaniu każdy użytkownik widział nowe wpisy. Korzystając z aplikacji, różni użytkownicy mogli wyraźnie współpracować nad tymi samymi projektami, nawet jeśli połączenie internetowe zostało przerwane gdzieś w wiosce. Jest to pośrednio sugerowane w każdym filmie produktu wyciętym w programie After Effects.
Chociaż wszyscy wiedzieli, do czego służy przycisk Odśwież, nikt tak naprawdę nie rozumiał, że aplikacje internetowe, o zbudowanie których nas poprosili, zwykle podlegały własnym ograniczeniom. I że jeśli nie będą już potrzebne, doświadczenia użytkownika będą zupełnie inne. Najczęściej zauważyli, że mogą „czatować” zostawiając notatki osobom, z którymi rozmawiają, więc zastanawiali się, czym to się różni od np. Slacka. Uff!
Projekt codziennych synchronizacji
Jeśli masz doświadczenie w tworzeniu oprogramowania, pamiętanie o tym, że większość ludzi nie jest w stanie po prostu spojrzeć na obraz interfejsu i zrozumieć, co zrobi podczas interakcji, musi być stresujące. Nie mówiąc już o tym, co dzieje się wewnątrz samego programu. Wiedza, że może się zdarzyć, jest w dużej mierze wynikiem wiedzy o tym, co nie może się wydarzyć, a co nie powinno się wydarzyć. To wymaga nie tylko to, co oprogramowanie robi, ale także to, jak jego poszczególne części są ze sobą skoordynowane i komunikują się.
Klasycznym tego przykładem jest użytkownik wpatrujący się w spinner.gif, zastanawiając się, kiedy ostatecznie prace zostaną ukończone. Deweloper zdałby sobie sprawę, że proces prawdopodobnie utknął i że gif nigdy nie zniknie z ekranu. Ta animacja symuluje wykonanie zadania, ale nie jest powiązana z jego stanem. W takich przypadkach niektórzy technicy lubią przewracać oczami, zaskoczeni rozmiarem dezorientacji użytkownika. Zauważ jednak, ilu z nich wskazuje na obracający się zegar i twierdzi, że tak naprawdę jest on nieruchomy?
To jest istota wartości w czasie rzeczywistym. Obecnie bazy danych czasu rzeczywistego są nadal bardzo rzadko wykorzystywane i wiele osób podchodzi do nich podejrzliwie. Większość tych baz danych opiera się w dużej mierze na stylu NoSQL, dlatego zwykle korzystają z rozwiązań opartych na Mongo, o których najlepiej zapomnieć. Jednak dla mnie oznacza to oswojenie się z pracą z CouchDB, a także nauczenie się projektowania struktur, które danymi może wypełnić więcej niż tylko biurokrata. Myślę, że lepiej wykorzystuję swój czas.
Ale prawdziwym tematem tego posta jest to, czego używam dzisiaj. Nie z wyboru, ale z powodu obojętnie i ślepo stosowanej polityki korporacyjnej. Przedstawię więc całkowicie uczciwe i bezstronne porównanie dwóch blisko powiązanych produktów baz danych Google działających w czasie rzeczywistym.
Obaj mają w imionach słowo Ogień. Jedną rzecz miło wspominam. Drugą rzeczą dla mnie jest inny rodzaj ognia. Nie spieszę się z podaniem ich imion, bo kiedy to zrobię, napotkamy pierwszy poważny problem: imiona.
Pierwszy z nich to tzw Baza danych czasu rzeczywistego Firebase, i drugi - Firebase w chmurze Firestore. Obydwa pochodzą z produktów firmy Pakiet Firebase Google. Ich interfejsy API nazywane są odpowiednio firebase.database(…) и firebase.firestore(…).
Stało się tak, ponieważ Baza danych w czasie rzeczywistym - to po prostu oryginał Ognisko przed zakupem przez Google w 2014 r. Następnie Google zdecydowało się stworzyć produkt równoległy Kopiuj Firebase oparty na firmie Big Data i nazwał go Firestore z chmurą. Mam nadzieję, że nie jesteś jeszcze zdezorientowany. Jeśli nadal jesteś zdezorientowany, nie martw się, sam przepisałem tę część artykułu dziesięć razy.
Bo trzeba wskazać Ognisko w pytaniu Firebase i Ognisko w pytaniu dotyczącym Firebase, przynajmniej po to, abyś zrozumiał kilka lat temu na Stack Overflow.
Gdyby przyznawana była nagroda za najgorsze doświadczenie w nazewnictwie oprogramowania, z pewnością znalazłaby się w gronie kandydatów. Odległość Hamminga między tymi nazwami jest tak mała, że dezorientuje nawet doświadczonych inżynierów, którzy palcami wpisują jedną nazwę, podczas gdy głowa myśli o drugiej. Są to plany pełne dobrych intencji, które niestety kończą się niepowodzeniem; spełnili przepowiednię, że baza danych stanie w ogniu. I wcale nie żartuję. Osoba, która wymyśliła ten schemat nazewnictwa, spowodowała krew, pot i łzy.
Pyrrhic zwycięstwo
Można by pomyśleć, że Firestore tak wymiana Firebase, jego potomek nowej generacji, ale byłoby to mylące. Nie ma gwarancji, że Firestore będzie odpowiednim zamiennikiem Firebase. Wygląda jakby ktoś wyciął z niego wszystko co ciekawe, a resztę na różne sposoby pomieszał.
Jednak szybki rzut oka na te dwa produkty może wprowadzić w błąd: wydaje się, że robią to samo, za pośrednictwem zasadniczo tych samych interfejsów API, a nawet w tej samej sesji bazy danych. Różnice są subtelne i można je dostrzec dopiero po dokładnym przestudiowaniu porównawczym obszernej dokumentacji. Lub gdy próbujesz przenieść kod, który działa idealnie w Firebase, aby działał z Firestore. Nawet wtedy okazuje się, że interfejs bazy danych zapala się, gdy tylko spróbujesz przeciągnąć i upuścić myszką w czasie rzeczywistym. Powtarzam, nie żartuję.
Klient Firebase jest uprzejmy w tym sensie, że buforuje zmiany i automatycznie ponawia aktualizacje, które dają priorytet ostatniej operacji zapisu. Jednakże Firestore ma limit 1 operacji zapisu na dokument na użytkownika na sekundę i ten limit jest egzekwowany przez serwer. Pracując z nim, od Ciebie zależy, czy znajdziesz sposób na obejście tego problemu i zaimplementujesz ogranicznik szybkości aktualizacji, nawet jeśli dopiero próbujesz zbudować aplikację. Oznacza to, że Firestore to baza danych czasu rzeczywistego bez klienta czasu rzeczywistego, która udaje bazę danych korzystającą z interfejsu API.
Tutaj zaczynamy dostrzegać pierwsze oznaki racji bytu Firestore. Być może się mylę, ale podejrzewam, że ktoś wysoko w kierownictwie Google spojrzał na Firebase po zakupie i po prostu powiedział: „Nie, o mój Boże, nie. To jest niedopuszczalne. Tylko nie pod moim przywództwem.”
Wyszedł ze swoich komnat i oświadczył:
„Jeden duży dokument JSON? NIE. Podzielisz dane na osobne dokumenty, z których każdy będzie miał rozmiar nie większy niż 1 megabajt.
Wydaje się, że takie ograniczenie nie przetrwa pierwszego spotkania z dostatecznie zmotywowaną bazą użytkowników. Wiesz, że tak jest. Na przykład w pracy mamy ponad półtora tysiąca prezentacji i jest to całkowicie normalne.
Mając to ograniczenie, będziesz zmuszony zaakceptować fakt, że jeden „dokument” w bazie danych nie będzie przypominał żadnego obiektu, który użytkownik mógłby nazwać dokumentem.
„Tablice tablic, które mogą rekurencyjnie zawierać inne elementy? NIE. Tablice będą zawierać wyłącznie obiekty lub liczby o stałej długości, zgodnie z zamysłem Boga.”
Jeśli więc miałeś nadzieję umieścić GeoJSON w swoim Firestore, przekonasz się, że nie jest to możliwe. Nic, co nie jest jednowymiarowe, nie jest akceptowalne. Mam nadzieję, że podoba Ci się Base64 i/lub JSON w JSON.
„Import i eksport JSON przez HTTP, narzędzia wiersza poleceń czy panel administracyjny? NIE. Będziesz mógł eksportować i importować dane tylko do Google Cloud Storage. Tak to się teraz nazywa, myślę. A kiedy mówię „ty”, zwracam się tylko do tych, którzy mają referencje właściciela projektu. Wszyscy inni mogą iść i tworzyć bilety.”
Jak widać, model danych FireBase jest łatwy do opisania. Zawiera jeden ogromny dokument JSON, który kojarzy klucze JSON ze ścieżkami URL. Jeśli piszesz z HTTP PUT в / FireBase jest następujący:
{
"hello": "world"
}
The GET /hello wróci "world". Zasadniczo działa dokładnie tak, jak można się spodziewać. Kolekcja obiektów FireBase /my-collection/:id odpowiednik słownika JSON {"my-collection": {...}} w katalogu głównym, którego zawartość jest dostępna w /my-collection:
{
"id1": {...object},
"id2": {...object},
"id3": {...object},
// ...
}Działa to dobrze, jeśli każda wstawka ma bezkolizyjny identyfikator, dla którego system ma standardowe rozwiązanie.
Innymi słowy, baza danych jest w 100% kompatybilna z JSON(*) i świetnie współpracuje z protokołem HTTP, takim jak CouchDB. Ale zasadniczo używasz go poprzez interfejs API czasu rzeczywistego, który wyodrębnia gniazda sieciowe, autoryzację i subskrypcje. Panel administracyjny posiada obie możliwości, umożliwiając zarówno edycję w czasie rzeczywistym, jak i import/eksport JSON. Jeśli zrobisz to samo w swoim kodzie, będziesz zaskoczony, ile wyspecjalizowanego kodu zostanie zmarnowane, gdy zdasz sobie sprawę, że JSON poprawek i różnic rozwiązuje 90% rutynowych zadań związanych z obsługą stanu trwałego.
Model danych Firestore jest podobny do JSON, ale różni się pod kilkoma istotnymi względami. Wspomniałem już o braku tablic w tablicach. Model podzbiorów ma być dla nich koncepcjami pierwszej klasy, niezależnymi od dokumentu JSON, który je zawiera. Ponieważ nie ma do tego gotowej serializacji, do pobierania i zapisywania danych wymagana jest wyspecjalizowana ścieżka kodu. Aby przetwarzać własne kolekcje, musisz napisać własne skrypty i narzędzia. Panel administracyjny pozwala na wprowadzanie niewielkich zmian tylko w jednym polu na raz i nie posiada możliwości importu/eksportu.
Wzięli działającą w czasie rzeczywistym bazę danych NoSQL i zamienili ją w powolną bazę danych inną niż SQL z automatycznym łączeniem i oddzielną kolumną inną niż JSON. Coś jak GraftQL.
Gorąca Jawa
Jeśli Firestore miał być bardziej niezawodny i skalowalny, to ironią losu jest to, że przeciętny programista skończy z mniej niezawodnym rozwiązaniem niż wybór FireBase od razu po wyjęciu z pudełka. Rodzaj oprogramowania, którego potrzebuje Grumpy Database Administrator, wymaga wysiłku i kalibru talentu, który jest po prostu nierealny w niszy, w której produkt ma być dobry. Przypomina to sytuację, w której HTML5 Canvas w ogóle nie zastępuje Flasha, jeśli nie ma narzędzi programistycznych i odtwarzacza. Co więcej, Firestore pogrąża się w pragnieniu czystości danych i sterylnej walidacji, która po prostu nie odpowiada sposobowi, w jaki przeciętny użytkownik biznesowy uwielbia pracować: dla niego wszystko jest opcjonalne, bo do samego końca wszystko jest szkicem.
Główną wadą FireBase jest to, że klient został stworzony kilka lat przed czasem, zanim większość twórców stron internetowych wiedziała o niezmienności. Z tego powodu FireBase zakłada, że zmienisz dane i dlatego nie korzysta z niezmienności zapewnianej przez użytkownika. Dodatkowo nie wykorzystuje ponownie danych zawartych w migawkach przekazywanych użytkownikowi, co znacznie utrudnia porównywanie. W przypadku dużych dokumentów jego zmienny mechanizm transakcji oparty na różnicach jest po prostu nieodpowiedni. Chłopaki, już to zrobiliśmy WeakMap w JavaScript. To jest wygodne.
Jeśli nadasz danym pożądany kształt i nie sprawisz, że drzewa będą zbyt obszerne, problem ten można obejść. Jestem jednak ciekaw, czy FireBase byłby znacznie bardziej interesujący, gdyby programiści wypuścili naprawdę dobry interfejs API klienta, który wykorzystywał niezmienność w połączeniu z poważnymi praktycznymi radami na temat projektowania baz danych. Zamiast tego wydawało się, że próbują naprawić to, co nie zostało zepsute, a to pogorszyło sytuację.
Nie znam całej logiki stojącej za stworzeniem Firestore. Spekulacje na temat motywów pojawiających się w czarnej skrzynce to także część zabawy. Takie zestawienie dwóch niezwykle podobnych, ale nieporównywalnych baz danych jest dość rzadkie. To tak, jakby ktoś pomyślał: „Firebase to tylko funkcja, którą możemy emulować w Google Cloud”, ale nie odkrył jeszcze koncepcji identyfikowania wymagań świata rzeczywistego ani tworzenia użytecznych rozwiązań spełniających wszystkie te wymagania. „Niech programiści się nad tym zastanowią. Po prostu spraw, aby interfejs użytkownika był piękny... Czy możesz dodać więcej ognia?”
Rozumiem kilka rzeczy na temat struktur danych. Zdecydowanie postrzegam koncepcję „wszystko w jednym dużym drzewie JSON” jako próbę wyabstrahowania z bazy danych jakiegokolwiek sensu struktury na dużą skalę. Oczekiwanie, że oprogramowanie po prostu poradzi sobie z dowolnym fraktalem o wątpliwej strukturze danych, jest po prostu szaleństwem. Nie muszę nawet wyobrażać sobie, jak źle może być, przeprowadziłem rygorystyczne audyty kodu i Widziałem rzeczy, o których wam się nigdy nie śniło. Ale wiem też jak wyglądają dobre konstrukcje, и . Potrafię sobie wyobrazić świat, w którym Firestore wydawałby się logiczny, a ludzie, którzy go stworzyli, uważaliby, że wykonali dobrą robotę. Ale my nie żyjemy na tym świecie.
Obsługa zapytań FireBase jest słaba pod każdym względem i praktycznie nie istnieje. Zdecydowanie wymaga poprawy lub przynajmniej rewizji. Ale Firestore nie jest dużo lepszy, ponieważ jest ograniczony do tych samych jednowymiarowych indeksów, które można znaleźć w zwykłym SQL. Jeśli potrzebujesz zapytań uruchamianych na chaotycznych danych, potrzebujesz wyszukiwania pełnotekstowego, filtrów wielozakresowych i niestandardowej kolejności zdefiniowanej przez użytkownika. Po bliższym przyjrzeniu się funkcje zwykłego SQL są same w sobie zbyt ograniczone. Ponadto jedyne zapytania SQL, które ludzie mogą uruchamiać w środowisku produkcyjnym, to szybkie zapytania. Będziesz potrzebować niestandardowego rozwiązania do indeksowania z przemyślanymi strukturami danych. W przypadku wszystkiego innego powinno być przynajmniej stopniowe zmniejszanie mapy lub coś podobnego.
Jeśli przeszukasz Dokumenty Google w poszukiwaniu informacji na ten temat, miejmy nadzieję, że zostaniesz skierowany w stronę czegoś takiego jak BigTable i BigQuery. Wszystkim tym rozwiązaniom towarzyszy jednak tak gęsty korporacyjny żargon sprzedażowy, że szybko się zawrócisz i zaczniesz szukać czegoś innego.
Ostatnią rzeczą, jakiej chcesz w przypadku bazy danych działającej w czasie rzeczywistym, jest coś stworzonego przez i dla osób na stanowiskach kierowniczych.
(*) To jest żart, nie ma czegoś takiego jak .
O prawach reklamy
Szukam do debugowania projektów, serwer do programowania i hostingu? Zdecydowanie jesteś naszym klientem 🙂 W cenę wliczony jest już dzienny cennik serwerów o różnych konfiguracjach, licencje anty-DDoS i Windows.
Źródło: www.habr.com