"Dünyanın en iyi açık kaynaklı ilişkisel veritabanının" en son sürümü birkaç hafta içinde çıkacak (eğer her şey planlandığı gibi giderse). Bu, yılda bir kez tonlarca yeni özelliğe sahip yeni bir sürümün piyasaya sürülmesi şeklindeki olağan programı takip ediyor ve açıkçası bu etkileyici. Bu yüzden PostgreSQL topluluğunun aktif bir üyesi oldum.
Bana göre PostgreSQL 12, önceki sürümlerden farklı olarak bir veya iki devrim niteliğinde özellik (bölümleme veya sorgu paralelliği gibi) içermiyor. Bir keresinde PostgreSQL 12'nin ana özelliğinin daha fazla kararlılık olduğunu söyleyerek şaka yapmıştım. İşletmenizin kritik verilerini yönetirken ihtiyacınız olan da bu değil mi?
Ancak PostgreSQL 12 bununla bitmiyor: yeni özellikler ve iyileştirmelerle uygulamalar daha iyi performans gösterecek, ve tek yapmanız gereken yükseltme yapmak!
(Belki indeksleri yeniden oluşturabiliriz ama bu sürümde alıştığımız kadar korkutucu değil.)
PostgreSQL'i yükseltmek ve gereksiz karışıklıklar olmadan hemen önemli iyileştirmelerin keyfini çıkarmak harika olacak. Birkaç yıl önce PostgreSQL 9.4'ten PostgreSQL 10'a yükseltmeyi inceledim ve PostgreSQL 10'daki gelişmiş sorgu paralelliği sayesinde uygulamanın nasıl hızlandığını gördüm. Ve en önemlisi, benden neredeyse hiçbir şey istenmedi (yalnızca bir yapılandırma parametresi ayarlamak yeterli) max_parallel_workers).
Katılıyorum, uygulamaların yükseltmeden hemen sonra daha iyi çalışması uygundur. Kullanıcıları memnun etmek için çok çalışıyoruz çünkü PostgreSQL'de bunlardan çok daha fazlası var.
Peki PostgreSQL 12'ye basit bir yükseltme sizi nasıl mutlu edebilir? Şimdi sana anlatacağım.
Önemli indeksleme iyileştirmeleri
İndeksleme olmadan bir veritabanı fazla ilerlemeyecektir. Bilgiyi başka nasıl hızlı bir şekilde bulabilirsiniz? PostgreSQL'in temel indeksleme sisteminin adı . Bu tür dizin depolama sistemleri için optimize edilmiştir.
Sadece operatörü kullanıyoruz CREATE INDEX ON some_table (some_column)ve PostgreSQL, biz sürekli olarak değerleri eklerken, güncellerken ve silerken dizini güncel tutmak için birçok çalışma yapar. Her şey sanki sihirli bir değnekmiş gibi kendi kendine çalışıyor.
Ancak PostgreSQL indekslerinin bir sorunu var: ve fazladan disk alanı kaplar ve veri alma ve güncelleme performansını azaltır. "Şişkinlik" derken, indeks yapısını etkisiz bir şekilde korumayı kastediyorum. Bu, kaldırdığı çöp demetleriyle ilgili olabilir veya olmayabilir (bilgi için Peter Gaghan'a teşekkürler))). Dizin şişkinliği özellikle endeksin aktif olarak değiştiği iş yüklerinde fark edilir.
PostgreSQL 12, B-ağacı dizinlerinin performansını büyük ölçüde artırıyor ve TPC-C gibi kıyaslamalarla yapılan deneyler, artık ortalama %40 daha az alanın kullanıldığını gösterdi. Artık yalnızca B ağacı dizinlerinin bakımına (yani yazma işlemlerine) değil, aynı zamanda dizinler çok daha küçük olduğundan veri almaya da daha az zaman harcıyoruz.
Tablolarını aktif olarak güncelleyen uygulamalar - genellikle OLTP uygulamaları () - diski ve işlem isteklerini çok daha verimli kullanacak. Disk alanı ne kadar fazla olursa, altyapıyı yükseltmeden veritabanının büyümesi de o kadar fazla olur.
Bazı yükseltme stratejileri, bu avantajlardan yararlanmak için B ağacı dizinlerinin yeniden oluşturulmasını gerektirir (örn. dizinleri otomatik olarak yeniden oluşturmaz). PostgreSQL'in önceki sürümlerinde, tablolarda büyük dizinlerin yeniden oluşturulması, bu arada değişiklik yapılamadığı için önemli ölçüde aksama süresine neden oluyordu. Ancak PostgreSQL 12'nin başka bir harika özelliği daha var: Artık dizinleri komuta paralel olarak yeniden oluşturabilirsiniz Kesinti süresini tamamen önlemek için.
PostgreSQL 12'de indeksleme altyapısında başka iyileştirmeler de var. Biraz sihrin olduğu başka bir şey - , diğer adıyla WAL (önceden yazma günlüğü). Yazma öncesi günlüğü, hata veya çoğaltma durumunda PostgreSQL'deki her işlemi kaydeder. Uygulamalar bunu arşivlemek için kullanır ve . Elbette, yazma öncesi günlüğü diske yazılır ve bu da performansı etkileyebilir.
PostgreSQL 12, dizin oluşturma sırasında GiST, GIN ve SP-GiST dizinleri tarafından oluşturulan WAL kayıtlarının yükünü azalttı. Bu, çeşitli somut faydalar sağlar: WAL kayıtları daha az disk alanı kaplar ve veriler, örneğin olağanüstü durum kurtarma veya belirli bir noktaya kurtarma sırasında daha hızlı yeniden oynatılır. Uygulamalarınızda bu tür indeksler kullanıyorsanız (örneğin PostGIS tabanlı coğrafi uygulamalar GiST indeksini çok kullanıyorsa), bu da sizin herhangi bir çaba harcamanıza gerek kalmadan deneyimi önemli ölçüde artıracak bir diğer özelliktir.
Bölümleme - daha büyük, daha iyi, daha hızlı
PostgreSQL 10 tanıtıldı . PostgreSQL 11'de kullanımı çok daha kolay hale geldi. PostgreSQL 12'de bölümlerin ölçeğini değiştirebilirsiniz.
PostgreSQL 12'de bölümleme sisteminin performansı, özellikle tabloda binlerce bölüm varsa, önemli ölçüde daha iyi hale geldi. Örneğin, bir sorgu binlerce bölüm içeren bir tablodaki yalnızca birkaç bölümü etkiliyorsa, çok daha hızlı yürütülür. Performans yalnızca bu tür sorgular için geliştirilmemiştir. Ayrıca birden fazla bölüm içeren tablolarda INSERT işlemlerinin ne kadar hızlı olduğunu da fark edeceksiniz.
Verileri kullanarak kaydetme - bu arada, bu harika bir yol ve işte bir örnek — PostgreSQL 12'deki bölümlenmiş tablolar da daha verimli hale geldi. COPY ile her şey zaten hızlıydı, ancak PostgreSQL 12'de kesinlikle uçuyor.
Bu avantajları sayesinde PostgreSQL, daha büyük veri setlerini saklamanıza ve bunların alınmasını kolaylaştırmanıza olanak tanır. Ve sizin açınızdan hiçbir çaba yok. Uygulamanın, zaman serisi verilerinin kaydedilmesi gibi çok sayıda bölümü varsa, basit bir yükseltme, uygulamanın performansını önemli ölçüde artıracaktır.
Bu tam olarak bir "yükseltme ve keyfini çıkarma" iyileştirmesi olmasa da PostgreSQL 12, bölümlenmiş tablolara referans veren yabancı anahtarlar oluşturmanıza olanak tanıyarak bölümlemeyi çalışmayı bir zevk haline getirir.
İLE sorgular artık çok daha iyi
Ne zaman (diğer adıyla CTE, diğer adıyla YOUR sorguları), hakkında bir makale yazmak için sabırsızlanıyordum. . Bu, uygulamayı hızlandıracak özelliklerden biridir. Tabii CTE kullanmıyorsanız.
SQL'e yeni başlayanların CTE'leri kullanmayı sevdiklerini sık sık görüyorum; eğer bunları belirli bir şekilde yazarsanız, gerçekten zorunlu bir program yazıyormuşsunuz gibi hissedersiniz. Kişisel olarak, etrafta dolaşmak için bu sorguları yeniden yazmayı sevdim olmadan CTE ve üretkenliği artırın. Artık her şey farklı.
PostgreSQL 12, yan etkiler olmadan belirli bir CTE türünü satır içi oluşturmanıza olanak tanır (SELECT), isteğin sonuna doğru yalnızca bir kez kullanılır. Yeniden yazdığım CTE sorgularını takip etseydim çoğu bu kategoriye girerdi. Bu, geliştiricilerin artık hızlı bir şekilde çalışan anlaşılır kodlar yazmasına yardımcı olur.
Üstelik PostgreSQL 12, hiçbir şey yapmanıza gerek kalmadan SQL yürütmesini kendisi optimize eder. Her ne kadar şu anda bu tür sorguları optimize etmem gerekmeyecek olsa da, PostgreSQL'in sorgu optimizasyonu üzerinde çalışmaya devam etmesi harika.
Tam Zamanında (JIT) - artık varsayılan
PostgreSQL 12 destekli sistemlerde JIT derlemesi varsayılan olarak etkindir. Öncelikle destek alıyorsunuz bazı dahili işlemler için ve ikinci olarak, seçilmiş listelerdeki (SELECT'ten sonra sahip olduğunuz) ifadelere sahip sorgular (en basit örnek x + y'dir), toplamalar, WHERE cümleciklerine sahip ifadeler ve diğerleri, performansı artırmak için JIT'i kullanabilir.
PostgreSQL 12'de JIT varsayılan olarak etkin olduğundan performans kendi kendine artacaktır, ancak sorgu performansını ölçmek ve herhangi bir ayar yapmanız gerekip gerekmediğini görmek için uygulamayı JIT'i tanıtan PostgreSQL 11'de test etmenizi öneririm.
PostgreSQL 12'deki diğer yeni özellikler ne olacak?
PostgreSQL 12, standart SQL/JSON rota ifadelerini kullanarak JSON verilerini inceleme yeteneğinden bir parametreyle çok faktörlü kimlik doğrulamasına kadar bir sürü harika yeni özelliğe sahiptir. clientcert=verify-full, oluşturulan sütunlar ve çok daha fazlası. Ayrı bir yazı için yeterli.
PostgreSQL 10 gibi PostgreSQL 12 de yükseltmeden hemen sonra genel performansı artıracaktır. Elbette kendi yolunuzu belirleyebilirsiniz; iyileştirmeleri etkinleştirmeden önce uygulamayı üretim sisteminde benzer koşullar altında test edin, tıpkı benim PostgreSQL 10'da yaptığım gibi. PostgreSQL 12 zaten beklediğimden daha kararlı olsa bile, test etme konusunda tembel olmayın. uygulamaları üretime sunmadan önce iyice inceleyin.
Kaynak: habr.com