, "Dünyanın ən yaxşı açıq mənbəli əlaqəli verilənlər bazası" nın ən son buraxılışı bir neçə həftəyə (hər şey plana uyğun gedirsə) çıxacaq. Bu, adi cədvələ uyğundur - bir çox yeni funksiyaları olan yeni versiya ildə bir dəfə çıxır və açığı, təsir edicidir. Buna görə də PostgreSQL icmasının fəal üzvü oldum.
Fikrimcə, keçmiş buraxılışlardan fərqli olaraq, PostgreSQL 12-də bir və ya iki inqilabi xüsusiyyət yoxdur (məsələn, bölmə və ya sorğu paralelliyi). Mən bir dəfə zarafat etmişdim ki, PostgreSQL 12-nin əsas xüsusiyyəti daha böyük sabitlikdir. Biznesinizin kritik məlumatlarını idarə edərkən bu sizə lazım deyilmi?
Lakin PostgreSQL 12 bununla məhdudlaşmır: yeni xüsusiyyətlər və təkmilləşdirmələrlə tətbiqlər daha yaxşı işləyəcək, Sizə lazım olan tək şey təkmilləşdirməkdir!
(Yaxşı, bəlkə hətta indeksləri yenidən qura bilərsiniz, lakin bu buraxılışda bizim adət etdiyimiz qədər qorxulu deyil.)
PostgreSQL-i təkmilləşdirmək və lazımsız jestlər olmadan dərhal əhəmiyyətli təkmilləşdirmələrdən həzz almaq əla olardı. Bir neçə il əvvəl mən PostgreSQL 9.4-dən PostgreSQL 10-a təkmilləşdirməni təhlil etdim və PostgreSQL 10-da təkmilləşdirilmiş sorğu paralelliyi sayəsində tətbiqin nə qədər sürətli olduğunu gördüm. Və ən əsası, məndən demək olar ki, heç nə tələb olunmur (sadəcə konfiqurasiya parametrini təyin edin) max_parallel_workers).
Razılaşın, yeniləmədən dərhal sonra tətbiqlər daha yaxşı işlədikdə rahatdır. Biz istifadəçiləri sevindirmək üçün çox çalışırıq, çünki PostgreSQL-də onların sayı getdikcə daha çoxdur.
PostgreSQL 12-ə sadə təkmilləşdirmə sizi necə xoşbəxt edir? İndi sizə deyəcəm.
Əsas indeksləşdirmə təkmilləşdirmələri
İndeksləşmədən verilənlər bazası uzağa getməyəcək. Başqa necə məlumatı tez tapa bilərsiniz? Əsas PostgreSQL indeksləşdirmə sistemi adlanır . Bu tip indeks saxlama sistemləri üçün optimallaşdırılmışdır.
Biz sadəcə operatordan istifadə edirik CREATE INDEX ON some_table (some_column), və PostgreSQL biz daim dəyərlər daxil edərkən, yeniləyərkən və silərkən indeksi yeni saxlamaq üçün əla iş görür. Hər şey sehrli kimi öz-özünə işləyir.
Ancaq PostgreSQL indekslərinin bir problemi var - onlar və əlavə disk sahəsi tutur və məlumatların çıxarılması və yenilənməsi performansı azalır. “Bloat” dedikdə, indeks strukturunun səmərəsiz saxlanılmasını nəzərdə tuturam. Bu, zibil qutuları ilə əlaqəli ola bilər və ya olmaya da bilər (məlumat üçün Peter Gagan-a təşəkkürlər))). İndeksin şişməsi indeksin aktiv şəkildə dəyişdiyi iş yüklərində xüsusilə nəzərə çarpır.
PostgreSQL 12 B-ağacı indekslərinin performansını xeyli yaxşılaşdırır və TPC-C kimi testlərlə aparılan təcrübələr göstərdi ki, indi yerdən orta hesabla 40% az istifadə olunur. İndi biz yalnız B-ağacı indekslərini saxlamağa (yəni, əməliyyatları yazmağa) deyil, həm də məlumatları əldə etməyə daha az vaxt sərf edirik, çünki indekslər xeyli kiçilib.
Cədvəllərini aktiv şəkildə yeniləyən proqramlar adətən OLTP proqramlarıdır () diskdən istifadə və sorğuların işlənməsi baxımından çox daha səmərəli olacaq. Nə qədər çox disk sahəsi olsa, verilənlər bazası infrastruktur təkmilləşdirmələri olmadan böyümək üçün bir o qədər çox yer tutmalıdır.
Bəzi təkmilləşdirmə strategiyaları bu üstünlüklərdən yararlanmaq üçün B-ağacı indekslərini yenidən qurmağınızı tələb edir (məsələn, indeksləri avtomatik olaraq yenidən qurmayacaq). PostgreSQL-in əvvəlki versiyalarında cədvəllərdə böyük indekslərin yenidən qurulması əhəmiyyətli fasilələrlə nəticələndi, çünki bu müddət ərzində heç bir dəyişiklik edilə bilməzdi. Lakin PostgreSQL 12 başqa bir gözəl xüsusiyyətə malikdir: indi əmrlə paralel olaraq indeksləri yenidən qura bilərsiniz. fasilələrin tamamilə qarşısını almaq üçün.
PostgreSQL 12 indeksləşdirmə infrastrukturunda başqa təkmilləşdirmələrə malikdir. Bir sehrin olduğu başqa bir şey - , aka WAL (qabaqcadan yazma jurnalı). Öncədən yazma jurnalı uğursuzluq və təkrarlama halında hər bir əməliyyatı PostgreSQL-ə yazır. Proqramlar onu arxivləşdirmə və . Əlbəttə ki, qabaqcadan yazma jurnalı diskə yazılır və bu, performansa təsir edə bilər.
PostgreSQL 12, indeks qurulduqda GiST, GIN və SP-GiST indeksləri tərəfindən yaradılan WAL qeydlərinin əlavə xərclərini azaldıb. Bunun bir sıra nəzərəçarpacaq üstünlükləri var: WAL qeydləri diskdə daha az yer tutur və verilənlər, məsələn, uğursuzluq və ya vaxtında bərpa zamanı daha sürətli təkrar oxunur. Tətbiqlərinizdə belə indekslərdən istifadə edirsinizsə (məsələn, PostGIS əsaslı yer məkan proqramları GiST indeksindən çox istifadə edir), bu, sizin tərəfinizdən heç bir səy göstərmədən performansı xeyli yaxşılaşdıracaq başqa bir xüsusiyyətdir.
Bölmə - daha böyük, daha yaxşı, daha sürətli
PostgreSQL 10 təqdim edildi . PostgreSQL 11-də istifadə etmək daha asan oldu. PostgreSQL 12-də arakəsmələri miqyaslandıra bilərsiniz.
PostgreSQL 12-də bölmə sisteminin performansı, xüsusən də cədvəldə minlərlə arakəsmə olduqda əhəmiyyətli dərəcədə yaxşılaşmışdır. Məsələn, əgər sorğu minlərlə olan cədvəldə yalnız bir neçə bölməyə təsir edərsə, o, daha sürətli işləyəcək. Performans təkmilləşdirmələri bu tip sorğularla məhdudlaşmır. Çox bölməli cədvəllərdə INSERT əməliyyatlarının nə qədər sürətli olduğunu da görəcəksiniz.
İstifadə edərək məlumatların yazılması - yeri gəlmişkən, bu əla yoldur və burada bir nümunə var - PostgreSQL 12-də bölmələrə ayrılmış cədvəllər də daha səmərəli oldu. COPY ilə hər şey sürətli idi, lakin PostgreSQL 12-də tamamilə uçur.
Bu üstünlüklər PostgreSQL-ə daha böyük verilənlər toplusunu saxlamağa imkan verir və onları əldə etməyi asanlaşdırır. Və sizin tərəfinizdən heç bir səy yoxdur. Tətbiqdə bir çox bölmə varsa, məsələn, zaman seriyası məlumatlarını yazırsa, sadə bir yeniləmə onun işini əhəmiyyətli dərəcədə yaxşılaşdıracaq.
Və bu, tam olaraq təkmilləşdirmə və sevindirici bir təkmil olmasa da, PostgreSQL 12-də bölmələrlə işləməyi zövqlü etmək üçün bölmələrə bölünmüş cədvəllərə istinad edən xarici açarlar yarada bilərsiniz.
İLƏ sorğular daha yaxşı oldu
Zaman (aka CTE, aka WITH sorğular), necə olacağı haqqında məqalə yazmağa can atırdım . Bu, tətbiqi sürətləndirəcək xüsusiyyətlərdən biridir. Əlbəttə ki, siz CTE-dən istifadə etmirsinizsə.
Mən tez-tez görürəm ki, SQL-ə yeni başlayanlar CTE-lərdən istifadə etməyi sevirlər: onları müəyyən bir şəkildə yazsanız, imperativ proqram yazdığınızı hiss edirsiniz. Şəxsən mən dolaşmaq üçün bu sorğuları yenidən yazmağı xoşlayırdım olmadan CTE və məhsuldarlığı artırın. İndi hər şey fərqlidir.
PostgreSQL 12 sizə əlavə təsirlər olmadan müəyyən bir CTE növünü daxil etməyə imkan verir (SELECT), sorğunun sonuna yaxın yalnız bir dəfə istifadə olunur. Yenidən yazdığım CTE sorğularını izləsəm, onların əksəriyyəti bu kateqoriyaya aid olardı. Bu, tərtibatçılara aydın kod yazmağa kömək edir və indi də sürətlidir.
Üstəlik, PostgreSQL 12 SQL icrasını optimallaşdırır, heç nə etmək lazım deyil. Yəqin ki, indi belə sorğuları optimallaşdırmağa ehtiyac duymayacağım halda, PostgreSQL-in sorğuların optimallaşdırılması üzərində işləməyə davam etməsi əladır.
Just-in-Time (JIT) - indi standartdır
Dəstəyi olan PostgreSQL 12 sistemlərində JIT kompilyasiyası standart olaraq aktivdir. Birincisi, dəstək alırsınız bəzi daxili əməliyyatlar üçün və ikincisi, seçilmiş siyahılardakı ifadələrlə (ən sadə nümunə x + y-dir) sorğular (sizdə SELECT-dən sonra var), aqreqatlar, WHERE bəndləri olan ifadələr və digərləri performansı yaxşılaşdırmaq üçün JIT-dən istifadə edə bilər.
PostgreSQL 12-də defolt olaraq JIT aktiv olduğundan, performans öz-özünə yaxşılaşacaq, lakin sorğunun performansını ölçmək və nəyinsə tənzimləməyə ehtiyacı olub-olmadığını görmək üçün tətbiqi JIT-in ilk təqdim edildiyi PostgreSQL 11-də sınamağı təklif edirəm.
Bəs PostgreSQL 12-nin qalan yeni xüsusiyyətləri haqqında nə demək olar?
PostgreSQL 12 standart SQL/JSON marşrut ifadələrindən istifadə edərək JSON məlumatlarını yoxlamaq qabiliyyətindən tutmuş bir çox faktorlu autentifikasiyaya qədər çoxlu yeni xüsusiyyətlərə malikdir. clientcert=verify-full, yaradılan sütunlar və s. Ayrı bir yazı üçün kifayətdir.
PostgreSQL 10 kimi, PostgreSQL 12 də təkmilləşdirmədən dərhal sonra ümumi performansı yaxşılaşdıracaq. Əlbəttə ki, öz yolunuz ola bilər - PostgreSQL 10 ilə etdiyim kimi təkmilləşdirmələrə imkan verməzdən əvvəl tətbiqi oxşar şərtlər altında istehsal sistemində sınaqdan keçirin. PostgreSQL 12 artıq gözlədiyimdən daha stabil olsa belə, tətbiqləri sınaqdan keçirmək üçün tənbəl olmayın. yaxşı, onları istehsala buraxmazdan əvvəl.
Mənbə: www.habr.com