01Sorun ve çözüm
Sorgu optimizasyonu çalışmasında önce en çok zaman tüketen sorguları veritabanının kendi istatistiklerinden buluruz. Her birinin yürütme planını okuyarak tam tarama, yanlış birleştirme yöntemi, hatalı satır tahmini ya da kilit beklemesi gibi asıl nedeni ortaya çıkarırız. Düzeltmeyi uyguladıktan sonra aynı sorguyu aynı veriyle yeniden ölçer, öncesini ve sonrasını yan yana raporlarız.
02Kimler için
Sorgu optimizasyonu kimler için gerekli
Yavaşlığın kaynağı bir ya da birkaç ekranda yoğunlaşıyorsa sorgu düzeyinde çalışmak en doğrudan yoldur.
- Belirli rapor ya da liste ekranları yavaş açılan ERP, CRM ve sipariş yönetimi kullanıcıları
- Veri büyüdükçe API yanıt süreleri uzayan SaaS ve mobil uygulama ekipleri
- ORM ile yazılmış bir uygulamada veritabanına giden sorgu sayısını kontrol edemeyen yazılım ekipleri
- Gün içinde zaman aşımı ve kilitlenme hatası alan, nedenini bulamayan BT birimleri
- Donanım yükseltmesine karar vermeden önce mevcut kaynağın verimli kullanılıp kullanılmadığını görmek isteyen yöneticiler
03İhtiyaçlar
Yavaş sorguların tipik nedenleri
Aşağıdaki nedenler farklı veritabanlarında farklı adlarla görünür ama mantığı aynıdır.
- 01
İndeksi kullanamayan koşullar
Sütunun bir fonksiyonla sarılması, metin ve sayı arasında örtük tür dönüşümü ya da başı joker karakterle başlayan arama, indeks olsa bile tam taramaya yol açar. Koşulu yeniden yazmak çoğu zaman yeni indeksten daha etkilidir.
- 02
N+1 sorgu deseni
Yüz satırlık bir liste için önce listeyi, sonra her satırın detayını ayrı ayrı çeken kod, tek bir sayfa açılışında yüzlerce sorgu üretir. Toplu yükleme ya da birleştirme ile bu sayı bir iki sorguya indirilir.
- 03
Eskimiş istatistikler ve hatalı plan
Veritabanı planını tablo istatistiklerine göre seçer. İstatistikler güncel değilse ya da SQL Server'daki parametre algılama gibi bir durum varsa, bir müşteri için hızlı çalışan sorgu başka bir müşteri için çok yavaşlar.
- 04
Derin sayfalama ve gereksiz sütunlar
Büyük OFFSET değerleriyle yapılan sayfalama, atlanan bütün satırları yine okur. Her yerde kullanılan SELECT * ise indeks içinden yanıt verilebilecek sorguları tabloya gitmeye zorlar.
- 05
Uzun işlemler ve kilit beklemeleri
Açık kalan bir işlem ya da toplu bir güncelleme, aynı satırlara erişmek isteyen diğer sorguları bekletir. Bekleme olayları incelenmeden bu yavaşlık yanlışlıkla sorgunun kendisine bağlanır.
04Özellikler
Sorgu optimizasyonu hizmetinde izlediğimiz adımlar
Çalışma ölçümle başlar, ölçümle biter; arada yapılan her değişiklik geri alınabilir şekilde kayıt altına alınır.
- 01
Yük profili çıkarma
Sorgu istatistik görünümlerinden toplam süre, çağrı sayısı ve okunan blok miktarına göre ilk sıradaki sorgular listelenir; tek seferlik yavaş sorgu ile sık çalışan orta hızdaki sorgu ayrı değerlendirilir.
- 02
Yürütme planı analizi
EXPLAIN ANALYZE, SQL Server gerçek yürütme planı ya da MySQL EXPLAIN çıktısında tahmini ve gerçek satır sayıları karşılaştırılır; planın nerede saptığı bulunur.
- 03
İndeks stratejisi
Eksik indeksler eklenirken yazma maliyeti de hesaba katılır; kullanılmayan ya da başka bir indeksin kopyası olan indeksler kaldırılmak üzere listelenir.
- 04
Sorgu ve kod düzeltmeleri
Sorgu yeniden yazılır ya da uygulama ekibine ORM tarafında yapılacak değişiklik somut örnekle iletilir; rapor sorguları için özet tablo veya materialized view önerilebilir.
- 05
Kalıcı izleme
Düzeltilen sorguların yeniden yavaşlaması fark edilsin diye sorgu süresi ve plan değişikliği için uyarılar tanımlanır.
05Entegrasyonlar
Çalıştığımız veritabanları ve araçlar
Yöntem aynı kalsa da her veritabanının kendi tanı araçları vardır.
- 01
SQL Server
Query Store, dinamik yönetim görünümleri ve Extended Events ile en pahalı sorgular, plan gerilemeleri ve bekleme türleri incelenir.
- 02
PostgreSQL
pg_stat_statements, auto_explain ve kilit görünümleri kullanılır; planlayıcının satır tahminlerini düzeltmek için genişletilmiş istatistikler değerlendirilir.
- 03
MySQL ve MariaDB
Yavaş sorgu günlüğü, Performance Schema ve sorgu özetleri üzerinden çalışılır; InnoDB tampon havuzu davranışı da göz önüne alınır.
- 04
Oracle
Lisansınız kapsamında erişilebilen AWR raporları ve yürütme planı geçmişi incelenir.
- 05
Uygulama tarafı izleme
Kullandığınız APM aracı ya da OpenTelemetry izleri, yavaş ekranı veritabanındaki sorguya bağlamak için kullanılır.
06Süreç
Sorgu optimizasyonu hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Canlı sistemi riske atmadan iyileştirme
Bir indeks eklemek ya da sorgu değiştirmek basit görünür, ama canlı tabloda kilit alan bir işlem bütün sistemi durdurabilir. Bu yüzden her değişiklik önce canlıya yakın hacimdeki bir kopya üzerinde denenir; büyük tablolarda çevrimiçi indeks oluşturma seçenekleri kullanılır ve uygulama zamanı yoğun saatlerin dışına planlanır.
Devamını okuDaha az göster
Bir sorguyu hızlandıran değişiklik başka bir sorguyu yavaşlatabilir. Yeni indeksin ekleme ve güncelleme maliyeti, plan değişikliğinden etkilenen diğer sorgular ve disk kullanımı birlikte ölçülür. Sonuç raporunda yalnızca hızlanan sorgular değil, bu yan etkiler de yer alır.
İnceleme için veritabanındaki kişisel verilere bakmak gerekmez; sorgu metinleri parametreleri gizlenmiş hâlde, istatistikler de özet olarak incelenir. Test için canlı verinin kopyası gerekiyorsa kişisel alanlar maskelenerek hazırlanır.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Bakım ve destek
Aylık sözleşmeli, SLA'lı bakım, destek ve geliştirme saati
Yayındaki bir sistemin sürekliliği için.
- Aylık sözleşme ve SLA
- İzleme, güncelleme ve hata düzeltme
- Aylık geliştirme saati
- 03
Danışmanlık
Saatlik veya günlük teknik danışmanlık
Karar, denetim veya yön belirleme gereken durumlar için.
- Saatlik veya günlük çalışma
- Yazılı rapor ve öneriler
- Ekibinizle birlikte çalışma
09Sık sorulan sorular
Sorgu optimizasyonu hakkında sık sorulan sorular
Sorgu optimizasyonu fiyatları neye göre belirlenir?
İncelenecek veritabanı sayısı, sorunlu ekran ya da rapor sayısı, değişikliklerin yalnızca veritabanında mı yoksa uygulama kodunda da mı yapılacağı ve test ortamının hazır olup olmadığı belirleyicidir. Kısa bir ön analizden sonra kapsamı sorgu ve ekran listesiyle birlikte teklif ederiz.
Kaynak kodumuza erişmeden sorgu optimizasyonu yapılabilir mi?
Veritabanı tarafındaki indeks, istatistik ve yapılandırma iyileştirmeleri kod erişimi olmadan yapılabilir. Sorun uygulamanın sorgu üretme biçimindeyse, değişikliği somut örnek ve önerilen sorguyla birlikte yazılım ekibinize ya da ürün tedarikçinize iletiriz.
Hazır bir ERP programı kullanıyoruz, yine de iyileştirme yapılabilir mi?
Çoğu zaman evet. Programın sorgularını değiştirmeden eksik indeks eklemek, istatistik ve bakım planını düzenlemek mümkündür. Bu değişikliklerin ürün güncellemeleriyle çakışmaması için tedarikçinin desteklediği sınırlar içinde kalırız.
Sunucuyu büyütmek yerine sorgu optimizasyonu daha mı mantıklı?
Darboğaz tek tük sorgulardaysa evet; donanım eklemek sorunu yalnızca erteler. Yük gerçekten büyüdüyse ve sorgular zaten verimliyse kaynak artırmak doğru karardır. İnceleme sonucunda hangisinin geçerli olduğunu verilerle gösteririz.
Sonucu nasıl ölçüyorsunuz?
Her sorgu için değişiklik öncesi ve sonrası süre, okunan satır ya da blok sayısı ve işlemci kullanımı aynı koşullarda ölçülür. Ekran bazında da açılış süresi karşılaştırılarak kullanıcının hissettiği fark raporlanır.
Bir sorgu optimizasyonu firması ile tek seferlik mi çalışmak gerekir?
Tek seferlik bir çalışma birikmiş sorunları çözer. Veri ve uygulama sürekli değiştiği için yeni yavaş sorguların düzenli gözden geçirilmesini isterseniz bakım ve destek anlaşmasıyla bunu periyodik olarak sürdürebiliriz.
10İlgili hizmetler