Zkušenosti se SurrealDB s přihlédnutím k oblasti time-series data

[popelar]

Zdravím,

narazil jsem na existenci nové databáze [SurrealDB](https://surrealdb.com/), která mě zaujala a rád bych zvážil její využití pro nový projekt. Jelikož je ale nová, není kolem ní tolik materiálů jako u jiných matadorů typu postgres. Rád bych se zde proto zeptal, jestli s ní máte někdo zkušenosti (ve zcela obecném smyslu).

Rád budu za naprosto jakékoli připomínky ať už z oblasti ergonomie provozu, vývoje, nebo benchmarky, spolehlivost, atd..

Nicméně zamýšlené použití je jako obecný datastore pro běžné věci typu user-settings, atd.. Ale především pro time-series data ze senzorů, aj. Nad daty se budou dělat i výpočty a ty se také ukládat, ale naprostá většina objemu a zpracování budou ty time-series. Realtimovost není kritická - v projektu nebude žádná okamžitá zpětnovazební smyčka. Jde spíše o zobrazování dat - takže nějaký ten sampling, filtering, atd. zkrátka typické použití časových řad.

Pokud tedy máte zkušenost i v tomto směru a uměli byste udělat nějaké stručné porovnání s dbs jako QuestDB, InfluxDB, bylo by to fajn.

---

Vyhledání výrazu "surrealdb" tady na fóru dává přesně 1 výsledek (slovy jeden výsledek), proto bych tento dotaz rád položil i přímo panu Jirsákovi:

SurrealDB. Protože má podle mne správný mix vlastností, aby se dala použít na spoustě různých projektů. Zároveň se velmi snadno používá. A věřím tomu, že s ní nepřijdu o data, protože jako storage používá existující a prověřená řešení. Ale zatím ji používám jen pro hraní, přeci jen teprve nedávno vyšla verze 1.0.0. Věřím tomu, že má budoucnost, protože od začátku záměrně kolem databáze budují komunitu, takže to nebude jen prskavka, která zazáří, nadchne pár lidí a zhasne. Doufám.

Z relačních databází PostgreSQL. Je kvalitní, umí spoustu věcí a věřím tomu, že s ní nepřijdu o data.

---

Díky

[Reklama]

[alex6bbc]

a co treba klic-hodnota databaze?

klic je cas, hodnota je namerena velicina.

[popelar]

a co treba klic-hodnota databaze?

klic je cas, hodnota je namerena velicina.

Omlouvám se, ale nepochopil jsem záměr vaší odpovědi. Ano, time-series data jsou speciálním případem key-value dat. Ano, na time-series projekt se dá použít jiná databáze a to buď specializovaná přímo na time-series, nebo jiná typu key-value, nebo klidně SQL - TimeScale je Postgres pro time-series.

Já se ale ptám na zkušenosti se SurrealDB. Máte nějaké a můžete se o ně podělit?

[petersveter]

Ak je nova tak na to kasli. Pouzi nieco co uz existuje v produkcii nejaky cas. Pozri na Timescale napriklad. Je to vlastne postgre ale s vlastnym db enginom urobenym na mieru pre time-series data. PG je overena db a ten engine uz bezi roky v produkcii. Ale nemam s tym prakticke skusenosti. Kratko som sa o TS data zaujimal ale na koniec som nemal ziaden use case na to.

PS: podla tohto https://surrealdb.com/features sa zda ze ta db je len vrstva nad inymi db. To mi pride ze to chce robit vsetko ciastocne, ale nic poriadne. Od toho by som dal ruky prec. Mozno tam bude rychla iteracia do produkcie ale v produkcii zacnes asi narazat na limity a potom zase budes musiet riesit migraciu. Takze ako som pisal, chod rovno do specializovanej TS databazy a na tieto "do it all" sa vykasli.

[Tomáš Crhonek]

PS: podla tohto https://surrealdb.com/features sa zda ze ta db je len vrstva nad inymi db. To mi pride ze to chce robit vsetko ciastocne, ale nic poriadne. Od toho by som dal ruky prec. Mozno tam bude rychla iteracia do produkcie ale v produkcii zacnes asi narazat na limity a potom zase budes musiet riesit migraciu. Takze ako som pisal, chod rovno do specializovanej TS databazy a na tieto "do it all" sa vykasli.

Distributed (SurrealKV) FUTURE

Jasně, takže nejdřív naimplementují vše okolo a potom udělají distributed :-D protože vůbec žádný projekt zrovna na tomhle nikdy neselhal a vůbec to není potřeba řešit odpočátku u každé jednotlivé featury s obrovskou pečlivostí. No nic, tak tohle na můj todo list už ani nepůjde, tohle je od počátku divný projekt.

[Reklama]

[_Tomáš_]

PS: podla tohto https://surrealdb.com/features sa zda ze ta db je len vrstva nad inymi db. To mi pride ze to chce robit vsetko ciastocne, ale nic poriadne. Od toho by som dal ruky prec. Mozno tam bude rychla iteracia do produkcie ale v produkcii zacnes asi narazat na limity a potom zase budes musiet riesit migraciu. Takze ako som pisal, chod rovno do specializovanej TS databazy a na tieto "do it all" sa vykasli.

Distributed (SurrealKV) FUTURE

Jasně, takže nejdřív naimplementují vše okolo a potom udělají distributed :-D protože vůbec žádný projekt zrovna na tomhle nikdy neselhal a vůbec to není potřeba řešit odpočátku u každé jednotlivé featury s obrovskou pečlivostí. No nic, tak tohle na můj todo list už ani nepůjde, tohle je od počátku divný projekt.

surrealdb má vyměnitelný storage engine (nad tikv nebo foundationdb už nějakou dobu funguje v distributed módu, to pouze jejich surrealkv nad rocksdb je ve vývoji, to kdybys to náhodou přečetl dál). Tikv nebo foundationdb jsou věci, které už nějakou dobu fungují různě po produkcích, tady se k tomu přidává nějaké IO, analytických engine, logický pohled přes tabulky atd. atd.

Není nad to komentovat něco z rychlíku.

Použít key-value databázi pro ukládání time-series (TS) dat je občas dost rizikové, asi rizikovější je, jak se řeší indexy, TS databáze potřebují shardovat i indexy a B-tree(+) je na to asi nejhorší volba, pro malé množství dat ok, při velkém to padá k zemi.

Timescaledb je fajn, ale zkuste si u toho udělat distributed režim, to je asi největší slabina.

Mimochodem, zrovna TikV na TS data vypadá jako jedna z těch středních cest, kdy dostanu dostatečnou flexibilitu, zároveň mám poměrně robustní základ.

[Tomáš Crhonek]

Není nad to komentovat něco z rychlíku.

No já jsem si to přečetl dál. A současně už nebylo potřeba psát víc, protože na problémy multiengine DB se v minulosti narazilo také.

Jinými slovy, co engine, to jiná feature set, takže featury A a B vůbec nikdy nemůžete používat společně. A někdo, kdo tohle neví, potom staví projekt nad A a B a potom přijde náraz v produkci.

[_Tomáš_]

Není nad to komentovat něco z rychlíku.

No já jsem si to přečetl dál. A současně už nebylo potřeba psát víc, protože na problémy multiengine DB se v minulosti narazilo také.

Jinými slovy, co engine, to jiná feature set, takže featury A a B vůbec nikdy nemůžete používat společně. A někdo, kdo tohle neví, potom staví projekt nad A a B a potom přijde náraz v produkci.

tak multiengine db je i takový postgresql nebo mariadb, že? To, že aplikace podporují více databází najednou je dnes už poměrně běžné, problémy s tím samozřejmě jsou, ale že bych to hodil rovnou do koše? Opravdu?

To, že jednu chybnou výtku nahradíš obecnou proklamací, že to může být problém jsi to moc nezlepšil.

SurrealDB si zaslouží hodně kritiky, pokud jde o pokrytí  testů, kvalitu kódu, způsob integrace enginů, ale shazovat jí jen tak, že ti to připadá špatné? Ale no  tak, myslel jsem, že jsi za ty roky už mohl dospět.

Pokud se SurrealDB nasazuje, je nutné dopředu si zvolit konkrétní engine a extenzivně si otestovat use cases nad ním. Řada problémů vzniká nepochopením jak ty enginy sami o sobě fungují. To stejné výkonnostně, některé operace nejsou pro některé typy enginů vůbec vhodné. Rozhodně se nejedná o produkt, který by vedl uživatele za ručičku, naopak je spíše hodí do davu problémů, je to nástroj a někdy až příliš low level. Když chceš hotový produkt, je tady clickhouse, elasticsearch, timescaledb, questdb atd.

[Tomáš Crhonek]

tak multiengine db je i takový postgresql nebo mariadb, že?

Psal jsem o tom před 12 lety.
https://www.heronovo.cz/report-ztrate-dat-aneb-proc-nemam-rad-mysql/

[_Tomáš_]

tak multiengine db je i takový postgresql nebo mariadb, že?

Psal jsem o tom před 12 lety.
https://www.heronovo.cz/report-ztrate-dat-aneb-proc-nemam-rad-mysql/

nj. tak to přesně vypadá, když člověk přejde z dospělé db na něco co si na db hraje, ale pořád se jedná jen o znalosti provozu té databáze, jakmile je získáš, umí sloužit dobře. U mysql/mariadb je skvělé, že vlastně vše, co jsi před 12 lety psal, platí i dnes.

To, že surrealdb je určitá fasáda nad více db jí nic na kvalitě neubírá, pro některé nasazení může být ok, nezatracoval bych jí, ale ani jí nebudu doporučovat jako tu nejlepší volbu. To ať si každý rozhodne sám.

[Tomáš Crhonek]

nj. tak to přesně vypadá, když člověk přejde z dospělé db na něco co si na db hraje, ale pořád se jedná jen o znalosti provozu té databáze, jakmile je získáš, umí sloužit dobře. U mysql/mariadb je skvělé, že vlastně vše, co jsi před 12 lety psal, platí i dnes.

Jasně, tohle podepisuju a proto na to upozorňuji. A ten, kdo chce daný produkt použít si musí být vědom všech "vlastností"  a umět s nimi pracovat. No ale pro mě, pokud už tohle vím, tak si rovnou vyberu lepší db, která tohle všechno umí a nepřekvapí mě. Pro mě je DB primárně o ochraně dat. A pokud vývojáři DB tohle berou na lehkou váhu, tak pro mě ten produkt končí jako celek. Prostě já si nechci zbytečně přidávat práci. Pro někoho může být MariaDB super skvělá v nějaké konkrétní vlastnosti a o všech problémech ví a má je vyřešené.

[popelar]

tak multiengine db je i takový postgresql nebo mariadb, že?

Psal jsem o tom před 12 lety.
https://www.heronovo.cz/report-ztrate-dat-aneb-proc-nemam-rad-mysql/

nj. tak to přesně vypadá, když člověk přejde z dospělé db na něco co si na db hraje, ale pořád se jedná jen o znalosti provozu té databáze, jakmile je získáš, umí sloužit dobře. U mysql/mariadb je skvělé, že vlastně vše, co jsi před 12 lety psal, platí i dnes.

To, že surrealdb je určitá fasáda nad více db jí nic na kvalitě neubírá, pro některé nasazení může být ok, nezatracoval bych jí, ale ani jí nebudu doporučovat jako tu nejlepší volbu. To ať si každý rozhodne sám.

Díky za podnětné odpovědi. Pro lepší kontext, což z mého prvního příspěvku nemusí být patrné - nejedná se o ani o velký, ani o kritický projekt. Jedná se o příležitost zkusit něco nového tam, kde případné problémy nebudou tolik vadit. U mission-critical bych samozřejmě neuvažoval o nové neznámé databázi..

Osobně nevidím žádný zásadní problém v tom, že aktuálně SurrealDB používá jiné db enginy a vlastní má teprve ve vývoji. Co mě asi ve výsledku odrazuje víc, je aktuální stav projektu. Kdy po projetí různých vláken po internetu na Discordu, Redditu, atd. to vypadá, že firma dosud věnovala nepoměrně víc usílí hypu než vývoji a tomu odpovídá kvalita knihoven, dokumentace, atd.. Mám chuť zkoušet nové zajímavé věci, ale ne asi ne za cenu vysloveně experimentálního vývoje bez doprovodné dokumentace.

Co mě na marketingové stránce zaujalo je ten "multi-model" db, kdy bych to mohl použít na všechny aspekty tohohle menšího projektu. To, že pro každou jednotlivou část projektu existuje lepší, možná dokonce optimální databáze na míru, pro mě nemá takovou cenu jako fakt, že bych mohl mít jednu na všechno včetně REST, graphQL, RPC komunikace out-of-the-box. Menší výkonnost celého systému by mě u daného projektu taky netrápila.

Aktuálně jsem v rozpoložení, že dám SurrealDB šanci zase třeba za rok, až bude projekt v pokročilejší fázi. Máte nějaké doporučení na jinou db, která by mohla obsloužit můj záměr - to jest především jedna db na všechno i za cenu, že nebude excelovat v ničem? Tenhle projekt se opravdu nehodí na to, abych měl 2 hlavní db - sql + time-series jako úložiště, před tím redis, před tím kafku, atd. atd. atd.. Něco tam je na sql, něco tam je na document-db, hlavní ingress je time-series. Je třeba ten posgres + timescale zajímavou variantou?

[Tomáš Crhonek]

Osobně nevidím žádný zásadní problém v tom, že aktuálně SurrealDB používá jiné db enginy a vlastní má teprve ve vývoji.

Já taky ne. Jen jsem upozornil na problém, že různé engine mohou umět různé věci a tedy nelze očekávat kompletní feature set.

Co mě asi ve výsledku odrazuje víc, je aktuální stav projektu ... firma dosud věnovala nepoměrně víc usílí hypu než vývoji

Ano, tenhle pocit jsem měl x let nazpět z MongoDB. Měl jsem to v kategorii "nutno prozkoumat" až do momentu, kdy změnili licenci na komerční (2018). Tak už to nikdy nepoužiju.

Máte nějaké doporučení na jinou db, která by mohla obsloužit můj záměr - to jest především jedna db na všechno i za cenu, že nebude excelovat v ničem?

Já takto provozuju PostgreSQL. Ale pozor, já to mám vždy na vlastním HW. I díky této diskusi, kdy Tomáš psal, že i pg je multiengine - ne není, má jen api v nějakém stavu (asi stále devel), kdy je možné si napsat vlastní storage engine. Co jsem našel, tak naposledy to někdo zkoušel v roce 2019 a před tím EDB (komerční postgres) v roce 2013. A nejvíce diskusí jsem našel u lidí, kteří to chtějí provozovat na cloudu a jde jim doslova o každý 1kB (někdo psal kompresní storage + delta změny místo MVCC). Já mám postgresql na vlastním hw a jestli ta DB má 4TB nebo 10TB je mi celkem jedno.

[Filip Jirsák]

Jsem si říkal, že se dozvím, jak používá SurrealDB někdo jiný, a skončil jsem zase u sebe

Praktické zkušenosti z provozu zatím nemám, zatím si s tím jen hraju. Jediná aplikace, kterou nad tím mám, má asi čtyři uživatele, tři tabulky a třicet záznamů. (Nicméně dost databází už mne odradilo i v této fázi nebo už dřív).

Podporu pro timeseries data mají teprve plánovanou v budoucích verzích, takže pokud to má být jádro vaší aplikace, velmi bych to zvažoval.

To, že podporují různé storage enginy, je za mne plus – používají praxí prověřené enginy, u kterých už se dá věřit tomu, že nebudou ztrácet data. Když se píše storage engine od nuly, vždycky je to na začátku trochu dobrodružné, zda tam nebudou nějaké okrajové případy, při kterých ten storage engine selže.

Co se týče stavu projektu – od začátku kolem toho budují komunitu, což je pro mne sympatické. Není to „něco ukuchtíme za zavřenými dveřmi a pak vám to milostivě dáme“. Že není dokumentace nebo knihovny úplně skvělé je pravda, nicméně každý projekt má nějaké omezené zdroje, a chápu, že teď jdou zdroje hlavní do vývoje samotné databáze. Databáze má REST a WebSocket API, takže napsat si vlastního klienta není těžké – a vývojáři SurrealDB ať se raději věnují samotné databázi. Každopádně ten vývoj jde dost rychle dopředu, za pár měsíců to celé bude vypadat zase dost jinak.

Já té databázi věřím a když budu potřebovat multi-model databázi na nekritické použití, použiju SurrealDB. Ale tohle už je na povaze a zkušenostech každého, já bych také nedal na to, že někdo v diskusi napíše, že té databázi věří.

[Tomáš Crhonek]

I díky této diskusi

Oprava: I díky této diskusi jsem si našel články o tom, jak lidé chtějí postgres používat na cloudu.