, a legújabb verziója a "világ legjobb nyílt forráskódú relációs adatbázisának" néhány héten belül megjelenik (ha minden a tervek szerint halad). Ez megfelel a szokásos ütemtervnek — évente jelenik meg új verzió számos új funkcióval, és őszintén szólva, ez lenyűgöző. Ezért lettem aktív tagja a PostgreSQL közösségnek.
Szerintem, a korábbi kiadásoktól eltérően, a PostgreSQL 12 nem tartalmaz egy-két forradalmi funkciót (mint például a partiionálás vagy a párhuzamos lekérdezések). Viccelődtem, hogy a PostgreSQL 12 fő vonzereje a nagyobb stabilitás. És nem ez a legfontosabb, amikor a vállalkozásod kritikus adatainak kezeléséről van szó?
De a PostgreSQL 12 nem merül ki ennyiben: az új funkciókkal és fejlesztésekkel a alkalmazások jobban fognak működni, és mindössze annyit kérünk tőled, hogy végezd el a frissítést!
(Nos, talán az indexeket is újra kell építeni, de ebben a kiadásban ez nem olyan rémisztő, mint ahogyan azt megszoktuk.)
Milyen nagyszerű is lesz — frissíteni a PostgreSQL-t, és azonnal élvezni a jelentős javulásokat minimális erőfeszítéssel. Néhány évvel ezelőtt elemeztem a PostgreSQL 9.4-ről 10-re való frissítést, és láttam, hogy mennyivel felgyorsult az alkalmazás a PostgreSQL 10 jobb párhuzamos lekérdezéseinek köszönhetően. És ami a legfontosabb, hogy tőlem szinte semmi nem volt szükséges (csak be kellett állítanom egy konfigurációs paramétert. max_parallel_workers).
Egyetértesz, hogy kényelmes, amikor a frissítés után az alkalmazások jobban működnek. Mi is nagyon igyekszünk örömet szerezni a felhasználóknak, hiszen egyre több van belőlük a PostgreSQL esetében.
Hogyan fog egy egyszerű frissítés a PostgreSQL 12-re boldoggá tenni? Most mesélek róla.
Jelentős fejlesztések az indexelésben
Indexelés nélkül az adatbázis nem fog messzire jutni. Hogyan találhatnánk meg gyorsan az információt? A PostgreSQL alapvető indexelési rendszere a . Ez a típusú index a tárolási rendszerekhez van optimalizálva.
Csak annyit kell tennünk, hogy a következő operátort használjuk: CREATE INDEX ON some_table (some_column),és a PostgreSQL elvégzi a nagy munkát, hogy naprakészen tartsa az indexet, miközben folyamatosan beszúrunk, frissítünk és törlünk értékeket. Minden automatikusan működik, mint egy varázslat.
De a PostgreSQL indexeinek van egy problémája — azok és felesleges helyet foglalnak el a lemezen, miközben a lekérdezések és adatok frissítéseinek teljesítménye csökken. A "túlnövekedés" alatt azt értem, hogy az indexstruktúra fenntartása hatékonytalan. Ez lehet — és lehet, hogy nem is — összefügg a törölt felesleges tuple-okkal, (köszönet az információért Peter Geoghgegan-nak ()). Az index túlnövekedése különösen észlelhető azokban a munkaterhelésekben, ahol az index aktívan változik.
A PostgreSQL 12 jelentősen javítja a B-fák indexeinek teljesítményét, és a TPC-C típusú tesztek kísérletei azt mutatták, hogy a tárhely most átlagosan 40%-kal kevesebb helyet igényel. Most kevesebb időt töltünk nemcsak a B-fa indexek karbantartásával (azaz írási műveletek), hanem az adatok lekérdezésével is, mivel az indexek sokkal kisebbek lettek.
Azok az alkalmazások, amelyek aktívan frissítik tábláikat — ezek általában OLTP alkalmazások () — sokkal hatékonyabban használják a lemezt és kezelik a lekérdezéseket. Minél több hely van a lemezen, annál nagyobb a lehetőség a bázi adatbázis növekedésére anélkül, hogy szükség lenne az infrastruktúra frissítésére.
Egyes frissítési stratégiák megkövetelik, hogy a B-fa indexeket újraépítsék az előnyök kihasználásához (például, nem építi újra automatikusan az indexeket). A korábbi PostgreSQL verziókban a nagy indexek újraépítése a táblákban jelentős leálláshoz vezetett, mivel ez idő alatt nem lehetett módosításokat végezni. De a PostgreSQL 12-ben van egy másik nagyszerű funkció: most a indexek párhuzamosan is újraépíthetők a parancs segítségével, hogy teljesen elkerüljük a leállást.
A PostgreSQL 12-ben még más javítások is vannak az indexelési infrastruktúrában. Még egy dolog, ahol nem maradt el a varázslat — , más néven WAL (write-ahead log). Az előzetes naplózás minden tranzakciót rögzít a PostgreSQL-ben hiba és replikáció esetére. Az alkalmazások ezt használják archiválásra és . Természetesen az előzetes naplózás a lemezre íródik, ami befolyásolhatja a teljesítményt.
A PostgreSQL 12 esetében csökkentek a WAL-bejegyzések költségei, amelyeket a GiST, GIN és SP-GiST indexek generálnak az index létrehozásakor. Ez számos kézzelfogható előnyt kínál: a WAL-bejegyzések kevesebb lemezterületet foglalnak el, és az adatok gyorsabban reprodukálhatóak, például hibaelhárítás vagy időpontra való visszaállítás során. Ha ilyen indexeket használ az alkalmazásaiban (például a PostGIS alapú térinformatikai alkalmazások nagymértékben használják a GiST indexet), ez egy újabb funkció, amely jelentősen javítja a teljesítményt, anélkül, hogy bárminemű erőfeszítést tennie kellene.
Partitionálás — több, jobb, gyorsabb
A PostgreSQL 10 már megjelent . A PostgreSQL 11-ben sokkal könnyebben használhatóvá vált. A PostgreSQL 12-ben már meg lehet változtatni a partíciók méretét.
A PostgreSQL 12-ben a partíciózási rendszerek teljesítménye jelentősen javult, különösen, ha a táblázatban ezrek vannak. Például ha a lekérdezés csak néhány partíciót érint a táblázatban, ahol több ezer partíció van, az jelentősen gyorsabb lesz. A teljesítmény nemcsak az ilyen típusú lekérdezések esetében javult. Ezen kívül észre fogja venni, hogy a sok partícióval rendelkező táblázatokba történő INSERT műveletek is felgyorsultak.
Az adatok rögzítése a — egyébként ez egy nagyszerű módszer és itt van egy példa -ba a partícionált táblázatokba a PostgreSQL 12-ben szintén hatékonyabb lett. A COPY már eddig is gyors volt, de a PostgreSQL 12-ben már szinte repül.
Ezeknek az előnyöknek köszönhetően a PostgreSQL-ben még nagyobb méretű adathalmazon állíthatók tárolásra, az adatok előhívása pedig egyszerűbb lett. És mindez erőfeszítések nélkül. Ha az alkalmazásban sok partíció van, például ha idősort adatok rögzítéséről van szó, egy egyszerű frissítés jelentősen javítja a teljesítményét.
Bár ez a fejlesztés nem pontosan a „frissítettük, és örvendünk” kategóriába tartozik, a PostgreSQL 12-ben külső kulcsok hozhatók létre, amelyek hivatkoznak a partícionált táblázatokra, így a partícionálás kezelése valódi élvezet.
A WITH lekérdezések sokkal jobbak lettek
Amikor (más néven CTE, más néven WITH lekérdezések), alig vártam, hogy cikket írjak arról, . Ez az egyik azok közül a funkciók közül, amelyek gyorsabbá teszik az alkalmazást. Ha természetesen CTE-t használ.
Gyakran észreveszem, hogy az SQL újoncok szeretik a CTE-ket használni: ha bizonyos módon írjuk őket, az ember úgy érzi, hogy imperatív programot ír. Személy szerint szeretek átírni ezeket a lekérdezéseket, hogy elkerüljem nélkül a CTE-ket és növeljem a teljesítményt. Most minden más.
A PostgreSQL 12 lehetővé teszi egy bizonyos típusú CTE beépítését mellékhatások nélkül (SELECT), amelyet csak egyszer használnak a lekérdezés vége felé. Ha statisztikát vezetnék az általam átírt CTE-vizsgálatokról, akkor a legtöbbjük ebbe a kategóriába tartozna. Ez segít a fejlesztőknek érthető kódot írni, amely most már gyorsan is működik.
Továbbá, a PostgreSQL 12 optimalizálja az SQL végrehajtását, így semmit sem kell tennie. És bár most valószínűleg nem kell optimalizálnom az ilyen lekérdezéseket, jó látni, hogy a PostgreSQL folyamatosan dolgozik a lekérdezések optimalizálásán.
Just-in-Time (JIT) — most már alapértelmezett
A PostgreSQL 12 rendszerében támogatott a JIT-lefordítás alapértelmezés szerint engedélyezve van. Először is, támogatást kap bizonyos belső műveletekhez, másodszor, az összetett kifejezések (a legegyszerűbb példa — x + y) a választási listákban (amelyek a SELECT után vannak), az aggregációkban, a WHERE kifejezésekkel és másokkal a JIT segítségével javíthatják a teljesítményt.
Mivel a JIT alapértelmezés szerint engedélyezve van a PostgreSQL 12-ben, a teljesítmény automatikusan javul, de azt javaslom, hogy tesztelje az alkalmazást a PostgreSQL 11-ben, ahol a JIT először jelent meg, hogy mérje a lekérdezések teljesítményét, és megtudja, szükség van-e bármiféle beállításra.
Mi a helyzet a PostgreSQL 12 többi új funkciójával?
A PostgreSQL 12 rengeteg új izgalmas funkciót kínál — a JSON adatok standard SQL/JSON kifejezésekkel történő vizsgálatától kezdve a többlépcsős hitelesítésig a következő paraméterrel clientcert=verify-full, létrehozott oszlopokkal és még sok mással. Ez egy külön posztot megérne.
A PostgreSQL 10-hez hasonlóan a PostgreSQL 12 is azonnal növeli az általános teljesítményt a frissítés után. Természetesen lehet saját módszere is — tesztelje az alkalmazást hasonló körülmények között a működő rendszerben, mielőtt engedélyezné a fejlesztéseket, ahogy azt én tettem a PostgreSQL 10-nél. Még ha a PostgreSQL 12 már most is stabilabb, mint gondoltam, ne lazítson a minőségi alkalmazástesztelés során, mielőtt élesbe állítja.
Forrás: habr.com
