Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - popelar

Stran: [1] 2 3
1
Hardware / Re:Koupit teď Mac mini M4, nebo čekat na M5?
« kdy: 12. 03. 2026, 16:49:55 »
Já bych počkal ...

osobně bych uplatnil obecné pravidlo nákupů výpočetní techniky: pokud vyloženě nemusím nakupovat teď hned nebo není jasné, že ceny půjdou dlouhodobě prudce nahoru, nákup co nejdéle odložit.

Ano, rozhodl jsem se počkat. Minimálně si srovnám nabídku, uvidím, s čím přijdou. A třeba potěší i drobným bonusem v podobě N1 chipu v základu. Drobné riziko vnímám v probíhající hw inflaci, ale tak snad to u Applu nebude tak hrozné. Případně bude lze ještě koupit i staší M4 ze skladových zásob a já na to opravdu nespěchám  8)

2
Hardware / Re:Koupit teď Mac mini M4, nebo čekat na M5?
« kdy: 12. 03. 2026, 16:46:38 »
Co počkat rovnou na M6 či M7? Nebo může počkat až dokud nenatáhne bačkory, pak ušetří nejvíc...

Tzv. argument do krajnosti, resp. continuum fallacy. Váš příspěvek je vším možným, jen ne věcný. Domnívám se, že to je pro vás forma zábavy, tak si užijte, že vám na to reaguji  ;)

3
Hardware / Re:Koupit teď Mac mini M4, nebo čekat na M5?
« kdy: 09. 03. 2026, 09:18:25 »
co se tyce ceny tak na hladine kolem 20tisic asi fakt muze byt vetsi rozdil. treba nove macbooky pro a max sice jsou trochu drazsi ale maji v zakladu 2x vetsi ssd a i konfigurace RAM se trochu zvedla - treba M5 max s 40 gpu cores zacina na 48GB RAM a 2TB disk, tam za ten priplatek oproti podobnemu M4 max modelu (36GB RAM, 1TB disk) clovek aspon neco dostane navic

Pro testování lokálních LLM bych počkal. Osobně mám Mini M4 Pro a už jsem i chvíli přemýšlel nad upgradem. U Applu je podle mě lepší kupovat základní model vyšší řady než přidávat RAM a uložiště k nižší řade. Stejně je těch 24GB málo protože kontext taky něco zabere, takže dám radši pár dolarů openrouteru pokud nepracuji s firemními daty.

S tím se neztotožňuji. Základní mocel Mini M4 (17k) + 24 GB ram příplatek stojí 21k. Zatímco Mini M4 Pro začíná na 41k (a má shodných 24 GB ram, plus ten 512 disk, ale to nepovažuji za podstatnou výhodu vzhledem k síťovému úložišti). Takže takřka dvojnásobek ceny. Ano, HW sice rychlejší, ale asi to osobně nepovažuji za stroj na doma (viz účel v prvním příspěvku) za odůvodněné. Cenově mi prostě základ za 17 přijde jak super universální stroj prakticky zadarmo. S drobným příplatkem za větší kontextové okno (24 GB) za 21k mi to přijde pořád jako skvělý kauf. 41k na druhé straně už vyžaduje odůvodnění takových nákladů a to se u mě nekoná..



Podle me na sdílený PC na doma jako "pracovní stanice" pro běžnou činnost, občasné hraní, zpracování fotek a videí, client pro připojovaní na pracovní dev stroj, plus nějaké to domácí programování staci M4. Sam pouzivam M1 Pro z 2022 a s vyjimkou hrani (hry nehraju) mi zatim staci (delam presne takovou domaci beznou cinnost, vc. programovani).

Na testování local LLM bych se rozhodoval mezi (min) M4 Pro a M5 Pro. M5 Pro je nove ohlasene, ale za chvilku uz budou na netu vykonova srovnani obou dvou a pujde z toho poznat o kolik moc je M5 Pro vykonnejsi - podle toho se rozhodni. Apple nema moc ve zvyku zdrazovat existujici modely, spis zdrazuje uvedenim novych, takze bych byl klidny ze az do ohlaseni dalsiho eventu budes moct M4 Mini koupit za stavajici ceny - a to ti da cas pockat na benchmarky a rozhodnout se.

To je trefná poznámka. Až na ten usecase LLM bude M4 bohatě dostačovat.. Vzhledem k cenám, viz výše, mi teda dává smysl si počkat na porovnání nákladních modelů M4 vs M5. Příplatek 100 % za občasné testování není odůvodněný. A když bych chtěl s modely dělat víc, stejně bych potřeboval jít do mnohem vyšší kategorie, především s pamětí..

jestli tomu dobre rozumim tak NPU na apple silicon je pro LLM nepouzitelne jak vykonove tak ani Apple nenabizi zadne rozumne API takze softwary typu llama.cpp NPU nepouzivaji. na M4 to jede na GPU pres Metal API. Pokud ty nove AI funkce noveho M5 GPU jsou dostupne pres stejne API mohlo by to jet 4x rychleji nez M4 jak rikaji, ale zadne benchmarky nebo potvrzeni ze je to takto pouzitelne jsem zatim nevidel (ale ani nehledal)

Hmm, taky přesně nerozumím, co od toho čekat. Dává asi smysl počkat na praktické testy.



Myšlenku chápu a protože dotaz zní jestli koupit teď nebo počkat, pak mi vychází, že tu není urgence koupit dnes.
Tím pádem M5 i když vyjde třeba až na podzim, bude mít delší životnost (pokud je v plánu vyždímat do konce životnosti). M4 pro popisované účely poslouží stejně dobře. Apple říká, že se Mac mini bude vyrábět (sestavovat) v USA letos. To tedy vypadá právě na podzim (bez záruky). Asi nic jim nebráni uvedení okolo WWDC. Ohledně paměti to udělalo čáru přes rozpočet nejen apple.
Otázkou tedy je jak moc to spěchá :)

Ano, přesně tak  :). To mi, ještě v souvislosti s jinými příspěvky, připomnělo vtip, že: na světě jsou 2 typy lidí – ti, kteří dokáží interpolovat z neúplných dat.

Životnost ve své podstatě nebude delší, ale jen začne později a tedy skončí později. Takže jak říkáte, je jen otázkou, kdy do toho vlaku naskočit. Skoro bych řekl že v oblasti 20k ta životnost není důležitá (a také v kontextu Apple, u kterého je to s životností, resp. relevantností zkrátka lepší, stejně tak s prodejem staršího hw, atd..)

4
Hardware / Re:Koupit teď Mac mini M4, nebo čekat na M5?
« kdy: 05. 03. 2026, 14:48:13 »
Zapomněl si napsat, proč si chceš koupit nový počítač - současnou situaci.

Účel jsem popsal. Současná situace s tím podle mě nesouvisí. Zkrátka jsem se rozhodl pro nový počítač a to konkrétně Mac mini. Dotaz je jen na výběr mezi současnou a novou variantou. Víceméně ani ten účel není podstatný, ten jsem si vyhodnotil sám a počítač dostačuje/je ideální. Zajímá mě spíš názor na samotnou koupi. Možná někdo přemýšlí nad stejnou věcí. Zda čekat neznámo dlouho na o trochu lepší verzi, nebo naopak zlepšení považovat za neopodstatněné a vzhledem k ostatním rizikům koupit hned současnou.

Jasný flame. Nejlepší je samozřejmě koupit normální ntb s Ryzenem 7840HS nebo lepším HX a nahodit tam Arch.

Vy se běžte někam nadýchat čerstvého vzduchu  ;)

5
Hardware / Koupit teď Mac mini M4, nebo čekat na M5?
« kdy: 05. 03. 2026, 13:00:39 »
Zdravím, řeším dilema zda koupit teď Mac mini M4, nebo počkat na novou M5 verzi.

Účel: sdílený PC na doma jako "pracovní stanice" pro běžnou činnost, občasné hraní, zpracování fotek a videí, client pro připojovaní na pracovní dev stroj, plus nějaké to domácí programování a spíše testování local LLM.

Co jsem zjistil: M5 Mac mini je víceméně potvrzený, Mark Gurman ho v listopadu zařadil do roadmapy 2026 a v prosinci se v uniklých Apple souborech objevily identifikátory M5 a M5 Pro Mac mini. Apple právě (4. března) představil MacBook Air M5 a MacBook Pro M5 Pro/Max, Mac mini ale stále chybí. Nejoptimističtější odhady říkají jaro 2026, ale může to být klidně i WWDC v červnu, nebo později. Takže to čekání je s nějakou mírou nejistoty.

Rychlejší GPU (benchmarky z MacBook Pro ukazují +45 %), vyšší paměťová propustnost (120 GB/s u M4 vs 153 GB/s u M5, tedy +28 %) a pravděpodobně 512 GB SSD v základu místo současných 256 GB. Jenže základní cena taky nejspíš půjde nahoru – minimálně o 100 dolarů, a to ještě před započtením inflace a aktuálních tarifních turbulencí.

Hodně se mluví o Neural Acceleratorech, pochopil jsem to zhruba takto: U M4 funguje AI akcelerace přes samostatný Neural Engine (NPU) – separátní blok na čipu, ke kterému data musí cestovat z GPU. M5 to dělá jinak: Neural Accelerator je zabudovaný přímo do každého GPU jádra, takže maticové operace (základ většiny ML výpočtů) probíhají přímo tam, kde GPU pracuje s daty. Díky tomu Apple hlásá 4× rychlejší AI výkon – ale to platí hlavně pro M5 Pro/Max oproti M4 Pro/Max, a navíc jde o peak compute čísla. Pro reálné lokální LLM je situace střízlivější: generování tokenů je z velké části omezeno paměťovou propustností, takže tam se projeví hlavně těch +28 % bandwidth. Apple sám na svém ML blogu publikoval benchmarky (MLX framework) a výsledek je +19–27 % oproti M4 – prostě rychlejší, ale ne dramaticky. Jestli čekat 42 nebo 52 sekund, rozdíl to je, ale odskočíte si od počítače v obou případech.

Síťový čip N1 (Wi-Fi 7, Bluetooth 6), který je nově v MacBook Air M5, by u Mac mini měl být asi jen v Pro variantě, ne v základu – aspoň podle dosavadních úniků.

Takže jak to vidíte vy? Má smysl čekat na M5 za nejistých podmínek a nejistého data vydání, nebo prostě vzít současný M4 za dobrou cenu? Bral bych základní variantu  + 24 GB ram, 256 GB SSD (další storage přes TB a síť) za 21.5k..

Uvítám názory, případně zákulisní info, které jsem přehlédl. Díky

6
Netuším, jak je to s licenčním užitím, ale jde si koupit IPC - průmyslový počítač s touto licencí. Dá se takto pořídit za 20k už i s licencí. Jako bonus je to počítač, který opravdu vydrží.. 👌🏻

7
Server / Re:Je toto díra v Dockeru?
« kdy: 19. 07. 2024, 09:17:11 »
Na hostitelském počítači, jako běžný uživatel, který je ve skupině "docker", si vytvořím kontainter, v tomto kontaineru mám root.
pokud do tohoto kontaineru nasdílím nějaký adresář hostitele,
docker run -v ...
Tak mohu z kontaineru do tohoto adresáře hostitele vytvářet soubory, které se na hostiteli tváří, že je vlastní root.
Navíc mohu takovémuto souboru z kontaineru nastavit s-bit .

Není toto díra ?


Je potřeba s tím počítat. Já na prod používám výhradně root LESS podman. Je s tím více prcání, především pokud autoři container image počítají s tím, že container poběží jako root, ale za tu bezpečnost to stojí.

8
Jenom bych si dovolil upozornit na takovou drobnost: 75k hrubeho HPP neni zase tak odlisne od 115k IČO. Kazde ma sve vyhody i nevyhody.

Já jsem se v těchto výpočtech nikdy přesně nevyznal, ale vychází mi tam rozdíl cca 30k čistého ve prospěch IČO (75k HPP - 54k na ruku; 115k IČO - 84k na ruku). Můžete nějak rozvést svůj výpočet?

9
Ahoj, pročítal jsem zrovna root a napadlo mě znovu otevřít toto téma. V podstatě, tvoje zpráva byla naprosto výstižná. Musel jsem prostě obepsat firmy, projít si pohovory a vybrat si mezi nabídkama. Zadarmo to nebylo, pohovorů bylo několik, v různých firmách. Paradoxně mě přijali tam, kde mi přišlo, že jsem měl nejmejší šanci na úspěch. Kdežto tam, že mi přišlo, že bych se hned uchytil mi řekli, že nejsem dost seniorní.

Každopádně, původně jsem tady na rootu začal brečet, že mám málo, kvůli tomu, že mi šéf nabídl 30k hrubého. Ukecal jsem ho na 38k hrubého (+ asi 2k stravenky) a po pár měsících jsem to vzdal, protože jsem dělal nesmyslně moc práce za málo peněz a přitom jsem necítil žádnou značnou přidanou hodnotu mé práce.

Job, kterým jsem to vyřešil, mi hodil 70k hrubého, po půl roce mi přidali na 75k, pak najednou utlumili hiring i navyšování mezd. Jde o ecommerce, takže přidaná hodnota taky za mě nic extra, ale určitě jsem udělal dobře, že jsem do toho šel.

No a ted mě čeká poslední měsíc v této práci a přecházím na IČO, mám pomáhat jednomu startupu za 115k měsíčně.

Tento vývoj jsem určitě nečekal, když jsem tento příspěvek původně psal ... Měl jsem naprosto uměle nastavené nějaké své hranice a ambice, což byla obrovská chyba. Jsem rád, že mi to došlo a usilovně pracuju na tom, abych nebyl lopata...

Ahoj, je super, že jsi sem dal po ~2 letech informaci, jak to dopadlo. A ten postup je dost inspirativní. Před tím jsi váhal, jestli je 30k v poho a teď už pojedeš za 115 - moc pěkné.

Sám na takový vývoj taky čekám. Resp. jsem v té fázi, kdy dělám pro jednu firmu za mrzké peníze a dokud v ní budu, nezmění se to. Ale je to poměrně unikátní pozice svou náplní a tak toho prozatím využívám s tím, že ty zkušenosti zužitkuju následně jinde.

Mohl bys rozvést, jak náročné bylo sehnat tvou aktuální pozici? Tj. z kolika pohovorů vzešla, jak jsi ji našel, atd.? Díky :)

10
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?

11
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á..

12
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!

13
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?

14
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?

15
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 :)

Stran: [1] 2 3