Web scale, tíz év távlatából: mire jutottunk a NoSQL-lázzal?

Van egy rövid rajzfilm 2010-ből, amit valószínűleg te is láttál, ha valaha adatbázisról vitáztál a folyosón. Két kutya beszélget, az egyik lelkesen nyomja, hogy MongoDB-re kell migrálni, mert az „web scale”, a másik meg egyre kétségbeesettebben próbál rákérdezni, hogy ez pontosan mit is jelent. A „web scale” azóta nem dicséret. “Szitokszó” lett arra, amikor valaki puszta divatból hoz architekturális döntést.

Innen indultunk. Érdemes megnézni, hova jutottunk.

A lelkesedés évei

A 2009 körül induló NoSQL-hullám nem a semmiből jött. Volt mögötte valódi fájdalom: a Google és az Amazon publikálta a BigTable és a Dynamo tanulmányát, a startupok pedig hirtelen úgy érezték, hogy a relációs adatbázis egy szűk keresztmetszet, amit maguk mögött kell hagyniuk. A jelszó a horizontális skálázás és a séma nélküliség volt. Nincs több ALTER TABLE, nincs több merev struktúra, csak dobod bele a JSON-t, és megy.

A probléma az, hogy a legtöbb csapatnál soha nem jött el az a pillanat, amiért ezt az egészet bevállalták. Ozan Onay 2017-es, azóta klasszikussá vált írásában “You Are Not Google” pontosan erre mutatott rá: a mérnökök úgy választanak technológiát, ahogy a Google vagy a LinkedIn tenné, holott a tényleges terhelésük ennek töredéke. Onay az UNPHAT-mozaikszóval foglalta össze, mit kéne csinálni helyette. A lényeg, hogy előbb értsd meg a saját problémádat, mielőtt lemásolod más megoldását. A cikk azért terjedt el, mert mindenki ismert legalább egy projektet, ami pontosan ezt a hibát követte el. :)

Amikor jött a hidegzuhany

A hype-ot két dolog józanította ki. Az egyik az üzemeltetési valóság, a másik Kyle Kingsbury.

Kingsbury (a neten Aphyr néven) 2013-ban elindította a Jepsen nevű tesztsorozatot, amiben elosztott adatbázisokat vetett alá kegyetlen hálózati hibaforgatókönyveknek és sorra mutatta ki, hogy ezek a rendszerek olyan adatvesztést produkálnak, amiről a marketingjük hallgatott. A MongoDB első Jepsen-analízise még 2013-ból való, és nem hízelgő. Négy évvel később a 3.4-es verziónál Jepsen azt találta, hogy a régi replikációs protokoll „intrinzikusan unsafe”, és a többségi szavazattal elfogadott dokumentumok is elveszhetnek. A történet 2020-ban tetőzött, amikor Jepsen a 4.2.6-os verziónál kimutatta, hogy az alapértelmezett beállításokkal a tranzakciók írásokat veszíthetnek és (dirty reads) piszkos olvasásokat engedhetnek, miközben a gyártó „a piacon elérhető egyik legerősebb konzisztencia-garanciájának” nevezte a terméket. A kettő nehezen fért meg egymás mellett.

Nem arról van szó, hogy a MongoDB rossz szoftver lenne. Arról van szó, hogy az elosztott konzisztencia nehéz, a marketing pedig könnyű, és a kettő közötti szakadékot évekig a felhasználók adatai töltötték ki.

Közben a piac is elkezdett visszafelé mozdulni. A MongoDB 2018-ban, a 4.0-s kiadásban bevezette a több dokumentumra kiterjedő ACID-tranzakciókat, vagyis pontosan azt, amit a relációs világ évtizedek óta tudott, és amitől a NoSQL annak idején nagy hangon elhatárolódott. A sajtóközlemény szövege önmagáért beszél: a tranzakciók „ismerősek lesznek azoknak a fejlesztőknek, akik relációs adatbázisokban már dolgoztak velük”. A kör bezárult.

A relációs oldal közben nem állt meg

Miközben a NoSQL a tranzakciók felé kacsingatott, a PostgreSQL csendben bekebelezte a funkciók felét, amiért annak idején az emberek elpártoltak tőle. Jött a JSONB, amivel dokumentumokat is tárolhatsz és indexelhetsz; jött a logikai replikáció; jött a pgvector, amivel egyszer csak vektoros keresést is csinálhatsz ugyanabban a rendszerben. Nem véletlen, hogy a DB-Engines rangsorában a PostgreSQL-t többször is (2017, 2018, 2020, 2023) megválasztották az év adatbázis-kezelőjének (db-engines.com).

Ebből nőtt ki a „Just Use Postgres for Everything” mozgalom. Stephan Schmidt eredeti, 2022-es írása, ami a Hacker Newson heves vitát váltott ki, amellett érvel, hogy a Postgres milliós felhasználószámig kiválthatja a Kafkát, a RabbitMQ-t, a Mongot és a Redist is, drasztikusan csökkentve a rendszer mozgó alkatrészeinek számát. A gondolat annyira megragadt, hogy 2026-ban is “It’s 2026, Just Use Postgres” címmel kerül vissza a fórumok élére. Egyetlen jól ismert, kiszámítható rendszer sok mérnök szemében többet ér, mint öt specializált, amiket külön kell üzemeltetni, monitorozni és éjjel debugolni.

Persze ennek is megvan a maga ellenmozgalma. Nem is kevesen figyelmeztetnek, hogy a „Postgres mindenre” ugyanolyan dogmává válhat, mint annak idején a „NoSQL mindenre” volt, csak az ellenkező irányba. Egy dedikált üzenetsor vagy egy oszlopos analitikai motor bizonyos terheléseknél tényleg jobb, és ezt homlokegyenest tagadni ugyanaz a hibás gondolkodás, csak fordítva.

A tanulság, amit láthatóan nem tanultunk meg

A legszebb az egészben, hogy miközben a NoSQL-lázból kijózanodtunk, elkezdtük ugyanazt a filmet lejátszani más szereplőkkel.

Amikor a Prime Video mérnökei 2023-ban megírták, hogy az egyik szolgáltatásukat elosztott, serverless microservice-architektúráról visszaköltöztették egy monolitba, és ezzel 90%-kal csökkentették a költséget, a szakma fele felhördült. Pedig a történet dramaturgiája kísértetiesen ismerős: divatból választott, túlbonyolított architektúra, amit később a valóság korrigál.

És most itt van az AI-hullám a maga vektoradatbázisaival. A Pinecone, a Weaviate, a Qdrant köré ugyanaz a retorika épül, mint annak idején a NoSQL köré: az általános célú adatbázis nem elég gyors erre a speciális terhelésre, kell egy dedikált rendszer. Lehet, hogy sok esetben igazuk van. De amikor kiderül, hogy a pgvector a projektek túlnyomó részének elég, és nem kell hozzá egy hatodik különálló adatstore-t bevezetni, akkor nehéz nem érezni egyfajta déjà vut.

A NoSQL nem halt meg, és soha nem is erről volt szó. A Cassandra és a ScyllaDB továbbra is verhetetlen extrém írási terhelésnél, a DynamoDB a globális kulcs-érték tárolásnál, a dokumentummodell pedig ott, ahol az adat tényleg heterogén. Ami meghalt, az a „vagy-vagy” felállás. A kérdés ma már nem az, hogy SQL vagy NoSQL. A kérdés az, hogy meg tudod-e indokolni számokkal, konkrét mért korláttal, hogy miért nem a Postgres a jó válasz. Ha nem tudod, akkor valószínűleg a válasz a Postgres. :)

Tíz évbe és jó pár elveszett adatba került, mire ezt megtanultuk.

Kérdésed van? Írj nekünk, és mi segítünk megtalálni a számodra optimális megoldásokat.