Vlákno názorů k článku Databáze pro 900 milionů obrázků aneb pořádný cluster v Seznamu od Adam Kalisz - Je super, že takové články vznikají, ale chtělo...

Je super, že takové články vznikají, ale chtělo by to zapracovat na jasnosti a struktuře sdělovaných informací.

Seznam má tři datacentra, která dále (spíše už logicky a ne jako např. AWS) dělí na tři AZ. A teď jsou celkově tři repliky dat rozdělené na všechny datacentra, nebo AZ? Ten diagram mi to nijak dál neosvětluje, autor mě diagramem neprovedl a mě tak výmluvný nepřijde.

Jak už bylo poznamenáno v diskuzi, 30 TB dat a 900 Mio. souborů a 3 000 req./s není zas až tak moc. Zdá se, že převládá čtení. Co v tomto případě přesně Kubernetes přináší např. oproti původnímu systému a obecně? Jak vypadá třeba vytížení v čase? Jak se testovaly patologické souhry (viz např. https://jepsen.io/ : "Together with PingCAP, we tested TiDB 2.1.7 through 3.0.0-rc.2, and found that by default, TiDB violated snapshot isolation, allowing read skew, lost updates, and incompatible orders, thanks to two separate auto-retry mechanisms which blindly re-applied conflicting writes. 3.0.0-rc.2 changed the default settings to provide snapshot isolation by default, as well as fixing a race condition in table creation, and some crashes on startup.")?

Moje zkušenost je, že rozkládat věci náročné/ější na IOPS a současně synchronizaci do co nejvíce uzlů je vysoce kontraproduktivní, protože mě často režie stojí kalhoty.

Proč se nehodily jiné prominentní produkty, např.: https://www.cockroachlabs.com/docs/stable/why-cockroachdb
Pro porovnání TiDB: https://docs.pingcap.com/tidb/stable/overview
Nějakou diskuzi by člověk mohl najít třeba zde: https://news.ycombinator.com/item?id=15499404

Proč ne Min.IO: https://min.io/docs/minio/kubernetes/upstream/ nebo Garage: https://garagehq.deuxfleurs.fr/documentation/cookbook/real-world/, když jde vlastně jen o to ukládat obrázky a replikovat je všude možně? Případně co Ceph Object Gateway?

On švábDB na tom není o moc lépe pokud jde o transakce, izolace, spolehlivost.

TiDB ukládá data do velkých souborů a postupně si je kompaktuje, FS pod tím nemusí spravovat 900 mio souborů. MinIO jede striktně erasure coding a každý block je jeden soubor na disku, tj. tohle mi udělá pětinásobek souborů na FS, což zrovna není sranda na správu (jeden náš český operátor tohle ladí už dva roky). Garaga je moc pěkný projekt (používám), ale chybí tomu spousty věci, třeba schopnost ověřit zapsaná data, snapshoty, má problémy s připojením více klientům (protože interně třeba thread pool a frontování požadavků přidali nedávno a ještě to není ono).

A důvodem je nejspíš opravdu to, že Seznam se rozhodl vše mít primárně na kubernetu a tlačí všechny projekty do použití kubernetu, stejně jako jinde. Ty pak těch alternative tolik nemáš, protože tě na HW přímo nepustí, jen ti dají přístupy a endpointy, podobné schéma zažívám i na jiných projektech a zrovna jak píšeš, dělat jakoukoliv databázi na spoustě uzlů je zlo, shardering postupně kupodivu mizí a objevují se tyhle mesh projekty, s kterými je buď dost práce nebo vlastně netuším, jestli tam jsou data uložena správně. Tady to mají jako storage pro obrázky, snapshot isolation je jim asi putna, stejně to jedou asynchronně a nepotřebují aktualizaci in time všude.

Ano a podla mna je to cele prearchitektovane. Dame tam tuto DB ta je teraz IN. A pouzijeme mikroservisy (z toho mam uz vyrazky) lebo ... je to moderne.
Pritom sa zasadne zabuda ze najvacsia bolacka v kubernetes je storage. Bud si sluzby napinujete na server a pouzijete nativny storage alebo pouzite nejaky cloud storage a ten je pomaly pokial do toho nenahadzate fakt VELKEEEE peniaze.

ano a když už použiji nějaký silný cloud storage, tak narazím na to, že z kubernetu horko těžko vytáhnu něco víc než 10GbE z nodu, a i to znamená nemalé úsilí toho dosáhnout (děláme storage servery s 4 x 56GbE pro srovnání)

Ne, dnešní kubernet není vhodný na cokoliv, co je diskově intenzivní (iops nebo velikost), stejně ta není vhodný pro cokoliv, co potřebuje extrémně moc výpočetní zdrojů (trénování AI) nebo extrémní síťový provoz.

Snaha mít vše nad jedné technologii je logická a člověk to chce mít jednotné, bohužel ne vše se pak dá provozovat. Zatím nejvíce času s kubernetem trávíme právě ohejbáním ho pro nestandardní situaci a nikoliv provozování těch standardních, pak to paradoxně práci přidává a ne naopak. Ono si to ale v podstatě děláme sami.

Mě přijde, že je důležité dívat se na celkové úsilí a výsledek. Mě by asi nebavilo provozovat spousty strojů, které něco stojí na pořízení a na provoz, jenom protože je někdo umanutý z pohledu technologie.

To je asi jako prohlížeče, kde převládá mýtus, jak jsou strašně dobře udělané a rychleji to nejde. Potom zjistíte, že je problém i jen rozumný rendering písma, nedej že někdo chce animovat pár boxíků a dokonce stínů. V roce 2023 je asi problém rozpoznat, že hýbu nějakým výsekem obrazu, který se nemění, nebo je třeba mimo viewport.

Kubernetes jsem zatím řešit nemusel. Myslím, že to neřeší podstatu problému v IT, která pramení z toho, že se stavem se v drtivé většině programovacích jazyků a asi i hardwaru pracuje poměrně špatně a je to náchylné na chyby. Že se většina softwaru nedá spolehlivě updatovat za běhu a že se systematicky nezjednodušuje/ neuklízí, ale spíše nabaluje.
Tak se vymýšlí po 150té izolace, virtualizace, nějaký management/ accounting toho všeho. Nikdo už nerozumí věcem nějak víc napříč a vytrácí se nadhled.

A přijde mi, že hysterie jako blockchain a dnes AI tomu všemu nepomohly. Hodně chytrých lidí řeší něco, co je postavené na příliš vratkých základech. Místo aby se šlo, a ty základy se udělaly robustnější, tak se to celé radši zalije dalšími miliony řádků kódu.

"Nikdo už nerozumí věcem nějak víc napříč a vytrácí se nadhled."

Typicky vyvojar cehokoli je lepic kodu, ktery pouziva horu vsemoznych knihoven, o kterych ani nevi, co vlastne delaji. Vysledky tomu dokonale odpovidaji ... mam zaznam z konfery jednoho dodavatele, kde jejich vlastni zamestnanec oznacil jejich vlastni aplikaci za ''s.cku' ;D. A legranda na tom bylo predevsim to, ze z presne stejneho duvodu jsem ji takhle pred 15 lety oznacil ja (coz kdyz sem mu dohledal tak nechapal, proc to uz davno neni predelany).

Pokud pujdes niz k HW, tak typicky nikdo netusi ani teoreticky jak to funguje. Takze se pak nediv, ze se ti generujou treba hromady IO na disky tam, kde by se krasne dala pouzit cache ... atd atd atd.

Update za behu? Neblazni, tohle sem delal na 8mibitech ... to je doslova vesmirna hypertechnologie.