, a „világ legjobb nyílt forráskódú relációs adatbázisának” legújabb verziója néhány héten belül megjelenik (ha minden a tervek szerint halad). Ez követi a szokásos ütemtervet, amikor évente egyszer kiadnak egy új verziót rengeteg új funkcióval, és őszintén szólva ez lenyűgöző. Ezért lettem a PostgreSQL közösség aktív tagja.
Véleményem szerint a korábbi kiadásokkal ellentétben a PostgreSQL 12 nem tartalmaz egy vagy két forradalmi funkciót (például particionálást vagy lekérdezés párhuzamosságát). Egyszer viccelődtem, hogy a PostgreSQL 12 fő jellemzője a nagyobb stabilitás. Nem erre van szüksége, amikor vállalkozása kritikus adatait kezeli?
A PostgreSQL 12 azonban nem áll meg itt: az új funkciókkal és fejlesztésekkel az alkalmazások jobban teljesítenek, és csak frissíteni kell!
(Nos, talán újjáépíteni az indexeket, de ebben a kiadásban ez nem olyan ijesztő, mint megszoktuk.)
Nagyszerű lesz frissíteni a PostgreSQL-t, és azonnal élvezni a jelentős fejlesztéseket, felesleges felhajtás nélkül. Néhány évvel ezelőtt áttekintettem a PostgreSQL 9.4-ről a PostgreSQL 10-re való frissítést, és láttam, hogyan gyorsult fel az alkalmazás a PostgreSQL 10 továbbfejlesztett lekérdezési párhuzamosságának köszönhetően. És ami a legfontosabb, szinte semmit sem kellett tőlem (csak be kell állítani egy konfigurációs paramétert max_parallel_workers).
Egyetértek, kényelmes, ha az alkalmazások közvetlenül a frissítés után jobban működnek. És nagyon igyekszünk a felhasználók kedvében járni, mert a PostgreSQL-ben egyre több van belőlük.
Tehát hogyan tehet boldoggá egy egyszerű frissítés a PostgreSQL 12-re? most elmondom.
Jelentős indexelési fejlesztések
Indexelés nélkül egy adatbázis nem megy messzire. Hogyan más módon találhat gyorsan információkat? A PostgreSQL alapvető indexelő rendszere az ún . Ez az indextípus tárolórendszerekhez van optimalizálva.
Egyszerűen az operátort használjuk CREATE INDEX ON some_table (some_column), és a PostgreSQL sokat dolgozik azért, hogy az indexet naprakészen tartsa, miközben folyamatosan beszúrunk, frissítünk és törölünk értékeket. Minden magától működik, mintha varázsütésre.
A PostgreSQL-indexekkel azonban van egy probléma – ezek és extra lemezterületet foglalnak el, és csökkentik az adatvisszakeresés és -frissítés teljesítményét. A "felfúvódás" alatt az index szerkezetének hatástalan fenntartását értem. Ez lehet – vagy nem – összefügg az eltávolított szemétsorokkal (köszönöm Peter Gaghannek az információt))). Az index felfúvódása különösen észrevehető olyan munkaterheléseknél, ahol az index aktívan változik.
A PostgreSQL 12 nagymértékben javítja a B-fa indexek teljesítményét, és a benchmarkokkal, például a TPC-C-vel végzett kísérletek kimutatták, hogy jelenleg átlagosan 40%-kal kevesebb területet használnak. Most már nem csak a B-fa indexek karbantartására (azaz írási műveletekre), hanem az adatok lekérésére is kevesebb időt fordítunk, mert az indexek sokkal kisebbek.
Alkalmazások, amelyek aktívan frissítik a tábláikat - jellemzően OLTP alkalmazások () - sokkal hatékonyabban fogja használni a lemezt és feldolgozni a kéréseket. Minél több lemezterület, annál több területet kell az adatbázisnak bővítenie az infrastruktúra frissítése nélkül.
Egyes frissítési stratégiák megkövetelik a B-fa indexek újraépítését, hogy kihasználják ezeket az előnyöket (pl. nem építi újra automatikusan az indexeket). A PostgreSQL korábbi verzióiban a nagy indexek újraépítése a táblákon jelentős leállást eredményezett, mert közben nem lehetett változtatásokat végrehajtani. De a PostgreSQL 12-nek van egy másik nagyszerű funkciója: most már a paranccsal párhuzamosan újraépítheti az indexeket az állásidő teljes elkerülése érdekében.
Vannak további fejlesztések is a PostgreSQL 12 indexelési infrastruktúrájában. Egy másik dolog, ahol volt valami varázslat... , más néven WAL (előre írható napló). Egy előreírási napló rögzít minden tranzakciót a PostgreSQL-ben hiba és replikáció esetén. Az alkalmazások archiválásra és . Természetesen az előreírási napló lemezre kerül, ami befolyásolhatja a teljesítményt.
A PostgreSQL 12 csökkentette a WAL rekordok többletköltségét, amelyeket a GiST, GIN és SP-GiST indexek hoznak létre az indexkészítés során. Ez számos kézzelfogható előnnyel jár: a WAL-rekordok kevesebb lemezterületet foglalnak el, és az adatok gyorsabban játszódnak le, például a katasztrófa-helyreállítás vagy a pontos helyreállítás során. Ha ilyen indexeket használ az alkalmazásaiban (például a PostGIS alapú térinformatikai alkalmazások sokat használják a GiST indexet), ez egy másik funkció, amely jelentősen javítja a felhasználói élményt anélkül, hogy az Ön részéről bármilyen erőfeszítést igényelne.
Particionálás - nagyobb, jobb, gyorsabb
Bemutatták a PostgreSQL 10-et . A PostgreSQL 11-ben sokkal könnyebbé vált a használata. A PostgreSQL 12-ben módosíthatja a szakaszok léptékét.
A PostgreSQL 12-ben a particionáló rendszer teljesítménye lényegesen jobb lett, különösen, ha több ezer partíció van a táblában. Például, ha egy lekérdezés csak néhány partíciót érint egy több ezer partíciót tartalmazó táblában, akkor sokkal gyorsabban fog végrehajtani. A teljesítmény nem csak az ilyen típusú lekérdezéseknél javul. Azt is észre fogja venni, hogy az INSERT műveletek milyen gyorsabbak a több partícióval rendelkező táblákon.
Adatrögzítés segítségével - mellesleg ez egy remek módszer és itt van egy példa — a PostgreSQL 12 particionált táblái is hatékonyabbak lettek. A COPY-nál már minden gyors volt, de a PostgreSQL 12-ben abszolút repül.
Ezeknek az előnyöknek köszönhetően a PostgreSQL lehetővé teszi még nagyobb adatkészletek tárolását, és megkönnyíti azok visszakeresését. És semmi erőfeszítés a részedről. Ha az alkalmazásnak sok partíciója van, például rögzíti az idősorok adatait, egy egyszerű frissítés jelentősen javítja a teljesítményét.
Bár ez nem egy „frissítés és élvezet” fejlesztés, a PostgreSQL 12 lehetővé teszi olyan idegen kulcsok létrehozását, amelyek particionált táblákra hivatkoznak, így a particionálás élvezetessé teszi a munkát.
A lekérdezésekkel sokkal jobb lett
Mikor (más néven CTE, más néven WITH queries), alig vártam, hogy cikket írjak róla . Ez az egyik olyan funkció, amely felgyorsítja az alkalmazást. Kivéve persze, ha CTE-t használ.
Gyakran tapasztalom, hogy az SQL-ben kezdők szeretik használni a CTE-ket; ha egy bizonyos módon írod őket, akkor tényleg olyan érzés lesz, mintha egy kötelező programot írnál. Személy szerint szerettem átírni ezeket a lekérdezéseket, hogy tájékozódjak nélkül CTE és a termelékenység növelése. Most minden más.
A PostgreSQL 12 lehetővé teszi egy adott típusú CTE beillesztését mellékhatások nélkül (SELECT), amely csak egyszer kerül felhasználásra a kérés végén. Ha nyomon követném az átírt CTE-lekérdezéseket, a legtöbbjük ebbe a kategóriába tartozna. Ez segít a fejlesztőknek világos kód megírásában, amely mostantól szintén gyorsan fut.
Ezenkívül a PostgreSQL 12 magát az SQL-végrehajtást optimalizálja anélkül, hogy bármit is tenne. És bár valószínűleg most nem kell optimalizálnom az ilyen lekérdezéseket, nagyszerű, hogy a PostgreSQL továbbra is dolgozik a lekérdezések optimalizálásán.
Just-in-Time (JIT) – most alapértelmezett
Támogatott PostgreSQL 12 rendszereken A JIT fordítás alapértelmezés szerint engedélyezve van. Először is kapsz támogatást bizonyos belső műveletekhez, másodszor pedig a kifejezéseket tartalmazó lekérdezések (a legegyszerűbb példa az x + y) kiválasztási listákban (amelyek a SELECT után vannak), aggregátumok, a WHERE záradékkal rendelkező kifejezések és mások használhatják a JIT-t a teljesítmény javítására.
Mivel a JIT alapértelmezés szerint engedélyezve van a PostgreSQL 12-ben, a teljesítmény önmagában javulni fog, de azt javaslom, hogy tesztelje az alkalmazást a PostgreSQL 11-ben, amely bevezette a JIT-et, hogy mérje a lekérdezés teljesítményét, és ellenőrizze, hogy szükség van-e valami beállításra.
Mi a helyzet a PostgreSQL 12 többi új funkciójával?
A PostgreSQL 12 rengeteg klassz új funkcióval rendelkezik, a JSON-adatok szabványos SQL/JSON útvonalkifejezésekkel történő vizsgálatának lehetőségétől a paraméteres többtényezős hitelesítésig. clientcert=verify-full, létrehozott oszlopokat és még sok mást. Elég egy külön bejegyzéshez.
A PostgreSQL 10-hez hasonlóan a PostgreSQL 12 is javítani fogja az általános teljesítményt közvetlenül a frissítés után. Természetesen Önnek is megvan a saját útja – tesztelje az alkalmazást hasonló feltételek mellett az éles rendszeren, mielőtt engedélyezné a fejlesztéseket, ahogy én tettem a PostgreSQL 10-nél. Még ha a PostgreSQL 12 már stabilabb is, mint vártam, ne legyen lusta a tesztelésben alkalmazásokat alaposan, mielőtt gyártásba bocsátanák őket.
Forrás: will.com