Mi jön a PostgreSQL 9.5-ben?

Láttuk már, hogy mit tesz le az asztalra a Microsoft SQL Server 2016, és lassan formát ölt a PostgreSQL új, 9.5-ös kiadásának kínálata is. A sorszintű biztonság és a JSON típusú adatok kezelése közös újdonság, a Postgres azonban egy izgalmas újdonsággal, az upsert funkcióval is gazdagodott. A PostgreSQL 9.5 teljes changelogja itt érhető el, mi az érdekesebb funkciókból szemezgettünk.

Jogosultságok és JSONB

A 9.5 egyik fontos újdonsága a sorszintű biztonság (row level security) lesz. A funkció lehetővé teszi, hogy sokfelhasználós környezetben jogosultság szerint megkülönbözessük, hogy mely sorokat mely felhasználók láthatnak, kérdezhetnek le. Ez a funkció a SQL Server 2016-ban is újdonság lesz, úgy tűnik, hirtelen mindeki most ért ide a kért képességek implementációjában (vagy csak nagyon figyelnek egymásra a területen dolgozó fejlesztők).

Egy ideje már kipróbálható, de stabil verzióban most lesz elérhető először a BRIN, vagyis a block range index. Ennek lényege, hogy ha olyan oszlopra érkezik lekérdezés, amely amúgy természeténél fogva sorba rendezett (timestamp, sorszám, stb.), akkor nélkülözhető ezekre a b-tree index létrehozása. A Postgres a táblákat page-ekre bontja, a BRIN pedig rögzíti, hogy az ilyen oszlopoknál melyik a nyitó és a záró érték. Ez a nagyon nagy tábláknál lehetővé teszi, hogy a motor villámgyorsan kikeresse, mely page-en található a kért rekord, majd a szekvenciális soron végigfutva megtalálja a kérdéses rekordot. A BRIN nem minden esetben ideális, a b-tree-nél lassabb, azonban jóval kisebb lemezterületet foglal és kevesebb erőforrást emészt fel a frissen tartása.

A Postgres kétféle JSON adattípust tud tárolni, ezek json és jsonb. Ez utóbbi egy bináris formátum, amely a nyers adatot már egy feldolgozott, konvertált formában tárolja. A formátum azonban nem volt túl hatékony, módosítás esetén például a teljes adatmennyiséget ki kellett olvasni, módosítani, majd újra beilleszteni az adatbázisba. A 9.5-től ez rugalmasabbá válik, operátorokkal és módosítókkal szűkíthetjük a lekérdezést a mezőben tárolt adat egy részére, ugyanez pedig a módosításra is igaz. Részletek itt.

Upsert - update OR insert

A PostgreSQL 9.5 egyik legjobban várt képessége a már korábban beharangozott upsert, amely röviden annyit takar, hogy a motor új rekordot illeszt be a táblába, kivéve, ha a rekord már létezik, olyankor csak frissíti (update) a meglévő sort. A képesség triviálisnak hangzik azok számára, akik nincsenek tisztában az elképesztően komplex adatbázis-kezelők működésével és felhasználási körülményeivel. Az egyszerű megvalósítás az, hogy megnézzük, a rekord létezik-e, majd a rendszer eldönti, hogy update vagy insert műveletet kell elvégeznie.

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

A fenti forgatókönyv azonban race conditiont teremt, mivel az ellenőrzés és a művelet végrehajtása között megváltozhat a tábla állapota (például létrejöhet a nem létező rekord). Ez komoly terhelésnél, sok párhuzamos művelet esetében valós veszély, a konzisztencia miatt így ez szóba sem jöhet. Lehetséges megoldás lenne a tábla zárolása az ellenőrzés és a művelet végrehajtása között, ez azonban a teljesítményt csökkentené elfogadhatatlan mértékben.

A Postgres fejlesztőinek megoldása ennél frappánsabb. Az insert SQL-parancsot terjeszti ki a mechanizmus, egy "on conflict" elemmel, amely akkor aktiválódik, ha az elsődleges kulcs (primary key) vagy valamely más megszorítás miatt az insert nem futna le. A kiterjesztéssel ilyenkor megadhatjuk, hogy milyen alternatív parancsot szeretnénk futtatni, ami hiba esetén azonnal le is fut. A fontos momentum, hogy az adatbázis-kezelő a parancs végrehajtásánál nem adja vissza a vezérlést az alkalmazásnak, hanem egyetlen lépésben képes az "upsert" végrehajtására.

További részletek az upsert implementációjáról a Compose blogon olvashatóak.