Neden bu seri? PostgreSQL'i üretimde kullanırken öğrendiklerim

Bugün geliştirdiğim projelerin hepsinde veri PostgreSQL'de duruyor: belediyelerin kullandığı bir saha yönetim sisteminde de, onlarca arka plan işçisinin aynı anda yazdığı bir analiz platformunda da, okuduğunuz bu blogda da. Bu seride PostgreSQL'i üretimde kullanırken karşılaştığım problemleri ve onları nasıl çözdüğümü anlatacağım.

#Bu seriyi neden yazıyorum

PostgreSQL'in belgeleri çok iyi. Bir özelliğin ne yaptığını orada bulursunuz. Ama üretimdeki problemler genellikle "bu özellik ne yapıyor?" sorusuyla değil, "sistem çalışırken bunu nasıl değiştiririm?" sorusuyla gelir.

Benim için en öğretici anlar hep böyle oldu. Canlıda çalışan bir şemaya sonradan kurum bazlı veri izolasyonu eklemek. Sistem kullanımdayken ORM'i ve şema yaklaşımını değiştirmek. Performans için elle yazdığım tabloların bir ORM göçünde sessizce silinmesini engellemek. Bunların hiçbiri belgelerin ilk sayfasında yazmıyor.

Bu seride tam olarak bu tür konuları, gerçek sistemlerden örneklerle yazacağım.

#Örnekler nereden gelecek

Yazılardaki örneklerin çoğu üç sistemden gelecek:

• Biocidal: Belediyelerin ve ilaçlama firmalarının haşereyle mücadele operasyonlarını yöneten, 2020'den beri canlıda olan çok kiracılı bir saha yönetim sistemi. Her kurumun verisi ayrı tutuluyor. PostGIS ile bir noktanın hangi sorumluluk bölgesine düştüğü bulunuyor, ilaç stoku lot ve son kullanma tarihine göre takip ediliyor.
• KillReport: EVE Online için gerçek zamanlı bir killmail takip ve analiz platformu. Yaklaşık 45 arka plan işçisi aynı veritabanına yazıyor. Liderlik tablolarındaki günlük sayaçlar, kaydın kendisiyle aynı transaction içinde artırılıyor; bu yüzden ayrı bir zamanlanmış işe gerek kalmıyor.
• Bu site: Blog yazıları ve bülten PostgreSQL'de. Bülten mailleri ayrı bir işçinin okuduğu bir iş tablosundan gönderiliyor. İşçiler işleri FOR UPDATE SKIP LOCKED ile alıyor, yani iki işçi aynı maili göndermiyor. Başarısız bir gönderim de bir süre bekledikten sonra en fazla beş kez yeniden deneniyor.

Örnekleri sadeleştireceğim, ama kurguyla değiştirmeyeceğim. Bir yaklaşımın bende neden işe yaradığını ya da neden yaramadığını, gerçek sistemin koşullarıyla birlikte anlatacağım.

#Seri nasıl ilerleyecek

Seri 12 bölümden oluşuyor ve beş gruba ayrılıyor:

Temel

1. Doğru veri modeli: normalizasyon nerede durmalı

Sorgu performansı

1. İndeksler: B-tree, GIN, GiST ve partial indeks ne zaman
2. EXPLAIN ANALYZE okumayı öğrenmek
3. Yavaş sorguları bulmak: pg_stat_statements
4. N+1 problemi ve GraphQL tarafında DataLoader

Eşzamanlılık ve büyüme

1. Kilitler, transaction'lar ve deadlock'lar
2. Büyük tablolar: partitioning ve arşivleme
3. VACUUM, autovacuum ve şişen tablolar (bloat)

Özel konular

1. PostGIS ile mekânsal sorgular
2. Çok kiracılı mimari: şema mı, satır mı, ayrı veritabanı mı

Operasyon

1. Yedekleme, PITR ve replikasyon
2. Bağlantı havuzu: PgBouncer ve ORM'lerle ilişkisi

Her bölüm tek başına okunabilecek şekilde yazılacak. Yine de sırayla ilerlemek işinizi kolaylaştırır: indeksleri anlamadan EXPLAIN ANALYZE çıktısını, kilitleri anlamadan da VACUUM'un neden takıldığını yorumlamak zor.

#Kimin için

Bu seri, PostgreSQL'i bir uygulamanın arkasında kullanan geliştiriciler için. Temel SQL bilmeniz yeterli. Prisma ya da TypeORM gibi bir ORM kullanıyor ve altında neler olduğunu merak ediyorsanız, özellikle sizin için.

Bir veritabanı yöneticisi (DBA) el kitabı yazmıyorum. Odak noktam, uygulama geliştiren birinin üretimde gerçekten karşılaşacağı konular. Örneklerde SQL'in yanında, gerektiğinde TypeScript ve Prisma kodu da olacak.

#"Doğru kullanmak" ne demek

Serinin adındaki "doğru" kelimesiyle kusursuz bir reçeteyi kastetmiyorum. Çoğu kararın bir bedeli var. Bir indeks okumayı hızlandırırken yazmayı yavaşlatır. Çok kiracılı mimaride hangi yolu seçerseniz seçin, bir şeyden vazgeçersiniz. Bu seride doğru cevabı ezberletmek yerine, o kararı verirken neye baktığımı anlatmaya çalışacağım.

#Sırada ne var

İlk bölümde her şeyin temelinden başlıyorum: veri modeli. Normalizasyonun nerede işe yaradığını, nerede durmak gerektiğini ve bir şemayı sonradan değiştirmenin neden bu kadar pahalı olduğunu anlatacağım.