Czy mamy kontakt z Bazą

Cześć Wojtek.

Cześć Michał.

Dzisiaj sprawdzamy, czy mamy kontakt z bazą.

Kontakt z bazą. Kontakt zbazą danych, rozumiem, masz na myśli?

Z bazą danych. Dotarliśmy już do takiego etapu, że już nawet i o bazach danych trzeba powiedzieć.

No tak. No, było, było kilka takich bardziej abstrakcyjnych tematów. Te systemy operacyjne przewałkowaliśmy chyba już wzdłuż i wszerz, więc może wróćmy teraz do…

Jeszcze „pohejtowaliśmy” na koniec.

Tak troche pohejto… No…

No to bazy też pohejtujemy. A co tam

…pohejtujemy, tak. No i to też temat pewnie bliższy może deweloperom i może też, może też programistom, więc w końcu coś ciekawego, jeśli komuś poprzednie tematy nie podpasowały.

No nie wiem, grywalnością bazy chyba gier nie przebiją.

No nie, no to jest temat oczywiście nadrzędny, więc pewnie jeszcze będzie wracał.

Może bazy w grach?

Bazy w grach, tak. Tudzież nasza baza nieogranych, zwana „kupką wstydu”.

Albo ta baza też nie mniejsza – niezrobionych.

Niezrobionych, to jest bardzo taka smutna baza, taka big data.

No, to lepiej, lepiej tam nie rozgrzebywać tego, za świeże rany.

No właśnie.

Czyli co, zaczynamy tradycyjnie od tego, co to,

Co to?

Baza. No bo mamy taki plik, na przykład na dysku, nie? Jest plik, możemy go sobie otworzyć, zamknąć i nawet zapisać, odczytać, coś tam, coś tam. Są dane.

Czy to już jest baza?

Czy to jest baza? No nie wiem, to zależy.

To zależy, właśnie. W takim potocznym rozumieniu słowa „baza danych” no to czasami gdzieś spotyka się, na przykład jak mamy jakieś skomplikowane Excele, to może ktoś mniej techniczny potrafi powiedzieć, że: „O, tu jest moja baza danych”.

No jak ma tam miliard rekordów jakiś tam w tabelce, są jakoś uporządkowane… jak tabela, troszkę…

Że kiedyś mieliśmy takiego znajomego – przepraszam, że wpadłem w słowo – który nam przyszedł z takim Excelem, i to jeszcze w ogóle wyglądającym jak aplikacja, nie? Tam faktycznie była i logika, także faktycznie można to byłoby, tak jakby człowiek nie widział prawdziwej bazy danych, podciągnąć pod to, że faktycznie – są dane, jest jakaś ich, jakby, konstrukcja bazowa. To może to już jest baza danych, nie? I później przyszedł taki ten, ten od Billa ktoś, i powiedział, że tu macie Accessa i też macie bazę już.

No właśnie. Access już dał pewną nakładkę na zarządzanie tymi danymi, pewne API do manipulacji. Czyli to już zrobił się nam taki database management system, czyli to już chyba taka jest bardziej pełnoprawna definicja właśnie bazy danych. Przez bazę danych właśnie rozumiemy właśnie tyle ten stos, co i same dane, wręcz. Tak, tak, tylko „baza danych” to jest potoczne określenie, ale raczej tu mamy na myśli bazę danych jako całość, czyli storage plus jakieś API do manipulacji tymi danymi.

Czyli ten sofcik, który po prostu potrafi nam dać wrażenie, że te nasze dane są w jakiejś strukturze, nie? Że jeżeli je tam wrzucimy, to one będą tam w jakiejś strukturze, jeszcze to już zależnie, tam abstrahując od w ogóle samego typu tej bazy, że one są zarządzane w jakiś tam sposób, nie? Że nie rozsypią nam się tak po prostu, no jak plik w FAT-cie.

Na przykład.

Na przykład.

No i do tego, jeśli dorzucimy na dokładkę może jakiś język zapytań albo jakiś język, dzięki któremu możemy tą bazę albo zawartość modyfikować, albo odpytywać o tę zawartość… No bo plik mamy oczywiście, tylko w jaki sposób możemy ten plik odczytywać? Możemy go…

…otworzyć.

Chyba ciężko powiedzieć, że Notatnik to jest jakiś język zapytań. Ciężko, zwłaszcza że w Notatniku windowsowym to za bardzo nie otworzymy za dużo.

To inna sprawa. Tak, Windows nam z definicji nie pozwoli otworzyć w Notatniku czegoś, co nie ma .txt na końcu, ale my jesteśmy sprytni junacy z Linuksa i wiemy, że można sobie dopisać rozszerzenie, jak Notatnik nie pozwala, ewentualnie plik przeciągnąć na ikonkę, a ikonka już otworzy wszystko. Tak, albo jakiegoś Sublime’a, albo Notepada, albo cokolwiek, co już jest mądrzejsze od Notatnika.

Tylko jak mamy na przykład jakąś strukturę binarną tam zapisaną, to średnio, nie? I nasze programy, pisane tak powiedzmy w ulubionym języku – czyli jak ktoś lubi C, to w C, w C++, albo w Javie, albo w czymkolwiek, co potrafi na plikach udostępnić jakieś operacje – pewnie ten program mógłby sobie już tę strukturę binarną jakoś zinterpretować, nie? Tylko to już jest coś zewnętrznego. Ciężko powiedzieć, że to jest…

Czyli mamy nasz plik, który w teorii ma nasze dane w naszej strukturze i zewnętrzne narzędzie, które próbuje nam dać to, co nam de facto silnik bazy już daje, tak?

Teoretycznie możemy sobie zbudować własną bazę danych, bo jeśli mamy plik i naszą aplikację, można powiedzieć, że to jest taka plikowa baza danych i my sobie te pliki odpytujemy. No i to będzie jakaś tam definicja, to będzie jakiś taki prosty konstrukt tej bazy danych. Ona oczywiście pewnie nie będzie spełniać różnych kryteriów bazodanowych, jakie mamy na myśli obecnie.

Czyli na przykład klasyczny ACID, o którym pewnie sobie też tam troszeczkę powiemy, ale można powiedzieć – jest baza danych.

Czyli ogólnie podsumowując, baza danych to byłyby te dane, gdzieś, gdzie sobie jest to, w sensie dane jako dane, czyli możliwość składowania, persystencji, plus jakaś tam warstwa administracyjna, powiedzmy, czy to do zarządzania właśnie użytkownikami, dostępami, tego typu rzeczy, plus pewnie jakiś język zapytań, którym możemy sobie w jakiś sposób te nasze dane odpytywać. I te trzy elementy stworzą nam właśnie jakąś bazę danych w rozumieniu systemu RDBMS, już takiej całości spójnej, która pozwoli nam faktycznie coś ze świata pozyskać, przechować, przetworzyć jakoś nawet i jeszcze zwrócić później jako jakiś wynik zapytania.

Dokładnie. No, a jakby wyjąć z tego teraz te dane, to nam zostaje ten silnik, nie?

No tak, tak, no, silnik. Tak, czyli jakiś to… Popatrz, kurde, to już za pierwszym razem mamy: co to, na co to komu i czym to można zastąpić?

W skrócie, no tak. Na co to komu, to chyba każdy mniej więcej sobie zdaje sprawę, do czego taka baza danych może służyć. Tu za wiele pewnie wyjaśniać nie trzeba. Za to możemy dopowiedzieć, do czego mogłaby nie służyć na przykład.

Proszę bardzo.

A, to ja mam tak, proszę bardzo. Przepraszam, to odkasływanie…

Antywzorce i historyczne ślepe uliczki

Powiedzmy, jak już się ludzie przyzwyczaili do tego, że silniki baz danych umożliwiały takie fajne operacje, które były no taką już grubą architekturą pod spodem realizowane. Te fajne operacje dodawania w bezpieczny sposób, transakcyjny na przykład, zestawu danych powiązanych ze sobą jakoś tam relacyjnie, bo tutaj transakcyjność i relacyjność były dwa takie najpopularniejsze chyba terminy wśród obsługujących. Transakcyjność najważniejszym z aspektów tego, że relacyjnie, czyli że możemy sobie pewne różne dane, które niekoniecznie musiałyby być jakoś ze sobą powiązane, jednak powiązać właśnie za pomocą relacji.

A dwa, jak operowaliśmy na takim zestawie powiązanych danych, to albo operacja się udawała w 100%, albo w ogóle. Jeżeli częściowe zmiany zostały wprowadzone w trakcie modyfikowania tego zestawu rekordów – a to mogła być na przykład lista całych grafów obiektów, nie? – to jeżeli udało się doprowadzić do szczęśliwego zapisu tego wszystkiego, to transakcja kończyła się commitem, a jeżeli nie mogło dojść do commita, bo po drodze pojawił się jakikolwiek błąd, to wszystko było wycofywane i ten stan danych nie zmieniał się w ogóle pod spodem.

Czyli no, kiedy ludzie posiedli taką moc, to zaczęli kombinować i stąd dziwne wynalazki. Czy to software’owe, czy to na poziomie troszkę takiego, jakby… znaczy software’u takiego customowego, gdzie firmy próbowały sobie pisać na przykład jakiegoś UI, jakimś tam językiem opisu go opisywać, swoim własnym, i wkładać to do bazy i kazać czemuś tam innemu wyciągnąć to z bazy i wyrenderować jakąś gotową stronę, czy jakąś formatkę w jakimś desktopie, czy coś w ten deseń. To taka architektura dwuwarstwowa, która swego czasu gdzieś tam była popularna, gdzie baza była tak jednocześnie i modelem, i tą odpowiedzialną za warstwę prezentacji. W łatwy sposób dało się bezpośrednio te dane manipulować.

Pokłosiem tego… Czy łatwy? No, w łatwy na ówczesne czasy. Wydawało się, że to jest łatwe, bo mamy bezpośredni wgląd do tych danych i możemy je bezpośrednio edytować tak, jak one są surowo w tej tabeli pokazane. Nie musimy robić żadnych, że tak powiem, czy to zapytań, czy konstruować jakiś modeli danych, tylko że taka bezpośrednia edycja, no wiadomo, na początku wydaje się spoko, ale reguły biznesowe i skomplikowanie domeny jak tego właśnie przybywa i pojawiają się reguły, zaczynają się pojawiać jakieś procesy biznesowe, jakieś reguły biznesowe, to się okazuje, że najprostsza walidacja na czymś takim to jest po prostu koszmar, nie?

No tak. I dlatego to, co próbujemy tutaj leciutko zhejtować, gdzieś tam próbowało zaistnieć w czasach takich obiektów łupanych jeszcze, ale z czasem, jak już zaczęło, jak całe podejście do designu zaczęło się tak oczyszczać, powiedzmy, i zaczęło to zmierzać już w stronę procesów biznesowych, które następnie przerodziły się już w koncepty związane z projektowaniem zorientowanym domenowo, to się okazało, że ludzie już po cichu po prostu rezygnowali z czegoś takiego.

Chociażby dlatego, że wyklepanie apki, która jakąś tam logikę biznesową i logikę UI także ma zakodowaną w języku innym niż SQL, jest po prostu lepsze, wydajniejsze, mniej błędne, bardziej rozszerzalne, bezpieczniejsze, więcej możliwości daje.

Chociaż to faktycznie jeszcze później, czy to później, czy może troszkę jednocześnie, ewoluowało w różne takie, w różnych językach to się ogólnie nazywa, powiedzmy, Active Record, te typy wzorców, które właśnie umożliwiają mniej lub bardziej bezpośredni dostęp do właśnie do tego modelu danych, które obecnie są tak naprawdę no antywzorcami. Gdzieś tam w językach i w Javie też gdzieś tam dało się w jakimś Java Server Pages pewnie czasami zobaczyć jakieś połączenie bezpośrednio do bazy danych, tylko po to, żeby zaraz te dane wrzucić do jakiegoś inputa HTML. No i jakby te warstwy mocno się sklejały, bo była taka techniczna możliwość i jakby ta obecność Javy na takim pseudofroncie i możliwość stworzenia tego SQL Connection, otwarcia go, gdzieś do tego zachęcała. No teraz już wiemy, że to nie tędy droga i że trzeba te warstwy rozdzielać.

No ale to musieliśmy do tego pewnie dojrzeć i parę… Tak, to musiało po prostu, kilka faili takich być spektakularnych po drodze, że nawet takie coś, co mogło być sprytnym nawet prototypem…

Tam chyba właśnie zajął teraz jakiś story gdzieś i dlatego mamy zakłócenia, nie wiem, czy będzie słychać. Ale kilka pewnie takich wynalazków musiało spektakularnie upaść gdzieś tam w późniejszych fazach, zapewne, bo nie sądzę, że na początku. Na początku było zachłyśnięcie się, że: „Patrzcie, o to wrzucamy XML-a do naszej kolumny w bazie, a tamten wynalazek nam renderuje całą piękną stronę i wszystko cudnie śmiga”. Tylko jak tego przybyło zbyt wiele i okazało się, że jednym prostym updatem można rozwalić potężny kawałek aplikacji, to pewnie już nie było tak wesoło.

Pewnie to stało się jeszcze bardziej widoczne w ramach tego, co już nieraz poruszaliśmy, czyli coraz większego stopnia skomplikowania aplikacji. No bo jeśli na początku te aplikacje miały po cztery przysłowiowe pola na krzyż, no to pewnie rzeczywiście taki Active Record gdzieś tam mógł zdawać egzamin. Natomiast przy obecnych domenach, coraz bardziej skomplikowanych regułach biznesowych i zależnościach pomiędzy systemami, no ciężko sobie wyobrazić, żebyśmy byli w stanie bezpośrednio gdzieś tam manipulować po bazie danych. No bo tak naprawdę efekty tego mogą być długofalowe i odbijające się echem w innych systemach, więc gdzieś musi być warstwa pośrednia, umożliwiająca tworzenie takich zależności, które są, ale niekoniecznie rzucają się w oczy tak za pierwszym razem.

Tak. No i jeszcze tylko jedna taka, nie wiem jak to nazwać, aberracja do wyłuszczenia, do wyświetlenia, to na przykład, że te właśnie pierwsze wynalazki operujące na jakimś prostym SQL-u okazały się niewystarczające do tego, żeby później tę logikę… Bo sam jeszcze zakodowanie UI to powiedzmy jest brzydka rzecz na poziomie, jak i w bazie, której jest obudowane jakimś tam silnikiem. Gdzieś tam, mimo że przywoływania danymi na potrzeby gier nie, to tam było pożądane, żeby dane były oddzielone od tego, co te dane wykorzystuje. W każdym przypadku to jest pożądane, tylko tutaj właśnie one były za blisko siebie. Mimo że pozornie były odłączone te dane, to jednak trzymanie reguł budowania chociażby UI jako dane właśnie się nie sprawdziło.

Niektórzy poszli jeszcze dalej i trzymali logikę biznesową w procedurach składowanych, nie? I właśnie na potrzeby chyba takich wymagań w ogóle język SQL rozwinął się w język proceduralny SQL i tam różni dostawcy, od Oracle’a poczynając, być może PostgreSQL i tam inne bazy, mniej lub bardziej pozwalają jakimś tam standardem… Jak to się nazywa? PSQL, PL/SQL. Nigdy tego jakoś za bardzo nie chciałem sobie przyswoić. I mam taką książkę, która 10 lat przeleżała u mnie na półce, a później przyniosłem ją tutaj i leży tu już piąty rok. I bałem się otworzyć, bo to było właśnie opis ten PL/SQL w Oracle 10 chyba, coś tam.

Także tudzież wynalazki umożliwiające również w Oracle pisanie w Javie, jakieś tam tworzenie takich javowych procedur. Czyli no widać, że ta logika…

Chyba raz z tego skorzystałem w jakimś projekcie, tak. Ale to chyba tylko dowodzi właśnie tej ułomności takiego podejścia dwuwarstwowego, bo widać, że ta logika zaczęła się pojawiać, więc gdzieś próbowano ją upychać.

Właśnie albo szukać narzędzi, bo jak ta Java się pojawiła, to znaczy, że ten PL/SQL nie wystarczał.

Tak, dokładnie, więc widać, że SQL nie wystarczał i zrobiono PL/SQL. Wciąż była tendencja, żeby tę logikę upychać po bazie danych, stąd właśnie te wynalazki, o których mówimy, ale no ewidentnie widać, że to nie pykło.

Jednak czy chociażby wdrażanie, czy edycja, czy utrzymywanie tej logiki, no nie jest aż tak wygodna. Logika lubi być testowalna, więc musimy ją testować jakoś, nie? A testowanie czegoś takiego, co jest wsadzone w bazę, to jest po prostu droga przez mękę.

Testowanie, wdrażanie, wersjonowanie, rollowanie – no wszystkie te rzeczy. No, baza danych nie jest przygotowana na taki continuous integration, tak jak dzisiaj to rozumiemy, a wtedy to był pewnie prostszy koncept, ale wciąż no jednak ta iteracja była wymagana. Co innego schemat – z natury na początku troszkę zmienny, ale później raczej stały i tylko co jakiś czas modyfikowany – na potrzeby jakiejś tam względnej niezmienności, a co innego jednak ciągła zmiana pewnej logiki. Więc tak, to była chyba ślepa uliczka. Możemy to powiedzieć z perspektywy przynajmniej dzisiejszej. Jakoś dzisiaj to za bardzo się tego nie praktykuje, za wyjątkiem projektów legacy, tak, gdzie to po prostu jeszcze jest, ale…

No, nawet projekty legacy mogą być prowadzone z głową i mogą mieć tendencję do „odlegacowywania się”. I na przykład, no nawet jeżeli jest pokaźny zbiór procedur jakiś tam składowanych, to ucieka się od tego, nie? Stara się tak wyciąć tę logikę, żeby jednak pozastępować te procedury jakimiś klocuszkami, które robią to co te procedury, ale są testowalne.

Procedury też są testowalne jakoś tam, ale zautomatyzowane testowanie tego jest niewygodne.

Więc na co to komu? Do trzymania danych, bym powiedział, a nie logiki.

No tak, tak, tak.

Krótka historia baz danych

Jeszcze może zróbmy taki lekki krok wstecz. Sięgnijmy, spójrzmy troszkę na przeszłość i kiedy się właściwie te koncepty bazy danych pojawiły, bo one są w sumie, można powiedzieć, tak stare jak same koncepty… gdzieś tutaj to chyba ogólnego zarania kina science fiction. Jak mieliśmy wyprawy na jakieś obce planety, inne takie, i były te takie wielkie komputery ze światełkami i ci ziomale w takich foliowych, błyszczących strojach, w kaskach futurystycznych jak na tamte czasy…

To od nich się zaczęło, od nich się zaczęło, bo mówili, że mają brak danych, ciągle brak danych. Te komputery mówiły, że mają, no i wtedy pewnie pomyślano – jeżeli mają brak danych, dajmy im jakąś bazę danych, niech mają te dane. W tych latach 60. zaczęli te bazy robić dlatego.

A tak naprawdę, to, to też jest prawda oczywiście, co powiedziałeś, w jakimś tam stopniu, w jakimś tam stopniu oczywiście.

Technicznym usprawnieniem, które rzeczywiście te bazy danych umożliwiło, było pojawienie się właśnie nośników, które dawały nam bardziej bezpośredni dostęp, nie sekwencyjny. Właśnie bezpośredni dostęp w odróżnieniu od takich bardzo wczesnych taśm magnetycznych czy, już nie mówiąc, kartach perforowanych, to był dostęp sekwencyjny, więc trzeba było włożyć następną kartę, następną… Trudno skonstruować bazę danych, jeśli my musimy najpierw pójść do innego pomieszczenia po zestaw, zestaw danych.

Bo to się niczym nie różni od naszej szuflady, gdzie mamy zwykłe karteczki, więc jakby nie ma sensu robić bazy danych. Szuflada to jest…

Tak, to się robi trudniejsza szuflada. Więc musiały pojawić się nośniki danych z bezpośrednim dostępem, gdzie możemy sobie zaadresować.

A kto kiedykolwiek wgrywał grę na Atari, ten wie.

No właśnie, kasety, kasety. No tak, na początku też było, ale to mimo wszystko było troszkę sprytniejsze niż te karty perforowane, które trzeba było właśnie sekwencyjnie…

Ale w Commodorku trzeba było głowicę dostrajać.

No tak, dostrajanie oczywiście zawsze było, że tak powiem, konieczne, ale mimo wszystko już te mechanizmy gdzieś tam szukania odpowiedniego sektora na tych pierwszych dyskach czy wcześniej na jakichś tam taśmach, już na tyle umożliwiały automatyzację pewną, że takie systemy mogły powstawać.

Chociaż na początku i tak mówimy raczej o bazach danych w takim systemie, w modelu nawigacyjnym. To nie był jeszcze model relacyjny, jaki mamy na myśli teraz, czy w ogóle obiektowy, czy model dokumentowy, tylko systemy bazodanowe były nawigacyjne w rozumieniu, że i tak poruszano się na nich na zasadzie wskazania na kolejny element bądź poprzedni element. To bardziej była taka lista…

Taka lista powiązana.

Lista, to wciąż się jakoś tam troszkę wiązało z ograniczeniami i pewną sekwencyjnością.

No pewnie pod spodem była ta taśma i gdzieś tam kiedyś…

Tak, tak, więc jeszcze to nie do końca jakby zostało odpięte od tych bardzo prostych, prowizorycznych nośników danych, ale zgadywałbym, że nie było jeszcze dobrze opracowanych struktur danych po prostu na coś lepszego, nie?

Tak, ograniczenia sprzętowe też, bo potrzebujemy pamięci właśnie o tym dostępie swobodnym i też jakby pewnie kwestia tego, że wciąż tych danych było na tyle mało, że nie było problemu, żeby sobie przeskoczyć kilka elementów, żeby znaleźć nasz docelowy element, bo nie było ich miliarda, tylko było ich ileś tam. Znośnie.

Systemy small data, nie big data, raczej small data.

Dokładnie, więc taki model nawigacyjny właśnie był takim pierwszym modelem stosowanym właśnie w tych pierwszych bazach danych. A model relacyjny, ten, który znany jest nam teraz, taki chyba najbardziej powszechny, wciąż, przez pana Codda został gdzieś tam zaproponowany.

Zakodowany.

Zakodowany przez pana Codda, wraz z całą tutaj algebrą relacji i postaciami normalnymi, o do diaska, nie, całą tą…

Koszmary.

Koszmary, się tak. W roku 1970, więc to już jest ponad pół wieku temu. No i ten model tak naprawdę rozwinął się i największy rozwój, można powiedzieć, w latach 80. nastąpił i 90. I jakby z tego czasu pochodzą tak naprawdę większość współczesnych baz danych, które znamy teraz.

No i ten model ma duże… model relacyjny, jak się pewnie na studiach nieraz byliśmy w stanie przekonać, ma duże zaplecze i aparat matematyczny wraz z jego sześcioma postaciami normalnymi.

Sześć jest? Jest aż sześć? Wyobraź sobie.

Ja nie wiem, czy ja do trzeciej dotarłem.

Z czego, z czego trzy ostatnie, trzy ostatnie można powiedzieć, że nie mają sensu, bo one są, jak tam głosi dopisek, tylko używane w celach teoretycznych rozważań. A szósta postać normalna została wprowadzona w roku 2003, więc to jest relatywnie…

Dostał ktoś Nobla za to?

Nie wiem, nie sprawdzałem. Oscara może. Chociaż Złotego Globa. Może Złotego Globa chociaż, albo jakąś inną statuetkę. W każdym bądź razie, no jest spory aparat taki teoretyczno-matematyczny za tym idący, ale wiadomo, w takim codziennym użyciu nie do końca chyba na to nawet…

Nie do początku, nie do końca na to zwracamy uwagę. Gdzieś tam redukcja do postaci normalnej pierwszej, drugiej czy trzeciej, no to były fajne ćwiczenia na studiach.

Ale raczej… Nie, fajne, były fajne, w rozumieniu zdarzały się.

Ale raczej w akademickim rozważaniu, ale raczej nie spotkamy na naszych boardowych tasków w postaci zdenormalizowanej…

A wszystkie dane są w jednym wielkim worku na śmieci.

Ale tak. No, czyli jak we współczesnych takich, dokumentowych. No, można tak powiedzieć, można tak powiedzieć.

No i w tych latach właśnie 70., latach 80. powstały tak naprawdę gdzieś tam te pierwsze, pierwsi duzi gracze. Oracle – to jest rok 1979, więc tutaj pan Ellison wtedy coś tam zaczął już kombinować. IBM DB2 – rok 83, więc chwilkę, chwilkę później. Microsoft dołączył w 89. No i PostgreSQL również w 89. Muszę posiłkować się rozpiską, naturalnie. No i MySQL jako najmłodsza, można powiedzieć, z takich dużych, liczących się graczy – rok 95.

Z tym że oczywiście te bazy nie powstały z niczego. One gdzieś tam miały swoich mniejszych czy większych, można powiedzieć, poprzedników czy jakieś takie wersje zerowe.

Inspiracje. To sobie można na pewno doczytać tam już w szczegółach. Część pewnie może też inspiracji zaginęła w mrokach dziejów, bo jednak wtedy standardy dopiero się wykluły, więc też ciężko powiedzieć, kto od kogo ściągał, kto od kogo coś tam podbierał.

Ja się spotkałem z taką opinią, że Oracle właśnie był tym takim pierwo… znaczy pierwowzorem to niekoniecznie, ale że był pierwszym takim poważnym produktem, który mógł się poszczycić tym, że dane są w nim bezpieczne.

Silnik bazodanowy, czyli „database inside out”

Dlatego, że są przechowywane, jak to się nazywa w Oracle, transaction logiem, a tak naprawdę jest event streamem opisującym wszystkie zmiany na transakcji, nie? Czyli my już o tym wielokrotnie wspominaliśmy w poprzednich odcinkach, już nawet dość dawno temu, bo gdzieś na początku, że taki system bazodanowy – i tu właśnie Oracle był przywoływany – jest systemem opartym o event sourcing.

Bo te wszystkie zmiany transakcyjne, które tam sobie, które w ramach danej transakcji wykonujemy i tym pojedynczym commitem ostatecznym zatwierdzamy – nie po to, żeby mieć całą tę atomowość z tego naszego ACIDa – to one właśnie wchodzą jako taka sekwencja bardzo wielu drobniutkich, malutkich zmianek. I jeżeli na końcu jest ten, ta klamra spinająca, ten nasz commit, to bierzemy je pod uwagę i budujemy z nich widok, czyli de facto tę naszą strukturę już tabelek. A jak się nie powiodą, to je olewamy i one sobie tam są.

Bo na przykład, jeżeli jest taka transakcja w trakcie i na przykład zgaśnie prąd, nie było commita, to nic się nie dzieje złego ze stanem bazy, który był wcześniej. Ponieważ jak system wstaje, to zaczytuje sobie transaction log od początku. Nawet jeżeli mieliśmy totalnie skasowane tabele i wszystko tam pokrzaczone, z transaction loga jesteśmy w stanie od początku tego transaction loga przejechać po tym i zbudować wszystkie dane takie, łącznie ze wszystkim tak naprawdę, zaaplikować całą zmienność tych danych, jaka nastąpiła od tego momentu zero do momentu tuż przed wykasowaniem się, czyli do ostatniej zatwierdzonej transakcji. Ten fragment zepsuty po prostu odrzucamy, ale mamy spójne dane.

No to właśnie chyba zadecydowało o tym, że te systemy się faktycznie ugruntowały, bo na przykład no Oracle był postrzegany w swoim czasie jako taka wyrocznia, jak nazwa wskazuje, że po prostu to, co było tam zapisane, było zapisane i koniec.

Nazwa rzeczywiście się… tak. No i w tym momencie możemy wiele tematów… Od tego może warto wspomnieć ten właśnie transaction log, o którym mówisz, i może nie wszyscy są świadomi takich właśnie konceptów podstawowych. I właśnie, które powstały, jak widać, w latach 70., 80. i na przykład teraz, kiedy na fali mamy bardzo mocno jakieś systemy kolejkowe, Kafki, event sourcing i tego typu rzeczy, i często zdarza się właśnie takie głosy zachwytów nad tym, jak wspaniałym wzorcem jest na przykład taki log w Kafce – append-only log, że to jest wspaniała konstrukcja, że to jest niesamowity wynalazek.

Ale jak się okazuje, to nie jest żaden nowy wynalazek. To jest dokładnie ten sam wynalazek, który… To jest, no to jest użycie patternu, które już funkcjonuje od 50 lat i jest praktycznie podstawą każdej bazy relacyjnej, bądź nie tylko. I tak naprawdę to nie jest żaden nowy wzorzec.

I nawet i każdego tego narzędzia do wersjonowania kodu takiego poważniejszego.

No też, też między innymi. I nawet czasami, czasami Kafkę czy jakieś inne systemy kolejkowe określa się właśnie takim mianem „database inside out”, czyli to jest taka baza danych wywrócona na zewnątrz, w sensie, że ten transaction log, ten log jest jakby tym pierwszym obywatelem, można powiedzieć, i to na nim operujemy, a w bazie danych on jest bardziej schowany i przykryty transakcjami, i dopiero jego projekcja to jest to… Dopiero jego projekcja jest tabelą, a w Kafce czy ogólnie jakichś systemach kolejkowych, no to ten log jest właśnie tym pierwszym obywatelem. Ale de facto to jest bardzo, bardzo podobny wzorzec, więc warto wiedzieć, skąd to się tak naprawdę bierze. To nie jest nic nowego, to jest pewne troszkę inne zastosowanie bardzo podobnego wzorca.

I to jest jakiś tam element wspólny i bardzo dobrze, bo po co to odkrywać na nowo?

Dokładnie, dokładnie. Więc to jest po prostu po kolei, pokazuje, że odkrywamy koło na nowo czasami, a czasami po prostu w innym jakimś tam zastosowaniu to koło inaczej…

Ta symulacja, żyjemy w symulacji, tak. Wszystko już było i teraz to odkrywamy.

Nie zmierzałem do tego, ale to jest dobre podsumowanie. Koło czasu, nie? Jeszcze tylko smok i te sprawy.

Stan rynku i dominacja chmury

Także, także tak jak mówisz, Oracle był rzeczywiście uznawany za tego największego i tak już płynnie przejdę do stanu rynku, jaki ten stan wygląda obecnie, bo to mnie bardzo, bardzo zaciekawiło i myślę, że też warto ten stan rynku co jakiś czas sobie zerknąć i widzieć, jak to się zmienia. No bo rzeczywiście przez wiele lat no ten Oracle był takim niekwestionowanym liderem na rynku, jeśli chodzi o udział w rynku w sensie takim liczbowym i jakby zysków. Natomiast w roku 2024 Oracle już nie jest liderem, jeśli chodzi o…

Świat się kończy.

Jeśli chodzi o, że tak powiem, finanse. I tutaj pierwsze miejsce ma Microsoft z jego SQL Serverem, drugie miejsce ma Amazon, Oracle jest dopiero trzeci. Z tym że Amazon, no to tu oczywiście mam na myśli bardziej sumę różnych bazodanowych rzeczy, które…

Bo oni to wzięli, wszystko wrzucili do swojego worka.

Tak, tak, tak, ale mimo wszystko jako taki provider baz danych, to oczywiście mamy na myśli oczywiście providera ich własnych baz danych, czyli DynamoDB, Aurora, a nie tego, że w Amazonie można sobie hostować Oracle’a, no bo to jeśli Amazon hostuje Oracle’a, to jest wciąż Oracle. Oczywiście amazoński tutaj nie ma żadnego znaczenia.

Oracle wciąż prowadzi w różnych rankingach, jeśli chodzi o popularność w rozumieniu liczby ofert, zapytań na Stack Overflow i tego typu rzeczy, więc widać, że wciąż jakby baza projektów opartych o tę bazę…

To było budowane przez lata, więc no teraz to się tylko już mogło rozrastać, stąd jest potrzeba tego Stack Overflow.

Dokładnie, tak, więc jakby widać ewidentnie schyłek Oracle’a, jeśli chodzi o zastosowanie w nowych rzeczach, ale popularność no wciąż będzie niezmienna i pewnie jeszcze przez lata będzie się mocno utrzymywać, więc jakby nie ma…

Chyba Microsoft jest zadziwiający, że on tutaj wskoczył na pierwsze miejsce, bo ta baza Microsoftu… jakbym miał estetykę używania Oracle’a i tego wynalazku, no to zdecydowanie bym wolał mimo wszystko Oracle’a.

To tak naprawdę, dlaczego Microsoft wyprzedził Oracle’a i dlaczego Amazon wyprzedził Oracle’a, to ma ścisły związek z chmurami. Za chwilkę do tego dojdziemy, bo to jest w ogóle mega… zwykle to w ogóle mega ciekawy wątek – baza danych kontra chmury i to, co się dzieje na połączeniu tychże.

A propos chmury to mam anegdotę, znaczy mema.

Proszę bardzo.

Tylko do omówienia. Leci sobie samolocik i pytanie z kontroli lotu naziemnej: „Podaj swoją pozycję”. „Jestem obok chmury”. „Bądź bardziej specyficzny”. „Wygląda jak Simba”. Chmury w kształcie lwa… Spaliłem, to się wytnie. Dobra, nie opowiadam więcej anegdot.

No dobrze, jakoś to się podrasuje i będzie śmiesznie.

Jakoś będzie śmiesznie, następnym razem opowiem.

Także tak, także dobrze, wracamy. Tak, o co chodzi w tych chmurach? Tak, mówiliśmy o popularności. Ogólnie jeszcze, jeśli chodzi też dla fanów jeszcze liczb, cały rynek baz danych, jeśli chodzi o zyski, to jest 91 miliardów za zeszły rok i daje nam to 14% wzrost rok do roku.

Meksykańskich pesos?

Meksykańskich nie pesos, ale dolarów amerykańskich. I tak naprawdę no to jest w ciągu tam pięciu, sześciu lat, to jest wciąż, to jest wzrost praktycznie o 100%, więc wydatki na bazy danych no rosną w tempie dwucyfrowym praktycznie rok do roku, więc to jest…

Bo ogólnie na chmury też rosną pewnie, nie?

Na chmury też rosną, też w dobrym tempie, tak, tak, tak. Nie pamiętam tutaj liczb, więc nie przytoczę z głowy, ale bazy danych, bazy danych bardzo ładnie rosną. Dlatego nawet ten Oracle, nawet jeśli traci procent tego rynku, to wciąż ten rynek rośnie, więc sumarycznie oczywiście wychodzi i tak na plus.

I tutaj jeszcze jest bardzo ciekawa statystyka, że chmury, a właściwie bazy danych hostowane w chmurze, stanowią już 55% rynku i po raz pierwszy właśnie praktycznie w zeszłym roku – to jest według takiego raportu Gartnera, więc generalnie ludzi, którzy przygotowują ten raport na podstawie dość dużej próbki firm – więc bazy danych chmurowe zajmują już ponad połowę rynku kontra takie zwykłe, hostowane.

Znowuż, taka mała wskazówka, że te chmury po prostu przejmują rynek.

Dokładnie tak. To jest też wskazówka, dlaczego Oracle tak traci, no bo jednak oni troszkę się do tej chmury spóźnili, troszkę ją zaniedbali. Ale co lepsze, 98% wzrostu całego rynku baz danych pochodzi właśnie z tej części chmurowych baz danych. Czyli bazy danych takie hostowane, że tak powiem, samemu, wymierają. One rosną tak symbolicznie, na zasadzie pewnie wzrostu tych danych, które gdzieś tam się jeszcze gromadzą, ale to nie jest taki wzrost, że robiąc nowe systemy, raczej już nikt nie idzie w stronę hostowania – albo bardzo nieznacznie – w stronę hostowania własnej bazy danych, a raczej hostujemy albo całą apkę w chmurze, albo chociażby tę bazę danych.

No bo tutaj jakby to… no bo hostowanie bazy nie jest wcale takie łatwe na własną rękę, na piechotę. Nie, bo tutaj trzeba przede wszystkim zapewnić, żeby – mimo tego, że mamy tego Oracle’a, który ma żelazny ten swój transaction log – żeby jednak ten transaction log mu się nie zepsuł. Bo jak mu się zepsuje, na przykład spłonie albo się utopi w powodzi…

Właśnie, zalało serwerownię.

To my musimy mieć backup w innej serwerowni, nie w tej samej, pokój obok.

No dokładnie, dokładnie, więc no tutaj koszty infrastruktury po prostu zostały przez chmury totalnie już…

Dokładnie, no to są pobite. Infrastruktury takich data center robionych na piechotę. My zresztą bywaliśmy w projektach, które uciekały z data center rodzimego i mimo że zakładano tam na przykład strategię wyjścia z chmury, to ta strategia wyjścia kasowała się w locie i już nie można było wrócić. Na przykład, znaczy można by było przejść do sąsiedniej chmury, tylko to już był niebagatelny wydatek, czasem większy niż samo to wejście do tej chmury.

To są dokładnie te same argumenty, które tak naprawdę są ważne w kontekście hostowania czegokolwiek, nie tylko bazy danych, ale każdego komponentu naszej aplikacji, więc tutaj są dokładnie te same argumenty.

Według tego raportu jeszcze, rynek nierelacyjnych baz danych to jest 21%, czyli wciąż nierelacyjne bazy danych to jest tylko około tej 1/5. Natomiast relacyjne zajmują praktycznie 80%. Z tym że wzrost poszczególnych kawałków rynku to nierelacyjne rosną nam rok do roku o 27%, czyli wszelkie jakieś grafowe, tego typu dane, tego typu nowoczesne wynalazki, a relacyjne – wzrost tylko o 12%. Więc widać, że dynamika jakby tutaj jest po stronie nowszych rozwiązań. I no, te relacyjne wciąż rosną i mają wciąż ogromną przewagę na rynku, ale widać już dość mocno, że tutaj…

Mieliśmy nie wchodzić w technikalia, ale no czasem to nie sposób, co nie?

Kiedy relacje, a kiedy worek na dane?

Lekko i tak tylko wypada, że właśnie w niektórych zastosowaniach ta relacyjność jest być może pożądana, jak mamy jakieś takie, nie wiem, jakieś takie domeny może tak skonstruowane, że coś tam zależy od czegoś i chcemy to odwzorować na poziomie modelu. No to wtedy ta relacyjność, którą nam daje ten czy tamten silnik bazy, jest pożądana, bo no po prostu załatwia nam część brudnej roboty sprawdzania tej spójności.

No ale w pozostałych przypadkach, co widać po tych cyferkach na przykład, czasem chcemy mieć taką swobodę wrzucenia jakichś dowolnych śmieci. Na przykład prototypujemy sobie coś i tutaj na przykład będzie spoiler z Firebasem, co nie?

Dokładnie. Zaspoilerowałeś po raz kolejny.

Zaspoilerowałem, ale ja kiedyś robiłem też takie coś, co też zaspoileruję, na tym Mongo, gdzie wystarczyło po prostu wziąć sobie dowolnego JSON-a, wrzucić go do tego Mongo, później wyjąć i mieć znowu tego samego JSON-a, nie? I nawet wyszukać po atrybutach i coś. No, tylko relacji nie miałem. A jak potrzebowałem relację, to miałem ID-ik jednego dokumentu w drugim dokumencie i już miałem relację. Żaden problem.

Nie, no dokładnie tak, dokładnie tak. Do takiego prostego pudełka na lekkie dane, po których nie musimy jakiś nie wiadomo jakich skomplikowanych budować widoków, bo to nam załatwia część biznesowa naszej aplikacji. Znaczy właściwie taka część troszkę infrastrukturalna, ale rozumiejąca domenę. Czyli na przykład chociażby projekcja z naszego event streamu. To nasz event stream może być taki sobie, dokumentowy, jakikolwiek, nie? Taki prosto JSON-owy, skrojony. Taka lista, sekwencja, właśnie taka zapisana na tej taśmie magnetofonowej, tylko w chmurze i tam się po prostu szybciej kręci. Ale już nie będę anegdotycznie tego opisywał.

I dopiero źródłowe, właśnie takie surowe, eventowe, dopiero one są projektowane na jakąś tam strukturę, która oddaje nam ten aktualny snapshot tych danych, i to jest używane w logice biznesowej. Tym się zajmują komponenty aplikacyjne, nie? Więc tak naprawdę warstwa danych potrzebna jest do tego, żeby była pudełkiem na dane i koniec. Nie potrzebujemy robić tam nie wiadomo jakich rzeczy, które na przykład robią jeszcze wciąż systemy legacy, bo są tak skrojone, tak są zaprojektowane.

Że są pudełkiem na wszystko.

Wtedy włącznie z logiką, od czego się bardzo chętnie już ucieka, kiedy tylko jest możliwość. Ale na przykład są pudełkiem na dynamicznie budowane widoki, nie? Czyli mamy kawałek danych, kawałek danych, kawałek danych i reguły, jak z tego zrobić coś, co wygląda jak tabela na przykład, albo zestaw tabel.

To, to tak. No bo widoki w bazie danych są też bezpośrednią odpowiedzią na to, co mówisz. Są odpowiedzią właśnie na takie modele. To model, czyli pewna projekcja na kilka różnych tabel. Różnica jest taka, że w tych sprytnych, nowoczesnych projekcjach robimy sobie projekcje wtedy, kiedy się dane zmieniają, aktualizujemy tę projekcję, a widok budujemy wtedy, kiedy się o niego pytamy. I on tam będzie keszowany, on będzie jakiś zmaterializowany czy coś, czasami, ale mimo wszystko on się robi na żądanie. A my tutaj, tutaj odwrócono ten porządek rzeczy i tę projekcję się robi wtedy, kiedy faktycznie dane się zmieniają, dzięki czemu projekcja zawsze jest łatwa w odczycie i odczyt jest błyskawiczny.

Dokładnie tak. Więc widać, że tutaj taki hype na NoSQL-owe bazy danych, który gdzieś tam… Termin w ogóle „NoSQL” gdzieś tam pojawił się pod koniec lat 90., ale w taką największą rozpoznawalność… no to lata 2000., a zwłaszcza 2012 bodajże, kiedy to Amazon właśnie opublikował swój artykuł o DynamoDB.

Bo DynamoDB tak naprawdę chyba jako pierwsze pokazało taki potencjał produkcyjny i fakt, że…

Przepraszam, Mongo nie było ciut wcześniej?

Było wcześniej, ale chyba jeszcze wtedy nie było tak rozpoznawane albo tak, może nie było takiego zaufania, że jest to w stanie udźwignąć produkcyjne workflow, produkcyjne, rzeczywiście, zastosowania.

Wątpliwości co do na przykład tego replikacji, czy do jeszcze wczesnych implementacji, co też jeszcze za chwilkę powiemy. Ale no generalnie, jeśli taka firma jak Amazon wypuszcza własne rozwiązanie i też sama przechodzi na to rozwiązanie, czyli niejako podkreślając, że to jest gotowe produkcyjnie, no to wtedy to…

Wiadomo, że tak. Wewnętrzny nepotyzm.

Historia jednej migracji, czyli jak Amazon porzucił Oracle

Taki wewnętrzny nepotyzm. I z tym się też wiąże bardzo ciekawa historia jeszcze z Oracle’em i z Amazonem. To nawet nie będzie anegdota, tylko będzie prawdziwa historia. Bo ten spadek Oracle’a, o którym mówimy, o którym może nie wszyscy słyszeli, no bo odkąd świat długi i szeroki, no to zawsze Oracle był pierwszy i nikt tego nigdy nie kwestionował.

Zawsze był kompocik.

Zawsze był i zawsze było tak jak było. Natomiast spadł z pozycji lidera w roku 2020 mniej więcej, chociaż tak naprawdę tracił procentowo udział gdzieś tam od 2013. I to mniej więcej zaczęło się, to się delikatnie właśnie pokrywa z DynamoDB i tak naprawdę z próbami po stronie Amazona, żeby właśnie uwolnić się od Oracle’a, którego bardzo mocno u siebie wykorzystywali, płacąc za to grube, grube miliony, bo to szły w dziesiątki milionów rocznie.

No i Larry Ellison wielokrotnie przechwalał się, że z Oracle’a nie da się zrezygnować i robił bardzo dużo różnych takich przytyków na zasadzie, że Dynamo do niczego się nie nadaje. Tak, jeśli chcecie jakieś tam drobne aplikacje robić, to tam bazy z AWS-a możecie brać, ale jak chcecie prawdziwe aplikacje dla mężczyzn, to tylko Oracle. I taka była generalnie linia tutaj Oracle’a i Larry’ego Ellisona, i też CTO Oracle’a. I mocno, no dużo takich było przytyków. Oczywiście Amazon też nie pozostawał dłużny, odpowiadali…

Ty też, te refreny, ty też.

Tutaj pan Vogel, CTO Amazona, bardzo mocno właśnie narzekał na tego Oracle’a. No i gdzieś tam właśnie w tej drugiej dekadzie, gdzieś tam po roku 2010, a może nawet ciut szybciej, zaczął się projekt migracji całego Amazona, używanych tam właśnie baz Oracle na ich własne rozwiązania, czyli czy to na Dynamo, czy na jakieś Redisy. No tam, gdzie było jakieś zastosowanie, na coś innego postanowili właśnie przemigrować się.

Ucięcie kosztów to jest raz, ale mam takie nieodparte przekonanie, że utarcie nosa panu Ellisonowi było chyba kluczową tutaj kwestią, bo to ewidentnie rozegrało się…

„Panie bezimienny, utrę ci nosa”.

I dokładnie to, to tutaj widać, że Jeff jednak nie mógł tego zdzierżyć i polecił po prostu za wszelką cenę tego Oracle’a, że tak powiem, usunąć. No i po stronie takiej produktowo-konsumenckiej stało się to właśnie pod koniec roku 2019, kiedy zamknięto ostatnią bazę Oracle’a. Przemigrowano 75 petabajtów danych – petabajt to jest 1000 terabajtów – więc no danych dość dużo. To zawierało, te dane były zawarte w 7500 baz danych, czyli 7500 różnych instancji Oracle’a gdzieś tam sobie śmigało.

Więc pewnie też tyleż licencji, tudzież płatnych supportów i innych tego typu dziwactw. No i to, co się wydawało niemożliwe tutaj panu Ellisonowi, stało się faktem. Amazon twierdzi, że zredukowało to koszty o 60% i zwiększyło, a właściwie zmniejszyło latency o 40% – czas odpowiedzi.

No i tak, no i stało się, tak naprawdę dokonało się. Oracle pewnie był troszkę, troszkę zaskoczony, no ale tak naprawdę czego mogli się spodziewać? Czy firma, czy mogli spodziewać się, że firma, która no jest tak mocno w chmurze i de facto stała się synonimem tej chmury, która robi własne systemy bazodanowe bądź umożliwia stawianie baz danych serverless jak Aurora, czy naprawdę będzie korzystała z zewnętrznych baz?

Tym bardziej, że ma swoich własnych klocków poza tym tyle, że się na ekranie nie mieści.

Więc to była tylko kwestia czasu, zanim tak naprawdę, zanim to zrobią. I tak naprawdę tutaj koszty były nieważne. Tam nad tą migracją podobno pracowało około 100 zespołów różnych. No jeśli mamy 7500 baz, no to na pewno tych zespołów była cała masa.

Także no i tutaj też na tę migrację bardzo mocno, jakby za tą migracją przekonywały pewne statystyki, które Amazon podawał. To było przynajmniej w ich przypadkach użycia – no wiadomo, że to się będzie różniło pomiędzy aplikacjami – ale oni twierdzą, że oni, czyli Amazon, w ich przypadkach użycia 70% operacji to jest tak naprawdę pobranie wartości za pomocą klucza, na zasadzie: SELECT WHERE klucz_główny = ... i dostajemy jeden wiersz. Z czego 20% to jest wiele wierszy, ale wciąż z tej jednej tabeli.

Więc tak naprawdę tutaj ewidentnym takim pasującym rozwiązaniem jest baza danych klucz-wartość, tak jak mówisz, a nie żadne relacyjne. No bo jeśli mamy nasz model danych i nasze tutaj, że tak powiem, operacyjne rzeczy de facto są kluczem i wartością, no to baza danych klucz-wartość będzie najszybsza i najbardziej wydajna, jeśli chodzi o tego typu zastosowania. I nawet wtedy, jeśli pozostałe 30% będzie troszkę innego rodzaju, to może jakoś to przebolejemy w tej naszej bazie klucz-wartość. Ewentualnie, jeśli to będzie wystarczająco duże, zrobimy sobie drugą bazę, dedykowaną bazę, ale też właśnie respektującą wymagania tej domeny.

Dokładnie, dokładnie. Więc troszkę Oracle, mam wrażenie, że tutaj się przeliczył.

Dał ciała.

Dał ciała. No i ten jego spadek też wiąże się z tym, że no tutaj jakby Microsoft i Amazon idą bardzo mocno w chmurę, również Google, ale Google z jego Big Data no nie jest może aż tak bardzo rozpoznawany w światku relacyjnych baz danych czy jego tam Spanner, czy podobne rozwiązania. Więc tak szybko pewnie Oracle’a nie dogoni.

Natomiast tutaj dwójka tych graczy, biorąc pod uwagę, że no są jakby tak naturalnie w tej chmurze się znaleźli i troszkę w ich DNA ta chmura jest i bazy danych również. Bo Microsoft, nie dość, że też może troszkę później do tej chmury wszedł, ale SQL Server jest jednak od już dziesięcioleci ich rozwiązaniem, więc nie było im trudno tego SQL Servera również dołączyć.

Tym bardziej, że można by dopowiedzieć, całkiem na poważnie, że Microsoft to się właśnie na poważnie wziął za tę chmurę.

Tak. No i bardzo fajnie marketingowo to rozegrał, bo jak już się wziął, to się wziął.

To jak się wziął, to się wziął, to trzeba przyznać, tak. I tego Azure’a tak wyklepał i się z miesiąca na miesiąc poprawiał.

Tak, to prawda. To to nawet ja byłem w stanie obserwować, jak tam już po prostu pewne rzeczy, które się zacinały gdzieś tam dwa miesiące temu, już dzisiaj działały całkiem znośnie.

Przyspawani do bazy, czyli problem vendor lock-in

Tak. I tutaj Oracle jako, no, chmurowo próbują coś zrobić. No mieli tę swoją próbę wejścia z Oracle Cloud 2 i inne jakieś inicjatywy, gdzieś próbują w tę stronę działać. No ale jakby te mocne przywiązanie do swojego flagowego produktu… No, można to obudować pewnymi chmurowymi rozwiązaniami, no tylko jednak nie jest to aż tak…

Żeby zechcieli… Nie wiem, czy ktoś będzie tam słuchał. Jakby co, to teraz możecie notować, panie Larry, że można by było jednak takiego swojego Redisa chlasnąć, jakieś swoje Mongo, w sensie trochę dokumentowe, trochę ten klucz-wartość, trochę może jakoś jeszcze inaczej, nie? Tak żeby troszkę było w koszyku więcej niż ta jedna baza.

Szczerze powiedziawszy, strasznie dawno zaglądałem tam do nich, bo jakoś tak ostatnio nawet nie miewam możliwości bycia w projekcie, który na Oracle’u się…

To jest chyba też drugi problem, że Oracle nie jest kojarzony jako pierwszy wybór, jeśli chcesz postawić jakąś małą apkę. Nawet nie rozważasz Oracle’a, bo no jednak kojarzy on się raczej z takimi ciężkimi workami…

Wielkimi kolosami.

Wielkimi kolosami, z wysokopłatnymi licencjami, z supportem. Mimo że to się zmieniło, i to już sporo lat wstecz, że właśnie udostępnili tak… tylko chyba dalej licencja, znaczy to tylko do niekomercyjnych projektów było, nie? W momencie jak się to pojawiło. Czyli można było jednak wziąć sobie tego pełnoprawnego Oracle’a i przygotować swój prototyp, a jak już wychodziliśmy na produkcję, to trzeba było kupić licencję za tam 300 000.

Na develop, jakiegoś Expressa czy jakąś prostą wersję, to coś takiego można było mieć, nie? Tylko tam było na przykład w Expressie ograniczenie do 4 giga danych. Więc jak już…

Włącznie dewelopersko się nadaje tak naprawdę.

No właśnie, to jest ten problem, że to nie jest jakby pierwszy wybór, nie jest z tym kojarzony. Też ich marketing pewnie nie do końca nadąża za trendami, więc teraz taki zwykły deweloper, jeśli będzie szukał jakiegoś rozwiązania do startupu czy do jakiegoś projektu hobbystycznego, no to prędzej zajrzy właśnie na Firebase, na Mongo, czy nawet do chmury, żeby sobie wziąć jakiegoś Redisa czy coś innego.

Tym bardziej, że na przykład wejdzie w takiego Azure’a i dostanie tam za darmo przez rok wszystko, nie?

Dokładnie, dokładnie. A wejdzie do Oracle’a i zobaczy, że no za darmo to ma jakąś testową wersję, a później to płać i właściwie nie wiadomo za co, a to to w ogóle jest niepotrzebne.

Więc to jeszcze nie zdąży nawet nic zrobić na tej…

No dokładnie, bo to jest tylko baza danych, a innych usług za bardzo nie dostanie, albo dostanie ich garść w porównaniu z tym, co oferują chmury czy chociażby taki Firebase, który też, jak już tutaj spoilerowaliśmy, ma całkiem fajne możliwości.

Także, także to jest ten problem Oracle’a. Na ich korzyść można powiedzieć – jeśli to tak można nazwać w przypadku baz danych – działa bardzo mocny mechanizm takiego vendor lock-inu. Bo jakby nie patrzeć, baza danych jest na tyle dużym i ważnym kawałkiem wszystkich systemów, że jednak jak już wejdzie gdzieś w użycie dany system, no to ciężko później to sobie podmienić.

I tutaj możemy sobie oczywiście implementować JPA i robić abstrakcyjne providery i repozytoria, i myśleć, że możemy w każdej chwili wymienić tego dostawcę baz danych. Natomiast w praktyce no to nie jest takie oczywiste, bo za zmianą bazy danych no też najczęściej potrzebujemy w naszej firmie mieć pewność, że gdzieś tam devopsi potrafią tę czy inną bazę obsługiwać, replikować, robić backupy, więc to nie zawsze też jest tak łatwo dostępne.

A najczęściej, jeśli już firmy, zwłaszcza większe, wydały masę pieniędzy na jakieś certyfikacje, szkolenia z Oracle’a i tego typu rzeczy, no to też bardzo szkoda to wywalić.

Szkoda to wywalić. No, nie wszyscy mają takie, że tak powiem, intencje jak Amazon, że tutaj jest troszkę inny cel – pozbycia się tego Oracle’a. Większość po prostu używa tego Oracle’a i im to nie przeszkadza, można powiedzieć. No i szkoda, szkoda, szkoda tych pieniędzy wyrzuconych na support, więc jest taka bardzo mocna inercja, jeśli chodzi o zmianę baz danych. No i na tym korzysta Oracle, który – co by nie mówić – jest po prostu przyspawany w wielu, wielu firmach już na stałe i ruszyć go jest bardzo ciężko.

No tak. Tak jak już się wejdzie w te specyficzne jakieś tam wynalazki albo jak się za dużo zakoduje w samej bazie, no wtedy to, wtedy już jest w ogóle dramat, nie?

A, no, przypadek Amazona pokazuje, że jednak da się to zrobić, jak się ma wystarczającą determinację do tego. Natomiast takie proste założenie, żeby właśnie to, co trzyma nasze dane, było trzymadełkiem, a logika, która na tych danych operuje, jest na zewnątrz tego trzymadełka. Co najwyżej, jeżeli potrzebujemy sprawdzić jakieś proste zależności między fragmentami tych danych, tam zwanymi rekordami najczęściej, no to okej, niech tam sobie ma, jak trzeba. Ale niech to będzie jakieś standardowe, że w razie czego tak naprawdę nie interesuje tej logiki, nawet tej logiki obsługującej model, z czym konkretnie pod spodem rozmawia. No to wtedy możemy to wymienić, tak pewnie jak to nie ma jeszcze rozmiaru jakiegoś kolosalnego, od tego, nie? A w tych większych no to niestety faktycznie można być przyspawanym. No i pewnie pozostanie już to do końca, chyba że projekt będzie przepisany zupełnie od nowa.

No tak. Dlatego właśnie mimo wszystko, mimo jednak spadku udziału w rynku, no jednak Oracle gdzieś tam, gdzieś tam się trzyma i pewnie trzymać się jeszcze, jeszcze długo będzie.

Przyszłość jest teraz: 3xV i polyglot persistence

Natomiast to, co tak już może wybiegając w przyszłość – chociaż ta przyszłość to tak naprawdę już jest teraźniejszością czasami, albo jest tuż za rogiem – no bo wspominaliśmy te bazy danych, które są hostowane już w cloudzie i stanowią ponad połowę rynku. Oracle’a też możemy sobie hostować w cloudzie, nie musimy go on-premise stawiać, ale tak naprawdę, jeśli chodzi o usługi towarzyszące, no to jednak tutaj Azure i AWS mają przewagę.

No właśnie, bo jeszcze jeden jest aspekt tego, że jak mamy tę chmurkę, to wszystko mamy pod ręką. I nie zrobimy sobie tak, że bierzemy z chmurki tej czy tamtej, czy tam bardziej lubimy Microsoft, czy AWS-a, wszystko jedno, czy jeszcze coś może. Nie weźmiemy sobie klocuszków stąd i bazy z Oracle’a, chowanej gdzieś tam w oraclowym cloudzie, dlatego, że między nimi jest za daleka odległość, po prostu, nie? Nawet jak mamy tę samą chmurę, to i tak dobierając, już składając docelowe środowisko, dbamy o to, żeby one geograficznie były blisko siebie w miarę, nie? Jeżeli nawet mamy w różnych centrach to porozrzucane, staramy się, żeby przynajmniej te centra były w tym samym kraju, nie? Albo no, jeżeli mamy możliwość, w tym samym centrum fizycznym to zrobić, no to korzystamy z tego, bo wtedy mamy najkrótszą drogę, czyli po prostu najlepszą komunikację.

Możemy oczywiście to jakoś tam obejść, próbując gdzieś tam stawiać nasze serwery w podobnych lokalizacjach, gdzie stoi nasza na przykład baza danych, i jakoś to łączyć jakimiś mechanizmami właśnie AWS-a, jakimiś tunelami czy czymś, no ale praw fizyki nie przeskoczymy.

Tak. No jeśli, no tak naprawdę wygodnie też jest używać pewnie usług od jednego providera. Względnie możemy ewentualnie pokusić się po prostu o wyhostowanie tej bazy danych, ale w danej chmurze. Zresztą ostatnio miałem taki przypadek, gdzie potrzebowaliśmy zrobić pewną projekcję konfiguracji AWS-a, no i bazą danych projektu był SQL Server Microsoftu. Robiliśmy to na AWS-ie. No, jakby nie było możliwości zrezygnowania z tej bazy, bo właśnie było za dużo logiki w procedurach, więc trzeba było użyć SQL Servera w AWS-ie właśnie.

I oczywiście jest taka możliwość. Można sobie spokojnie zahostować taki SQL Server, można do niego dołączyć własną licencję albo można sobie wybrać wersję z licencją już wbudowaną w cenę, którą się płaci za bazę danych. Więc jakby takie połączenie jeszcze względnie ma sens, bo wciąż jakby zostajemy z tą bazą danych, którą mamy w naszym data center na przykład, więc nie musimy robić wielkich migracji i tego typu rzeczy, a jednocześnie cała nasza infrastruktura będzie w tej chmurze, więc zarządzanie będzie w miarę proste.

Zwłaszcza, że w AWS mamy też możliwość postawienia bazy danych jako taki RDS, zupełnie zarządzany przez AWS-a, czyli my nawet nie mamy dostępu do maszyny, na której ta baza jest hostowana. Czyli sobie instancja Oracle’a albo SQL Servera i ona sobie działa, ona jest backupowana i my tylko mamy, można powiedzieć, connection URL-a i niczym się nie zajmujemy. A mamy też możliwość zrobienia tak zwanego Custom RDS, gdzie ta instancja też jest postawiona przez AWS-a, ale możemy się na nią wbić zdalnie przez SSH czy Remote Desktop i możemy sobie coś tam ewentualnie pogrzebać, pozarządzać, jeśli potrzebujemy coś tam pozmieniać. Więc jest to dość elastyczne i możemy sobie w ten sposób przejść.

Ale faktycznie, jeśli mielibyśmy teraz brać Oracle’a z chmury Oracle’a i łączyć z inną chmurą, pewnie byłoby to troszkę trudniejsze, chociaż nie niemożliwe oczywiście.

No, oprócz tego, że właśnie no wygoda użytkowania, może wygoda licencjonowania też czasem nie bez znaczenia, bo czemuż by nie dostać zniżki na tę bazę od konkurencji, hostowaną w tej chmurze, jeżeli cała reszta jest w tej chmurze, a akurat trzeba.

Ale też i security jakieś, nie? To komunikacja to jest oczywiście ważna rzecz, ale zabezpieczenie połączenia między tymi dwoma komponentami – to łatwiej jest zrobić, jak się jest wewnątrz chmury, w jakiejś wydzielonej podsieci, niż jak się jest w różnych sieciach fizycznych w ogóle, nie?

To jeszcze dodatkowo obniża pingi, więc no tutaj później komfort już użytkownika końcowego ucierpi na tym na pewno.

Widać, że no zmierzamy pewnie w stronę takiego bardziej kompleksowego świadczenia usług, gdzie bierzemy całe dobrodziejstwo inwentarza danej chmury i to jest, no na pewno dla takich nowych aplikacji stawianych od początku, no to będzie pewnie docelowy…

To dobrodziejstwo jest właśnie tak bardzo granularne, że możemy sobie wziąć tylko ten kawałeczek, ten i ten, nie? I nie musimy wcale tam wielkiego Oracle’a… ale mu się oberwało dzisiaj.

Cóż to się porobiło.

Ale troszkę się należało.

Zbierał przez lata, nie? Stracił taką, taki rynek.

Także nie musimy tego wielkiego grajdołka całego brać i płacić za niego 300 000 i pewnie odświeżać co ileś tam lat, bo nie pamiętam, jak oni tam mają, tylko możemy sobie jakieś małe coś tam kupić, nie? I później tylko na rachunku zobaczymy, że no przeholowaliśmy w tysiącach.

Zwijamy ten interes.

Albo nas zwinięto już.

Albo nas zwinięto. No właśnie. I tak może zanim się jeszcze… [Muzyka] …zwiniemy, no i też ogólnie może o kierunku baz danych. No bo to mówimy relacyjne, ale ktoś może powiedzieć, że chwila, chwila, no przecież relacyjnych to już nikt nie chce używać i tylko NoSQL. Na co to komu? Przecież to już nikomu niepotrzebne.

No i to jest po części, po części prawda, bo nie że nikomu niepotrzebne, bo jednak czasami to jest potrzebne, ale nie ma co ukrywać, że aplikacje ze względu na coraz większą różnorodność danych potrzebują troszkę innych modeli przechowywania, różnych typów. Wspominaliśmy właśnie ten typ key-value jako taki jeden chyba z bardziej popularnych rozwiązań, czyli blisko też rozwiązań takich keszujących, no bo to jest de facto też jakaś podstawa cache’a.

Mówimy też często o bazach grafowych, czyli też do pewnych czy to rozwiązań algorytmicznych, czy wiadomo, sieci społecznościowe. Jeśli byśmy chcieli zrobić nowego Facebooka czy coś takiego…

Nie polecam.

Nie polecam, wystarczy nam jeden. Ale…

A ten nowy ma jeszcze cenzurować.

To też jest pewnie jakieś, no już dedykowane rozwiązanie i są też na to na to bazy danych. No i klasyczne rozwiązania też do lepszego wyszukiwania, chociażby tekstowego i czy ogólnie jakiś właśnie read modeli, tego typu rzeczy. No tutaj tych możliwości troszkę jest, te dane się dość mocno…

Dla każdego coś miłego.

Dla każdego coś miłego. I te dane, no te dane się zmieniają na trzech różnych osiach tak naprawdę, dlatego stąd te zmiany są też potrzebne. I te osie czasami się określa takimi literkami 3xV, bo tutaj zmienia się nam Volume, czyli jakby objętość danych nam rośnie, przybywa nam tych danych i te relacyjne bazy danych nie do końca potrafią nam sobie poradzić z taką wielką objętością. No bo wiemy, że relacyjność ma pewne jakieś tam nawet techniczne, można powiedzieć, ograniczenia, jeśli chodzi o ilość tych danych. Możemy to oczywiście indeksować, możemy to oczywiście jakoś tam shardować, robić wersje historyczne i jakkolwiek to robić, ale gdzieś tam pewnie ten sufit napotkamy i nie da się pewnie już czy to robić analizy, czy jakiegoś machine learningu, albo nie zawsze da się łatwo robić to na relacyjnych bazach danych. Więc jakby coraz większa ilość danych wymaga coraz lepszych sposobów składowania tych danych.

Różnorodność tych danych, czyli Variety, to drugie V. Przez różnorodność rozumiemy brak struktury, czyli to, że już coraz rzadziej mamy prostą tabelkę, gdzie mamy pięć kolumn albo 50 i sobie tam wrzucamy…

Albo 200 jak w Oracle’u.

Albo 200 jak w Oracle’u, albo jak w naszym którymś z projektów mieliśmy tę drugą, która… Ale to nie my dodawaliśmy, to już było.

Tak było, tak było.

Nawet nie dali usunąć.

Nie dali usunąć, bo już się nie dało usunąć, bo się relacje były, bo ALTER trwał 10 minut.

I właśnie ten brak struktury i chociażby, albo zmiana tej struktury, która jest później potrzebna. No dane częściowo są w postaci JSON-a, w postaci jakiegoś tekstu, w postaci, no zupełnie bez struktury, nawet… No, to może być JSON, ale jakiś zmienny. I jasne, możemy sobie wziąć Postgreasa i wziąć sobie typ JSONB i tam sobie to wrzucać, i nawet natywnie zapytać tego JSON-a.

I to będzie: „czy masz takie property?”. Tak, i możemy sobie po tym wyszukiwać. I to nawet może w części przypadków się sprawdzić, bo jeśli czujemy jakąś wielką potrzebę, a jednak składowania tego JSON-a, może faktycznie, tak jak zresztą kiedyś zrobiliśmy w jednej z aplikacji, składowaliśmy właśnie te eventy JSON-owe i to się fajnie sprawdzało, bo zanim byśmy dostali zgodę albo gdzieś tam wywalczyli naszą bazę danych bardziej dokumentową, to my sobie to w parę godzin zrobiliśmy w Postgresie i też działało, i było wystarczające na nasze…

Albo w Mongo można to było.

Albo w Mongo też wtedy. Więc czasami da się to zrobić w istniejących rozwiązaniach i to wcale często, często jest droga do celu. Ale czasami ta różnorodność jest na tyle duża i jest już jakby u zarania tego systemu, że może nie warto tego robić na tej relacyjnej bazie danych i tam to wpychać, i próbować, i de facto emulować te wszystkie modele. Emulować to, bo skończymy z Postgresem, który będzie miał same kolumny JSONB, a reszta to będzie taki Redis. I ewentualnie ID. No też chyba nie o to chodzi. Więc tutaj ten brak struktury jest czymś, co warto wziąć pod uwagę.

No i tym trzecim V w tej zmienności jest Velocity, czyli prędkość i szybkość przyrostu tych danych, i zmienność tych danych, co też właśnie wpływa na czy chociażby processing tych danych w czasie rzeczywistym, czyli też szybkość dostępu do tych danych. Czyli już nie chcemy czekać, aż jakieś tam zapytanie wsadowe, jakiś SQL wykona się…

Tyle, tyle danych mamy.

Chcemy ten raport… Tam się widoki materializują.

I nie dość, że chcemy ten raport mieć w 3 sekundy, to on jeszcze musi być maksymalnie aktualny, czyli najstarsze dane mogą mieć sekundę, sprzed 10 sekund, powiedzmy. No i jak zaczniemy tak często do tak dużej tabeli pisać dane, a później jeszcze czytać, no to chyba wydajnościowo ta tabela trzaśnie drzwiami i pójdzie.

No dokładnie. Już nie mówiąc, jeśli byśmy chcieli w tej tabeli zmienić schemat, coś dorzucić, coś zrobić. Więc to pokazuje, że jakby ten relacyjny model danych nie zawsze się spina. I tak naprawdę troszkę to ewoluuje. No jeśli te trzy rzeczy mamy jednocześnie, no to można powiedzieć, że w ogóle już idziemy w stronę Big Data, no bo jeśli mamy dużo danych, zmiennych danych, które chcemy też mocno analizować…

Tak, to się już zaczęło w czasach hurtowni danych, gdzieś tam względnie dawno temu.

Tak, więc to już mamy takie bardziej już w ogóle modele Big Data i to bardziej narzędzia jakieś MapReduce mogą nam przyjść z pomocą, no bo to już jest niekoniecznie baza danych jako taka.

Ale dobra, to zaraz jeszcze zhejtujesz.

Nie, nie, nie, tylko podtrzymam.

Ale, ale właśnie, no to wymaga pewnej zmiany, pewnych narzędzi. I bardzo często może być tak, że do jednej części naszego systemu będziemy mieli tę naszą fajną relacyjność, a do tej drugiej części będziemy mieli jakiś taki właśnie worek na te nasze surowe dane, całe wszystko, nie dbając właściwie, co tam jest. Później się pomyśli, później możemy sobie coś z tym zrobić.

Tak jak zresztą mieliśmy w jednym z projektów, gdzie faktycznie mieliśmy tego SQL-a i w początkowych fazach, kiedy właśnie wchodziła analityka do naszego projektu, no to biznes robił po prostu zapytania na tej bazie danych, na naszej produkcyjnej bazie danych. Gdzieś tam szły jakieś zapytania o ilość pewnych rzeczy czy podsumowanie jakieś tam finansowe. No i wiadomo, tutaj były pewne tarcia, bo biznes potrzebował pewnych pól analitycznych, więc prosił deweloperów i zespół, żeby dodawał to do schematu. No ale ten schemat nie służył do tego, bo to była troszkę inna domena. Miałeś tutaj pewną encję, która służy do opisu pewnego konceptu, a nagle przychodzi ci koncept zupełnie taki analityczny, że dodaj mi jakieś tam ID albo coś tam. No i oczywiście dodajesz, no bo wiadomo, tutaj potrzebne są te zapytania, ale to powinno być w różnych, w różnych jakby częściach systemu rozwiązywane.

I koniec końców w tym projekcie tak się też stało, no bo przeszliśmy właśnie na koncepcję tego data lake’a i tutaj kombinacja Firehose’a, Kinesis i Amazon Atheny sprawiła, że stworzyliśmy zupełnie osobny model do analizy właśnie w AWS, a nasza baza danych była czyściutka i zajmowała się tylko naszą domeną, a zasilaliśmy tamten model danymi do analizy. I tak naprawdę przy większych właśnie wolumenach, przy większej ilości danych, no to jest takie docelowe rozwiązanie. I tutaj jest miejsce i dla bazy danych relacyjnej, i również dla tych nowszych rozwiązań. To nie jest tak, że teraz bierzemy tylko NoSQL, Mongo i w ogóle, a relacyjna baza danych to w ogóle nikomu niepotrzebna. Tutaj oba te rozwiązania idealnie nam współdziałały.

No to ja właśnie chciałem, przepraszam, ja chciałem tylko to podtrzymać i właściwie już no zabrałeś mi tę część opowieści swoją.

Bardzo proszę.

Ale okej, bo to miało wybrzmieć, że czasem właśnie trzeba wziąć ten stary zestaw danych, chociażby pochodził z jakichś archaicznych czeluści, przepuścić przez nowe maszynki, wypluć do nowych. Przy okazji event processingu mówiliśmy o tym, jak to strumienie na przykład kafkowe… Zresztą tam nawet był taki przypadek, opisywali to w swoim artykule, że te swoje strumienie danych, które no są takie, jakby można je traktować jako odpowiedniki takich event streamów, no bo de facto to właśnie takie zdarzenia spływające z tych wszystkich ich systemów, one były tam na przykład krzyżowane ze sobą, jakoś tam separowane, jakoś procesowane. Czyli ze strumienia wejściowego robili jeden lub więcej strumieni wyjściowych, nie? I to były dane przetransformowane, które można dalej znowu gdzieś składować, można je łączyć z nowymi jakimiś danymi, które spływają. Możliwości jest mnóstwo. No i zależnie od tego, jakie mamy wymagania, to użyjmy takich klocków, które właśnie do tych wymagań pasują, a nie ładujemy wszystko do tego, co mamy. Nie hejtujemy innych.

Tak jak kiedyś hejtowanie, to nie daje rady.