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?
Málokterá databáze umí horizontálně škálovat. Zpravidla to znamená poměrně dost procesů okolo a v nich může být také chyba, to snižuje celkovou spolehlivost. V podstatně skoro nic neumí horizontálně škálovat samotné dotazy, je to trik za trikem a musíš k tomu uzpůsobit aplikaci.
On se blbě horizontálně škáluje už i blbý file storage, natož něco, co má indexy a vnitřní vztahy, zámky a oprávnění.
Pro horizontální škálování databází je hodně těžká ta část, kdy přidáváš nový node, potřebuješ odněkud pro něj získat, data, když se jedná o netriviální velikost dat trvá to prostě strašně dlouho a zatížíš s tím současnou databázi. Máloco má tohle řešeno úhledně a přesně.
S počtem databázových nodů často roste složitost vzájemných vztahů (a tím se může snížit stabilita nebo snížit observabilita), stejně tak i moderní databáze mají řadu procesů, kde počet nodů generuje O(N) nebo i O(N^2) složitost některých operací.
Kubernetes, VM a jakýkoliv podobný overlay schovává strašně důležitou věc, fsync, databáze pak neví, kdy data jsou persistována a kdy nejsou. Řeší se to strašnými kotrmelci a nutností složitě data znovu číst a ověřovat, málokdo dělá a není nic horšího než při pádu celého k8s clusteru příjdeš i o data. Raw block volumes jsou pořád v ranné fázi, ale už je možné je nějak používat, to může být řešení, pak ale budeš pinnovat disky k instanci, no, ztratíš část výhod.
Moje doporučení je prostě databázi neškálovat horizontálně, udělat jí vysokodostupnou v několika instancích, snažit se v počátku škálovat vertikálně a optimalizovat. Přidávat instance pouze v poloautomatickém režimu. Cloud databáze, které tohle papírově umí mají za sebou dost vysoké náklady na vývoj a speciální infrastrukturu, snad nikdo z velkých hráčů ty technologie nemá open source (snowflake, bigquery, Cosmos) a přitom mají také dost velké problémy se škálováním a ne vždy to funguje dobře.
Pokud už člověk nemá vyhnutí, tak v kontejnerech se mi osvědčily věci jako tidb/tikv, scylladb, cockroachdb atd. Jen to "osvědčili" znamená, že dobře funguje jejich práce v kubernetu, ne že sami nemají zase svoje chyby. Stejně tak dobře fungují in-memory databáze, logicky. Pak to ale naráží na to, že síť v kubernetu je prostě obvykle pomalá a sotva se na projektech dostáváme na 10GbE stabilní intra node komunikaci, to na HW už máme přes 100GbE běžně.
Největší problém je asi to, že drtivá většina lidí považuje fungující databázi takovou, pro kterou najdou do kubernetu operátor a která jim běží a funguje. Už ale málokdo řeší a zohledňuje hraniční případy, jak bude fungovat obnova, jak se to zachová při blackoutu clusteru, jak to bude řešit partitioning, jak se bude řešit oprava dat atd. Některým to funguje roky bez problémů a pak tvrdí, jak to je stabilní. Stabilitu ale musím prokázat a ne že se mi náhodou stane.
Z praxe mohu říct, že čím větší projekt, tím více roli hraje shardování, cachování, asynchronní replikace a verzování stavu aplikace. Prostě se dělají spousty malých databází a řeší se, jestli stav je konečný, průběžný nebo zastaralý. Tj. zase tam je nějaká logika okolo.
26 Odpovědí
5326 Zhlédnutí