Vlákno názorů k článku evitaDB: spuštění, definice schématu a naplnění daty od trehak1 - Ja se obavam, ze je to zbytecna prace.
-
Taky tomu moc nerozumím.
Je to financované EU, takže vlastně nevím, jestli jen ten grant drží ten projekt při životě a autoři to zabalí až příjem vyschne, a nebo to má nějaký větší potenciál.
Jde mi o to, že ta databáze třeba může být dobrá, ale pokud se ten projekt neuživí a skončí, tak chudáci ti, kteří to v něčem použili - budou muset migrovat a to bude práce navíc.
1. 2. 2024, 11:19 editováno autorem komentáře
-
Pro tyto jednoúčelové speciály nemáte moc náhradu. Většinou to řeší něco, co se v SQL dělá extrémně špatně, a výsledek může být pomalý a může vám přetěžovat db. Nejsem expert na e-shopy, takže mohu být mimo, ale řekl bych že tato db cílí na eshopy typu alzy nebo mall.cz. Velké a hodně zatížené. Tam pokud budou mít zájem, a licence to dovolí, budou mít bezproblémově kapacity, aby případně pokračovali ve vývoji. Tyto databáze nejsou extra komplikované, a šikovný (třeba ne průměrný) programátor si s nimi poradí.
-
Rekl bych, ze predstava, ze si provozovatel libovolne aplikace bude sam vyvijet nejakou libovolnou databazi je hodne naivni. Zcela bez ohledu na velikost.
Naopak, pokud ma firma svepravne vedeni, tak nebude nasazovat zadnou technologii, ktera neni na trhu dostatecne dlouho a neporadi si sni dostatecne velky pocet lidi/dodavatelu.
Jednoduse proto, ze nechce kazdych par mesicu resit, ze to uz zase umrelo nebo odesel jediny clovek, ktery o tom neco vedel.
-
To platí za předpokladu, že je na trhu nějaká technologie, kterou si můžete koupit, a která vám vyhovuje, a která je na trhu dost dlouho. U jednoho projektu, kterého jsem se účastnil jsme řešili neskutečně dlouho problémy s nasazením jedné analytické databáze, tehdy 10 let starý produkt, v majetku velké korporace. Tři roky trvalo, než se podařilo tento produkt nasadit - odladit chyby, stabilizovat. Za tu dobu by si firma jednoúčelovou colum store databázi napsala bez problémů. Produkt neumřel, ale dostal jiného majitele, který se snaží vytěžit, co jde, takže bez ohledu na podepsané smlouvy změnil licenci, změnil ceny, a ta firma musí nakonec tento produkt stejně opustit. To by se u vlastní databáze nestalo.
Je důležité si uvědomit, že jsou různé typy databází s různou složitostí. V momentě, kdy například nemusíte řešit plný ACID nebo máte např. append only data, tak napsat si vlastní databázi není až tak pracné. Dnes navíc nemusíte psát 100% kódu - na hromadu komponent databáze jsou knihovny, můžete vzít existující řešení a to si upravit, nebo napsat extenzi do Postgresu nebo MySQL. Na druhou stranu to znamená, že musíte mít vývojáře i management, který je v obraze a rozumí technologiím - což může být problém.
Nemá cenu si psát vlastní řešení, které je k dispozici za rozumných podmínek a rozumnou cenu. Pokud ale už musíte hodně znásilňovat nějakou technologii, tak je lepší si napsat vlastní db - i když to může být jenom knihovna, nebo nějaký wrapper - a in memory db jsou jednoduché.
-
U vlastni, nejen databaze, to bude vypadat tak, ze nejprve se rekne "to si napisem sami, vzdyt na tom nic neni" (tedy toto prohlasi mlady dynamicky menezr).
Pak se typicky zacne z voleje bez dalsiho psat, a ti co to psat budou budou vznaset cim dal zaludnejsi a cim dal neresitelnejsi dotazy na tema "a jak se ma resit to ci ono".
Cely projekt se bude cim dal vice zadrhavat a zpomalovat.
Po 3 letech bude nejmene 1/2 lidi kteri u toho na zacatku byli davno pryc. A ta druha uz nebude vedet, jaky ze problem to vlastne maji resit. Ale protoze to stalo hromadu clovekohodin a hromadu milionu .... tak se to prece musi nasadit.
Den po nasazeni odejde posledni z tech co o tom neco vedeli. Pak to bude par mesicu ci let pekne hnit a presne v okamzeni, kdy se nekde neco zmeni, protoze to prece na nic nemuze mit vliv, to cele lehne.
Psat si vlastni reseni nema smysl prakticky nikdy, protoze je porad lepsi zabijet klince sroubovakem, nez stavet kovarnu abych si vyrobil kladivo.
Pokud priklad konkretne na tema databaze, tak v libovolnem korporatnim prostredi se chce, aby data byla konzistentni. Napsat databazi tak, aby toto splnovala , je vsechno mozne jen ne snadne.
-
Ano v mnoha případech máš pravdu. Nestabilní tým, projekty pro zákazníka. Jednorázové řešení atd. To vše může produkt pohřbít.
To je důvod, proč tolik firem dělá projekty a tak málo produkty.
Uspět s produktem je těžké a jde to jedině, když budeš mít něco co jiní nemají. => musíš něco vytvořit. Klidně to můžeš dát jako opensource. Konkurence bude, ale budou to v 99 procentech lidé hledající rychlá řešení, aby se dalo fakturovat o provozování a rozvoj produktu nemají zájem.
Věř tomu nebo ne, ale existují firmy, kde jsou lidé i v dnešní době 10, 15 nebo i 20 let. Protože pracují na produktu nebo vidí cestu k produktu a jdou si za tím.
Když máš produkt, který vydělává, nepotřebuješ tolik investory, kteří tě pak prodají, protože jediné co má na světě smysl je profit. Máš čas i na zdokonalování produktu. Máš stabilitu a klid na práci.
-
Na tyhle komentáře je velmi těžké reagovat. Jistě - každý má nějaké špatné životní zkušenosti, ale s tímto přístupem by nikdy nic nového nevzniklo. Mohu Vám říct, že Vámi nastíněný příběh se tomu našemu nepodobá, ale Vy mi budete namítat opak a k ničemu rozumnému se nedobereme.
K psaní přistupujeme s respektem, nikdo z nás si nemyslí, že na tom nic není. Koneckonců na tom postupně pracujeme už pátým rokem, což už je celkem dlouhá doba na to, abychom si to dobře uvědomili. Snažíme se prototypovat, psát dostatek testů a ověřovat si naše hypotézy. Tým je možná malý, ale nápady spolu konzultujeme a snažíme si je navzájem konfrontovat, když to dává smysl.
Mě je 45 let a programuji od 18, takže jsem všechno jiné, než mladý dynamický manažer. Klínce šroubovákem jsem zabíjel tak dlouho, že mi připadá postavení kovárny jako zajímavá změna a kolegům v mém týmu taky. Máme výhodu v tom, že naše firma není korporát, takže v tom to máme asi snadnější.
-
Aha, takže psát vlastní řešení nemá smysl a všechny ty projekty co používáme napsal tedy kdo? Tunu databází co jsou open-source, programovací jazyky, frameworky atd. Hodně z toho začalo na zelené louce a v malém týmu. Nějak moc extrapolujete na základě osobních zkušeností a to Vás ještě podezřívám, že to je spíš nějaký vrozený pesimismus než zkušenost.
-
No a pak v tom stejném korporátu, kde cit. " se chce, aby data byla konzistentni" se vymejšlí, jak už jednou vytahaná data ze SAPu nebo kýblu nacpat do REDISu, protože když se to neudělá, tak to prostě nějak kolem půl deváté ráno všechno lehne na přetížení.
Fakt tohle "dumbing out" celého IT oboru jednou dopadne pěkně špatně. On měl ten Elzet s programátory a lepiči už tehdy pravdu.
-
.... ale řekl bych že tato db cílí na eshopy typu alzy nebo mall.cz. ....
vseobecne by se snad dalo souhlasit, ale ja mam u toho takovy zvlastni pocit.
Na netu je mozno si precist napr. o te Alze a tom jejich systemu a ten jede tvrde uz desetileti na MSSQL a v soucasnosti je pry mozno pouzit i pgsql nebo Mongo. T.zn. ze i takove velke shopy 'patrne' nepotrebuji nejakou specialni databazi. U Alzy napr. tu rychlost resi tak, ze servry maji 6 TB pameti.
V tech popisech tech velkych shopu je ovsem napadne, ze ta problematika neni ani tak ta databaze, ale ta komplexita cele problematiky. Ja se jako rada dalsich zde nedokazu tak nejak zbavit dojmu, ze autori to cele delaji hlavne 'rádi'. -
Jak to mají v Alze by mne zajímalo také, nicméně pochybuji, že by jeli čistě na MSSQL nebo čistě na Postgresu. Co jsem zažil, tak i v rámci jednoho projektu se používal Postgres, a MySQL (pro jiný typy dat a dotazů), do toho redis a Elastic. Zde popisovaná evitaDB není ani tak konkurent Postgresu jako spíš Elasticu. Můžete mít dost paměti, tak že kompletně všechna data a indexy budete mít v RAM, a inmemory databáze bude rychlejší (protože používáte jednodušší datové struktury - přímočařejší), a to přestože to bude naprogramované v Javě. Můžete se podívat třeba na testy MonetDB a Postgresu - a v určitých testech je Monet 100x rychlejší, a pokud by se použilo jádro, které používá vektorové zpracování dat, tak je 1000x rychlejší.
Není to proto, že by byl Postgres špatně naprogramovaný - žádná relační db není 2x rychlejší než Postgres, ale je to o tom, že pro inmemory db můžete použít jiné algoritmy a jiné datové struktury.To, že má někdo nějaký sw rád, a rád na něm dělá, je dobře. Navíc to jak to tady autor prezentuje mi přijde jako věcné, realistické, bez snahy někoho balamutit. Možná si tady ještě pár pamětníků bude pamatovat pár projektů, které prošly zdejším IT mediálním prostorem ve stylu úžasná databáze, a nový dotazovací jazyk, který nahradí SQL, atd atd. EvitaDB mi ale nepřijde jako tenhle případ. Pro mne EvitaDB není databáze, kterou bych použil, nebo se s ní někdy prakticky setkal, a stejně tak pro 80% čtenářů roota. Stejně jako se čtenáři roota asi nesetkají s proudovými databázemi nebo databázemi polí. Je to ale ukázka jak se dají dělat věci inteligentně - ne úplně otrocky. Jestli je to správné nebo ne, to záleží na kontextu.
-
Grant skončil rokem 2022 (to je dohledatelné). Rozvoj financujeme i nadále sami, protože databázi současně používáme pro vlastní potřeby. Vlastnosti databáze nám kompenzují část práce, kterou bychom museli tak jako tak investovat na stejné funkcionality budované nad "zavedenou" databází. Riziko, že se projekt jednou ukončí tu je samozřejmě vždy - ale záruku nemáte nikdy a to ani u největších společností.
Výhoda u této databáze je ta, že cílí na to být sekundárním vyhledávacím indexem - tj. primární data a primární logiku máte jinde. evitaDB vám pomáhá jen zrychlit a zlevnit vývoj frontendu + ustát peaky v návštěvnosti (a zároveň na tom neprodělat kalhoty), což je jen část Vašeho systému.
