Hlavní navigace

Vlákno názorů k článku Jak nám v Alze aktualizace Windows způsobila výkonové problémy databáze od Tomáš2 - stará doba velkých mašin pořád ještě neumřela, exadata,...

Článek je starý, nové názory již nelze přidávat.

  • 8. 9. 2018 13:22

    Tomáš2

    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).

  • 10. 9. 2018 10:20

    Tomáš2

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

  • 9. 9. 2018 22:45

    Tomáš2

    uhf, to jako bys chtěl nahradit MSSQL logstashem pro vstup a sparkem pro výstup? :) Nepopisuješ náhodou úplně něco jiného? Na tohle eshop nepostavíš....

    Mimochodem, ani jedna z vyjmenovaných technologií neumí nativně seskupovat shodné dotazy dohromady nebo nevím jak jsi to myslel.

  • 7. 9. 2018 22:43

    Karel (neregistrovaný) ---.net.upcbroadband.cz

    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?

  • 8. 9. 2018 18:24

    Karel (neregistrovaný) ---.net.upcbroadband.cz

    Logstash i spark jsou prave soucast tech front, pres ktere tecou data do ruznych db a zvysuji propustnost diky agragacim nebo seskupovanim podobnych dotazu. (app->log->filebeat->logstash->elastic, app->kafka->spark->db apod)

  • 10. 9. 2018 9:21

    Karel (neregistrovaný) ---.cust.vodafone.cz

    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?