Bu neden önemli?
Postgres, dünyanın en çok kullanılan veritabanlarından biri. 'Her şey için Postgres' diyenlerin elini güçlendiren her özellik, bir ek servis daha kurmak zorunda kalmamak demek. Graf sorguları da SQL standardının bir parçası, yani öğrendiğin şey başka yerde de işine yarayabilir.
Sorun: JOIN zincirleri
Bir online mağaza düşün. customers (müşteriler), orders (siparişler) ve products (ürünler) tabloların var. Bunları birbirine bağlayan iki ara tablo daha var: hangi müşterinin hangi siparişi verdiğini tutan customer_orders ve hangi siparişte hangi ürün olduğunu tutan order_items.
“Ayşe hangi ürünleri aldı?” gibi basit bir soru için beş tabloyu JOIN ile birbirine bağlaman gerekiyor. Yazılabilir ama okunması zor. İlişkiler karmaşıklaştıkça daha da çirkinleşiyor.
Çözüm: Tabloları graf olarak görmek
Graf, noktalar ve onları bağlayan oklardan oluşan bir yapı. Noktalara düğüm (vertex), oklara kenar (edge) deniyor. Sosyal ağlar, yol haritaları ya da bizim mağaza örneği aslında birer graf.
Postgres 19, SQL standardının bir parçası olan SQL/PGQ (Property Graph Queries) desteğini getiriyor. İki adımı var:
1. Grafı tanımla. CREATE PROPERTY GRAPH ile Postgres’e hangi tabloların düğüm, hangilerinin kenar olduğunu söylüyorsun. Mağaza örneğinde müşteriler, siparişler ve ürünler düğüm. İki ara tablo da kenar. Her kenar için “kaynak şu tablo, hedef şu tablo” diyorsun.
Önemli nokta: Bu işlem yeni tablo oluşturmuyor, verini kopyalamıyor. Belgelere göre graf tanımı, tabloların üstünde duran salt okunur bir görünüm (view) gibi çalışıyor. Şeman olduğu gibi kalıyor.
2. Deseni yaz. Sorguda GRAPH_TABLE ifadesinin içine bir desen yazıyorsun. Desende düğümler parantezle (), kenarlar okla -[]-> gösteriliyor. Kabaca “müşteriden siparişe, siparişten ürüne giden yolları bul, müşterinin adı Ayşe olsun” diye okunuyor. Sonuç normal bir tablo gibi dönüyor. İstersen onu başka tablolarla JOIN’leyebiliyor, filtreleyebiliyorsun.
Neo4j’nin yerini alır mı?
Neo4j gibi graf veritabanları, veriyi doğrudan graf yapısında saklıyor. Postgres’te ise veri yine tablolarda duruyor. Belgelere göre graf sorguları da normal sorgularla aynı planlayıcıdan geçiyor. Videodaki yorum da bu yönde: Çok büyük graflarda derin gezinme performansına ihtiyacın varsa özel bir graf veritabanı hâlâ daha iyi seçenek olabilir. Ama derdin uzun JOIN zincirlerinin okunmazlığıysa, bu özellik tam sana göre.
Diğer yenilikler
ON CONFLICT DO SELECT. “Bu e-postayla kullanıcı yoksa ekle, varsa mevcut kaydı bana ver” çok yaygın bir istek. Şimdiye kadar genelde iki ayrı sorgu gerekiyordu: bir INSERT, ardından bir SELECT. İkisi arasında başka biri araya girebiliyordu. Artık tek bir INSERT ... ON CONFLICT DO SELECT ... RETURNING ile satır ya ekleniyor ya da mevcut hali dönüyor. İstersen satırı aynı anda kilitleyebiliyorsun.
REPACK. Postgres bir satırı güncellediğinde eskisini yerinde değiştirmez, yeni bir kopya yazar. Eski kopyalar zamanla boşluk olarak birikir. VACUUM bu boşluğu tekrar kullanılabilir yapar ama diske geri vermez. VACUUM FULL verir ama işlem boyunca tabloyu kilitler. Yeni REPACK komutu VACUUM FULL ile CLUSTER komutlarını birleştiriyor. CONCURRENTLY seçeneğiyle tablo okunup yazılmaya devam ederken çalışabiliyor. Videonun hatırlattığı bir detay: İşlem sırasında tablonun ve indekslerinin ikinci bir kopyası için boş disk alanına ihtiyacın var.
Sürüm notlarında bunların yanında zaman aralıklı güncellemeler için FOR PORTION OF, sorgu planlayıcısının kararlarını sabitlemeye yarayan yeni eklentiler ve paralel çalışabilen autovacuum da var.
Ne zaman çıkıyor?
Postgres 19 henüz beta aşamasında. 13 Ağustos’ta üçüncü beta yayınlandı. Postgres’in büyük sürümleri genelde sonbaharda çıkıyor. Canlı sistemlerde son sürümü beklemek, denemeleri ise şimdiden bir test ortamında yapmak mantıklı.
Düşün
- Kendi projendeki en uzun JOIN zinciri hangisi? Onu bir yol deseni olarak nasıl anlatırdın?
- Aynı iş için ayrı bir veritabanı kurmak ile mevcut veritabanına bir özellik eklemek arasında nasıl karar verirsin?