Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: popelar 02. 05. 2024, 11:11:56
-
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 (https://surrealdb.com). 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 (https://www.postgresql.org). Je kvalitní, umí spoustu věcí a věřím tomu, že s ní nepřijdu o data.
---
Díky :)
-
a co treba klic-hodnota databaze?
klic je cas, hodnota je namerena velicina.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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/
-
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.
-
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é.
-
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?
-
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.
-
Jsem si říkal, že se dozvím, jak používá SurrealDB někdo jiný, a skončil jsem zase u sebe 8)
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ěří.
-
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.
-
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.
Jasně ale ten storage engine klidně a ochotně uloží data, která zmršila ta vrstva nad tím. Opět příklad z MySQL. VARCHAR(5), uložím tam "Dobrý den pane Jirsáku." a v DB mám bez jediné chybičky "Dobrý". Takže storage engine nezklamal, ale přes to s tím výsledkem nejsem spokojený.
-
Jsem si říkal, že se dozvím, jak používá SurrealDB někdo jiný, a skončil jsem zase u sebe 8)
Používám, ale momentálně jen na vyzkoušení na drobný projekt kde by mi nevadila ztráta dat. Takže o zkušenosti se zatím moc dělit nemohu.
-
Jasně ale ten storage engine klidně a ochotně uloží data, která zmršila ta vrstva nad tím. Opět příklad z MySQL. VARCHAR(5), uložím tam "Dobrý den pane Jirsáku." a v DB mám bez jediné chybičky "Dobrý". Takže storage engine nezklamal, ale přes to s tím výsledkem nejsem spokojený.
Jenže tohle je tak navržené záměrně. Myslet si o tom můžu co chci, ale je to záměr, a i když to nevím, zjistím to poměrně snadno.
Takových věcí se nebojím. (Ale taky nepoužívám MySQL…) Bojím se těch případů, kdy čas od času i od lidí, kteří vědí, jak to provozovat, přijdou informace, že za nějakých nejasných okolností přišli o část dat. A všichni tuší, že tam je nějaký okrajový případ, který je špatně vyřešen, ale nikdo to nedokáže nasimulovat a opravit to. A věřím, že třeba RocksDB už takovéhle chyby nemá, protože už je dostatečně prověřená.
Navíc ani ten koncept vzít key-value databázi a nad ní postavit databázi s komplexnějším modelem není nový. A mám pocit, že se osvědčil. Takže za mne SurrealDB bere existující osvědčené věci a „jenom“ je spojuje tím správným způsobem.
Používám, ale momentálně jen na vyzkoušení na drobný projekt kde by mi nevadila ztráta dat. Takže o zkušenosti se zatím moc dělit nemohu.
Špatná zkušenost obvykle stačí jedna :-)
Já přeci jen jednu zkušenost přidám – dokumentace je zatím taková dost rozpracovaná (ale pořád se to zlepšuje). Občas je nějaká funkcionalita popsaná (i se syntaxí) třeba v changelogu nebo ve features, ale v referenční příručce to ještě popsané není. Takže pak člověk pátrá, kde teda viděl tu syntaxi napsanou. A taky se mi stalo (ale to bylo ještě před verzí 1.0.0), že něco bylo krásně popsané v dokumentaci – akorát to ještě nebylo implementované, o čemž v té dokumentaci jaksi chyběla zmínka.
-
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.
Ale takhle přesně je třeba udělaný timescaledb jako extension do pg, api pro extension je už dnes stabilní a to využívá řada firem k jeho rozšiřování. Sám pg v sobě více storage enginů nemá, ale má otevřené dveře, aby to mohli udělat ostatní.
Nj. dnes je moderní dávat vše do kubernetu vč. databází, trpí u toho všichni kromě zadavatelů.
-
Ale takhle přesně je třeba udělaný timescaledb jako extension do pg, api pro extension je už dnes stabilní a to využívá řada firem k jeho rozšiřování. Sám pg v sobě více storage enginů nemá, ale má otevřené dveře, aby to mohli udělat ostatní.
TimescaleDB je podle mne rozšíření, které ale interně ukládá data do standardního storage enginu PostgreSQL.
-
cassandra
-
A co QuestDB? https://questdb.io/
Je to time-series, je to pod apache licencí (takže žádné výpalné, kdybys chtěl vlastní cloud) a používají to už tisíce firem...
SurrealDB je cool, protože tam je rust, ale to je tak asi všechno...
-
A co QuestDB? https://questdb.io/
Je to time-series, je to pod apache licencí (takže žádné výpalné, kdybys chtěl vlastní cloud) a používají to už tisíce firem...
SurrealDB je cool, protože tam je rust, ale to je tak asi všechno...
Jako je to od vás a předchozí jedno-slovné cassandry pěkné a děkuji, ale úplně jste nepochopili smysl mé otázky. Resp. vaše odpověď by mohla být označena jako "accepted" na otázku "Jaké existují time-series databáze?". Opravdu není problém napsat do googlu "time-series databáze" a hodit sem první 2 odpovědi. Není to ale moc užitečné.
Doufal jsem, že to bude více či méně jasné už z mého prvního, případně dalších příspěvků, ale asi ne. Takže: v tomto postu se neptám na to, jestli existují time-series databáze. Neptám se ani na příklady takových databází. Ptám se na zkušenosti se SurrealDB. Ptám se na míru vhodnosti jejího použítí s přihlédnutím k tomu že většina (rozuměj ne všechna!) dat je time-series povahy.
Zmínil jsem a opakuji, že se nejedná ani o velký, ani o kritický projekt. Naopak, jedná se o projekt, který nabízí příležitost zkusit něco nového, trochu experimentovat a tudíž příliš nevadí, pokud se u toho trochu spálím.
Jedná se o malý projekt co to objemu dat i co do velikosti týmu. Není tedy potřeba optimální databáze (optimální datová struktura). Důležitější je snadnost použítí a vývoje. S tím souvisí to, že jenom a pouze specializovaná time-series databáze neobslouží další potřeby na jiné formy dat. Už jsem zmínil věci typu user settings, vypočtené charakteristiky, atd. Obecně řečeno, přestože většina vstupních dat je time-series ze senzorů atp., tak jsou tam další strukturovaná i nestrukturovaná data. Použití TS DB by tedy vyžadovalo použití ještě minimálně jedné další DB, což jde proti tomu, že to je malý projekt pro malý tým, kde prioritu má jednoduchost. Proto se nabízí použití multi-model databáze a proto se ptám na zkušenosti s asi nejnovějším přírustkem v této oblasti - SurrealDB.
Pokud k tomu umíte říct jen "existuje QuestDB" a "jediná pozitivní věc na SurrealDB je Rust", tak mockrát děkuji!
-
Jasně ale ten storage engine klidně a ochotně uloží data, která zmršila ta vrstva nad tím. Opět příklad z MySQL. VARCHAR(5), uložím tam "Dobrý den pane Jirsáku." a v DB mám bez jediné chybičky "Dobrý". Takže storage engine nezklamal, ale přes to s tím výsledkem nejsem spokojený.
Jenže tohle je tak navržené záměrně. Myslet si o tom můžu co chci, ale je to záměr, a i když to nevím, zjistím to poměrně snadno.
Takových věcí se nebojím. (Ale taky nepoužívám MySQL…) Bojím se těch případů, kdy čas od času i od lidí, kteří vědí, jak to provozovat, přijdou informace, že za nějakých nejasných okolností přišli o část dat. A všichni tuší, že tam je nějaký okrajový případ, který je špatně vyřešen, ale nikdo to nedokáže nasimulovat a opravit to. A věřím, že třeba RocksDB už takovéhle chyby nemá, protože už je dostatečně prověřená.
Navíc ani ten koncept vzít key-value databázi a nad ní postavit databázi s komplexnějším modelem není nový. A mám pocit, že se osvědčil. Takže za mne SurrealDB bere existující osvědčené věci a „jenom“ je spojuje tím správným způsobem.
Používám, ale momentálně jen na vyzkoušení na drobný projekt kde by mi nevadila ztráta dat. Takže o zkušenosti se zatím moc dělit nemohu.
Špatná zkušenost obvykle stačí jedna :-)
Já přeci jen jednu zkušenost přidám – dokumentace je zatím taková dost rozpracovaná (ale pořád se to zlepšuje). Občas je nějaká funkcionalita popsaná (i se syntaxí) třeba v changelogu nebo ve features, ale v referenční příručce to ještě popsané není. Takže pak člověk pátrá, kde teda viděl tu syntaxi napsanou. A taky se mi stalo (ale to bylo ještě před verzí 1.0.0), že něco bylo krásně popsané v dokumentaci – akorát to ještě nebylo implementované, o čemž v té dokumentaci jaksi chyběla zmínka.
Díky moc za vaše komentáře. Ad poslední odstavec: jde to asi trochu proti tomu, že říkám, že jsem ochoten experimentovat, ale přestože mě SurrealDB přijde zajímavá a souhlasím i s tím, že postavit multi-model nad key-value je v pořádku, ostatně nad čím jiným stavět multi-model.. tak mě nějvíc odrazuje (ne)vyzrálost projektu. A pokud jak říkáte, je potřeba honit informace po change-logu, release notes a dokumentaci, není to ideální.
A že to bylo ještě před verzí 1.0.0 mi v případě Surreal nepřijde relevantní, protože sami autoři říkají, že 1.0.0 u nich neoznačuje production-ready. Je v tom naopak ta snaha honit hype a vzbudit zdání, že je projekt mature. Sami naopak upozorňují (i když především na redditu, aby tím neposkvrnili svůj dojem na stránkách), že projekt ještě není prod-ready. Nevím pak, kde a jak mám hledat jistotu (věřit autorům), že (ta či jiná funkce) už prod-ready je.
Pořád to zvažuju, protože by mi přišlo škoda za rok zjistit, že už celý projekt vyzrál a je ok to použít, přičemž by můj projekt bylo potřeba migrovat (a to odůvodnitelné téměř určitě nebude). Jinak řečeno, jestli třeba ten rok nezkusit přežít porodní bolesti a začít z toho později sklízet ovoce.
Jako alternativu se dívám po ArangoDB (v tuto chvíli už je snad jasné, že se vzhledem ke specifikaci projektu dívám po multi-model db). Máte nějaké zkušenosti s touto db? Projekt je mnohem vyzrálejší, dokumentace všude haldy a popisu se většina funkcí překrývá..
-
Nj. dnes je moderní dávat vše do kubernetu vč. databází, trpí u toho všichni kromě zadavatelů.
Nejedná se o případ mého projektu, který naopak pojede na max pár lokálech v air-gapped prostředí. Ale přesto se chci zeptat, jak lépe byste řešil horizontální škálování u velkých projektů, kde navíc (ne vždy, ale přece) kubernetes pro servicy smysl dává - tzn. pokud má firma servicy v kubernetu, jak lépe byste z hlediska ops nákladů řešil databáze?
-
A pokud jak říkáte, je potřeba honit informace po change-logu, release notes a dokumentaci, není to ideální.
A že to bylo ještě před verzí 1.0.0 mi v případě Surreal nepřijde relevantní, protože sami autoři říkají, že 1.0.0 u nich neoznačuje production-ready.
Jenom upřesním, z vaší reakce mi došlo, že jsem to nenapsal úplně přesně – changelogem jsem myslel oficiální popis nových vlastností na webu, neprocházel jsem changelog v podobě jednotlivých commitů. A co se týče té verze 1.0.0 – ano, vím o tom, tu verzi jsem zmiňoval kvůli spolehlivosti dokumentace. Od verze by měla být dokumentace na webu spolehlivá v tom smyslu, že vše, co je v ní popsáno, je i implementováno. Ale stále mohou nastávat opačné případy, že něco už je implementováno, ale v dokumentaci to ještě popsáno není. Ale to nevnímám jako chybu, to je dnes u projektů s krátkým release cyklem celkem normální.
Je v tom naopak ta snaha honit hype a vzbudit zdání, že je projekt mature. Sami naopak upozorňují (i když především na redditu, aby tím neposkvrnili svůj dojem na stránkách), že projekt ještě není prod-ready. Nevím pak, kde a jak mám hledat jistotu (věřit autorům), že (ta či jiná funkce) už prod-ready je.
Ono je to těžké, co prod-ready vlastně znamená. Použil bych SurrealDB pro nějaký soukromý projekt, který ale bude používat víc lidí a selhání by pro ně bylo nepříjemné? Ano, použil – ale zálohování budu řešit tak, abych byl v případě potřeby schopen zrekonstruovat data nezávisle na SurrealDB. Použil bych SurrealDB na core bankovního systému? Ne, nepoužil, a nepoužil bych ji pro to ještě několik let, protože u takové věci požaduji i určité prověření časem. Jenže do takového místa bych nepoužil třeba ani MySQL – i kdybych odhlédl od výkonnosti nebo funkcionality. Ale nepovažoval bych ji za dostatečně spolehlivou. Ale neřekl bych, že MySQL není prod-ready.
Jedná se o malý projekt co to objemu dat i co do velikosti týmu.
Ta zmínka o týmu je za mne klíčová. Já bych do toho s týmem zatím nešel. Zkouším si to na soukromých věcech, případně to použiju u nějaké pomůcky, na které sice mohou dělat další dva tři lidé, ale tu databázovou část řeším sám. Takže je to čistě na mně, jak si poradím s dokumentací, se zprovozněním něčeho atd. Zkrátka bych do toho netahal jiné lidi, kteří nejsou na stejné vlně jako já a nepřistupují k tomu tak, že si chtějí vyzkoušet něco nového – a jsou si vědomi toho, že to občas bude průzkum neprobádaných cestiček a někdy i ústup zpět.
Jako alternativu se dívám po ArangoDB (v tuto chvíli už je snad jasné, že se vzhledem ke specifikaci projektu dívám po multi-model db). Máte nějaké zkušenosti s touto db? Projekt je mnohem vyzrálejší, dokumentace všude haldy a popisu se většina funkcí překrývá..
Zkušenost s ArrangoDB nemám. Také jsem ji zvažoval, nějaký příklad z webových stránek jsem si také vyzkoušel, zvažoval jsem ji – ale mezi tím přišla SurrealDB. ArrangoDB vnímám více jako grafovou databázi – má podporu pro procházení grafů do hloubky (takové to kamarád má kamaráda, který má kamaráda, jehož kamarád…). SurrealDB má Record link, kterým se dají vyjádřit vazby mezi záznamy, ale nemá tam to procházení do hloubky. Já to nepotřebuju a samozřejmě se to dá emulovat v aplikaci, ale za mne SurrealDB není pravá grafová databáze, ArrangoDB je.
-
Nj. dnes je moderní dávat vše do kubernetu vč. databází, trpí u toho všichni kromě zadavatelů.
Nejedná se o případ mého projektu, který naopak pojede na max pár lokálech v air-gapped prostředí. Ale přesto se chci zeptat, jak lépe byste řešil horizontální škálování u velkých projektů, kde navíc (ne vždy, ale přece) kubernetes pro servicy smysl dává - tzn. pokud má firma servicy v kubernetu, jak lépe byste z hlediska ops nákladů řešil databáze?
Málokterá databáze umí horizontálně škálovat. Zpravidla to znamená poměrně dost procesů okolo a v nich může být také chyba, to snižuje celkovou spolehlivost. V podstatně skoro nic neumí horizontálně škálovat samotné dotazy, je to trik za trikem a musíš k tomu uzpůsobit aplikaci.
On se blbě horizontálně škáluje už i blbý file storage, natož něco, co má indexy a vnitřní vztahy, zámky a oprávnění.
Pro horizontální škálování databází je hodně těžká ta část, kdy přidáváš nový node, potřebuješ odněkud pro něj získat, data, když se jedná o netriviální velikost dat trvá to prostě strašně dlouho a zatížíš s tím současnou databázi. Máloco má tohle řešeno úhledně a přesně.
S počtem databázových nodů často roste složitost vzájemných vztahů (a tím se může snížit stabilita nebo snížit observabilita), stejně tak i moderní databáze mají řadu procesů, kde počet nodů generuje O(N) nebo i O(N^2) složitost některých operací.
Kubernetes, VM a jakýkoliv podobný overlay schovává strašně důležitou věc, fsync, databáze pak neví, kdy data jsou persistována a kdy nejsou. Řeší se to strašnými kotrmelci a nutností složitě data znovu číst a ověřovat, málokdo dělá a není nic horšího než při pádu celého k8s clusteru příjdeš i o data. Raw block volumes jsou pořád v ranné fázi, ale už je možné je nějak používat, to může být řešení, pak ale budeš pinnovat disky k instanci, no, ztratíš část výhod.
Moje doporučení je prostě databázi neškálovat horizontálně, udělat jí vysokodostupnou v několika instancích, snažit se v počátku škálovat vertikálně a optimalizovat. Přidávat instance pouze v poloautomatickém režimu. Cloud databáze, které tohle papírově umí mají za sebou dost vysoké náklady na vývoj a speciální infrastrukturu, snad nikdo z velkých hráčů ty technologie nemá open source (snowflake, bigquery, Cosmos) a přitom mají také dost velké problémy se škálováním a ne vždy to funguje dobře.
Pokud už člověk nemá vyhnutí, tak v kontejnerech se mi osvědčily věci jako tidb/tikv, scylladb, cockroachdb atd. Jen to "osvědčili" znamená, že dobře funguje jejich práce v kubernetu, ne že sami nemají zase svoje chyby. Stejně tak dobře fungují in-memory databáze, logicky. Pak to ale naráží na to, že síť v kubernetu je prostě obvykle pomalá a sotva se na projektech dostáváme na 10GbE stabilní intra node komunikaci, to na HW už máme přes 100GbE běžně.
Největší problém je asi to, že drtivá většina lidí považuje fungující databázi takovou, pro kterou najdou do kubernetu operátor a která jim běží a funguje. Už ale málokdo řeší a zohledňuje hraniční případy, jak bude fungovat obnova, jak se to zachová při blackoutu clusteru, jak to bude řešit partitioning, jak se bude řešit oprava dat atd. Některým to funguje roky bez problémů a pak tvrdí, jak to je stabilní. Stabilitu ale musím prokázat a ne že se mi náhodou stane.
Z praxe mohu říct, že čím větší projekt, tím více roli hraje shardování, cachování, asynchronní replikace a verzování stavu aplikace. Prostě se dělají spousty malých databází a řeší se, jestli stav je konečný, průběžný nebo zastaralý. Tj. zase tam je nějaká logika okolo.