Vlákno názorů k článku Jak nám v Alze aktualizace Windows způsobila výkonové problémy databáze od Karel - Cely problem Alzy jsou licence. Nelze skalovat do...
-
Karel (neregistrovaný)
Cely problem Alzy jsou licence. Nelze skalovat do sirky, protoze roste pocet licenci, ktere nechce platit. Dnes uz se nestavi supervykona krava s jednou zakladni deskou, ale spousta malych, snadno nahraditelnych nodu, queue a replikaci s minimem raidu, ktere umozni prezit i vypadek velke casti fyzickych serveru bez ztraty dat a hlavni funkcnosti (napr. ruzne kombinace cassandra, kafka, glusterfs, elastic, logstash, galera, maria, spark). Jde tohle na MS?
-
stará doba velkých mašin pořád ještě neumřela, exadata, netezza, teradata atd. pořád existují a pořád prodávají nové a nové.
O ty nové kombinace se snaží kde kdo, ale je to dost práce, ty databáze jsou zatím lehce nespolehlivé a někdy dost tupé, hlavní problém je chybějící integrace na všechny ostatní systémy, zatím špatná vzdělanost devops, malá univerzálnost (potřebuji zkombinovat několik technologii), občas chybějící placený support atd.
Logstash a spark mi tam nesedí, není to db a ani storage :).
Vyškolit vlastní lidi trvá několik let, na našem trhu je třeba pořád více lidí pro Oracle než pro Elastic. Provozovat třeba OLTP (třeba sklad a objednávky u Alzy) je při desítkách instancí dost náročná technologie, zejména když potřebuji strong a ne eventually consistent, tam v praxi stejně končím na jednotkách instancí (klidně přes shardering).
-
Karel (neregistrovaný)
Staci cist sipky spravne. Nikde se o vystupu z db pres spark nic nepise. Spark je tam na ukladani a to seskupovani, agregace, zahazovani duplicitnich dotazu v casovem okne. Logstash zase treba zajisti davkove vkladani misto solo dotazu, nevykonavani duplicitnich dotazu. Vystup z db se naopak poresi shardovanim, cachovanim, kaskadou slave apod.
Proc by to ty technologie meli delat nativne, kdyz to podle vyznamu dat stejne musi mit nejakou vyssi logiku? Napr. sledovani aktivity uzivatele: nepotrebuji do db udelat 100x update, ze videl stejny produkt behem minuty. Staci jednou ulozit +100 a now() a to pres spark+kafku udelate snadno. MSSQL to vyresi jak? -
tohle jsou zajímavé věci :). A Jak tímhle chceš nahradit MSSQL? Vždyť tím řešíš, problém, který třeba ani nemají a stejně potřebuješ nějakou db na skladovou evidenci a fungování eshopu, na čem bys to tedy postavil?
Už chápu tvoje shlukování dotazů, ty chceš sdružovat pouze inkrementy do časového okna a uložit najednou, to poté ano, ale on takový eshop není jen věc inkrementů, ale složitých filtrovacích dotazů na zboží. Krom toho, co když ti zrovna spadne spark proces, který drží v paměti data za poslední sekundy, jak to uděláš, abys data neztratil (a udržel konzistenci)?
MSSQL na to má in-memory oltp s možností přes procedury to přetahovat na disk-based stored tabulky v nějakém časovém okně, mimochodem, rychlostně se to nemůže rovnat s Redisem, provozem na silném stroji to je velice schopná věc (tím neříkám, že bych to nasazoval, ale jako utopii to nevidím).
Začal jsi tím, že chceš mít spousty slabých nodů místo jednotek silných, ale zrovna kafka a spark streams s windowed aggregation se staví na velice silných strojích, aby zvládli vysokou zátěž. Spark má velkou režii na každý executory, který je spuštěný, mít jich 50, bude to neskutečně pomalé a budeš bojovat s správným balancováním dat nebo naopak výrazně zatěžovat db desítkami spojení, Kafka naopak také nemá ráda velké množství strojů a staví se, aby saturovala síť/disk.
Kombinovat více technologií do sebe s sebou nese problém tracingu, debugování a monitoringu, cenu takového řešení to může výrazně zvýšit.
Jo, jdeš na to dobře, ale chybí ti reálné zkušenosti z projektů :)