Nagy DB összehasonlító topik

Adatbázis: SQL, XML DB

https://hup.hu/comment/3032071#comment-3032071 adta az ötletet, hogy vitassuk meg, 2024-ben hogy áll a helyzet a Relációs-NoSQL fronton. Pár szempontot feldobok nyitónak:

 

- mit tekintünk sémának?

- teljesítmény? Írás, olvasás.

- hibatűrés?

- mennyire bonyolult, mennyire könnyű adminisztrálni?

 

Szerk:

Elírtam a topic nyitót, mert nem relációs-nosql háborút akartam indítani, hanem olyan példákat látni, hogy mi van akkor ha valamit _meg lehet csinálni_ két vagy több adatbázisban akkor mi az a pont ahol már érdemes bevállalni a heterogén környezetből eredő hátrányokat. Ez lehet akár két nosql adatbázis is, nem csak relációs-nosql vonalon lehet gondolkozni.

( _Franko_ v | 2024. 02. 27., k – 08:24 )

Mit akarsz összevetni? Teljesen másra jók, NoSQL fronton belül még egy MongoDB vs Cassandra összehasonlítás is teljesen értelmetlen, mert más célra vannak kitalálva, sok projekten együtt használnak adott célra alkalmas megoldásokat.

https://iotguru.cloud

Van sok olyan usecase amiket simán meg lehet valósítani különböző platformokon is, ráadásul egyre több.

Hogyne, de akkor lófaszt se használsz ki a tudásukból és a lehetőségeikből és/vagy rosszul használod, nagyságrendekkel rosszabb a teljesítménye, csak még elmegy az is, annyira kicsi a feladat.

A másik, hogy sokszor jön olyan komment, hogy ez egy szar mert én _10 évvel_ ezelőtt egyszer használtam és szar volt. Csak azóta eltelt 10 év.

Az architektúra ezek alatt nem nagyon változott, az alátett hardver fejlődött, ami miatt mondjuk már lehet használni olyan terhelésre is, amire 10 éve nem lehetett, de továbbra se optimális...

https://iotguru.cloud

Hogyne, de akkor lófaszt se használsz ki a tudásukból és a lehetőségeikből és/vagy rosszul használod, nagyságrendekkel rosszabb a teljesítménye, csak még elmegy az is, annyira kicsi a feladat.

Cserébe lehet, hogy a fejlesztési idő lényegesen kevesebb mert a fejlesztő már ismeri az eszközt és ez fontos szempont.

Az architektúra ezek alatt nem nagyon változott, az alátett hardver fejlődött, ami miatt mondjuk már lehet használni olyan terhelésre is, amire 10 éve nem lehetett, de továbbra se optimális...

 Ez így van, teljesítményben nem optimális, de más szempontok szerint még lehet optimális. Pl. Fejlesztési idő, üzemeltetési költség (csak egyféle szart kell üzemeltetni), integrációs költség.

Szerintem a való életben ki kellene venni ezekből a képletekből a "fejlesztő ismeri és ez előnyt jelent" dolgot. Mert ahogyan a projektnél (jó esetben) a feladathoz választjuk a megfelelő eszközt, úgy olyan fejlesztőt kellene alkalmazni, aki azt az eszközt ismeri. Ne a befőtt tegye el a nagymamát.

Ez a fordítva gondolkodás, hogy "na, fijúk, ez a feladat, írjátok meg olyan DB-vel, amit a legjobban ismertek, leghamarabb elkészül". Ebből lesz az, mikor a POC szuper, aztán a 100 ezer felhasználót kiszolgáló éles rendszer meg lehal egy csillagromboló-flottán futtatva is.

Cégkultúrája és érettsége válogatja.
Általánosságban: a betervezésért az architect, az implementációért a fejlesztő, a teljesítménytesztért a tesztelő, a prod konfigért az ops.

És ugye valaki a pullrequestet is elfogadja...

Értelmes és jól implementált folyamatok esetén egy hiba mindig több ember egymás utáni mulasztásának következménye.
Ha kicsit tovább megyünk: ha nincsenek folyamatok vagy rosszak, ott is mindig meg lehet találni hogy kin/min csúszott el.

De sokszor nem a hibást érdemes keresni hanem a megjavítás célszerű módját.

Gábriel Ákos

( golgota | 2024. 02. 27., k – 08:27 )

Ezzel a temaval az a baj, hogy ha NoSQL-rol beszelunk, akkor elo kell vennunk a document store, columnar store, key-value store es gaph tipusokat is, ami mind mashogy mukodik es masra jo. Van ahol a sema mint olyan nem is ertelmezheto. Raadasul mindegyik masra van.

Peladual egy columnar metric storage irasa es olvasasa messze gyrosabb lesz, mint egy document store-e. Ugyanakkor meg mindig fenyeveket ver ra egy document store egy RDBMS-re. Aztan az egyes docuentstore-ok is mashogy taroljak az adatokat. Igy az egyik gyrosabb a masik lasabb, viszont lehet a lasabbnak mashol tobb elonye van (self-healing mondjuk).

Aztan kerdes hogy egy node-rol beszelunk iras olvasas eseten vagy tobb node-rol, ahol sharding es replikacio is van. 

Az adminisztracioval kapcsolatban meg annyi, hogy mondjuk pont az ES eseten a 6-os sorozatig volt elegge magas adminisztracios koltsege az uzemeltetesnek, ha magat az infrastrukturat nezzuk, de mara ez elenyeszo. Viszont van egy adat menedzsment pont amiatt hogy schemaless alapbol. De ha semat alitasz be akkor figyelni kell az eldobott dokumentumokra, mehet a reprocessing, reindexing stb stb (bar mara mar erre is benne vannak az automatizmusok, na ezert enterprise product)

"Akinek kalapácsa van az mindent szögnek néz." 

Ismerek olyan helyet ahol mindent springboot-postgres-kafka szentháromsággal akarnak megoldani. Van egy csomó kis-közepes feladat amire megfelelő ez a kombó de vannak olyan problémák ahol szemmel láthatóan megy a kínlódás - meg pl. a postgres fossá tuningolása irdatlan időráfordítással. Holott egy redissel vagy elastic-kal akár pythonból megfelelő sebességgel meg lehetne oldani a feladatot. 
Egyszerűen azért mert _erre való_. 

Gábriel Ákos

Na pont ez lenne itt a lényeg, hogy összeszedjük meg példákat adjunk, hogy hol vannak ezek a határok amikor már érdemes bevállalni akár addig ismeretlen technológia megtanulását.

Félreértés ne essék, én szeretek új dolgokat megtanulni csak azért mert érdekesek, de ha ezt az időt el kell adni egy projektben, akkor az általában kevés, hogy azért mert engem érdekel, hogy jobb-e :)

Nincs példa, minden egyes feladat más, aminél le kell ülni, fogni papírt, ceruzát és gondolkodni kell rajta, akár olyan eredménnyel, hogy ami tegnap még jó volt, az ma már suboptimális, holnap meg szar és teljesen át kell alakítani az egészet, mert rossz alapokra épült.

https://iotguru.cloud

Pont ezt irtam a masik topicban is, Mi ES-bol akarunk atvinni dolgokat vissza postgresql-be es mellette elkezdtunk Clickhouse-zal foglalkozni,mert kell az OLAP (arra meg az ES nem a legmegfelelobb). Ezen kivul hasznalunk meg csomo mindent, pl hadoop-ban hive-ot, aztan van cassandrank, meg Influxunk is.

Mindenhol probaljuk a legoptimalisabbat megtalalni. De nem ugy hogy "na probaljunk ki valami ujat, mert miert ne" hanem "merjuk ki pontosan, csinaljunk PoC-ot, lassuk meg jobban teljesit e adott business igenyehez kepest".

Azért van ennyi minden, mert a mai technikai színvonalon csak ilyen heterogén rendszerrel lehet megoldani az igényeket, vagy 10 évvel ezelőtt csak így lehetett és azóta így maradt?

A PoC is pénzbe kerül. Nyilván egy új rendszer esetében ezt beárazza az ember de meglévő _működő_ rendszerek esetében néha nagyon nehéz ilyenekre forrást találni.

Clickhouse-ról nem hallottam eddig úgyhogy most ránéztem. DuckDB ugrott be hasonló dolognak. Azt néztétek esetleg?

Ket dolog miatt nem megfelelo a DuckDB. Az egyik hogy ez inkabb egy embedded db, amit egy alkalmazashoz csomagolsz (mint egy Derby-t, persze annal tobbet tud) es nem distributed HA, self-healing funkcionalitassal. Masreszt nem annyira mature (Clickhouse-al meg 2015-16 kornyeken talalkoztam eloszor). Nalunk inkabb a bigdata-n van a hangsuly es a rengeteg forrasbol szarmazo adat analizalasan. 

A PoC-ot ne ugy ertsd, hogy a teljes kornyezetet megepitjuk es minden szir-szart letesztelunk. A PoC-ban csakis azt nezzuk meg kicsiben, hogy megfelel e a business igenyeknek es ha igen, mi az ami tobb, mint az eddigi rendszerek nyujtanak.

A kérdésed alapján (ahogy én értem) szerintem nem jó úton jársz a probléma megközelítésében sem.

"a mai technikai színvonalon" nekem azt mondja, hogy mára elég erősek a gépek, használjunk egy megoldást és majd erőből jó lesz. Ha ez az alap gondolat, akkor szerintem erre hiba a választ keresni, mert nem ez a jó út.

Régen volt mindenből egy, aztán azzal oldottak meg minden feladatot. Aztán ahogy a feladatok változatosabbak lettek, születtek az egyre specializáltabb eszközök a megoldásukra, és ez mostanra oda jutott, hogy nagyjából mindenre van céleszköz.

Szerintem minden projektnél az adott részfeladatoka a megfelelő céleszküzt kell választani (így projektenként sok különböző lesz, amiből összeáll a rendszer), nem egy eszközt használni, és a "technikai színvonalban" bízni, hogy majd megoldja a nem-éppen-optimáis szoftver is.

hogy hol van az a határ amikor már célszerszámot kell választani. Mert oké, hogy elméletben egy columnstore gyorsabb pl. loggyűjtésre, de van az a terhelés, amit egy jól beállított relációs adatbázis is simán elvisz.

A relációs adatmodellhez sql-t kell használni,  a nagy teljesítményű, nem relációs adattárakhoz meg no-sqlt. Ha fordítva csinálod, nem korszerű vagy, hanem

https://blog.claryel.hu

( zolti v | 2024. 02. 27., k – 18:26 )

Meg fogtok kövezni, de szeretem az SQLite -ot szerver oldalon használni. Általában WAL mode -ban 2 kapcsolattal használom egy az írás -hoz és egy readonly, ez általában szét van szedve API szinten is. Gyors, egyszerű nincs vele problémám.

( Oregon | 2024. 02. 27., k – 21:25 )

A nagybaszás tesztbe benezvezném a pinát,  a faszt és a segget. A kérdés az, hogy melyikkel a legjobb baszni. :)

( kruska v | 2024. 02. 28., sze – 00:45 )

Foglalkozási ártalom, de én sokszor HANA-t használok, 32G méretig ez ingyenes, és sokféle nyelvből lehet használni.

Columnar and Row-Based Data Storage
SAP HANA Client Interface Programming Reference

Még a PostgreSQL-t szeretem, de úgy, hogy az üzleti logika egy részét leprogramozom PL/pgSQL-ban vagy PL/Python-ban adatbázisfüggvényként / tárolt eljárásként, majd ráültetek egy PostgREST-t, ezzel kész is a backend API. Ha gyorsan kell valami belső rendszer, így nagyon gyorsan megy (nyilván mert nem fejlesztő vagyok, nincs sok gyakorlatom).

PostgREST - Serve a RESTful API from any Postgres database

Éppen erről van szó! Nem az van, hogy az egyik csak erre, a másik csak arra jó, mindegyiknek van előnye és hátránya. Éppen azért hoztam létre ezt a témát, hogy akinek _van tapasztalata_ az ezt meg tudja osztani. Pont az lenne itt a lényeg, hogy kiderüljön _meddig_ jó egy adott megoldás. Pl. ebben az esetben mi az az adatmennyiség ami felett váltani kell postgres-re.

Most jövök rá, hogy picit elírtam a topic nyitót, mert nem relációs-nosql háborút akartam indítani, hanem olyan példákat látni, hogy mi van akkor ha valamit _meg lehet csinálni_ két vagy több adatbázisban akkor mi az a pont ahol már érdemes bevállalni a heterogén környezetből eredő hátrányokat.

Éppen azért hoztam létre ezt a témát, hogy akinek _van tapasztalata_ az ezt meg tudja osztani.

 

1) Nehez elkepzelni olyan problemat amit csak es kizarolag egy adatbazisgyarto termekevel lehetne megoldani.

2) legalabb ilyen nehez olyan embwrfiat talalni, amelyik az osszessel is dolgozott, es mondegiket ismeri kivulrol-belulrol

Igy az egesz topik max 🔥-re eleg.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

en mongodb-rol alltam at ferretdb + sqlite-ra. Az ok a licenszeles. Konkretan eltunt mogule a kozossegi hatszel, mar nem hype-oljak, es kb. semmi se indokolta a teljesitmenyigenyt, mindosszesen baromi kenyelmes volt mongodb-re fejleszteni.

Oszt' egy sqlite is elviszi.

 

Ettol en nem erzem magam adatbazis specialistanak. Sot.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem, nem agyatlanul hasznaltuk. Es mint mondtam nem mindent akarunk atvinni, csak egyes dolgokat. Raadasul itt nem is technologiai oka van hanem uzleti inkabb. Az ES-ben is jol vannak azok az adatok (amugy timeseries-rol van szo es nem is az osszesrol ami beleomlik, hanem az egyik specialis projekt eseten). Az ES-ben levo adatokat szamtalan helyen hasznaljuk es rengetegszer reprocesszelunk. Megy rajta ML is. Na most pont az adot projektnek nincs szuksege ML-re es a tobbi ES funkciora, viszont minden mas PostgreSQL-ben van nekik. Sot, mar hasznaljak a Timescale-t is. Ebben az esetben az uzlet ugy dontott, hogy egyszerubb nem ket-harom csapat kommunikaciojara es uzemeltetesere bizni az adatokat,hanem mi lenne ha az adott projekt own-olna a sajat adatat megha az azt is jelenti hogy atirjuk a shipperek konfigjait, hova csapja bele az adatokat. 

Hidd el eleg nagy tapasztalat van itt Hadoop (Hive, Impala), Cassandra, ES, Influx. Clickhouse, PostgreSQL teruleten. Mindegyiket megrpobaljuk a leheto legjobban hasznalni. A Clickhouse is csak nekem uj (amit emlitettem is, hogy mi most kezdtunk el belenyalni), mert egy masik team mar vagy 3-4 eve hasznalja). Es mondjuk a fentiak csak azok amikrol en tudok, de nem lepodnek meg ha lenne Mongo is meg tenyleg minden istennyila :D 

Nem is mondtam egy szóval sem hogy ti agyatlanul használnátok. Ahogy leírod az alapján ez egy jól megtervezett rendszer - ahol a konkrét implementáció elég könnyen cserélhető.

A jól tervezett rendszert onnan (is) lehet megismerni hogy egy-egy ilyen "platformdöntésnek" nincs gigantikus visszavonhatatlan következménye hanem ha bármiért "nem jön be" egy megoldás akkor tudsz "lépni".

Gábriel Ákos

Önmagában a  timeseries funkcionalitásra szerintem szinte csak hátránya van az elasticnak az influxhoz képest, már csak azért is mert az influx pont erre lett kitalálva.

Non-functional előnye viszont van/lehet az elasticnak. Elasticban triviális szinte agyonüthetetlen cluster-t összerakni, influxban nem tudom.
Elasticban kb végtelen mennyiségű timeseries-t letárolhatsz és ha megírod akkor szépen csinálja neked a mindenféle summákat ügyesen.
Tud tiered storage-t is ha arra vágynál, influx szerintem nem tud.

Gábriel Ákos

( tornai | 2024. 02. 28., sze – 12:32 )

Szerkesztve: 2024. 02. 28., sze – 12:36

Kb bármilyekkel lehet jó szoftvert készíteni. Nem ettől lesz olcsó/könnyen üzemeltethető/fejleszthető. Bármelyiket odaadhatod egy szar team szar fejlesztőinek, egy kupac szar lesz a végeredménye.

Egy jó fejlesztő meg eldönti, hogy az adott feladathoz melyik az optimális figyelembe véve 1000 szempontot. A fejlesztő ebben az esetben lehet architekt, főnök vagy chief-lead akármi. Az is lehet szempont, hogy a cégnél X stackkel dolgozunk és bár jobb lenne egy eddig nem használt akármi, de a cég/fejlesztők szempontjából meg jobb az amit ismerünk, mert nem sokkal kerül többe és/vagy nem lesz annyival lassabb/akármi, mintsem amennyire fájna az, hogy egy 'egzotikus' cuccot használunk.

Nincs megoldás. De szar fejlesztők, szar managerekkel, szar üzemeltetőkkel csak szart fognak alkotni - ezt ne feledjük.

( andras0602 | 2024. 02. 28., sze – 17:35 )

Ezekbe szoktam beleolvasni mikor egy új db-t szeretne valamelyik csapat. Még ha nem is mindegyik a legfrissebb, leírnak kemény dolgokat, amiket a doksik jellemzően nem szoktak. https://jepsen.io/analyses

"If I had six hours to chop down a tree, I'd spend the first four hours sharpening the axe."

( n.balazs v | 2024. 02. 29., cs – 10:11 )

A felvetés teljesen értelmetlen. Kb. mint nagy szerver hardver összehasonlító topik lenne. 1000+1 paraméter befolyásolja, hogy mi milyen hatékonysággal működik vertikálisan és horizontálisan is. Hiába a jó hardver, hiába a jó szoftver, ha gatya fejlesztők produktumát kell futtatni vagy épp 1.0-s kollégák üzemeltetik a rendszert.

Ráadásul mit vársz? Valaki azt mondja, hogy 10 GB-nyi adatmennyiségig, 1000 tranzakció/mp-ig X DB a jó, ha 1000-5000 tranzakcióról van szó, akkor Y DB a jó? Ezt így el is fogod hinni, mert a te használati mátrixod is pont ilyen? A mátrixnak része az üzemeltetési, licence, technikai támogatás költsége is.

A nagy gyártók (pl: Oracle) még azt is megtiltják, hogy bármilyen teljesítmény teszt megjelenjen a termékükről.

Igen, pl. kiindulásnak valamki leírja, hogy nála mekkora load-ot visz egy adott rendszer, erre másvalaki válaszol, hogy pl. erre mi mást használunk mert kényelmesebb az apija és ugyanúgy elvisz ekkora terhelést.

Vagy pl. ha már az Oracle szóba került, adott esetben megéri-e pl. postgres-re váltani - természetesen rendes fizetős supporttal mert kell a papír a segg*****re. Vagy épp az ellenkezője, hogy nálunk felmerült és nem váltottunk mert ez meg az nem jött volna jól ki.

Nem univerzális igazság meghatározása lett volna a cél hanem, hogy olyan kis tapasztalatmorzsákat gyűjtögessünk amik egy ilyen döntés esetében hasznosak lehetnek.

Még mindig nem értem, hogy ezekből a morzsákból mit fogsz tudni összehasonlítani. Minden helyzet más és más. Csak egy zöldmezős rendszernél tudsz szabadabban dönteni.
Éppenséggel össze lehetne rakni egy olyan döntéstámogató rendszert, ami irányt mutatna a DB-k tengerében. Ezt fel is kellene tudni paraméterezni. Csak ilyet senki nem csinál ingyen, hát még ingyen hozzáférést se kapsz hozzá. Amikkel találkoztam, azok mind "confidental, internal use only"-k voltak.

Csak pár konkrétumra reagálva:
- Load: Egy rendszernél többféle load is értelmezett. Nem csak a CPU load, amit a Linux szépen kiír.
- Oracle vs Postgresql: Mi van, ha nekem extra discountom van az Oracle-nél és 98%-s kedvezménnyel (nem elírás, léteznek ilyen mértékek) kapok szinte mindent az Oracle-től? Általában az NDA-k miatt ezt nem is hozhatom nyilvánosságra. És a migráció része a licence költségek beleszámolása is. Alma vs. körte.
- IT döntések: Mindig van egy szigorúan vett IT szakmai és nem szakmai részük. Ritka eset, hogy önmagában a szakmai dönt. A nem szakmai rész például a humán erőforrások szaktudása, a VSP faktor, a jogi előírások, CAPEX/OPEX, üzleti igények, kollégák tanulási hajlandósága.

Szerintem.

( bartaszili | 2024. 02. 29., cs – 21:06 )

Mit ajánlotok olyasvalamihez, hogy iszanyat sokfelől érkeznének logok. Ezek jelenleg táblánként 100GB-ot is nyomnak MySQL alatt. De ekkora méretű adathalmazban lassan lehet keresgélni. Milyen adatbázist használnátok? Mongo-t pl? Full elkülöníteném, mert amellett, hogy 0-24 szünet nélkül ömlene bele a log, még visszafelé is ki kellene szolgálnia tömeges lekérdezéseket. Javarészt fulltexteset. Máshol volt szerencsém a Mongo-hoz, de nem ekkora adatmennyiséggel. Log turkáláshoz pöpec gyors volt. A MySQL se kutya ha számításba veszem egyszerre mennyi mindent kell csináljon mekkora adathalmazzal. De szeretjük a mégnagyobb sebességet.

Ez úgy szokott lenni, hogy olvasáshoz van használva, mint cache, az írás perzisztens, ha áramszünet van, akkor az induláskor felolvassa a lemezről az egészet újra és megy tovább. Nyilván írás intenzív use-case esetén nem sok haszna van a memóriában tárolt adatbázisnak. Olvasásra viszont piszokgyors.

https://iotguru.cloud

Hat akkor ne csak olvasgasd hanem ertelmezd is. Ott a subscription matrix, hogy mi az ami penzbe kerul. A legtobb funkcio ugyanugy ingyenes, mint regebben volt. Ami fizetos az az ML, a searchable snapshot, SSO meg mas enterprise feature-ok. 

Most mondhatod persze, hogy ott az OpenSearch amiben benne vannak a hasonlo dolgok ingye', de azt jobb nem elindian, ha nem akarod magad ugy megszopatni, hogy felrepedjen a szad szele. Az ami meg abban ugy ahogy jol mukodik az ingenes az ES-ben is. 

Ezt a "szimpi" dolgot meg jol elrakom es hasznalom, ha majd hulyulni akarok a kollegakkal. Koszi. :D

(Nalunk altalaban a feladatara hasznaljuk az eszkozt es nem szerelmesek leszunk bele)

Eloszor is amikor clusterben van, hajlamosak elveszteni egymast a node-ok, de orokre (2.4-2.8), aztan az S3-ba snapshotolas a doksi szerint nem mukodik (bar a javas s3 api-t hasznaljak a sajat kodjukban van valami fortelmes workaround) es csak ugy tudtuk beallitani, hogy a java code-ot olvastuk el, hogy mire is gondolt a kolto. Szamos mas eseben is a java code-ot kellett megnezni, hogy vajh mit es hogyan is kellene csinalni. A kubernetes operator egy halom szemet az ES operatorahoz kepest. Hegynyi workaround kell hozza, hogy mukodjon, ha a security is fontos.

Amugy is a prometheus utan a legszarabb doksija van amit eletemben lattam, pedig 25 eve vagyok a szakmaban. :D

Ugyhogy productionben inkabb nem kiserletezunk vele, de egy node-os dev kornyezeteknek azt huzzuk fel (neha, mert inkabb ott is pereferaljuk az egy node-os ES-eket).

No igen, ez elofordulhat (ezert is jobban szeretem azokat a cluster implementaciokat ahol mondjuk zookeeper-rel kivulrol van megtamogatva az egesz es nem belulrol probalja meg megoldani, mert he lehal egy service, akkor ugye annak a cluster-es resze is lehal).

Mondjuk ES-nel igen ritka volt az OpenSerchnel meg naponta estek keltek a test clusterek. Es nem az volt a baj, hogy kiesett es elveszett a node, hanem hogy kb lehetetlen volt ravenni, hogy visszatalaljon, mig azert az ES-nel ezt legalabb brute-force modszerrel meg lehet csinalni. Ugyanazt probalva az OS-ben ugyanugy baszhattuk. :)

Modnom mitol lehet: hanyagsagtol :D (en 2014 ota hasznalom meg a 2-es sorozat ota, de eddig mindig valami emberi mulasztas miatt dolt ossze a cluster)

Nalunk egyszer azert fordult elo meg a 6-os soroat alatt, mert ultra secure-ra kellett tenni a rendszert igy a node-oknak sajat certje volt amivel ugye a transport protokolon beszelgettek. Na mikor lejart jott a nagy baj. :D

Masik alkalommal valamit baszakodtak a halozaton (ep esszel fel sem tudom fogni, mert nagyon nem vagyok halozati specialista) es folyamatsoan esett kelt a cluster

Aztan volt amikor K8s alatt a host-okon nem mukodott az NTP (ez egy masik haloztaos orulet volt) igy a cluster tagok folyamatosan ujraindultak, mert nem talaltak meg egymast igy a health sosem volt jo. A problema ott volt, hogy valami java nevfeloldasi cache miatt, mindig az elozo inditassal kapott IP-t akartak hasznalni, de ugye akkor mar az uj podnak mas volt az IP-je, szoval szep vegtelen ciklusban indulgattak ujra. Na de mire rajottunk hogy a kurva NTP miatt van....:D

De mint mondtam, ezek mind emberi mulasztas miatt jottek elo. (meg mondjuk amikor az uj kollega azt gondolta, hogy az ES training utan o majd tuningolja kicsit a buffereket a 6-os clustereken meg a shard mereteket meg mindent is :D)