Baza danych w NodeJS? Wydawałoby się niemożliwe… A jednak, twórcy HarperDB porwali się z “motyką na słońce” i stworzyli właśnie coś takiego. W tym odcinku, całkiem subiektywnie, rozprawiamy o tym szalonym pomyśle.

Przydatne Linki

• HarperDB - http://harperdb.io
• Ciekawy post o HarperDB - https://medium.com/dailyjs/building-a-database-written-in-node-js-from-the-ground-up-c4be925c537
• Benchmarki - https://harperdb.io/developers/benchmarks/

Transkrypt

Marek Piechut: No witaj Bartku.

Bartek Witczak: Witam Panie Marku.

Marek Piechut: No dobrze, to dzisiaj mam taki temat, który powiem Ci mnie dosyć zaintrygował, odkryłem go wiesz, na jakimś takim spontanicznym przeglądaniu internetu. Temat jest bardzo kontrowersyjny, mianowicie jest coś takiego co się nazywa Harper DB i jest to, ni mniej, ni więcej tylko baza danych napisana w Node JS.

Bartek Witczak: No, z tego co kojarzę, to jeszcze tego nie grali.

Marek Piechut: Jeszcze tego nie grali, właśnie i dobra. Najpierw chciałem się dowiedzieć jakieś twoje takie wiesz, pierwsze wrażenie. Ja miałem pierwsze wrażenie swoje i potem miałem drugie, ale to pogadamy za chwilę, ale jakieś twoje pierwsze wrażenie na ten temat w ogóle.

Bartek Witczak: No dobra.Pierwsze wrażenie jest takie, że wydaje mi się to mocno abstrakcyjne, głównie biorąc pod uwagę fakt, że mamy w Node jeden wątek. I teraz w zależności od tego, jak na to patrzymy, to możemy powiedzieć, że baza danych z założenia dopuszcza wiele połączeń. Czyli powinna tam gdzieś sobie działać bardzo multikulti. Więc jak powiedziałeś mi w ogóle, że jest baza danych zrobiona w Node, no to pierwsze wrażenie to, to że jestem lekko zszokowany, to byłoby mało. Na takim pierwszym strzale powiedziałbym raczej, że to jest jakaś zabawa, natomiast jak trochę dłużej bym o tym pomyślał, to teraz zastanawiam się, czy samo powiedzenie, że baza danych jest napisana w Node nie jest jakąś taką formą prowokacji i bardziej to jest tam low level wszystko działa tak jak powinno, a z założenia na przykład będzie taka mocna asynchroniczna, a tak naprawdę ten jeden wątek, nie wiem może on wystarczy na robienie i obsługiwanie tych wszystkich requestów. Także nie wiem czy mnie sprowokowałeś, czy po prostu robisz sobie ze mnie żarty.

Marek Piechut: Widzę że, ostrożnie podchodzisz do tematu, raczej nie znamy chyba osobiście nikogo, kto robi tą bazę, więc mogłeś spokojnie obrażać. Znaczy moje, moje pierwsze odczucie było takie wiesz, what the fuck, co tu w ogóle ktoś sobie wymyślił niezłą bzdurę i jak o tym myślę no to generalnie jest taki trochę szalony pomysł, że w ogóle zacząłem coś przeglądać z tym dalej, właśnie przez to moje takie odczucie że w ogóle co to jest za jakiś głupi pomysł…? Robisz bazę danych po pierwsze w języku, który nie ma wątków. Po drugie w języku który ma garbage collector. Po trzecie w języku który nie jest wiesz, statycznie komplikowany, więc nawet nie da się takiego marketingu zrobić, żeby powiedzieć, że to będzie działać tak szybko jak statycznie kompilowany kod, bo to jest poprostu niemożliwe. Po czwarte na platformie, która nie daje ci bezpośredniego dostępu do calli systemowych, gdzie tam musisz właśnie alokować pliki na dysku itd. Itd. Wiesz jakimiś low level API tak naprawdę, no bo te wszystkie wyższego poziomu API, no to są za wolne. Dostępu do pamięci też nie masz, tak żeby móc optymalizować te wszystkie algorytmy wyszukiwania, sortowania, cudowania itd. bo też chcesz jakby grać na pamięci i na wydajności na procesorze. Nie masz nawet, jakby model pamięci jest taki totalnie referenced based, więc nawet nie jest w stanie takich struktur robić, jak w C sobie, gdy wiesz, że są blokami pamięci i bardzo łatwo się na nich działa i są bardzo tanie. Moje pierwsze w ogóle wiesz było, że what the fuck co tu się dzieje. Oczywiście w tym blog poście, w którym to czytałem, goście mówią, że no myśleli żeby zrobić w Go, ale Node juz znali itd. więc dla mnie Go jest głupim pomysłem do robienia bazy danych.

Bartek Witczak: Dobrze, że nie pomyśleli żeby w PHPie zrobić.

Marek Piechut: Z tego względu, że po prostu Go też ma garbage collector, no i przy bazie danych moim zdaniem, to jest słaba akcja, żeby bazować na garbage collector, ale zacząłem drążyć temat i ten mój what the fuck, trochę zamienił się w taką ciekawość. Znaczy nadal uważam, że to jest abstrakcyjny pomysł w ogóle, żeby coś takiego robić, ze względu właśnie na te ograniczenia platformy jako-takiej, że to jest straszne tłuczenie się, wiesz walka z tą platformą. Ale zacząłem wiesz, patrzeć w to dalej. I nagle okazuje się, że chłopaki robili benchmarki. Też chwilę pogadamy o tym za momencik. Ale tak jakby z haseł, z tych ich benchmark, Harper TV jest 38 razy szybsze niż Mongo. Na Raspberry PI jest 581% szybszy na Raspberry PI jako wbudowana baza danych. Nie wiem, co ty o tym myślisz?

Bartek Witczak: Poczekaj, wróćmy jeszcze w ogóle do samego początku. Co dokładnie według nich znaczy, że baza została napisana w Node?

Bartek Witczak: To znaczy, jakby duża część bazy jest faktycznie w Node. Z tego co ja doszedłem do wewnętrznych bebechów, to parser SQL jest w JavaScript. Bo tam jest obsługa z SQL, No SQL itd. Dużo logiki tej takiej wewnętrznej bazy jest w JavaScript, i na koniec to uderza do takiego natywnego modułu, który jest key/value storem. Więc oni jakby samo sterowanie na dysku itd. to jest takie trochę oszustwo, że to jest napisane w Node.

Bartek Witczak: Tak się można było spodziewać właśnie, żeby jakikolwiek gdziekolwiek sens był…

Marek Piechut: …tak jakby ktoś miał tam wiesz, te strumienie otwierać i pisać na dysk bez memory map file. I tak dalej takich rzeczy, w ogóle nie wyobrażam sobie jak można zapisywać w bazie danych. Że tam każda kropka się zmieniła, a ty co… Otwierasz plik i jedziemy. Tutaj zapisujemy do pliku zamykamy plik, to wogóle nie miałoby racji bytu. No, ale tam duża część tej bazy jest w tym Node ,jakaś tam część poza IO, tak że też bym nie przesadzał, że to jest taka ściema, z tym, że to jest w tym Node, chociaż jeżeli sam storage jest natywny w jakims C no to…

Bartek Witczak: Właśnie teraz wiesz, bo to jest standardowa akcja. Pytanie pozostaje takie, czy jeżeli wszystkie operacje takie IO są rzeczywiście napisane w C, czy tam w czymś, to rzeczywiście czy to jest baza napisana w Node…? Jakby właśnie trudno powiedzieć, bo to jest trochę taka pierwsza rzecz, która przyszła mi do głowy tytuł i nazwa jest na tyle chwytliwa, żeby ludzie się tym zainteresowali. Potem okazuje się jeszcze, że pewnie otwierasz jakiś tam Readme, i jest 300 tysięcy razy szybsza niż pół świata i kończy się tym, że postanawiasz ją wziąć w kolejnym projekcie dla klienta.

Marek Piechut: I to od razu ją bierzesz, już wchodzi produkcyjnie. Znaczy wiesz, to jest ten problem benchmarku. Ja tak przeglądałem te benchmarki i pierwsze moje wrażenie jest takie, że to jest niemożliwe. To są bzdury. No, ale z drugiej strony, to jest możliwe, ja bym też nie przesadzał, że to jest niemożliwe, bo oczywiście każdy zrobi taki benchmark, żeby w nim dobrze wypaść, tak..? I np. to co ja jeszcze za chwilę przejrzę, bo tam jest parę ciekawych rzeczy w ogóle w tej bazie, że w ogóle abstrahując od tego, że ona jest w Node, to jest takie zabawne, tam chłopaki parę ciekawych pomysłów mieli. To znaczy tak, jeżeli chodzi o Node, no to oni musieli trochę ten model Node wziąć, i to moim zdaniem jest duży win dla nich, z samego względu, że mają ten model wykonania, który jest Node, więc muszą zrobić klastrowanie, bo inaczej nie ma żadnej racji bytu ten produkt. Więc to jest baza, która się mocno klastruje, i to jest taki “win” moim zdaniem, bo to jest dosyć ciężkie w wielu bazach. Postgresa się nie da w ogóle sklastrować, tak…? Musisz sharde-ować samemu na poziomie aplikacji itd. To jest jakiś tam “win”. Wracając do tych benchmarków, no to jak przyjrzałem się im troszkę bliżej, to oczywiście to jest tak, że używali tego SQLite-a i używali tej swojej bazy i SQLite-a no i przy tysiącu rekordów wystawionych do bazy, to byli 1000 proc. szybsi. Tylko, że to dla mnie też jest taki dziwny use-case, że wstawiamy sobie 5 tysięcy rekordów do bazy… To jakby w przypadku SQLite-a to jeszcze może jest jakiś sensowny benchmark, ale w przypadku Mongo moim zdaniem, to już nie jest żaden sensowny benchmark - włożenie pięciu tysięcy obiektów do bazy. I wiesz, porównujemy czas tego. I to jest takie totalnie syntetyczne, bo baza produkcyjna po jakimś tam czasie, a bazy żyją długo, to nie jest to 5 tysięcy rekordów, nie. I bardzo dużo rzeczy trzeba brać pod uwagę. Ja nie mówię że Mongo to jest jakiś “state of the art”, bo nie jest. Ale myślę, że przeżyło troszkę więcej niż jakiś benchmark 5 tysięcy rekordów.Także te benchmarki, to średnio widzę. Ale jest właśnie parę ciekawych rzecz, np. z tym klastrowaniem. To, co mówiłem ci przed chwilą. No i druga rzecz, która jest ciekawa, to jest data model jaki oni przyjęli. I ten ostateczny data model jest taki, że każdy atrybut jest zapisywany w osobnym indeksie, jakby w osobnej bazie. Czyli wysyłając obiekt który ma pięć pól, to tak naprawdę masz pięć plików i każde pole w swoim pliku. I każde pole jest jakby osobnym key-value store-m.

Bartek Witczak: Ok, a to jest cała baza key-value store tak?

Marek Piechut: Ona jest takim mixed-model. To znaczy, to jest taki dokument store bardziej. Mieszanina SQL-a i document store-a. Czyli możesz to wszystko traktować jak SQL, ale może też taki zwykły dokument store z tego robić takie jak mongo. I to jest dosyć ciekawy patent, bo nagle się okazuje, że oni się tym chwalą, chociaż nad tym zastanowić, to może niekoniecznie. Że przez to nie potrzeba w tej bazie indeksów, bo każdy ten atrybut jest po prostu sterowany osobno, w posortowanej kolekcji. Czyli, miałoby to wyglądać tak jakbyśmy mieli same indeksy w Postgresie.

Bartek Witczak: Ok.

Marek Piechut: …że nie masz w ogóle żadnej tabeli z danymi, tylko same indeksy.

Bartek Witczak: Czyli to jest tak, że każdy atrybut ma osobny plik, ale rozumiem, że to wygląda w ten sposób, że jeżeli będziemy mieli jakąś tam kolekcję obiektów,no to każdy plik będzie po prostu dzielił, w sensie każdy plik osobny będzie miał te atrybuty jednego typu, tak? Dobrze to rozumiem?

Marek Piechut: Znaczy będzie miał jedno pole. Czyli tam np. będzie samo name usera.

Bartek Witczak: Ale będzie name jednego usera, czy będzie name wszystkich userów?

Marek Piechut: Jakby name wszystkich userów, powiedzmy.

Bartek Witczak: Ok, dobra.

Marek Piechut: I to jest taki moim zdaniem ciekawy patent, z tym żeby trzymać rzeczy w ogóle myśląc tak sobie abstrakcyjne o pomyśle na bazę danych. Ciekawy patent, żeby żeby robić coś takiego, że np. olewamy wszystko, mamy same indeksy. Ten model, jak nad tym troszkę więcej się zastanowić, to to jest dosyć ograniczające. Po pierwsze, dlatego, że ja nie wierzę w super wydajność zapisywania w takiej bazie danych, bo nagle okazuje się, że masz 500 indeksów do utrzymywania…

Bartek Witczak: Dokładnie

Marek Piechut: …których właściwie nie potrzebujesz, ale je masz.I druga rzecz jest taka no spoko, że oni mówią, że wszystko jest poindeksowane, ale nie zawsze twoje indeksy są takie prymitywne. Nie zawsze to jest indeks stylu po tym polu i koniec…

Bartek Witczak: Zgadza się

Marek Piechut: …i tracisz możliwość tworzenia takich indeksów złożonych itd itd. Albo w jakichś bazach bardziej rozbudowanych, to indeksów które na funkcjach bazują, które w jakiś przekształconych danych działają, itd. I w ogóle nie masz takiej mocy, ale z drugiej strony ta koncepcja z tym, że jest cała baza są same indeksy po jakimś id joinowane, to jest całkiem ciekawy pomysł.

Bartek Witczak: No dobra, a powiedz mi taką rzecz jak ty sobie trochę myślałeś o tej bazie. Po tych wszystkich artykułach, benchmarkach, to zastanawiałeś się nad tym, kiedy w ogóle taka baza, jaki byłby dobry juse case takiego modelu?

Marek Piechut: Z tymi indeksami? Nie wiem, tylko z grubsza myśląc, to jest dosyć ciekawy use case, patrząc na to z punktu widzenia w jakich typowych aplikacji tam biznesowych, że masz po prostu suche dane, i je wyciągasz, i jakoś tam na nich operujesz. Jest to dosyć ciekawy ciekawy model.

Bartek Witczak: A to powiedz mi jeszcze jedną rzecz, bo ja cały czas nie wiem, czy ja to dobrze rozumiem. Czy to jest tak, że jeżeli chcę wyjąć już powiedzmy sobie całą krotkę, cały dokument, to musimy jakby czytać z kilku plików?

Marek Piechut: Tak, to musisz czytać z tylu plików, wiesz…

Bartek Witczak: Ile atrybutów tak?

Marek Piechut: Ile jest atrybutów. I to jest ciekawe, bo to się klastruje, więc jeszcze możesz czytać z Node’ów różne atrybuty. To też jest ciekawy patent, że przy takim modelu klastrowania twój parcer musi wybrać Node’y do których uderza potem nie, że masz zparcowane do jakiegoś AST tego SQL powiedzmy, bo tam nie tylko SQL możesz pytać. Potem nagle się okazuje, że ty uderzać do kilku Node’ów.

Bartek Witczak: Brzmi jak bardzo szybki system.

Marek Piechut: Wiesz, to jest system który może skalować zajebiście. On nie jest szybki, ale może zajebiście skalować. Także wiesz, tak jak mówię to są takie ciekawe rzeczy. Dla mnie to podejście z tym, że to jest w Node, jest szalone. Ale jakby model tego jak zacząłem czytać coraz więcej o tym to okazuje się, że ten model ma ręce i nogi, że to nie jest wcale tak, że tam dwóch szalonych gości usiadło i powiedziało “Choć zrobimy bazę danych, bo mamy wolny weekend” i oni usiedli i mówią- “Ty, umiesz w czymś programować?” -“W Node.” -“No to w tym zrobimy.”

Bartek Witczak: My akurat nie mamy wolnego weekendu. Ale to brzmi jak coś ciekawego do zrobienia, to może…

Marek Piechut: W wolny weekend…

Bartek Witczak: …Wybierzemy jakiś inny język…

Marek Piechut: Tak…losowy jakiś. Słyszałem, że można w tym postscript programować, w języku do drukarek.

Bartek Witczak: RAM 4 weźmiemy, i coś tam wybierzemy.

Marek Piechut: Moje pierwsze what the fuck,był taki dokładnie, że jacyś goście się spotkali, i programowali w Node więc napisali coś w Node, ale potem jak zacząłem zaglądać, to tam jest dużo ciekawych takich różnych pomysłów. Może wyjdzie im coś z tego ciekawego. Pewnie ten Node będzie ostatecznie takim wrzodem na tyłku, wydajnościowym.Chociaż niekoniecznie bo, ten data Store jest jednak nie w Node.

Bartek Witczak: Właśnie, bo to może skończyć się tak, że oni zostawią, że to jest w Node napisane, coraz więcej kodu zaczną przenosić do C i skończy się tym, że parę operacji odczytów jest w Node, a reszta idzie już na maszynie.

Marek Piechut: Myślę, że pewnie warto by było ten parser SQL przerzucić do C, bo on pewnie dramatyczny miałby wynik, jeżeli chodzi o poprawę wydajności. Ale reszta logiki to lutowanie do tych węzłów klastra itd. tam akurat nie wiem, czy jest tak dużo do wygrania, nie..? Mówię, to jest ta część ściemy, że to jest baza Node, jeżeli jest jakaś biblioteka, która pisze w C i w natywnym kodzie ona pisze na dysk, bo właśnie tego sobie nie mogłem… chociaż dobra w sumie te wszystkie operacje, które jakby nie są czystym odczytem i zapisem są robione w pamięci w tym Node. Ja jestem bardzo ciekawy jak wygląda zużycie pamięci w takiej bazie przy takim prawdziwym workloadzie. Dlatego benchmarki są świetne, bo puszczamy sobie 10 querysów i one sobie idą jeden po drugim i mierzymy czas końcowy, ale w prawdziwym workloadzie, gdzie w jakiejś aplikacji sensownej to tam idą setki, tysiące zapytań naraz.

Marek Piechut: Masz duży data set i to też jest taka akcja, że o mamy 10 tysięcy rekordów. No świetnie, że macie 10 tysięcy rekordów, ale weź posortuj teraz w pamięci jak masz ich milion. To są takie rzeczy, że jak to wrzucisz w Node’a, to może eksplodować przy każdym zapytaniu, jak ty im powiesz, że posortuj mi po czymś. Albo jakieś zapytania przestrzenne, bo oni też tam robią zapytania przestrzenne. I teraz nagle okazuje się, że po podstawowym sprawdzeniu geometrii pasują ci tam miliony obiektów i potem musisz to wszystko zaciągnąć do pamięci odfiltrować i dopiero odesłać. I takich benchmarków jestem ciekawy.

Bartek Witczak: To znaczy w ogóle jestem ciekawy, jak to wygląda rzeczywiście w takim sensie jak to jest napisane, bo też to może być tak,że dobra mamy napisane system w Nodzie i nie wiem, oni tam korzystają bardzo mocno z jakiś child procesów i spawnują sobie tych procesów mnóstwo. I gdzieś to się tam wszystko odkłada. Ten Node sobie tam chodzi jakby relatywnie dobrze. Bo to też jest taka akcja co mówisz, jeżeli tam będzie kilkaset czy kilka tysięcy requestów naraz i wszystko miałoby tam iść w jednym wątku, to dosyć szybko tam zaraz się zapcha wszystko, nie…?

Marek Piechut: Nie no, niech nawet nie idą w jednym wątku, tylko że nagle się okazuje, że Ty potrzebujesz nie wiadomo ile ramu, żeby te wszystkie rzeczy obsługiwać naraz.

Bartek Witczak: No tak, ale to jest jedna rzecz, ile ramu potrzebujesz, a druga jest, że nie możesz puścić benchmarki naraz w jakiejś tam, set czy tysięcy requestów i wiesz w jakimś tam modelu wątkowym możesz sobie…

Marek Piechut: ..że stawiasz postgresa na maszynie która ma 4 Cory i on sobie daje radę z tym, a tutaj potrzebujesz mieć 5 serwerów, żeby w ogóle to odpalić, tyle requestów naraz. Tak, chociaż chłopaki sprzedają to w chmurze, możesz sobie wykupić tylko dostęp.

Bartek Witczak: Jest taki suwak…

Marek Piechut: Jest taki suwak i wkładać do niego kartę kredytową…

Bartek Witczak: Ale ogólnie powiem ci że, bardzo mi się podobają takie rozkminy, takiego zupełnie innego podejścia do jakichś problemów, bo może to jest mało realne, że coś będzie z tego rozwiązania ale, może się okazać, że po prostu osoby jakieś tam inne wezmą część konceptów, i napiszą to sobie w innym języku. Potem ktoś znowu przyjdzie jakieś rozwiązania i okaże się że, za rok czasu będzie rozwiązanie, które gdzieś tam bazowało na tym o czym teraz rozmawiamy i co wydawało się na początku dosyć zabawne.

Marek Piechut: Bo to też jest ta kwestia, że to oni mogą tak zrobić, dlatego ten wybór Node wcale nie musi być zły. W sensie, że zaczynamy to sprzedawać tak, mamy to napisane w Node. Pewnie się okaże, że to wszystko nam eksploduje i tego właśnie chcemy, bo mamy bardzo dużo klientów, to nam eksploduje, wtedy zatrudniamy 14 programistów, oni nam piszą w Rust albo w jakimiś Objective C, w Swift, albo czymkolwiek, co się kompiluje do czegoś sensownego i powoli wymieniamy te klocuszki. Bo to też jest właśnie fajne w bazach danych jako takich, że tam te klocki są od bardzo dawna w miarę zdefiniowane, więc tam też, o parcel jest za wolny, no to wymieniamy, o te funkcje od przestrzennych tych są za wolne no to wymieniamy je, tak..?. Sortowanie czy tam wszystkie te agregujące funkcje są za wolno, o no to przepiszemy je do czegoś innego. Także to jest też szansa dla nich tym bardziej, że z tego co czytałem to właśnie oni dosyć szybko mogli wejść na rynek dzięki temu. Także, to może być może być dobra decyzja.Pewnie ona nie jest dobra na tysiąc lat, ale może to się im się sprawdzi, jako taki proof of concept. No, ale tam jeszcze Node nie grali. No tam jeszcze nie wpadłbym na to.

Bartek Witczak: Panie Marku jestem z pana bardzo dumny, naprawdę.Ciekawy temat Pan wybrał. Zupełnie coś innego.

Marek Piechut: Jest już Node w IOT, bo tam Node’a pakują na te wszystkie Raspberry PI. No i teraz jest też w bazach danych, nie…? Ciekawe co dalej.

Bartek Witczak: Jestem bardzo ciekawy jaki będzie kolejny krok. No dobra!