Bahadır Bilir

27 Eki 2026

Veritabanı optimizasyonu: 876ms → 17ms

Bir aramanın bir saniyeye yakın sürdüğü bir fabrika ölçüm veritabanı. Üç tür değişiklik, her biri tek tek ölçüldü; aynı arama artık 17 ms sürüyor.

Sorun

Bir fabrika ölçüm hattındaki proses kontrol uygulaması raporlarını PostgreSQL’de tutuyor: dört tabloya yazılan 9 milyon ölçüm noktası, rapor başına yaklaşık 84 nokta. Operatörün veri sayfası son 522 bin noktada arıyor. Bir arama altı SQL sorgusu gönderiyor ve filtresiz 681 ms, 30 filtrenin hepsi doluyken 876 ms sürüyordu; bu hızlı bir makinede, orijinal makinede saniyeler. Ölçülen değerler dahil her kolon text’ti, hiçbir tabloda key ya da index yoktu.

Veri sayfasının aradığı tablo, önce ve sonra
Göster
Önceson ölçümler522 bin satır, key yok, index yokrapor numarasıtextölçüm zamanıtextparça kimliğitextölçülen değertextfiltre alanları × 30textSonrason ölçümler tablosundaki rapor numarası, rapor tablosuna bağlanır. son ölçümler tablosundaki açılır liste alanları × 2, açılır liste değeri tablosuna bağlanır.raporyeni tablo4.641 satır, 1,4 MBrapor numarasıtextanahtarölçüm zamanıtextindeksparça kimliğitextson ölçümler522 bin satır, 5 indexrapor numarasıtextölçüm zamanıtextindeksparça kimliğitextindeksölçülen değertextölçülen değer, sayı olaraknumericyeniaçılır liste alanları × 2textindeksen seçici filtreler × 3textindeksaçılır liste değeriyeni tablodeğertextanahtar

Adlar genel, uygulamanın kendi adları değil. Bir çizgi bir kolonu gösterdiği tabloya bağlıyor. Kalan 27 filtre alanı olduğu gibi duruyor.

Ne değiştirdim

  • Soruya uyan index’ler: sayfanın sıralaması, farklı parça sayımı, iki açılır liste ve en seçici üç filtre. Bütün filtreler doluyken sayfa 26.301 blok okumaktan 975 bloğa indi.
  • Sayı olarak saklanan sayılar: her ölçülen değerin numeric bir kopyası; filtre her satırda text’i regular expression ile sınayıp dönüştürmek yerine sayı karşılaştırıyor.
  • Rapor başına tek satırlık tablo: altı sorgudan dördü noktaları değil raporları soruyor; 4.641 satır her birine yaklaşık 1 ms’de cevap veriyor.

Sonuç

Bir tıklama, altı sorgu: istemcide sıcak medyan
Göster
  • Filtresiz
  • Bütün filtreler dolu
  1. Orijinal şema ve sorgular681 ms876 ms
  2. 1. Sayfanın sıralamasına göre index432 ms766 ms
  3. 2. Farklı parça sayımı için index169 ms548 ms
  4. 3. İki açılır liste için index'ler171 ms438 ms
  5. 4. En seçici üç filtre üzerinde index145 ms94 ms
  6. 5. Ölçülen değerler sayı olarak da saklanıyor143 ms82 ms
  7. 6. Rapor başına tek satırlık tablo6,9 ms16,7 ms
FiltresizBütün filtreler dolu
Orijinal şema ve sorgular681 ms876 ms
1. Sayfanın sıralamasına göre index432 ms766 ms
2. Farklı parça sayımı için index169 ms548 ms
3. İki açılır liste için index'ler171 ms438 ms
4. En seçici üç filtre üzerinde index145 ms94 ms
5. Ölçülen değerler sayı olarak da saklanıyor143 ms82 ms
6. Rapor başına tek satırlık tablo6,9 ms16,7 ms

Her adım öncekileri de içeriyor. Geri yüklenen bir kopyada (PostgreSQL 15.8) ölçüldü: her seferinde tek değişiklik, istemcide üç sıcak çalışmanın medyanı.

Bütün filtreler doluyken 876 yerine 17 ms, filtresiz 681 yerine 6,9 ms: 50 ile 100 kat arası hızlanma. Her değişiklik birkaç saniyelik bir migration’dı; index’ler ve numeric kolonlar 206 MB’lık tablonun yanında 124 MB tutuyor ve uygulamanın orijinal sorguları her adımdan sonra çalışmaya devam etti.