Python ve SQL

Azure SQL Database Serverless ile Maliyet Azaltma

2026-05-10T00:00:00Z

Selamlar, bu yazıda Azure SQL Database'in serverless katmanına (compute tier) bir göz atalım. Konu basit gibi duruyor ama uygulamada bir sürü ince ayar var; özellikle 'hangi DB serverless'a taşınmalı, hangisi taşınmamalı' sorusu çoğu ekibin gözünden kaçıyor. Lafı çok uzatmadan başlayayım.

Bir gece nöbetinde dashboard'a baktığımda dev ve staging veritabanlarının neredeyse hiçbir iş yapmadığını ama provisioned olarak full kapasite faturalandığını görünce, 'burada ciddi bir israf var' demiştim. İşte tam bu nokta, serverless'in geldiği yer.

Serverless Tier Nedir?

Azure SQL Database'in vCore satın alma modelindeki General Purpose service tier'i altında iki compute seçeneği var: provisioned ve serverless. Provisioned'da sabit bir vCore sayısı belirliyorsunuz ve database 7/24 açık olsa da olmasa da o kapasite için para ödüyorsunuz. Serverless ise iki şey yapıyor:

Otomatik ölçekleme: Min ve max vCore aralığı tanımlıyorsunuz, gerçek CPU talebine göre database bu aralıkta aşağı yukarı gidiyor. Faturalandırma vCore-saniye üzerinden.
Otomatik durdurma (auto-pause): Database belirli bir süre (en az 60 dakika) boş kalırsa Azure DB'yi 'pause' ediyor. Pause halindeyken sadece storage için para ödüyorsunuz, compute sıfır.

Yeni bir bağlantı gelir gelmez database otomatik olarak ayağa kalkıyor. Ama uyanma süresi var; buna birazdan döneceğim.

Ne Zaman Kazandırır, Ne Zaman Kaybettirir?

Bence bu en kritik kısım. Çünkü herkes 'serverless = ucuz' diye düşünüp taşıyor, sonra production OLTP database'inde ay sonu faturası iki katına çıkıyor.

Serverless'in parladığı durumlar:

Dev ve test veritabanları (mesai dışı tamamen ölü)
Sadece iş saatlerinde çalışan iç araçlar
POC'lar ve demo ortamları
Günde 1-2 saat aktif olan batch işleyen DB'ler
Trafiği çok düşük, gecelik uzun boş dönemleri olan küçük production DB'leri

Serverless'in kaybettirdiği durumlar:

Steady-state OLTP yükleri (CPU sürekli yüzde 30-40 bandında gezen sistemler)
Gerçek zamanlı, düşük gecikme bekleyen API arka uçları
7/24 sürekli yazılan loglama veya telemetri DB'leri
Çok sık küçük sorgu alan ama hiçbir zaman tam olarak boş kalmayan sistemler

Pratik bir eşik vereyim: database'iniz günün yüzde 60-70'inden fazla aktifse, provisioned neredeyse her zaman daha ucuz. Aktiflik bunun altındaysa serverless'a geçmek mantıklı.

CLI ile Kurulum

Portal'dan da yapabilirsiniz ama benim tercihim CLI; hem tekrar edilebilir hem de Terraform/Bicep geçişi için temel oluşturuyor. Yeni bir serverless DB açmak için:

az sql db create \
    --resource-group rg-staging \
    --server sql-staging-01 \
    --name app-db \
    --edition GeneralPurpose \
    --compute-model Serverless \
    --family Gen5 \
    --min-capacity 0.5 \
    --capacity 2 \
    --auto-pause-delay 60 \
    --max-size 32GB

Buradaki --min-capacity 0.5 aktif haldeki taban maliyeti minimuma indiriyor. --capacity 2 ise tavan, yani yük patlasa bile 2 vCore'u geçmez. --auto-pause-delay 60 60 dakika hareketsizlikten sonra DB'yi uyutuyor.

Mevcut bir DB'yi serverless'a çevirmek için de update komutu var:

az sql db update \
    --resource-group rg-staging \
    --server sql-staging-01 \
    --name app-db \
    --edition GeneralPurpose \
    --compute-model Serverless \
    --min-capacity 0.5 \
    --capacity 4 \
    --auto-pause-delay 120

Auto-pause istemiyorsanız --auto-pause-delay -1 verin; sadece otomatik ölçekleme avantajını kullanırsınız.

Uyanma Gecikmesi - En Sık Karşılaşılan Tuzak

Burada çoğu ekip yanılıyor. Pause halindeki bir DB'ye bağlantı geldiğinde toparlanması 1-2 dakika sürüyor. Eğer uygulamanızın connection timeout değeri 15 saniyeyse, sabah ilk istek boş yere <TimeoutError> alıyor.

Connection string'inize en az 60 saniye timeout verin:

Server=sql-staging-01.database.windows.net;Database=app-db;Connection Timeout=60;Encrypt=true;

Bir de monitoring sistemleri konusu var. Eğer DB'ye 5 dakikada bir health check ping atan bir sisteminiz varsa, auto-pause hiçbir zaman tetiklenmez ve serverless'in tüm mantığı çöpe gider. Bunu fark etmesi bile bir hafta sürebiliyor; faturayı görünce anlıyorsunuz.

Sık Karşılaşılan Hatalar

Tüm production'ı serverless'a taşımak: Provisioned ucuz olduğu yük profilleri var. Önce metrik toplayın, sonra karar verin.
Min vCore'u gereksiz yüksek tutmak: 0.5 yerine 1 koymak, taban maliyetinizi iki katına çıkarır. Zorunlu değilse 0.5 bırakın.
Auto-pause'u 60 dakikaya çekip sonra her 30 dakikada bir ping atmak: DB hiçbir zaman uyumaz, sadece serverless'in ölçekleme kısmından faydalanırsınız - bu da çoğu zaman provisioned'dan daha pahalıya çıkar.
Storage'i unutmak: DB pause olsa bile storage faturası devam eder. 500 GB tutmanıza gerek yoksa küçültün.

Kapanış

Serverless tier, doğru yerde kullanıldığında gerçekten ciddi bir tasarruf aracı. Şahsi kanaatim, dev/test ortamlarının neredeyse hepsi serverless'a taşınmalı; production tarafında ise önce metrikleri okuyup karar vermek lazım. 1-2 dakikalık uyanma gecikmesini tolere edemiyorsanız veya DB'niz zaten sürekli meşgulse, provisioned'da kalmak daha mantıklı. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

MySQL'de Tablo Kilit Çakışmalarını İzlemek

2026-05-10T00:00:00Z

Selamlar, bu yazıda MySQL'de tablo kilit çakışmalarını (table lock contention) nasıl tespit ederiz, ona bakacağız. Konu kuru gibi gözüküyor olabilir ama eminim aklınıza şu sahne gelmiştir: sabah saat 9'u biraz geçer, dashboard'larda kırmızı alarm patlar, kullanıcılardan 'sayfa açılmıyor' mesajları yağar, oysa CPU rahat, disk rahat, ağ rahat. İşte bu klasik bir kilit çakışması semptomudur. Hadi başlayalım.

Önce semptomu doğru okuyalım

Bir sorgunun yavaşladığı her duruma 'kilit var galiba' demek doğru değil. Yavaşlık çoğu zaman index eksiğinden, plan değişikliğinden, ya da bir batch job'ın ortalığı süpürmesinden kaynaklanır. Kilit çakışmasının imzası farklı: aynı sorgu bazen 5ms'de dönüyor, bazen 8 saniye bekliyor, bazen de timeout yiyor. Yani süre dağılımı bimodal. Bunu Grafana'da histogram olarak çizdiğinizde iki tepeli bir şey görürseniz büyük ihtimalle kilit söz konusudur.

Bir başka işaret de şu: yavaşlama belirli saatlere bağlı. Sabah 9'da rapor cron'u koşuyor ve LOCK TABLES ile uzunca bir süre tabloyu tutuyorsa, o saatte gelen yazma istekleri kuyruğa girer. Diğer saatlerde her şey yağ gibi.

Global sayaçlara hızlı bakış

İlk durağımız performance_schema.global_status. Burada iki sayaç var, ikisini de oranlamamız lazım:

SELECT VARIABLE_NAME, VARIABLE_VALUE
FROM performance_schema.global_status
WHERE VARIABLE_NAME IN ('Table_locks_waited', 'Table_locks_immediate');

Table_locks_immediate beklemeden alınan kilitler, Table_locks_waited ise sıraya girmek zorunda kalanlar. Tek başlarına bir anlam ifade etmezler, oranlamak gerek:

SELECT ROUND(waited / (waited + immediate) * 100, 2) AS lock_wait_ratio_pct
FROM (
  SELECT
    (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME='Table_locks_waited')    AS waited,
    (SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME='Table_locks_immediate') AS immediate
) t;

Şahsi kanaatim, %1'in altı normal, %1-5 arası 'gözünü aç', %5 üstü 'müdahale et'. Ama bu sayaç MySQL açıldığından beri kümülatif olduğu için tek bir okumayla yanıltıcı olabilir; iki dakika arayla iki ölçüm alıp delta'sına bakmak daha sağlıklı.

Suçlu tabloyu bulmak

Oran yüksekse, suçlu tabloyu bulmamız lazım. performance_schema.table_lock_waits_summary_by_table bunu söyler:

SELECT
  object_schema,
  object_name,
  COUNT_READ + COUNT_WRITE AS total_accesses,
  SUM_TIMER_WAIT / 1e12   AS total_wait_sec
FROM performance_schema.table_lock_waits_summary_by_table
WHERE SUM_TIMER_WAIT > 0
ORDER BY total_wait_sec DESC
LIMIT 10;

Tipik olarak listenin tepesinde bir-iki tablo durur. O tabloya SHOW CREATE TABLE çekip engine'ine bakın - hâlâ MyISAM ise hikaye orada bitiyor zaten.

Anlık çatışmayı yakalamak

Şu an ne oluyor sorusunun cevabı için sys şemasındaki view daha pratik:

SELECT
  waiting_pid     AS waiting_thread,
  waiting_query,
  blocking_pid    AS blocking_thread,
  blocking_query
FROM sys.schema_table_lock_waits;

InnoDB tarafında satır kilidi şüpheniz varsa SHOW ENGINE INNODB STATUS\G çıktısının LATEST DETECTED DEADLOCK ve TRANSACTIONS bölümlerine bakın; ya da performance_schema.data_locks ile data_lock_waits join'i daha modern yöntem:

SELECT r.trx_id AS waiting_trx, b.trx_id AS blocking_trx, w.OBJECT_NAME
FROM performance_schema.data_lock_waits w
JOIN information_schema.innodb_trx r ON w.REQUESTING_ENGINE_TRANSACTION_ID = r.trx_id
JOIN information_schema.innodb_trx b ON w.BLOCKING_ENGINE_TRANSACTION_ID  = b.trx_id;

Sık karşılaşılan tuzaklar

MyISAM tablosunu InnoDB sanmak: Eski bir tablo yıllar önce import edilmiş olabilir, kimse engine'e bakmamıştır. ALTER TABLE <TblName> ENGINE=InnoDB çoğu zaman tek başına problemi çözer.
LOCK TABLES'ı uygulama kodunda bırakmak: Eski PHP scriptlerinde sıkça görülür. Transaction + SELECT ... FOR UPDATE neredeyse her zaman daha iyi.
DDL'i mesai saatinde almak: ALTER TABLE varsayılan olarak metadata lock alır. MySQL 8'de ALGORITHM=INPLACE, LOCK=NONE kombinasyonu mümkünse onu seçin.
Sayacı tek seferlik okumak: Kümülatif değer servis açıldığından beri birikir; yorumlamak için delta lazım. mysqladmin extended-status ile watch -n 5 kombinasyonu ya da basit bir bash döngüsü iş görür.

Kapanış

Tablo kilit çakışması çoğunlukla mimari değil, miras bir kararın ürünü - eski engine, eski LOCK TABLES çağrısı, kötü zamanlanmış DDL. Bence vakit harcanması gereken yer bu üç kalem. Önce ölçün, sonra suçluyu bulun, sonra çözün; sırasını şaşırmayın. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

OAuth2 Server Error'larını Çözmek

2026-05-10T00:00:00Z

Selamlar, bu yazımda OAuth2 ile çalışırken hepimizin er ya da geç yüzleştiği o sinir bozucu server_error yanıtlarına bakacağız. Bilirsiniz, request gönderiyorsunuz, kod tarafında her şey kitabına uygun, ama yetkilendirme sunucusu size 500 ya da 503 fırlatıyor. Sebebini de açıklamıyor üstelik. Hadi konuya girelim.

OAuth2'de 4xx hataları size 'request'in yanlış' der; düzeltmek genelde sizin elinizdedir. 5xx ise 'sorun bende' demektir ve genellikle geçici olur. İşin sıkıntılı yanı, sunucu logunu görme şansınız olmadığında bu geçici miydi yoksa kalıcı bir arıza mı, ayırt etmek zor.

Server Error neye benziyor?

Tipik bir 5xx yanıtı şu şekilde gelir:

{
  "error": "server_error",
  "error_description": "The authorization server encountered an unexpected condition that prevented it from fulfilling the request."
}

Burada görmemiz gereken iki şey var: HTTP statüsü (500, 502, 503, 504) ve OAuth2'nin kendi error alanı. İkisi farklı şeyler söyleyebilir. Mesela 200 dönüp body'de error: server_error koyan bizim de baş belamız servisler oldu zamanında. O yüzden response.ok kontrolü tek başına yetmez; body'yi de okumak gerekir.

Hangi statü ne anlama geliyor, kabaca:

500: Sunucu kendi içinde patladı. Genelde yetkilendirme servisinin loguna bakmak lazım.
502: Önündeki proxy ya da load balancer arka uca ulaşamıyor. Servis ayakta olabilir, route bozuk.
503: Servis aşırı yük altında ya da bakımda. Bekleyip tekrar denemek mantıklı.
504: Timeout. Genelde veri tabanı sorgusu uzadığında ya da downstream bir bağımlılık takıldığında görülür.

Yeniden deneme stratejisi: üstel backoff

Geçici hata için en doğru tepki sabırla yeniden denemektir, ama körlemesine değil. Üstel backoff (exponential backoff) tam burada işe yarar. Her başarısız denemede bekleme süresini katlıyoruz; üstüne biraz da rastgelelik (jitter) ekliyoruz ki tüm istemciler aynı anda saldırmasın.

class OAuth2RetryClient {
    constructor(config) {
        this.config = config;
        this.maxRetries = config.maxRetries ?? 3;
        this.baseDelay = config.baseDelay ?? 1000;
        this.maxDelay = config.maxDelay ?? 30000;
    }

    async tokenRequest(params) {
        const response = await fetch(this.config.tokenEndpoint, {
            method: 'POST',
            headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
            body: new URLSearchParams(params).toString(),
        });

        if (!response.ok) {
            const body = await response.json().catch(() => ({}));
            const err = new Error(body.error_description ?? 'Token isteği başarısız');
            err.status = response.status;
            err.code = body.error;
            throw err;
        }
        return response.json();
    }

    async withRetry(operation) {
        for (let attempt = 0; attempt < this.maxRetries; attempt++) {
            try {
                return await operation();
            } catch (error) {
                if (!this.isRetryable(error) || attempt === this.maxRetries - 1) {
                    throw error;
                }
                const delay = this.calculateDelay(attempt);
                await new Promise(r => setTimeout(r, delay));
            }
        }
    }

    isRetryable(error) {
        if (error.status >= 500 && error.status < 600) return true;
        if (error.code === 'temporarily_unavailable') return true;
        return false;
    }

    calculateDelay(attempt) {
        const exp = this.baseDelay * Math.pow(2, attempt);
        const jitter = exp * 0.25 * Math.random();
        return Math.min(exp + jitter, this.maxDelay);
    }
}

Bence buradaki kritik nokta isRetryable metodunun ne kadar dar tutulduğu. 4xx'i tekrar denerseniz aynı hatayı tekrar alırsınız ve kullanıcı bekler durur. Sadece 5xx ve temporarily_unavailable için tekrar deneyin.

Circuit breaker: dur dediğinde dur

Yetkilendirme sunucusu gerçekten çökmüşse her istekte üç kez tekrar denemek sistemi daha da yorar. Burada devre kesici (circuit breaker) deseni devreye girer. Kısaca: belli sayıda art arda hata olduğunda devreyi 'OPEN'a alıp bir süre hiç istek geçirmeyiz, sonra 'HALF_OPEN'da bir deneme yapıp servis düzeldiyse 'CLOSED'a döneriz.

class CircuitBreaker {
    constructor({ threshold = 5, resetMs = 30000 } = {}) {
        this.threshold = threshold;
        this.resetMs = resetMs;
        this.state = 'CLOSED';
        this.failures = 0;
        this.openedAt = null;
    }

    async execute(operation) {
        if (this.state === 'OPEN') {
            if (Date.now() - this.openedAt >= this.resetMs) {
                this.state = 'HALF_OPEN';
            } else {
                throw new Error('Devre kesici acik, istek gonderilmedi');
            }
        }
        try {
            const result = await operation();
            this.failures = 0;
            this.state = 'CLOSED';
            return result;
        } catch (e) {
            this.failures++;
            if (this.failures >= this.threshold) {
                this.state = 'OPEN';
                this.openedAt = Date.now();
            }
            throw e;
        }
    }
}

Sık karşılaşılan hatalar

Tüm hatalarda tekrar denemek: 400 invalid_grant hatasını 3 kez denemek refresh token'ı boşa harcar ve kullanıcıyı tekrar login'e atar. Önce statüye bakın.
Jitter koymamak: 1000 istemci aynı anda 503 yiyip aynı anda yeniden denerse sunucuyu tekrar dize getirirsiniz. Rastgelelik şart.
Kullanıcıya teknik mesaj göstermek: 'server_error' yazısı kullanıcıya bir şey ifade etmez. 'Giriş servisi şu an yoğun, az sonra tekrar deneyin' gibi sade bir mesaj çok daha iyi.
Retry-After başlığını okumamak: Sunucu size ne kadar bekleyeceğinizi söylüyor olabilir. Kendi backoff'unuzdan önce o değere bakın.

Kapanış

5xx hataları çoğunlukla kendiliğinden geçer; bizim işimiz panik yapmadan, akıllı bir geri çekilmeyle sistemi ayakta tutmak. Bana sorarsanız üstel backoff ve devre kesici ikilisi olmadan hiçbir OAuth2 istemcisi production'a çıkmamalı; bu ikisi olmadan ilk küçük dalgalanmada kullanıcı oturum açamıyor diye ortalık karışır. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Terraform Backend'ini Veri Kaybetmeden Geçirmek

2026-05-10T00:00:00Z

Selamlar, bu yazımda Terraform'un en gergin operasyonlarından birine bakacağız: backend geçişi. State dosyası tek bir JSON gibi görünür ama Terraform için kâinatın merkezidir; o dosyayı kaybederseniz Terraform yönettiği her şeyi 'tanımıyorum' moduna alır. Resource'lar duruyor, ama sizin onları yönetebilme yetiniz buharlaşıyor. Lafı uzatmadan başlayalım.

Backend geçişi neden olur? Önce local ile başlamışsınızdır, ekip büyür, S3'e geçmek istersiniz. Sonra Terraform Cloud'un workspace yönetimini denemek istersiniz. Bazen de iki şirket birleşir, state'leri tek bucket'ta toplamak gerekir. Hepsi normal ihtiyaçlar; ama her biri yanlış adımda saatlerce uğraşacağınız bir kurtarma operasyonuna dönüşebilir.

Geçişten önce yapılması gerekenler

Tek bir kuralı asla atlamayın: yedek. Terraform'un kendi state push/pull mekanizması güvenli, ama dosyayı bir kez elden çıkarınca geri alamayabilirsiniz.

# 1. Ekipteki herkesi haberdar edin, CI/CD pipeline'larini durdurun
# 2. Mevcut state'i tarihli bir dosyaya cekin
terraform state pull > state-backup-$(date +%Y%m%d_%H%M%S).json

# 3. Yedegin tam oldugunu dogrulayin
jq '.resources | length' state-backup-*.json
terraform state list | wc -l

# 4. Yedegi repo disinda bir yere koyun
aws s3 cp state-backup-*.json s3://my-backups/terraform/

Bence bu adımı atlamak, geçişin başarısı umurumda değil, prensip olarak kabul edilemez. Yedek olmadan başlanan migration'ın bir adı vardır: kumar.

Local'den S3'e

En sık görülen senaryo bu. Önceden backend "local" bloğunuz var ya da hiç yok; yeni durumda S3'e yazıyorsunuz.

# backend.tf - YENI hali
terraform {
  backend "s3" {
    bucket         = "myorg-terraform-state"
    key            = "prod/app/terraform.tfstate"
    region         = "eu-central-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

Sonra init:

terraform init
# Terraform soracak:
# Do you want to copy existing state to the new backend?
# Cevap: yes

terraform plan
# Cikti: No changes. -> ise yaradi

Plan boş çıktıktan sonra local dosyayı silin, bir saniye bile önce değil:

rm terraform.tfstate terraform.tfstate.backup

S3'ten Terraform Cloud'a

Burası iki backend tipi farklı olduğu için Terraform'un otomatik geçişi her zaman tetiklemediği bir yer. Manuel push'a hazırlıklı olun.

terraform {
  cloud {
    organization = "myorg"
    workspaces { name = "prod-app" }
  }
}

# Once mevcut state'i alalim
terraform state pull > current-state.json

# backend.tf'i guncelleyip init
terraform init

# Eger Terraform migrate teklif etmediyse manuel push:
terraform state push current-state.json

terraform plan

Cross-cloud: S3'ten GCS'e

İki farklı cloud arası geçişte, kontrolü Terraform'a bırakmak yerine elinize alın. init sırasında migrate'e 'no' deyin, ardından kendiniz push edin. Şahsi tercihim hep budur; bir adımı kendi gözümle görmek bana huzur veriyor.

terraform state pull > migration-state.json

# backend.tf'i GCS'e guncelle, sonra:
terraform init -reconfigure
# Migrate teklifine: no

terraform state push migration-state.json
terraform plan

İşler ters giderse

Panik yok, çünkü yedeğiniz var. Üç tipik senaryoya bakalım.

State hiçbir backend'de yok

git checkout backend.tf
terraform init -reconfigure
terraform state push state-backup-20260510_103000.json
terraform plan

State iki backend'de birden var

Aslında bu kısmen iyi haber - hiçbir şey kaybolmadı. Hangisinin güncel olduğunu serial numarasına bakarak anlayın:

terraform state pull | jq '.serial'

Yüksek olan kazanır. Diğerini elle silin.

Lock takılı kaldı

terraform force-unlock LOCK_ID

Ama önce o lock'u kimsenin gerçekten tutmadığından emin olun; başka bir CI job'ı çalışıyorsa state'i bozabilirsiniz.

Sık karşılaşılan tuzaklar

Yedek almadan başlamak: En tehlikeli hata bu. Geçiş başarılı olsa bile yedek olmadan başarıyı doğrulayamazsınız, çünkü 'eskiden ne vardı' sorusunun cevabı kalmamış olur.
Local dosyayı erken silmek: terraform.tfstate'i remote backend doğrulanmadan silmek, geri dönüşü olmayan bir karardır. Önce plan, sonra silme.
Workspace'leri unutmak: Birden fazla workspace varsa her biri ayrı state taşır. Sadece default'u taşıyıp diğerlerini unutursanız üç gün sonra fark edersiniz.
CI/CD credentials güncellemesini ertelemek: Geçiş bittikten sonra pipeline'lar hâlâ eski backend'e yazmaya çalışırsa hem state bozulur hem lock karışır. Backend değiştiği gün CI değişkenleri de değişmeli.
-migrate-state ile -reconfigure karıştırmak: İlki state'i taşır, ikincisi sadece backend ayarlarını yeniden okur. Yanlış flag yanlış sonuç verir.

Doğrulama

Geçiş bittikten sonra şu beş şeyi sırayla kontrol edin:

terraform state list                  # State okunuyor mu?
terraform plan                        # Sifir degisiklik mi?
terraform state list | wc -l          # Kaynak sayisi yedekle ayni mi?
jq '.resources | length' state-backup-*.json
# Tum ekip terraform init calistirdi mi?

Hepsi yeşilse rahat nefes alın. Eski backend'i bir hafta daha açık bırakın - panik anında geri dönüş kapısı olarak işinize yarar.

Kapanış

Terraform backend geçişi gözünüzde büyüttüğünüz kadar zor değil; disiplinli bir checklist'le yarım saatlik bir iş. Bence en kritik nokta yedek - state'i bir kez yazılı bir dosyaya almışsanız, gerisi en kötü senaryoda bile telafi edilebilir bir teknik problem. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

AWS'te Talos Linux için Hazır AMI'leri Kullanmak

2026-05-10T00:00:00Z

Selamlar, bu yazımda AWS üzerinde Talos Linux ile küme kurmaya niyetlenenler için bir kestirme yoldan bahsedeceğim: Sidero Labs'in resmi olarak yayınladığı hazır AMI'ler. Kendi image'ınızı Packer ile pişirmeye, bir image pipeline'ı sürdürmeye, her sürümde yeniden build almaya gerek yok. Doğru AMI'yi bulup user-data ile makine konfigürasyonunu geçiyorsunuz, gerisi Talos'un işi. Lafı uzatmadan başlayalım.

Talos AMI'leri kim yayınlıyor?

Sidero Labs, her Talos sürümü için tüm AWS bölgelerinde hem amd64 hem arm64 mimarileri için AMI yayınlıyor. Bu image'lar herkese açık ama AWS Marketplace'in tipik vitrininde değiller (orada da bir kayıt var, ama doğrudan değil); resmi yol ya Talos dokümantasyonuna bakmak ya da AWS CLI ile sorgulamak.

AMI'lerin sahibi (owner ID) 540036508848. Bu Sidero Labs'in AWS hesabı ve filtrelerken bu ID'ye dayanmak başka bir 'talos' isimli image'a yanlışlıkla denk gelmemenizi sağlıyor. Bence AMI seçerken her zaman --owners ile bu ID'yi vermek iyi bir alışkanlık; isim eşlemesine güvenmek bir gün sizi yanıltır.

Doğru AMI'yi bulmak

Bölgenizdeki son birkaç sürümü görmek için en hızlı yol şu:

# Bölgenizdeki son Talos AMI'lerini listele
aws ec2 describe-images \
  --owners 540036508848 \
  --filters 'Name=name,Values=talos-v1.7*' \
  --region us-east-1 \
  --query 'Images | sort_by(@, &CreationDate) | [-5:].{Name:Name, ImageId:ImageId, Arch:Architecture, Date:CreationDate}' \
  --output table

Çıktı son beş image'ı tarih sırasıyla verir; en alttaki en yenisidir. Aynı işi talosctl ile de yapabilirsiniz:

# Belirli sürüm ve mimari için varsayılan AMI'yi sor
talosctl image default --talos-version v1.7.0 --platform aws --arch amd64

İkisinin de pratik faydası farklı: CLI sorgusu hangi sürümlerin canlı olduğunu görmek için, talosctl ise script'lerden tek bir AMI ID çekmek için daha uygun.

Hangi varyant?

Talos'un AWS image'ları tek tip değil. En sık karşılaşacağınız üç varyant şöyle:

Standart: Çoğu donanım için derlenmiş kernel modülleriyle gelen varsayılan image. Tipik bir Kubernetes kümesi için bu yeter.
NVIDIA GPU: p3, p4, g4 ailesi GPU instance'lar için NVIDIA sürücüleri içerir. ML iş yükü çalıştıracaksanız buna geçin.
ZFS: Storage katmanınız ZFS gerektiriyorsa kernel modüllerini hazır getirir.

Standart image'ın işi görmediği özel bir senaryo yoksa onu seçin. Şahsi kanaatim, ihtiyaç doğmadan GPU veya ZFS varyantına atlamak gereksiz bagaj taşımak.

Instance'ları başlatmak

AMI ID'yi aldıktan sonra önce konfigürasyonu üretiyoruz:

# Talos konfigurasyonunu olustur
talosctl gen config my-cluster https://my-cluster-lb.us-east-1.elb.amazonaws.com:6443

# Bu komut su dosyalari uretir:
# - controlplane.yaml (control plane node'lar icin)
# - worker.yaml (worker node'lar icin)
# - talosconfig (talosctl kimlik dogrulamasi icin)

Sonra control plane'i kaldırıyoruz:

# Ilk control plane node'u baslat
aws ec2 run-instances \
  --image-id ami-0xxxxxxxxxxxxxxxxx \
  --instance-type m5.xlarge \
  --count 1 \
  --subnet-id subnet-xxxxxxxx \
  --security-group-ids sg-xxxxxxxx \
  --iam-instance-profile Name=talos-controlplane \
  --user-data file://controlplane.yaml \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=cp-1},{Key=kubernetes.io/cluster/my-cluster,Value=owned}]' \
  --block-device-mappings '[{"DeviceName":"/dev/xvda","Ebs":{"VolumeSize":50,"VolumeType":"gp3","Encrypted":true}}]'

Buradaki kritik nokta --user-data ile controlplane.yaml'ı geçiriyor olmamız. Talos açıldığında maintenance mode'a girer ve user-data'da konfigürasyon görürse otomatik uygular; siz ayrıca SSH'lamak zorunda değilsiniz, zaten Talos'ta SSH yok.

Worker'ları da benzer şekilde, worker.yaml ile başlatın. Disk boyutu için control plane'de 50 GB rahat yeter; worker'da container image cache'i ve ephemeral storage'ı baz alıp 100-200 GB civarı bir yerde tutuyorum genelde.

Cluster'ı bootstrap etmek

Instance'lar ayağa kalkınca etcd'yi başlatmak için tek bir komut yetiyor:

# talosctl'i kumeye yonlendir
export TALOSCONFIG=./talosconfig
talosctl config endpoint <ControlPlaneIp>
talosctl config node <ControlPlaneIp>

# Ilk control plane node'unda etcd'yi bootstrap et
talosctl bootstrap

# Kume ayaga kalksin, kubeconfig'i al
talosctl kubeconfig ./kubeconfig
export KUBECONFIG=./kubeconfig
kubectl get nodes

Bu noktadan sonra elinizde çalışan bir Kubernetes kümesi var.

Sık karşılaşılan tuzaklar

Owner ID vermeden filtreleme: İsim filtresi tek başına başka birinin yayınladığı image'a denk gelebilir. Her zaman --owners 540036508848 kullanın.
EBS şifrelemesini unutmak: gp3'te şifreleme bedava, performans düşürmüyor; varsayılan olarak Encrypted: true verin. Sonradan dönüp düzeltmek snapshot dansı gerektirir.
Yanlış mimari AMI'si seçmek: arm64 image'ı x86 instance'a (ya da tersi) verirseniz boot'ta sessizce takılır. Sürüm filtresine Name=architecture,Values=arm64 eklemek hayat kurtarır.
Yeni node için launch template'i güncellememek: In-place upgrade çalışan node'lar için tatlı, ama yeni katılan node hâlâ eski AMI ile geliyorsa cluster'da sürüm karışıklığı olur. AMI'yi değiştirdiğinizde launch template'i de değiştirin.

Sürüm güncellemesi

Yeni bir Talos sürümü çıktığında her şeyi yeniden kurmanıza gerek yok, in-place upgrade var:

# Bir node'u yeni surume yukselt
talosctl upgrade --nodes <NodeIp> \
  --image ghcr.io/siderolabs/installer:v1.7.1

Doğru ayarlanmış pod disruption budget'larıyla iş yükleriniz drain edilip yeniden zamanlanır. Yine de yeni katılacak node'lar için launch template'i yeni AMI'ye işaret edecek biçimde güncellemeyi ihmal etmeyin.

Kapanış

Hazır AMI'ler, AWS üzerinde Talos ile küme kurmayı 'birkaç komut' işine indiriyor; image pipeline derdiniz olmuyor, her bölgede her sürüm hazır. Bence yola çıkarken standart image'la başlayın, Image Factory'ye ancak gerçek bir ihtiyaç doğduğunda uzanın. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

GPU Üzerinde TensorFlow Serving'i Flux CD ile Dağıtmak

2026-05-10T00:00:00Z

Selamlar, bu yazımda TensorFlow Serving'i GPU node'ları üzerinde Flux CD ile nasıl dağıttığımıza bakacağız. ML modellerini production'a almak başlı başına ayrı bir dert; bir de işin içine GPU, model versiyonu, kaynak ayarı, drift gibi şeyler girince elle yönetmek hızla kabusa dönüşüyor. Bence bu noktada GitOps şart, lafı çok uzatmadan girelim konuya.

Olay aslında basit. Eğitilmiş bir TensorFlow modeli var, bunu düşük gecikmeyle servis etmek istiyoruz. CPU ile mümkün ama gerçek üretim trafiğinde GPU'nun farkı çok bariz. TensorFlow Serving zaten bu iş için biçilmiş kaftan; üstüne Flux CD'yi koyduğumuzda her değişiklik bir pull request'e dönüyor, cluster da Git'teki gerçeğe göre kendini sürekli düzeltiyor.

Ön hazırlık

Başlamadan önce şunlara ihtiyacınız olacak:

NVIDIA device plugin yüklü, GPU node'lu bir Kubernetes cluster
Git deponuza bootstrap edilmiş Flux CD v2
Paylaşımlı bir volume veya object storage'da (GCS, S3) duran SavedModel
Cluster'dan erişilebilen bir container registry

Cluster'a kubectl get nodes -o json | jq '.items[].status.allocatable' | grep nvidia çekip GPU'ların gerçekten görünür olduğunu doğrulamadan devam etmeyin. Tecrübeyle sabittir, sonradan 'pod neden Pending'de takılı?' diye saç baş yolmak yerine en başta görmek daha iyi.

Namespace ve model config

Önce namespace'i ve TensorFlow Serving'in okuyacağı model konfigürasyonunu hazırlayalım. Burada model versiyon politikasını da belirliyoruz; biz son iki versiyonu canlı tutacağız ki rollback bir komut uzaklığında olsun.

# clusters/prod/tf-serving/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: tf-serving
  labels:
    app.kubernetes.io/managed-by: flux
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: tf-serving-models
  namespace: tf-serving
data:
  models.config: |
    model_config_list {
      config {
        name: 'oneri-modeli'
        base_path: '/models/oneri-modeli'
        model_platform: 'tensorflow'
        model_version_policy {
          latest { num_versions: 2 }
        }
      }
    }

Yeni bir model versiyonu yayınlamak istediğinizde bu ConfigMap'e değil, model store'a yeni klasörü atıyorsunuz; TensorFlow Serving en yenisini kendisi seçiyor.

GPU'lu deployment

Asıl iş burada. GPU kaynağını requests ve limits üzerinde aynı değere set ediyoruz çünkü nvidia.com/gpu paylaşılabilir bir kaynak değil, bütün veya hiç.

# clusters/prod/tf-serving/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tf-serving
  namespace: tf-serving
spec:
  replicas: 2
  selector:
    matchLabels:
      app: tf-serving
  template:
    metadata:
      labels:
        app: tf-serving
    spec:
      tolerations:
        - key: 'nvidia.com/gpu'
          operator: 'Exists'
          effect: 'NoSchedule'
      containers:
        - name: tf-serving
          # GPU destekli imajın spesifik etiketi - asla 'latest' kullanmayin
          image: tensorflow/serving:2.14.0-gpu
          args:
            - '--model_config_file=/etc/tf-serving/models.config'
            - '--rest_api_port=8501'
            - '--grpc_port=8500'
            - '--enable_batching=true'
          ports:
            - { containerPort: 8500, name: grpc }
            - { containerPort: 8501, name: rest }
          resources:
            requests:
              nvidia.com/gpu: 1
              memory: '8Gi'
              cpu: '4'
            limits:
              nvidia.com/gpu: 1
              memory: '8Gi'
              cpu: '4'
          env:
            - { name: TF_FORCE_GPU_ALLOW_GROWTH, value: 'true' }
          volumeMounts:
            - { name: model-config, mountPath: /etc/tf-serving }
            - { name: model-store, mountPath: /models }
      volumes:
        - name: model-config
          configMap: { name: tf-serving-models }
        - name: model-store
          persistentVolumeClaim: { claimName: model-store-pvc }

TF_FORCE_GPU_ALLOW_GROWTH çok kritik. Default'ta TensorFlow GPU belleğinin tamamını başta cımbızlıyor; bu sizi tek model + tek pod senaryosuna kilitler. Açtığınızda bellek gerektikçe büyüyor, aynı GPU'da farklı şeyler kohabit edebiliyor.

Flux Kustomization

Tüm bu dosyaları Flux'a teslim etmek için ufak bir Kustomization yetiyor. Sağlık kontrolünü ekliyoruz ki Flux pod gerçekten ayağa kalkmadan 'başarılı' demesin.

# clusters/prod/flux-kustomization-tf-serving.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: tf-serving
  namespace: flux-system
spec:
  interval: 5m
  path: ./clusters/prod/tf-serving
  prune: true
  sourceRef:
    kind: GitRepository
    name: flux-system
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: tf-serving
      namespace: tf-serving

prune: true deyince Git'ten silinen kaynaklar cluster'dan da gidiyor; manuel kubectl apply ile bıraktığınız hayalet kaynaklar varsa onlar da temizlenir, dikkatli olun.

Doğrulama

Deploy gittikten sonra basit bir kontrol:

flux get kustomizations tf-serving
kubectl rollout status deployment/tf-serving -n tf-serving

curl -X POST http://<svc-ip>:8501/v1/models/oneri-modeli:predict \
  -H 'Content-Type: application/json' \
  -d '{"instances": [[1.0, 2.0, 3.0, 4.0]]}'

Cevap geldiyse gerisi konfor.

Sık karşılaşılan tuzaklar

latest imaj etiketi kullanmak: Reprodüksiyon ölür, rollback belirsizleşir. Her zaman 2.14.0-gpu gibi sabit etiket.
Batching'i kapalı bırakmak: GPU saniyede tek istek için boşa beslenir. --enable_batching=true ve bir batching.config ile kuyruğu doldurun.
PodDisruptionBudget koymamak: Node drain sırasında iki replikanız da aynı anda inebilir. minAvailable: 1 zorunlu.
GPU'yu CPU node'una düşürmek: Tolerasyon var ama nodeSelector yoksa scheduler bazen şaşırır; nvidia.com/gpu.present: 'true' etiketiyle hedef node'u sabitleyin.

Kapanış

Bu yazıda TensorFlow Serving'i GPU node'larında Flux CD ile nasıl yönetilebilir bir hâle getirdiğimize baktık. Bana sorarsanız ML platformunun en az kod yazılan ama en çok kazandıran kısmı tam burası: model versiyonu artık 'birinin laptopundan deploy ettiği şey' olmaktan çıkıp sıradan bir PR'a dönüşüyor. Umarım faydalı olur, görüşmek üzere.

Python sınıflarında slots ile bellek tasarrufu

2026-05-09T00:00:00Z

Python, esnekliği ve kullanışlılığı ile bilinen bir programlama dilidir. Ancak bazı durumlarda, bellek kullanımı optimize edilmesi gereken bir konu haline gelebilir. Özellikle büyük veri kümelemeleri veya nesne koleksiyonları ile çalışırken, bellek verimliliği önemli bir rol oynar. Bu yazıda, Python sınıflarında slots tanımlayarak nasıl bellek tasarrufu sağlayacağımızı inceleyeceğiz.

Sınıflarda Bellek Kullanımı

Normalde, Python'da bir sınıf tanımladığımızda, her bir nesne için bir sözlük (dictionary) oluşturulur. Bu sözlük, nesneye ait tüm özellikleri saklar. Ancak bu durum, bellek kullanımı açısından bazı dezavantajlar doğurur. Özellikle çok sayıda nesne oluşturduğumuz durumlarda, bu sözlük yapısı gereksiz yere fazla bellek tüketir.

slots kullanarak, bu durumu düzeltmek mümkündür. Sınıfımıza slots tanımladığımızda, her nesnenin özellikleri sabit bir yapı içinde saklanır. Bu yapı, nesne bazında bellek ihtiyacını azaltarak performans artışı sağlar.

slots Kullanımı

Bir Python sınıfında slots tanımlamak oldukça basittir. Aşağıda bir örnek üzerinden açıklayalım:

class Numara:
    __slots__ = ['isim', 'yas']
    
    def __init__(self, isim, yas):
        self.isim = isim
        self.yas = yas

Yukarıdaki örnekte, Numara adında bir sınıf tanımladık ve isim ve yas adlı iki özellik için slots kullandık. Bu durumda, Numara nesneleri oluşturduğumuzda, her nesne bu iki özellik için bellek alanı ayıracak, ancak ek bellek tüketen sözlük yapısı kullanılmayacaktır.

Bellek Kazancı

slots kullanarak oluşturduğumuz sınıfların bellek tüketimini gözlemlemek, yapılan optimizasyonun etkisini anlamak açısından faydalıdır. Aşağıda, slots kullanmayan bir sınıf ile kullanan bir sınıf arasındaki bellek farkını incelemek için basit bir örnek kod verelim:

import sys

class Normal:
    def __init__(self, isim, yas):
        self.isim = isim
        self.yas = yas
        
class Optimizasyon:
    __slots__ = ['isim', 'yas']
    
    def __init__(self, isim, yas):
        self.isim = isim
        self.yas = yas

normal_nesne = Normal('Ali', 30)
optimizasyon_nesne = Optimizasyon('Ayşe', 25)

print('Normal sınıf bellek kullanımı:', sys.getsizeof(normal_nesne))
print('Optimizasyon sınıf bellek kullanımı:', sys.getsizeof(optimizasyon_nesne))

Bu kodu çalıştırdığımızda, Normal sınıfının bellek kullanımı daha fazla çıkacakken, Optimizasyon sınıfı slots sayesinde daha az bellek tüketecektir. Bu, büyük nesne koleksiyonlarıyla çalıştığımızda önemli bir avantaj sağlar.

Sonuç

Python'daki slots ile bellek yönetimi, büyük projelerde performans artışı sağlamak amacıyla dikkate alınması gereken bir tekniktir. Kodlarımızda slots kullanarak bellek tasarrufuna giderek sistem kaynaklarını daha verimli kullanabiliriz. Özellikle büyük veri kümeleri üzerinde çalışan geliştiricilerin slots kullanımını göz önünde bulundurarak programlarını optimize etmeleri faydalı olacaktır.

uv ile hızlı Python paket yönetimi

2026-05-09T00:00:00Z

uv Nedir?

Python geliştirme dünyasında paket yönetimi, projelerin sürdürülebilirliği ve güvenliği açısından kritik bir rol oynar. Geleneksel araçlar arasında yer alan pip, venv ve pip-tools, genellikle geliştiriciler arasında yaygın olarak kullanılmaktadır. Fakat son zamanlarda, uv adında tek dosyalık bir paket çözücü, bu araçların yerini almak için ön plana çıkmıştır. uv, hem kullanıcı dostu olması hem de hızlı bir deneyim sunmasıyla dikkat çekiyor.

uv’nin Avantajları

uv, entegre bir paket yönetim aracı olarak, avantajları sayesinde geliştiricilere zaman kazandırmayı hedefler. İşte uv kullanmanın bazı faydaları:

Hızlı Kurulum: uv, paketlerin daha hızlı inşa edilmesini sağlarken, zamandan tasarruf etmenizi sağlar. Bu sayede, geliştirme süreçleri hızlanır.
Kolay Kullanım: Basit bir CLI (Komut Satırı Arayüzü) sunarak, kullanıcıların paketleri hızlıca kurmasına ve yönetmesine yardımcı olur.
Tek Dosya Yapısı: uv tek bir dosya olarak sunulmakta. Bu, kurulum ve yönetim süreçlerinde basitlik sağlar.

Temel Kullanım

uv kullanımına başlamadan önce, sisteminizde Python ve pip kurulu olmalıdır. Kurulum adımları oldukça basittir. İlk olarak, uv paketini kurmak için aşağıdaki komutu kullanabilirsiniz:

pip install uv

Kurulumdan sonra, uv ile yeni bir proje oluşturmak için şu adımları izlemeniz yeterli:

uv create <ProjectName>
cd <ProjectName>

Bu komutlar, <ProjectName> isimli yeni bir proje dizini oluşturacak ve o dizine geçiş yapacaktır. Projenizde ihtiyaç duyduğunuz paketleri eklemek için aşağıdaki gibi bir komut kullanabilirsiniz:

uv add <PackageName>

Buradaki <PackageName>, kurmak istediğiniz paketin adıdır. Birden fazla paket eklemek için isimleri aralarına boşluk koyarak ekleyebilirsiniz.

Proje Yönetimi

uv, projelerinizi yönetmek için güçlü bir yapı sunuyor. Proje içindeki paketleri görüntülemek ve güncellemek oldukça kolay. Aşağıdaki komutu kullanarak mevcut paketlerinizi ve sürümlerini görüntüleyebilirsiniz:

uv list

Ayrıca, belirli bir paketin güncellemelerini kontrol etmek için:

uv update <PackageName>

komutunu kullanabilirsiniz. Bu komut, belirttiğiniz paketin en son sürümüne güncellenmesini sağlar.

Sonuç

uv, Python geliştirme akışını önemli ölçüde hızlandıran bir araç olarak dikkat çekmektedir. Tek dosyalık yapısı ve kullanıcı dostu arayüzü sayesinde projelerinizi daha verimli bir şekilde yönetebilirsiniz. Özellikle büyük projelerde zaman kazandırması, bu aracı denemeniz için yeterli bir sebep olabilir. Eğer henüz uv kullanmadıysanız, projelerinize entegre etmeyi düşünmelisiniz.

MySQL'de CREATE TABLE AS SELECT ile Hızlı Tablo Üretmek

2026-05-09T00:00:00Z

Selamlar, bu yazımda MySQL'in az konuşulan ama gerçekten işe yarayan deyimlerinden birine, CREATE TABLE AS SELECT'e (kısaca CTAS) bakacağız. Konu basit gibi durur: 'bir SELECT yaz, sonucundan tablo üret', tamam. Ama bence asıl mevzu deyimin ne yaptığında değil, ne yapmadığında gizli. Index taşımıyor, primary key kurmuyor, foreign key'i unutuyor. Bunu bilmeden production'a CREATE TABLE ... AS SELECT atan biri ertesi sabah JOIN'lerin neden bu kadar yavaşladığını soruyor olur. Hadi başlayalım.

CTAS nedir, ne işe yarar?

CTAS, tek bir deyim içinde hem yeni bir tablo oluşturur hem de SELECT'in döndürdüğü satırları o tabloya basar. MySQL, sütunların tipini SELECT'in ifadesinden çıkarır (type inference). Yani siz SUM(quantity * unit_price) yazdığınızda, MySQL ortaya çıkan değerin uygun bir decimal(...) olduğuna kendi karar verir.

Korunan şey sadece NOT NULL ve karakter seti gibi sütun-düzeyinde temel attribute'lar. Index'ler, primary key, AUTO_INCREMENT, UNIQUE, foreign key - hiçbiri taşınmaz. Yani CTAS size çıplak bir tablo verir; üzerine ne giydireceğiniz size kalmış.

Tipik kullanım yerleri:

Periyodik tazelenen özet (summary) tabloları
ETL pipeline'larında geçici staging tabloları
Analitik snapshot'lar - 'mart sonu itibarıyla şu durumdaydı' kayıtları

En basit hâli

Önce küçük bir kullanıcı tablosu kuralım, sonra ondan yeni bir tablo türetelim:

CREATE TABLE users (
    id         INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    username   VARCHAR(50)  NOT NULL,
    email      VARCHAR(255) NOT NULL,
    country    CHAR(2),
    created_at DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO users (username, email, country) VALUES
    ('ali',   'ali@ornek.com',   'TR'),
    ('berk',  'berk@ornek.com',  'TR'),
    ('clara', 'clara@ornek.com', 'DE');

-- TR kullanicilarindan yeni bir tablo turetelim
CREATE TABLE tr_users AS
    SELECT id, username, email, created_at
    FROM users
    WHERE country = 'TR';

Şimdi DESCRIBE tr_users yaparsanız ilginç bir şey görürsünüz: id sütunu var, int unsigned, NOT NULL - hepsi tamam. Ama Key sütunu boş, Extra sütunu boş. Yani primary key yok, AUTO_INCREMENT gitmiş.

Bu yüzden CTAS'ı atar atmaz hemen ardından ALTER TABLE ile eksikleri tamamlamak alışkanlık olmalı:

ALTER TABLE tr_users
    ADD PRIMARY KEY (id),
    ADD UNIQUE INDEX uq_email (email),
    ADD INDEX idx_created_at (created_at);

Hesaplanmış sütunlar ve takma adlar

CTAS'ın gerçek gücü, agregasyon sonuçlarını materialize ederken ortaya çıkıyor. Burada AS ile takma ad vermek şart, çünkü yeni tablonun sütun adı buradan geliyor:

CREATE TABLE order_totals AS
    SELECT
        user_id,
        COUNT(*)                          AS order_count,
        SUM(total_amount)                 AS lifetime_value,
        MIN(created_at)                   AS first_order_at,
        MAX(created_at)                   AS last_order_at
    FROM orders
    GROUP BY user_id;

Takma ad vermezseniz sütun adı COUNT(*) gibi pek de sevimli olmayan bir şey olur ve sonradan refactor canavarı olarak karşınıza çıkar.

Boş bir tablo, sadece yapısı için

Bir tablonun yalnız yapısını kopyalamak istiyorsanız iki yol var. Birincisi CTAS hilesi:

CREATE TABLE users_staging AS
    SELECT * FROM users WHERE 1 = 0;

WHERE 1 = 0 hiçbir satıra uymaz, dolayısıyla tablo boş gelir ama yapısı çıkarılır. Şahsi kanaatim: bu yöntem hızlı bir hile için iyi, ama yine index'siz/PK'sız bir tablo verir. Ben yapısal kopya istediğimde CREATE TABLE ... LIKE tercih ediyorum:

CREATE TABLE users_staging LIKE users;

LIKE versiyonu index'leri ve PK'yı da taşır (FK hariç). Sonra INSERT INTO users_staging SELECT ... FROM users ile veriyi doldurursunuz. Tip sadakati ve index'lerle uğraşmak istemiyorsanız bu çok daha temiz.

CTAS mı, LIKE mı?

İkisi farklı işler için. Karıştırmamak adına kısa bir karşılaştırma:

Özellik	CTAS	CREATE TABLE LIKE
Veriyi de kopyalar mı?	Evet	Hayır
Index'leri taşır mı?	Hayır	Evet
Primary key'i taşır mı?	Hayır	Evet
Foreign key'i taşır mı?	Hayır	Hayır
Sütun tipleri	Çıkarılır	Birebir
İdeal kullanım	Özet, snapshot, ETL stage	Yapısal kopya

Sık karşılaşılan tuzaklar

Primary key eklemeyi unutmak: CTAS sonrası ALTER TABLE ... ADD PRIMARY KEY atmazsanız tablo PK'sız kalır. JOIN'lerde ve replication'da başınız ağrır.
AUTO_INCREMENT'in kaybolması: Kaynak tabloda olsa bile yeni tabloya geçmez. Yeni tabloda ihtiyaç varsa elle eklemek lazım.
Foreign key beklemek: Foreign key kesinlikle taşınmaz. Referans bütünlüğü gerekiyorsa CTAS sonrası elle tanımlayın.
Üretimde uzun süren CTAS: Büyük bir tablodan CTAS atmak metadata lock alır ve kaynak tabloda işlemleri bekletir. Yoğun saatlerde sakın yapmayın; replica üzerinde ya da gece batch'inde tercih edin.
Tip çıkarımına güvenmek: Bir decimal(32,2) görürseniz şaşırmayın - MySQL geniş aralık seçer. Sonra ALTER TABLE ... MODIFY ile daraltmak gerekebilir.

Kapanış

Bu yazıda CTAS'ı, ne taşıdığını ve neyi geride bıraktığını gördük. Bence akılda kalması gereken tek cümle şu: CTAS size ham bir tablo verir, geri kalanı sizin işiniz. Periyodik özetler ve hızlı analiz snapshot'ları için biçilmiş kaftan; ama yapısal kopya istiyorsanız CREATE TABLE ... LIKE daha doğru adres. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

MySQL MEDIUMBLOB ile İkili Veri Saklamak

2026-05-09T00:00:00Z

Selamlar, bu yazıda MySQL'in MEDIUMBLOB tipine bakacağız. PDF'leri, küçük resimleri, imza dosyalarını veritabanında tutmak isteyen ekipler bir noktada bu tipe denk geliyor; ben de yıllar içinde 'şu dosyayı veritabanına atalım, kolay olsun' kararının bazen kurtarıcı, bazen ayak bağı olduğunu gördüm. Hadi tipin sınırlarına ve doğru kullanım senaryolarına dalalım.

MEDIUMBLOB nedir?

MEDIUMBLOB, en fazla 16.777.215 bayt yani yaklaşık 16 MB ikili veri saklayabilen bir tiptir. MySQL'in BLOB ailesinde BLOB (64 KB) ile LONGBLOB (4 GB) arasındaki boşluğu doldurur. Yani çok küçük olmayan ama devasa da sayılmayacak dosyalar için biçilmiş kaftan.

Burada gözden kaçmayan bir detay var: InnoDB'nin DYNAMIC satır formatında BLOB içeriği satırla aynı sayfada tutulmaz. Verinin kendisi off-page'e gider, satırda yalnızca 9 ile 12 bayt arası bir işaretçi kalır. Bu sayede 65.535 baytlık satır limitine BLOB sütunları neredeyse hiç yük bindirmez. Aslında MEDIUMBLOB'un cazibesinin yarısı bu mimari karardan geliyor.

Tablo tasarımı

Bir dosya yükleme tablosu kurarken ne istediğimizi en baştan netleştirelim. Aşağıdaki şema, hem dosyanın kendisini hem de işine yarayacak meta verileri tek satırda toplar:

CREATE TABLE uploaded_files (
    id          INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    filename    VARCHAR(255) NOT NULL,
    mime_type   VARCHAR(100) NOT NULL,
    file_data   MEDIUMBLOB NOT NULL,
    file_size   INT UNSIGNED GENERATED ALWAYS AS (LENGTH(file_data)) STORED,
    uploaded_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

file_size sütununu generated column olarak tutmamın sebebi listeleme sorgularında LENGTH(file_data) çağırarak BLOB'u sayfaya taşımak zorunda kalmamak. Küçük bir numara ama büyük bir tasarruf.

Veri ekleme ve okuma

Python tarafında mysql-connector-python ile bir PDF eklemek oldukça düz:

import mysql.connector

conn = mysql.connector.connect(host='localhost', user='root', database='mydb')
cursor = conn.cursor()

with open('sunum.pdf', 'rb') as f:
    pdf_bytes = f.read()

cursor.execute(
    """INSERT INTO uploaded_files (filename, mime_type, file_data)
       VALUES (%s, %s, %s)""",
    ('sunum.pdf', 'application/pdf', pdf_bytes)
)
conn.commit()
print(f'{len(pdf_bytes)} bayt yazildi')

Geri okumak da aynı şekilde sade. Tek dikkat edilecek nokta, fetchone() BLOB'u baştan sona belleğe alır. Yani 15 MB'lık bir dosyayı okuyorsanız o satır anında 15 MB RAM tüketir:

cursor.execute(
    'SELECT filename, mime_type, file_data FROM uploaded_files WHERE id = %s',
    (1,)
)
filename, mime_type, file_data = cursor.fetchone()

with open(f'indirilen_{filename}', 'wb') as f:
    f.write(bytes(file_data))

max_allowed_packet ayarı

Büyük insert'lerde başınıza gelecek ilk hata genelde Packet too large olur. Çünkü MySQL istemci ile sunucu arasındaki tek bir paketin boyutuna sınır koyar. MEDIUMBLOB ile çalışıyorsanız bu sınırı yükseltmeniz gerek:

-- Mevcut degeri gor
SHOW VARIABLES LIKE 'max_allowed_packet';

Sunucu tarafında my.cnf içine max_allowed_packet = 20M yazmak çoğu durumda yeter. İstemci tarafında da bağlantı parametresiyle ayarlanır:

mysql -u root -p mydb --max_allowed_packet=20M

Bu ayarı yapmadan yapılan testler 'lokalde çalışıyordu' efsanesinin en büyük kaynaklarından biridir.

Sık karşılaşılan hatalar

SELECT * ile listelemek: Listeleme sorgularında BLOB sütununu çekmek bütün satırları sayfaya yüklemenize yol açar. Sadece ihtiyacınız olan sütunları seçin, dosyayı yalnızca indirme anında çekin.
MIME türü doğrulamamak: İstemci 'image/png' diyorsa diye doğrudan inanmayın. python-magic veya benzer bir kütüphane ile baytlardan tipini doğrulayın; aksi halde XSS veya yanlış servis edilen dosya sorunları kapıda.
Yedek boyutunu görmezden gelmek: BLOB'lar yedek dosyalarınızı şişirir. Bir noktada mysqldump çıktısı 50 GB'ı bulduğunda 'biz neyi nereye koyduk?' diye soracaksınız.
Versiyon yönetimi beklemek: MEDIUMBLOB tek bir mevcut hali tutar; CDN, varyant üretimi, geçmiş sürümler istiyorsanız S3 benzeri nesne depolama daha doğru adres.

Ne zaman MEDIUMBLOB, ne zaman dış depolama?

Bence kural basit: dosya 5 MB altındaysa, çok sık okunmuyorsa ve satırla transaksiyonel olarak tutarlı kalması önemliyse MEDIUMBLOB iyi seçimdir. Mesela kullanıcı imzası, PDF rapor eki, küçük thumbnail. Ama dosyalar büyük, sık okunan, CDN üzerinden dağıtılması gereken şeylerse S3 veya GCS'e gönderin, veritabanında sadece URL ile metadata tutun.

Kapanış

MEDIUMBLOB, doğru senaryoda hayatı çok kolaylaştıran bir tip; 'her dosyayı veritabanına atalım' refleksiyle kullanılırsa da en hızlı şekilde sırtınıza yük olan bir tip. Boyutu, erişim sıklığını ve yedek maliyetini birlikte değerlendirin; karar zaten kendiliğinden çıkar. Umarım faydalı olur, görüşmek üzere.

mysqlimport ile Toplu CSV Yüklemek

2026-05-09T00:00:00Z

Selamlar, bu yazımda MySQL'in çoğu zaman gözden kaçan bir aletini, mysqlimport'u konuşacağız. Elinizde birkaç yüz binlik bir CSV varsa ve bir de tutup INSERT döngüsüyle yüklemeye çalıştıysanız, ne demek istediğimi anlarsınız. Saatlerce bekleyen bir script, bir de yanında soğumuş bir kahve. Halbuki MySQL kutudan çıkar çıkmaz size hızlı bir yol sunuyor, biz farkında değiliz. Hadi başlayalım.

mysqlimport nedir?

mysqlimport aslında LOAD DATA INFILE SQL ifadesinin komut satırı kılığına bürünmüş hali. Yani arka planda bambaşka bir motor yok, MySQL'in kendi toplu yükleme komutu çalışıyor; siz sadece terminalden çağırıyorsunuz. Ama bu basit görünen sarmalama, sıradan INSERT yığınına göre çoğu senaryoda 10 ila 50 kat hız farkı yaratıyor. Tek satırlık bir komutla milyonlarca satır akıtabiliyorsunuz.

İlginç bir kuralı var: hedef tabloyu dosya adından çıkarıyor. Yani siparisler.csv dosyası otomatik olarak siparisler tablosuna gidiyor. Tablo adını parametreden vermiyorsunuz. İlk başlarda bu bana garip gelmişti, ama bir-iki kullanımdan sonra mantığı oturuyor; toplu yükleme yapacaksınız zaten dosyalarınızı tablo adına göre düzenli tutmanız işinize geliyor.

Temel kullanım

En sade biçimi şöyle:

mysqlimport [secenekler] veritabani_adi dosya1 [dosya2 ...]

Bir örnek üzerinden gidelim. Diyelim magaza veritabanında musteriler adlı bir tablomuz var ve elimizde /tmp/musteriler.csv dosyası duruyor:

# Dosya adi tablo adiyla ayni olmali
mysqlimport -u root -p magaza /tmp/musteriler.csv

Bu kadar. Tek satır. CSV ne kadar büyükse, INSERT'e göre kazancınız da o kadar büyür.

Ayraç ve tırnak ayarları

Hayatta her CSV virgülle ayrılmış olmuyor maalesef. Bazıları tab, bazıları pipe (|), bazıları da kim bilir hangi karaktere bayılmış birinin tercihiyle geliyor. mysqlimport bunların hepsini idare ediyor:

# Tab ile ayrilmis dosya
mysqlimport --fields-terminated-by='\t' -u root -p magaza /tmp/siparisler.tsv

# Pipe ile ayrilmis dosya
mysqlimport --fields-terminated-by='|' -u root -p magaza /tmp/urunler.txt

# Tirnak icine alinmis alanlar varsa
mysqlimport \
  --fields-terminated-by=',' \
  --fields-enclosed-by='"' \
  -u root -p magaza /tmp/musteriler.csv

Bana sorarsanız --fields-enclosed-by neredeyse her zaman lazım oluyor; çünkü gerçek CSV'lerde bir yerlerde mutlaka virgül içeren bir ad ya da adres çıkıyor karşınıza.

Başlık satırı, sütun sırası ve çakışmalar

Çoğu CSV'nin ilk satırı sütun adlarıyla geliyor; bunu --ignore-lines ile atlıyorsunuz. Dosyadaki sütunların sırası tablodakinden farklıysa --columns ile mantıklı bir eşleme veriyorsunuz:

# Ilk satiri (basligi) atla
mysqlimport --ignore-lines=1 \
  --fields-terminated-by=',' \
  -u root -p magaza /tmp/musteriler.csv

# Sutun sirasini elle belirt
mysqlimport \
  --columns=id,ad,eposta,olusturulma \
  --ignore-lines=1 \
  --fields-terminated-by=',' \
  -u root -p magaza /tmp/musteriler.csv

Yükleme sırasında aynı birincil anahtara sahip kayıt zaten varsa ne olacak? İki seçeneğiniz var: ya üzerine yazarsınız ya da o satırı atlarsınız.

# Mevcut kayitlari yenisiyle degistir
mysqlimport --replace --fields-terminated-by=',' \
  -u root -p magaza /tmp/musteriler.csv

# Cakisan satirlari sessizce gec
mysqlimport --ignore --fields-terminated-by=',' \
  -u root -p magaza /tmp/musteriler.csv

Hangisini seçeceğiniz veriyi nereden aldığınıza bağlı; gece koşan bir senkronizasyondaysanız --replace, tek seferlik bir göç ise --ignore çoğu zaman daha güvenli.

Paralel yükleme ve LOAD DATA karşılığı

Aylık dosyaları ayrı ayrı tutuyorsanız hepsini birden, paralel olarak yükleyebilirsiniz:

mysqlimport --use-threads=4 \
  --fields-terminated-by=',' \
  -u root -p magaza \
  /tmp/siparisler_ocak.csv \
  /tmp/siparisler_subat.csv \
  /tmp/siparisler_mart.csv \
  /tmp/siparisler_nisan.csv

Perde arkasında üretilen SQL aslında bu:

LOAD DATA INFILE '/tmp/musteriler.csv'
INTO TABLE musteriler
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'
IGNORE 1 LINES
(id, ad, eposta, olusturulma);

Yani mysqlimport öğrenmek bir bakıma LOAD DATA INFILE öğrenmek demek; biri terminalden, diğeri SQL istemcisinden hayatınıza giriyor.

Sık karşılaşılan tuzaklar

Dosya adı tablo adıyla uyuşmuyor: musteri_listesi.csv koyup musteriler tablosuna gitmesini bekleyemezsiniz. Yüklemeden önce dosyayı yeniden adlandırın ya da sembolik bağ kurun.
Sunucuda dosya yok: mysqlimport varsayılanda dosyayı sunucuda arar. Dosya sizdeyse --local parametresini ekleyin; ayrıca my.cnf içinde local_infile=1 açık olmalı.
Karakter kodlama uyumsuzluğu: Türkçe karakterler bozuk çıkıyorsa --default-character-set=utf8mb4 ekleyin. Çoğu hata buradan çıkıyor.
Index'ler darboğaz oluyor: Çok büyük yüklemelerde önce ALTER TABLE ... DISABLE KEYS ile indexleri devre dışı bırakın, yükleme bitince ENABLE KEYS ile geri açın. Bence bir milyondan büyük her yüklemede bunu refleks haline getirmek lazım.

Kapanış

mysqlimport öğrenmesi bir öğleden sonra sürmeyen ama elinizde tuttukça size saatler kazandıran bir alet. Bence MySQL ile çalışan herkesin cebinde olması gereken o ufak ama keskin araçlardan biri. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Cloud Run Servisini Cloud SQL Örneğine Bağlamak

2026-05-09T00:00:00Z

Merhabalar, bu yazımda Cloud Run üstünde koşan bir servisi Cloud SQL örneğine nasıl bağladığımıza bakacağız. Konu kâğıt üstünde basit duruyor ama ilk denediğinizde 'connection refused' veya 'too many connections' hatasıyla karşılaşmamak için bilmeniz gereken birkaç ufak detay var. Lafı çok uzatmadan başlayayım.

Cloud Run, GCP'nin sunucusuz container platformu. Trafik geldiğinde sıfırdan N instance'a ölçekleniyor, gelmeyince yine sıfıra iniyor. Bu güzel ama veritabanı tarafında bir gerçeklik var: Cloud SQL örneğinin sınırlı sayıda bağlantısı var ve siz patlayan instance sayısıyla doğru orantılı bağlantı açarsanız hızla duvara toslarsınız. O yüzden bağlantı şeklini ve havuzu doğru kurmak işin yarısı.

Bağlantı için iki yol var

Pratikte iki ana yaklaşım kullanılıyor:

Yerleşik Cloud SQL connector + Unix socket: Servisi deploy ederken --add-cloudsql-instances parametresini geçiyorsunuz, Cloud Run container içine /cloudsql/<INSTANCE_CONNECTION_NAME> yolunda bir Unix socket bind ediyor. Public IP veya private IP fark etmiyor, akış GCP'nin kendi proxy'si üzerinden geçiyor.
Cloud SQL Connector kütüphaneleri: Python için cloud-sql-python-connector, Java için postgres-socket-factory gibi paketler. IAM Authentication ve TLS'i programatik olarak yönetiyorlar. IAM tabanlı auth kullanmak istiyorsanız genelde tercih edilen yol.

Bence ilk projede socket yaklaşımı yeter. Connector kütüphaneleri IAM auth veya çok özel ihtiyaçlar varsa devreye girer; basit bir CRUD servisinde fazladan bağımlılık.

IAM ve servis hesabı

İlk yapılacak iş Cloud Run servisinin koştuğu service account'a roles/cloudsql.client rolünü vermek. Cloud SQL Admin API'sinin de açık olması lazım; aksi halde proxy bağlantı kuramıyor.

Connection name'i almakla başlayalım:

gcloud sql instances describe my-postgres \
  --format='value(connectionName)'
# ornegin: my-project:europe-west1:my-postgres

Bu üçlü project:region:instance ileride deploy ederken sürekli işimize yarayacak. Sonrasında deploy:

gcloud run deploy payment-api \
  --image=europe-west1-docker.pkg.dev/my-project/apps/payment-api:1.4.0 \
  --region=europe-west1 \
  --service-account=payment-api-sa@my-project.iam.gserviceaccount.com \
  --add-cloudsql-instances=my-project:europe-west1:my-postgres \
  --set-env-vars=DB_HOST=/cloudsql/my-project:europe-west1:my-postgres,DB_USER=payment,DB_NAME=payments \
  --set-secrets=DB_PASS=db-password:latest \
  --max-instances=20

Burada dikkat etmenizi istediğim iki şey var. Birincisi şifreyi --set-env-vars ile değil --set-secrets ile geçiyoruz; düz metin parola env'e asla yazılmaz, Secret Manager bunun için var. İkincisi --max-instances koymak. Cloud Run kendi haline bırakılırsa yüzlerce instance açabilir, her biri bağlantı tutar, Cloud SQL'in max_connections limiti kısa sürede dolar.

Uygulama tarafı

Python tarafında SQLAlchemy ile bağlanırken host olarak /cloudsql/... socket yolunu veriyoruz. URL'de host yerine query parametresinde belirtmek gerekiyor, çünkü TCP gibi davranmıyor:

import os
from sqlalchemy import create_engine
from sqlalchemy.engine.url import URL

instance = os.environ['DB_HOST']  # /cloudsql/proj:region:instance

url = URL.create(
    drivername='postgresql+psycopg2',
    username=os.environ['DB_USER'],
    password=os.environ['DB_PASS'],
    database=os.environ['DB_NAME'],
    query={'host': instance},
)

engine = create_engine(
    url,
    pool_size=3,
    max_overflow=2,
    pool_pre_ping=True,
    pool_recycle=1800,
)

pool_size=3 ve max_overflow=2 belki size düşük gelebilir. Ama hesabı yapın: 20 instance × 5 bağlantı = 100. Cloud SQL küçük bir tier'daysa default max_connections zaten 100-200 civarında. Pool'u büyütmeden önce instance sayısını sınırlamak daha sağlıklı.

pool_pre_ping=True da kritik. Cloud Run instance'ları cold start sonrası uyuyabiliyor, bağlantı kopuk olabiliyor; pre-ping olmazsa ilk istek hata yiyor.

Private IP isteyenler için kısa not

Eğer Cloud SQL örneği sadece private IP ile erişilebiliyorsa, Cloud Run'ın VPC'ye girmesi lazım. Bunun için Serverless VPC Access connector oluşturuyoruz ve deploy sırasında --vpc-connector ile bağlıyoruz. Bu yazıda detaya girmeyeceğim ama unutmayın: socket yöntemi public IP yokken bile çalışır, çünkü Cloud SQL Auth Proxy GCP içinden konuşuyor. Yani private IP zorunluluğu güvenlik gerekçesiyle değilse, socket genelde yeterli.

Sık karşılaşılan tuzaklar

connection refused hatası: Çoğunlukla --add-cloudsql-instances adı yanlış yazılmış veya servis hesabında roles/cloudsql.client rolü yok. Bir de Cloud SQL Admin API'nin açık olduğunu kontrol edin.
too many connections: Pool size'ı küçültün, --max-instances koyun. Gerekirse Cloud SQL tarafında max_connections flag'ini artırın ama bu ikinci adım; önce uygulama tarafını disipline edin.
Connection timeout: Cold start sırasında Cloud SQL Auth Proxy'nin ayağa kalkması bir-iki saniye sürebiliyor. Container'ın --timeout değerini ve client tarafındaki connect timeout'u makul tutun, pool_pre_ping zaten bayat soketleri eler.
Plaintext parola: --set-env-vars=DB_PASS=... yazma alışkanlığı çok yaygın. Loglara, revision history'ye sızar. Secret Manager'a 30 saniye veriyorsunuz, ömür boyu rahat ediyorsunuz.

Kapanış

Cloud Run + Cloud SQL ikilisi doğru kurulduğunda çok rahat çalışıyor; iş, ölçeklenmenin veritabanı tarafında yarattığı baskıyı ciddiye almakta. Bana sorarsanız küçük pool, sıkı max-instances ve Secret Manager üçlüsü neredeyse her senaryoya yetiyor; gerisi konfor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python'da Listeyi Parçalara Bölmek

2026-05-08T00:00:00Z

Merhabalar, bu yazımda Python'da bir listeyi daha küçük parçalara nasıl böldüğümüze bakacağız. Konu kulağa basit geliyor olabilir - aslında bir noktaya kadar öyle de - ama gerçek hayatta toplu veritabanı insert'i, API sayfalama, paralel işleme gibi yerlerde tam olarak hangi yöntemi seçtiğin epey fark yaratıyor. Hadi başlayalım.

Senaryo şu: elinizde 100 bin kayıt var, bunları veritabanına 1000'lik gruplar halinde basmak istiyorsunuz. Ya da bir API rate limit'i var, dakikada en fazla 50 istek geçebiliyor. Ya da concurrent.futures ile paralelleştireceğiniz bir iş var, her worker'a ayrı bir parça vermeniz gerekiyor. Hepsi aynı temel probleme dönüyor: listeyi parçalara böl.

En klasik yol: list comprehension ile slicing

Aklınıza gelen ilk yöntem muhtemelen şu olur, ki bence çoğu zaman da en doğrusu budur:

def parcala(liste, boyut):
    return [liste[i:i + boyut] for i in range(0, len(liste), boyut)]

veri = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
print(parcala(veri, 3))
# [[1, 2, 3], [4, 5, 6], [7, 8, 9], [10]]

Üç satır, okunaklı, sürpriz yok. Son parça eksik kalırsa kalır, kimseyi rahatsız etmez. Liste küçük-orta büyüklükteyse (diyelim 100 bin elemana kadar) bu yaklaşımı bırakıp başka bir şeye geçmek için ciddi bir gerekçeniz olmalı.

Bellek dostu sürüm: generator

Liste milyonlarca elemana çıkıyorsa veya daha kötüsü dosyadan satır satır okuyorsanız, hepsini bir anda parçalara bölüp belleğe almak israf. Generator burada işi çözüyor:

def parcala_gen(liste, boyut):
    for i in range(0, len(liste), boyut):
        yield liste[i:i + boyut]

for parca in parcala_gen(range(1_000_000), 10_000):
    # her seferinde sadece bir parca bellekte
    toplam = sum(parca)

Tek değişiklik return yerine yield. Ama davranış tamamen başka: artık parçalar gerektiği anda üretiliyor, hepsi aynı anda bellekte durmuyor. Bunu özellikle ETL benzeri pipeline'larda sıkça kullanırım.

Python 3.12 ile gelen `itertools.batched`

Eğer 3.12 veya üstündeyseniz, standart kütüphane bu işi sizin için zaten yapıyor:

from itertools import batched

veri = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
for parca in batched(veri, 3):
    print(parca)
# (1, 2, 3)
# (4, 5, 6)
# (7, 8, 9)
# (10,)

Dikkat: parçalar tuple olarak dönüyor, list değil. Liste lazımsa list(parca) yapacaksınız. Şahsen bu küçük detayı ilk gördüğümde 'ya niye?' demiştim, ama tuple daha hafif ve immutable olduğu için aslında mantıklı bir tercih.

Indekslenemeyen şeyler için: `itertools.islice`

Elinizdeki şey bir liste değil de bir generator veya iterator ise, liste[i:i+n] çalışmaz - çünkü slicing yok. İşte islice tam buraya:

from itertools import islice

def parcala_iter(iterable, boyut):
    it = iter(iterable)
    while True:
        parca = list(islice(it, boyut))
        if not parca:
            break
        yield parca

Bu fonksiyon hem listeyi yer hem de bir DB cursor'unu, bir generator'ı, bir dosya okuyucuyu... her türlü iterable'ı parçalara böler. 3.12 öncesinde bence en taşınabilir çözüm budur.

NumPy ile sayısal veri

Sayısal verilerle uğraşıyorsanız ve zaten NumPy projedeyse, array_split özellikle 'N eşit parçaya böl' senaryolarında çok temiz:

import numpy as np

dizi = np.arange(10)
for p in np.array_split(dizi, 3):
    print(p)
# [0 1 2 3]
# [4 5 6]
# [7 8 9]

Eleman sayısı parça sayısına tam bölünmediğinde, array_split farkı ilk parçalara dağıtır. np.split ise tam bölünmüyorsa direkt hata verir, dikkat.

Sık karşılaşılan tuzaklar

chunk_size=0 veya negatif değer geçmek: range(0, n, 0) ValueError fırlatır, ama negatifte sessizce boş liste döner. Fonksiyonun başında if boyut < 1: raise ValueError(...) koymak ileride saatlerce debug etmekten kurtarır.
Generator'ı iki kez tüketmeye çalışmak: Generator bir kez biter ve biter. Üzerinden iki kez geçmeniz gerekiyorsa ya list() ile materialize edin ya da itertools.tee kullanın - ama tee de sonuçta belleğe alıyor, sihir yok.
batched çıktısını liste sanmak: Tuple döner. parca.append(...) yazınca AttributeError yer, ekrana bakar 'ne oldu' dersiniz.
Çok küçük parçalarla DB'ye basmak: 50 kayıt için her seferinde yeni bir transaction açıyorsanız, asıl darboğaz parçalama değil, transaction overhead'i. Batch boyutunu 500-5000 arasında tutmak çoğu PostgreSQL/MySQL için tatlı nokta.

Hangisini seçmeli?

Tecrübeyle sabittir ki, %80 vakada list comprehension yeter. Liste devasa veya iterable indekslenemiyorsa generator'a (islice) geçin. Python 3.12 elinizdeyse batched standart kütüphane çözümü olarak en temizi. NumPy zaten projedeyse ve sayısal veriyse array_split doğal seçim.

Kapanış

Kısacası, listeyi parçalara bölmek için tek doğru yöntem yok; durum ne istiyorsa o. Bence aklınızda iki ana eksen olsun: bellek mi sıkışık, yoksa kod sadeliği mi öncelik. İkisinden birini seçince geri kalanı kendiliğinden netleşiyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python SDK ile Azure Blob Storage Yaşam Döngüsü Yönetimi

2026-05-08T00:00:00Z

Merhabalar, bu yazıda Azure Blob Storage'ın yaşam döngüsü yönetimi (lifecycle management) tarafına Python SDK üzerinden bakacağız. Konu kulağa kuru gelebilir ama inanın bana, ay sonu faturasına bakınca insanın yüzünü güldüren tek özelliklerden biri bu. Hadi başlayalım.

Şöyle bir senaryo: bir uygulama log'larını, kullanıcıların yüklediği medya dosyalarını, bir de gece bittikten sonra kimsenin dönüp bakmadığı geçici raporları aynı container'a atıyorsunuz. İlk gün hepsi sıcak (Hot) katmanda, mantıklı. Ama bir ay sonra hâlâ Hot'ta duruyor olmaları hiç mantıklı değil. İşte yaşam döngüsü politikaları tam burada devreye giriyor.

Katmanları kısaca hatırlayalım

Azure'da dört erişim katmanı var ve fiyat farkı ciddi:

Hot: Depolama pahalı, erişim ucuz. Sürekli okuduğunuz veriler için.
Cool: Depolama daha ucuz, erişim biraz daha pahalı. En az 30 gün bekleyecek veriler.
Cold: Daha da ucuz. 90 gün ve üzeri bekleyecekler.
Archive: En ucuz depolama, en pahalı erişim. Geri çağırması saatler sürebilir.

Archive ile Hot arasındaki depolama maliyet farkı kabaca on katı civarında. Ama Archive'dan bir blob'u geri istediğinizde hem para hem zaman ödüyorsunuz; bunu bir kenara not edin, birazdan döneceğiz.

Politikayı SDK ile kurmak

Yaşam döngüsü politikası storage account seviyesinde tanımlanır, container seviyesinde değil. Bu yüzden management SDK kullanıyoruz, blob SDK değil. Önce gerekli paketleri kuruyoruz:

pip install azure-storage-blob azure-mgmt-storage azure-identity

Şimdi bir politika tanımlayalım. Üç farklı prefix için üç farklı kuralımız olsun: logs/ altındakiler kademe kademe arşive gitsin, temp/ altındakiler ertesi gün silinsin, media/ altındakiler bir hafta sonra Cool'a düşsün.

from azure.identity import DefaultAzureCredential
from azure.mgmt.storage import StorageManagementClient
from azure.mgmt.storage.models import (
    ManagementPolicy, ManagementPolicySchema, ManagementPolicyRule,
    ManagementPolicyDefinition, ManagementPolicyFilter,
    ManagementPolicyAction, ManagementPolicyBaseBlob,
    DateAfterModification,
)

credential = DefaultAzureCredential()
client = StorageManagementClient(credential, '<SubId>')

log_rule = ManagementPolicyRule(
    name='log-tiering',
    enabled=True,
    type='Lifecycle',
    definition=ManagementPolicyDefinition(
        filters=ManagementPolicyFilter(
            blob_types=['blockBlob'],
            prefix_match=['logs/'],
        ),
        actions=ManagementPolicyAction(
            base_blob=ManagementPolicyBaseBlob(
                tier_to_cool=DateAfterModification(days_after_modification_greater_than=30),
                tier_to_archive=DateAfterModification(days_after_modification_greater_than=90),
                delete=DateAfterModification(days_after_modification_greater_than=365),
            ),
        ),
    ),
)

policy = ManagementPolicy(policy=ManagementPolicySchema(rules=[log_rule]))

client.management_policies.create_or_update(
    resource_group_name='<RgName>',
    account_name='<AcctName>',
    management_policy_name='default',  # bu isim sabit, 'default' olmak zorunda
    properties=policy,
)

Burada dikkat: management_policy_name her zaman 'default'. Buraya yaratıcı bir isim yazarsanız Azure kabul etmez. Bir de filtreleri prefix bazlı yazıyoruz; yani container içinde mantıklı bir klasör yapısı kurduysanız hayatınız çok kolaylaşır.

Yerleşik politikanın yetmediği yer

Yerleşik politika sadece son değişiklik veya oluşturulma zamanına bakar. Ama bazen son erişim, dosya boyutu ya da metadata'ya göre karar vermek isteriz. Bu durumda blob SDK ile kendi mantığımızı yazıp bir Azure Function ile zamanlamak en temiz çözüm:

from azure.storage.blob import BlobServiceClient
from datetime import datetime, timedelta, timezone

svc = BlobServiceClient(account_url='<Url>', credential=credential)

def cool_down_idle(container, days=30):
    cont = svc.get_container_client(container)
    cutoff = datetime.now(timezone.utc) - timedelta(days=days)
    for blob in cont.list_blobs(include=['metadata']):
        if blob.last_accessed_on and blob.last_accessed_on < cutoff:
            if blob.blob_tier == 'Hot':
                cont.get_blob_client(blob.name).set_standard_blob_tier('Cool')

last_accessed_on özelliği için storage account üzerinde access time tracking'i açmış olmanız gerekiyor; varsayılanda kapalıdır. Açmadan bu kontrolü yazarsanız her blob için None döner ve hiçbir şey hareket etmez.

Sık karşılaşılan tuzaklar

Politikayı kurar kurmaz tetiklenmesini beklemek: Azure politikayı bir kerede koşturmaz, günde bir kez değerlendirir. Test ederken sabırlı olun, dakikalar içinde sonuç beklemeyin.
Archive'a geçirip ertesi gün geri istemek: Hot'a rehydrate etmek hem saatler sürer hem de okuduğunuz veri başına ücretlendirilir. Archive'a sadece gerçekten 'unutulacak' veri gönderin.
Erken silme cezasını unutmak: Cool'da 30, Cold'da 90, Archive'da 180 günden önce silerseniz Azure kalan günlerin maliyetini sizden almaya devam eder. Yaşam döngüsünüzü buna göre kurun.
Snapshot'ları temizlememek: Base blob'u Cool'a çekersiniz ama snapshot'lar Hot'ta kalır. snapshot action'ı da politikaya eklemeyi unutmayın.
Politikayı kurup hiç doğrulamamak: list_blobs ile katman dağılımını periyodik raporlayın. Bence bu olmadan maliyet kazandığınızı gerçekten bilemezsiniz.

Kapanış

Yaşam döngüsü yönetimi Azure'da en hızlı geri dönüş veren optimizasyonlardan biri; bir öğleden sonra ayırıp doğru kurarsanız, ay sonunda farkını net görüyorsunuz. Şahsen ben yerleşik politikayı temel kuralları için, blob SDK'sını da metadata ya da boyut tabanlı özel mantık için kullanmayı tercih ediyorum - ikisi birbirini güzel tamamlıyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

PostgreSQL Array Tipleri ve Sorgular

2026-05-08T00:00:00Z

Selamlar, bu yazımda PostgreSQL'in çoğu zaman göz ardı edilen ama doğru yerde kullanıldığında ekstra tablolardan kurtaran array veri tipine bakacağız. ORM'ler bu tipi nadiren first-class vatandaş olarak gördüğü için biraz unutulmuş bir özellik gibi geliyor; oysa etiket, telefon numarası, kısa permission listesi gibi yerlerde junction table açmaktan çok daha pratik. Hadi başlayalım.

Array nedir, ne zaman tercih edilir?

PostgreSQL'de bir kolon, herhangi bir scalar tipin dizisi (array) olabilir: TEXT[], INTEGER[], hatta çok boyutlu INTEGER[][]. Yani aynı kolonda birden fazla değer tutabiliyorsunuz, ayrıca bunları sorgulayabileceğiniz operatör seti de epey zengin.

Peki her duruma uygun mu? Bence şu basit kontrol işe yarıyor:

Eleman sayısı küçük ve nispeten sabit mi (etiketler, kısa rol listeleri, telefon numaraları)? Array uygun.
Elemanların kendi başına foreign key, ayrı kolonlar veya per-eleman timestamp gibi metadata'sı var mı? Array uygun değil, junction table açın.
İç içe karmaşık yapı mı tutacaksınız? JSONB daha doğru cevap.

Şahsi kanaatim, tags kolonu için array; comments ilişkisi için ayrı tablo. Bu sınır net olduğunda hayat kolaylaşıyor.

Tablo, ekleme, erişim

Hadi minimum bir örnekle bakalım. Bir articles tablosu kuruyoruz:

CREATE TABLE articles (
    id SERIAL PRIMARY KEY,
    title VARCHAR(255) NOT NULL,
    tags TEXT[],                  -- metin dizisi
    ratings INTEGER[],            -- tam sayi dizisi
    published_dates DATE[]
);

Veri eklerken iki yazım var. İlki literal sözdizimi, ikincisi ARRAY constructor; ben okunabilirliği için ikincisini tercih ediyorum:

-- literal yazim
INSERT INTO articles (title, tags, ratings)
VALUES ('PostgreSQL Rehberi', '{postgresql,veritabani,sql}', '{5,4,5}');

-- ARRAY constructor (daha okunakli)
INSERT INTO articles (title, tags, ratings)
VALUES ('Bir Baska Yazi', ARRAY['tech', 'programlama'], ARRAY[4, 3, 5]);

Erişim 1-indexli, buraya dikkat: tags[1] ilk eleman demek. Slice de var, tags[1:2] ilk iki elemanı veriyor. Negatif indeks yok; son elemana ulaşmak için tags[array_length(tags, 1)] yazıyoruz. Biraz çirkin, evet.

Operatörler ve sorgular

İşin asıl gücü buradaki üç operatörde gizli: @> (içerir), <@ (içerilir), && (kesişir). Bir de eski güzel ANY var.

-- 'postgresql' etiketini iceren yazilar
SELECT * FROM articles WHERE tags @> ARRAY['postgresql'];

-- 'postgresql' veya 'mysql' etiketinden herhangi biri varsa
SELECT * FROM articles WHERE tags && ARRAY['postgresql', 'mysql'];

-- her iki etiketi de tasiyorsa
SELECT * FROM articles WHERE tags @> ARRAY['postgresql', 'veritabani'];

-- tek deger kontrolu
SELECT * FROM articles WHERE 'postgresql' = ANY(tags);

Buradaki kritik nokta şu: = ANY(tags) ile tags @> ARRAY['postgresql'] mantıken aynı şeyi yapıyor ama indeks açısından eşit değiller. GIN indeksi @> ve && ile çalışırken, = ANY query planner'a göre bazen indekse uğramayabiliyor. Tecrübem o yönde, planner'a güvenmeyin, EXPLAIN ANALYZE çekin.

Toparlama tarafında da array_agg çok işe yarıyor:

-- aktif kullanicilarin isimlerini tek diziye topla
SELECT array_agg(name ORDER BY created_at DESC)
FROM users WHERE active = true;

-- diziyi satirlara ac
SELECT id, unnest(tags) AS tag FROM articles;

unnest, array sorgularında en sık başvurduğum fonksiyon. Tag bulutu, frekans sayımı, distinct etiket listesi - hepsi bunun üzerine kurulu.

GIN indeksi olmadan olmaz

Birkaç bin satırda her şey hızlı görünür. Yüz binlere çıktığınızda containment sorgusu sequential scan'e döner ve canınız yanar. Çare basit:

CREATE INDEX idx_articles_tags ON articles USING GIN(tags);

Sonra EXPLAIN ANALYZE ile Bitmap Index Scan on idx_articles_tags satırını görmelisiniz. GiST de bir alternatif, daha küçük ama daha yavaş; tag aramaları için ben GIN'i öneririm.

İfade indeksi de bazen lazım oluyor. Mesela 'üçten fazla etiketi olan yazılar' sorgusu için:

CREATE INDEX idx_articles_tag_count ON articles(array_length(tags, 1));

Sık karşılaşılan tuzaklar

Tek elemanı in-place güncellemek: UPDATE articles SET tags[1] = 'yeni' WHERE id = 1 çalışır gibi görünür ama PostgreSQL her durumda tüm array'i yeniden yazar. Bunun yerine array_replace, array_append, array_remove kullanın; niyetiniz daha okunaklı olur.
GIN indeksini unutmak: Containment sorgusu var ve indeks yoksa veri büyüdükçe yavaşlama lineer değil, hissedilir. Tablo 10 bin satıra ulaştığında indeksi atın, sonra atmadığınıza pişman olmayın.
Array'i ilişki yerine kullanmak: Elemanların kendi metadata'sı varsa (oluşturulma tarihi, kim ekledi, ayrı silinebilir mi) array değil, ayrı tablo. 'Az kalsın junction'dan kurtulurum' diye başlayan her hikâye kötü bitiyor.
= ANY ile indeks beklentisi: Çalışıyor ama planner her zaman indekse gitmiyor. Performans hassassa @> tercih edin.
Aşırı büyük array'ler: Bir satırda yüzlerce eleman tutmaya başladığınızda hem TOAST'a düşersiniz hem de update maliyeti patlar. Sınır koyun.

Doğrulama

Lokalde Docker ile bir Postgres ayağa kaldırın, küçük bir tablo doldurun ve EXPLAIN ANALYZE ile gerçekten indeksin devreye girip girmediğine bakın:

docker run -d --name pg-test -e POSTGRES_PASSWORD=test -p 5432:5432 postgres:16
psql -h localhost -U postgres -c "EXPLAIN ANALYZE SELECT * FROM articles WHERE tags @> ARRAY['postgresql'];"

Çıktıda Bitmap Index Scan görüyorsanız işiniz tamam; Seq Scan görüyorsanız ya indeks eksik ya da tablo henüz çok küçük (planner küçük tablolarda zaten sequential tercih eder).

Kapanış

Bu yazıda PostgreSQL array tipinin kullanımına, operatörlerine ve indekslemenin neden hayati olduğuna baktık. Bence array, etiket ve kısa liste senaryolarında junction table'dan çok daha pratik; ama ilişkinin kendi metadata'sı varsa zorlamayın, ayrı tablo açın. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

PostgreSQL Şema Migrasyonlarını Yönetmek

2026-05-08T00:00:00Z

Selamlar, bu yazımda PostgreSQL şema migrasyonlarını biraz toparlayacağız. Konuyu sevdiğim için anlatacağım ama uyarayım: migrasyon, kod kadar kolay konuşulan bir alan değil. Bir tablo silindi, bir sütun tipi değişti derken canlıdaki sorgular bir anda 'relation does not exist' demeye başlıyor. Hadi nasıl bu duvara toslamadan ilerleriz, ona bakalım.

Neden bir araca ihtiyacımız var?

İlk akla gelen soru bu. 'Ben SQL dosyalarımı kendim yönetirim' diyebilirsiniz, ama birkaç geliştiriciyle çalışmaya başlayınca işin rengi değişiyor. Hangi migration ne zaman çalıştı? Staging'de var mı, prod'da var mı? Hangi sıraya göre uygulanmalı? Bu soruların cevabını el ile vermeye çalışmak, bence kısa sürede ekibi tüketir.

Migrasyon araçları aslında basit bir şey yapıyor: veritabanında küçük bir tablo (flyway_schema_history, alembic_version gibi) tutuyor ve hangi script'in uygulandığını oraya yazıyor. Geri kalan her şey bu tablonun üzerine inşa ediliyor.

Üç popüler seçenek

Türk ekiplerinde en sık karşılaştığım üçlü Flyway, Liquibase ve Alembic. Şahsi kanaatim şu: SQL'inizi olduğu gibi yazmak istiyorsanız Flyway, dilden bağımsız bir DSL istiyorsanız Liquibase, Python ekosistemindeyseniz Alembic. Hadi her birine kısaca bakalım.

Flyway

Flyway'in en güzel yanı saf SQL ile çalışabilmesi. Dosya isimlendirmesi V<sürüm>__<açıklama>.sql şeklinde:

-- V1__kullanicilar_tablosu.sql
CREATE TABLE kullanicilar (
    id SERIAL PRIMARY KEY,
    eposta VARCHAR(255) UNIQUE NOT NULL,
    olusturulma TIMESTAMP DEFAULT NOW()
);

-- V2__kullanicilara_isim_ekle.sql
ALTER TABLE kullanicilar ADD COLUMN isim VARCHAR(100);

Çalıştırması da bir o kadar düz:

flyway migrate     # bekleyen migrasyonlari uygula
flyway info        # durum ozeti
flyway repair      # bozulan checksum'lari onar

Alembic

Python ile çalışıyorsanız, özellikle SQLAlchemy modelleriniz varsa Alembic'in --autogenerate özelliği ciddi zaman kazandırır. Modeli değiştiriyorsunuz, Alembic farkı çıkarıp size bir migration dosyası üretiyor:

alembic revision --autogenerate -m "kullanicilar tablosunu olustur"
alembic upgrade head

Üretilen dosya da okunaklı:

# migrations/versions/001_kullanicilar_tablosu.py
from alembic import op
import sqlalchemy as sa


def upgrade():
    # Yeni tabloyu olusturuyoruz
    op.create_table(
        'kullanicilar',
        sa.Column('id', sa.Integer(), primary_key=True),
        sa.Column('eposta', sa.String(255), nullable=False, unique=True),
    )


def downgrade():
    op.drop_table('kullanicilar')

downgrade kısmını ihmal etmeyin; canlıda 'şuna geri dön' demek bazen hayat kurtarıyor.

Sıfır kesintili migrasyon

Bence yazının asıl önemli kısmı burası. Küçük bir tabloda ALTER TABLE neyse de, milyonlarca satırlı bir tabloda yanlış komut size dakikalarca kilit getirir. Birkaç altın kural var.

İlk olarak index'leri her zaman CONCURRENTLY ile oluşturun. Bu, yazma işlemlerini bloklamaz:

CREATE INDEX CONCURRENTLY idx_kullanicilar_eposta
    ON kullanicilar(eposta);

İkincisi, foreign key gibi kısıtları önce NOT VALID ile ekleyip sonra ayrı bir adımda doğrulayın. Böylece tablo taraması kilit tutmadan ilerler:

ALTER TABLE siparisler
    ADD CONSTRAINT fk_kullanici
    FOREIGN KEY (kullanici_id) REFERENCES kullanicilar(id) NOT VALID;

ALTER TABLE siparisler VALIDATE CONSTRAINT fk_kullanici;

Bir sütun tipini değiştirmek istiyorsanız, tek ALTER COLUMN ... TYPE ile gitmek yerine adımları parçalayın: yeni sütunu nullable olarak ekleyin, veriyi parça parça doldurun, sonra NOT NULL koyun, en son eski sütunu düşürün. Uzun gibi görünüyor, ama canlıyı düşürmüyor.

Sık karşılaşılan tuzaklar

ALTER TABLE ... ADD COLUMN ... NOT NULL DEFAULT ... PostgreSQL 10 ve öncesinde tabloyu baştan yazar: Yeni sürümlerde bu çoktan optimize edildi, ama hâlâ eski bir cluster'la çalışıyorsanız ekleyip backfill etmek daha güvenli.
CREATE INDEX (CONCURRENTLY olmadan) yazma kilidi alır: Trafik varken çalıştırırsanız uygulama saniyelerce bekler. Üretimde bunu yapmak istemezsiniz.
Migration dosyasını sonradan düzenlemek: Flyway checksum tutar, dosyayı değiştirirseniz bir sonraki migrate komutu hata verir. Yapacağınız değişikliği yeni bir versiyon olarak ekleyin.
Geri alma planı olmadan deploy: downgrade veya down.sql dosyasını şart koşun. 'Geri dönmeyiz nasılsa' demeyin, bir sefer dönmeniz gerektiğinde pişman olursunuz.
Uzun migrasyonu tek transaction'a sıkıştırmak: Milyonlarca satırlık UPDATE'i tek seferde çalıştırmak hem WAL'ı şişirir hem replica'ları geride bırakır. Batch'lere bölün.

Doğrulama

Migrasyonu canlıya açmadan önce temiz bir Docker container'ında deneyin. Bence bu adımı atlamak en pahalı kestirme:

docker run -d --name test-db -e POSTGRES_PASSWORD=test -p 5433:5432 postgres:16
sleep 5
flyway -url=jdbc:postgresql://localhost:5433/postgres migrate
psql -h localhost -p 5433 -U postgres -c "\dt"
docker rm -f test-db

Aynı script'i CI'a koyduğunuzda her PR'da otomatik koşar; üç dakika sonra 'bu migration sıfırdan açıyor mu?' sorusunun net cevabı elinizde olur.

Kapanış

PostgreSQL şema migrasyonlarını yönetmek aslında bir araç seçimi değil, bir disiplin meselesi. Aracı seçtikten sonra sıfır kesintili kalıpları öğrenmek, geri dönüş planını her zaman hazır tutmak ve değişikliği önce temiz bir veritabanında denemek kalıyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

MySQL'de ADDDATE() ve SUBDATE() ile Tarih Aritmetiği

2026-05-08T00:00:00Z

Selamlar, bu yazımda MySQL'in en sık karşımıza çıkan ama bir o kadar da kafa karıştırabilen iki fonksiyonuna, ADDDATE() ve SUBDATE()'e bakacağız. Tarih aritmetiği görünüşte basit bir konu; ne var ki MySQL'in iki ayrı kullanım şekli sunması, bir de aynı işi yapan DATE_ADD() / DATE_SUB()'ın varlığı, yeni başlayanı haklı olarak duraklatıyor. Hadi kafa karışıklığını dağıtalım.

ADDDATE() ne işe yarar?

ADDDATE() bir tarihe belirli bir süre ekler. İki farklı çağırma biçimi var: ya INTERVAL ifadesiyle ay, hafta, saat gibi birimler verirsiniz, ya da ikinci argümana düz bir tam sayı geçip 'şu kadar gün ekle' dersiniz. İkincisi, yani kısa-yol biçimi, ADDDATE()'in DATE_ADD()'den ayrıldığı tek nokta.

-- Tam INTERVAL söz dizimi (DATE_ADD ile aynı)
ADDDATE(tarih, INTERVAL ifade birim)

-- Kısa-yol: N gün ekle
ADDDATE(tarih, gun_sayisi)

Birkaç örnekle netleştirelim:

-- 10 gun ekle (kisa-yol)
SELECT ADDDATE('2026-05-08', 10);
-- Sonuc: '2026-05-18'

-- 3 ay ekle
SELECT ADDDATE('2026-05-08', INTERVAL 3 MONTH);
-- Sonuc: '2026-08-08'

-- 2 saat 30 dakika ekle
SELECT ADDDATE('2026-05-08 09:00:00', INTERVAL '2:30' HOUR_MINUTE);
-- Sonuc: '2026-05-08 11:30:00'

-- Negatif tam sayi: aslinda cikarma yapar
SELECT ADDDATE('2026-05-08', -7);
-- Sonuc: '2026-05-01'

Son örnek ilginç: ikinci argümana negatif değer verince fonksiyon sessizce çıkarma moduna geçiyor. Bence bu pratik ama kodunuzu okuyan biri için niyetinizi gizleyen bir kullanım; tarih çıkarmak istiyorsanız doğrudan SUBDATE() çağırın, okunurluk artar.

SUBDATE() tarafı

SUBDATE() aynı mantığın ters yüzü. INTERVAL'la her birimi çıkarır, ya da kısa-yol biçiminde gün sayısı alır.

-- 10 gun cikar
SELECT SUBDATE('2026-05-08', 10);
-- Sonuc: '2026-04-28'

-- 1 ay cikar
SELECT SUBDATE('2026-05-08', INTERVAL 1 MONTH);
-- Sonuc: '2026-04-08'

-- Bugunden 90 gun once
SELECT SUBDATE(NOW(), 90);

SUBDATE(NOW(), 90) tarzı kullanımlar raporlama sorgularında çok işinize yarar. Aşağıda buna döneceğiz.

Peki DATE_ADD()'den farkı ne?

Şöyle ki: ADDDATE(tarih, INTERVAL ...) ile DATE_ADD(tarih, INTERVAL ...) birebir aynı şey. Tek fark, ADDDATE()'in tam sayı kısa-yol biçimini de kabul etmesi.

-- Bu ucu de ayni sonucu verir
SELECT ADDDATE('2026-05-08', 5);
SELECT ADDDATE('2026-05-08', INTERVAL 5 DAY);
SELECT DATE_ADD('2026-05-08', INTERVAL 5 DAY);
-- Hepsi: '2026-05-13'

Bana sorarsanız ekipte tek tip kullanım belirleyin: ya hep DATE_ADD / DATE_SUB kullanın (birim her zaman açık görünür), ya da ADDDATE / SUBDATE'e geçin ve gün sayısı söz konusu olduğunda kısa-yolu serbest bırakın. Aynı kod tabanında ikisinin karışması okumayı zorlaştırıyor.

Pratik: son tarih hesabı

Görev tablosunda her satıra ait bir 'kaç gün içinde teslim' alanı varsa, son tarihi anlık hesaplamak için ADDDATE() biçilmiş kaftan:

CREATE TABLE gorevler (
    id INT AUTO_INCREMENT PRIMARY KEY,
    gorev_adi VARCHAR(100),
    olusturma_tarihi DATE,
    sure_gun INT
);

INSERT INTO gorevler (gorev_adi, olusturma_tarihi, sure_gun) VALUES
('Rapor yaz',         '2026-05-08', 7),
('Kod incele',        '2026-05-08', 3),
('Prod yayina al',    '2026-05-08', 14);

SELECT
    gorev_adi,
    olusturma_tarihi,
    ADDDATE(olusturma_tarihi, sure_gun) AS son_tarih
FROM gorevler;

Burada ikinci argüman hard-coded değil, doğrudan kolondan geliyor. Bu, kısa-yol biçiminin gerçekten kazandığı yer; INTERVAL ile aynısını yapmak için dinamik SQL'e gerek duyardınız.

Raporlama pencereleri

Son N gün, önümüzdeki N gün gibi pencereler hemen her dashboard sorgusunda var:

-- Son 30 gun siparis
SELECT * FROM siparisler
WHERE siparis_tarihi >= SUBDATE(CURDATE(), 30);

-- Onumuzdeki 7 gun randevu
SELECT * FROM randevular
WHERE randevu_tarihi BETWEEN CURDATE() AND ADDDATE(CURDATE(), 7);

Diğer tarih fonksiyonlarıyla da güzel bestelenir; mesela 'üç ay sonraki ayın son günü' tek satırda çıkar:

SELECT LAST_DAY(ADDDATE(CURDATE(), INTERVAL 3 MONTH)) AS gelecek_ay_sonu;

Sık karşılaşılan tuzaklar

Negatif tam sayıyla ADDDATE() kullanmak: Çalışır ama okuyucuyu yanıltır. Niyetiniz çıkarmaksa SUBDATE() yazın.
NULL beklemediğiniz yerden gelir: ADDDATE(NULL, 10) ya da ADDDATE(tarih, NULL) her zaman NULL döner. Kolondan gelen değerler için COALESCE ile bir varsayılan koymak çoğu zaman iyi fikir.
Ay sonu sürprizleri: ADDDATE('2026-01-31', INTERVAL 1 MONTH) size 2026-02-28 verir. MySQL ay sonunu otomatik kırpar; bu davranışın farkında olmak iş kuralınızla uyumsuzluğa düşmenizi engeller.
Index'siz tarih aritmetiği: WHERE ADDDATE(kolon, 30) > NOW() yazarsanız index kullanılmaz. Aritmetiği sabit tarafa taşıyın: WHERE kolon > SUBDATE(NOW(), 30). Klasik tuzak ama hâlâ sıkça gördüğüm bir şey.

Kapanış

ADDDATE() ve SUBDATE(), MySQL tarih aritmetiğinin günlük araçları; INTERVAL ile esnek, tam sayı kısa-yoluyla pratik. Şahsi kanaatim, ekip içinde tek bir biçim seçip ona sadık kalmak en büyük kazancı veriyor; ondan sonra fonksiyonlar sessizce işini görüyor zaten. Umarım faydalı olur, görüşmek üzere.

MySQL CONCAT_WS() ile NULL'a Takılmayan Birleştirme

2026-05-08T00:00:00Z

Selamlar, bu yazımda MySQL'in görece sessiz kalan ama bir kez alıştığınızda elinizden düşmeyecek fonksiyonlarından biri olan CONCAT_WS()'e bakacağız. Bilhassa nullable kolonlardan ad-soyad ya da adres üreten herkesin başına gelmiştir: CONCAT() ile string birleştiriyorsunuz, ortadaki bir kolon NULL çıkıyor ve sonuç bir anda komple NULL oluyor. Hadi CONCAT_WS() bu kâbusu nasıl bitiriyor, bakalım.

CONCAT_WS() nedir?

İsmindeki WS, 'with separator' kısaltması; yani 'ayraçlı birleştir'. Fonksiyon iki ya da daha fazla string'i, ilk argüman olarak verdiğiniz ayraçla bir araya getiriyor. Asıl can alıcı özelliği ise şu: argümanlardan biri NULL ise onu sessizce atlar, geriye düzgün bir sonuç döndürür.

İmzası şöyle:

CONCAT_WS(ayrac, str1, str2, str3, ...)

Üç kuralı baştan aklınızda tutun: ayraç zorunlu, ayraç NULL olursa sonuç NULL döner ve gerisindeki NULL argümanlar atlanırken yerlerinde çift ayraç bırakmazlar. Son madde aslında en kıymetlisi - üreteceğiniz string'in cımbızla temizlenmesine gerek kalmıyor.

Temel kullanım

Üç hızlı örnekle ısınalım:

SELECT CONCAT_WS(', ', 'Ayşe', 'Yılmaz', 'İstanbul');
-- Sonuc: 'Ayşe, Yılmaz, İstanbul'

SELECT CONCAT_WS('-', '2026', '05', '08');
-- Sonuc: '2026-05-08'

SELECT CONCAT_WS(' | ', 'MySQL', '8.0', 'String Fonksiyonlari');
-- Sonuc: 'MySQL | 8.0 | String Fonksiyonlari'

Görüyorsunuz, ayraç tek karakter olmak zorunda değil; çok karakterli ayraç da çalışıyor. Bu sayede kayıt sınırlayıcı yerine ' - ' gibi okunabilir ayraçlar koyabiliyorsunuz.

CONCAT()'tan farkı: NULL muamelesi

İşin can damarı burası. Aynı veriyi iki fonksiyona verelim:

-- CONCAT() bir argüman bile NULL'sa sonucu NULL yapar
SELECT CONCAT('Ayşe', NULL, 'Yılmaz');
-- Sonuc: NULL

-- CONCAT_WS() NULL argümanı görmemiş gibi geçer
SELECT CONCAT_WS(' ', 'Ayşe', NULL, 'Yılmaz');
-- Sonuc: 'Ayşe Yılmaz'

Şahsi kanaatim, kolonun nullable olduğu her senaryoda CONCAT() kullanmak başınıza iş açar. COALESCE(col, '') ile bunu manuel çözmeye çalışırsanız bu sefer ortada boş ayraçlar belirir. CONCAT_WS() ikisini de tek hamlede halleder.

Nullable kolonlardan tam ad üretmek

Klasik senaryo: ikinci adı opsiyonel olan bir kişi tablosu. Hadi gerçek veriyle bakalım:

CREATE TABLE kisiler (
    kisi_id     INT PRIMARY KEY,
    ad          VARCHAR(50),
    ikinci_ad   VARCHAR(50),
    soyad       VARCHAR(50)
);

INSERT INTO kisiler VALUES
(1, 'Ayşe',  'Nur',   'Yılmaz'),
(2, 'Mehmet', NULL,   'Demir'),
(3, 'Zeynep', 'Su',    NULL);

SELECT
    kisi_id,
    CONCAT_WS(' ', ad, ikinci_ad, soyad) AS tam_ad
FROM kisiler;

Sonuç:

kisi_id	tam_ad
1	Ayşe Nur Yılmaz
2	Mehmet Demir
3	Zeynep Su

İkinci satırda 'Mehmet Demir' gibi çift boşluklu bir çıktı yok; üçüncü satırda da sondan sarkan bir boşluk yok. Çünkü NULL argüman tamamen atlanıyor, yerine ayraç eklenmiyor.

Adresleri ve etiketli string'leri kurmak

Adres kolonları neredeyse her zaman kısmen NULL'dur. CONCAT_WS() burada da bir nimet:

SELECT
    CONCAT_WS(', ', sokak, mahalle, ilce, sehir, posta_kodu) AS tam_adres
FROM adresler;

Eksik kolon hangisi olursa olsun, çıktı temiz kalır. Aynı mantığı raporlama için de kullanabilirsiniz:

SELECT
    calisan_id,
    CONCAT_WS(' - ', isim, COALESCE(departman, 'Atanmamis'), CONCAT('₺', FORMAT(maas, 0))) AS etiket
FROM calisanlar;
-- Ornek: 'Ayşe Yılmaz - Mühendislik - ₺85,000'

Burada COALESCE'i bilinçli olarak kullandım: departmanın NULL olmasını atlamak değil, 'Atanmamis' yazmak istiyorum. CONCAT_WS()'in NULL davranışı her zaman aradığınız şey olmayabilir, ikisini birlikte kullanmak şart.

Sık karşılaşılan tuzaklar

Ayracın kendisinin NULL olması: SELECT CONCAT_WS(NULL, 'a', 'b'); çağrısı NULL döner. Eğer ayracı bir alt sorgudan ya da değişkenden alıyorsanız, IFNULL(ayrac, ',') ile garanti altına almakta fayda var.
Boş string ile NULL'u karıştırmak: '' (boş string) NULL değildir; CONCAT_WS() bunu atlamaz, normal değer gibi araya ekler ve çift ayraç oluşur. Boş string'leri de atlamak istiyorsanız NULLIF(col, '') ile önce NULL'a çevirin.
Sayısal kolonlarda otomatik dönüşüm: Sayısal kolonlar string'e cast edilir, sorun yok; ama bilhassa DECIMAL kolonlarda biçim beklediğiniz gibi gelmeyebilir. FORMAT() ile önden biçimlendirmek sağlıklı.
GROUP_CONCAT() ile karıştırmak: CONCAT_WS() aynı satırdaki kolonları birleştirir; birden fazla satırı tek string'e toplamak için GROUP_CONCAT() lazım. İkisi farklı işlerdir.

Kapanış

CONCAT_WS() kâğıt üstünde küçük bir fonksiyon ama nullable kolonlarla çalışırken CONCAT() + IFNULL() kombinasyonunun sıkıntısını tamamen ortadan kaldırıyor. Bana sorarsanız, ad-soyad veya adres benzeri her birleştirmede varsayılanınız CONCAT_WS() olsun; ihtiyacınız değişirse CONCAT()'a düşersiniz, tersi acı verici. Bir sonraki yazıda görüşmek üzere.

Python Sözlüklerinde Anahtar Var mı Kontrolü

2026-05-08T00:00:00Z

Selamlar, bu yazıda Python'da küçük ama sürekli karşımıza çıkan bir konuya bakacağız: bir sözlükte (dict) belli bir anahtarın olup olmadığını nasıl kontrol ederiz? Soru basit görünüyor ama bir-iki tane tuzağı var; özellikle değerin None olduğu durumlarda. Lafı çok uzatmadan başlayayım.

En Pythonic yol: `in` operatörü

Bir sözlükte anahtarın var olup olmadığını öğrenmenin en okunaklı yolu in operatörü. Eski bir alışkanlıkla has_key gibi bir şey aramayın; o Python 2'de kalmış bir metot, artık yok.

user = {'name': 'Ada', 'age': 30}

if 'name' in user:
    print('isim var')

if 'email' not in user:
    print('email yok')

Burada dikkat: 'name' in user ifadesi sözlüğün anahtarlarına bakar, değerlerine değil. in user.keys() yazmaya gerek yok; doğrudan in user aynı işi yapıyor ve aslında biraz daha hızlı çalışıyor çünkü ekstra bir dict_keys view'ı oluşturmuyoruz.

`dict.get` ile tek hamlede değer ve kontrol

Anahtarın varlığını test ettikten sonra büyük ihtimalle değerini de okuyacağız. O zaman iki kez sözlüğe bakmak yerine get metodu işimizi tek seferde halleder. Anahtar yoksa varsayılan olarak None döner; istersen kendi varsayılanını da verebilirsin.

config = {'host': 'localhost', 'port': 5432}

host = config.get('host')           # 'localhost'
timeout = config.get('timeout', 30) # 30 (varsayılan)

Burada bir tuzak var: değerin kendisi None ise get ile gerçekten eksik anahtarı ayırt edemezsiniz.

data = {'optional': None}

print(data.get('optional'))  # None
print(data.get('missing'))   # None

İkisi de None döndü. Bu ayrımı yapmamız gerekiyorsa in operatörüne geri dönüyoruz; o sözlükte None değerli bir anahtar varsa bile True döner.

`setdefault` ile yoksa ekle

Bazen sadece kontrol etmek değil, yoksa ekleyip varsa olanı kullanmak istiyoruz. Klasik kullanım yeri: gruplama (group-by). Mesela bir liste içindeki kelimeleri ilk harflerine göre gruplayalım.

words = ['Ada', 'Ali', 'Bora', 'Burak', 'Can']
groups = {}

for w in words:
    groups.setdefault(w[0], []).append(w)

# groups -> {'A': ['Ada', 'Ali'], 'B': ['Bora', 'Burak'], 'C': ['Can']}

setdefault anahtar yoksa onu boş bir liste ile ekliyor ve o listeyi geri döndürüyor; varsa zaten olan listeyi döndürüyor. Tabii bu işin daha temiz hali collections.defaultdict ama tek seferlik küçük gruplamalar için setdefault yeter.

EAFP stili: try/except KeyError

Python topluluğunda 'önce iznini al' (LBYL) yerine 'önce dene, hata olursa yakala' (EAFP) yaklaşımı yaygındır. Anahtarın çoğu zaman var olduğunu bekliyorsanız bu stil hem daha hızlı hem de daha doğal.

try:
    score = scores['ada']
except KeyError:
    score = 0

Bence bu yaklaşımı her yerde kullanmaya gerek yok; özellikle anahtarın yarı yarıya eksik olduğu durumlarda get daha okunaklı. Ama performans kritik bir döngüde, anahtar çoğu zaman doluyorsa, try/except sürekli if kontrolünden hızlı çıkıyor.

Birden fazla anahtarı tek seferde kontrol

Bir sözlükte birkaç anahtarın hepsinin var olup olmadığını kontrol etmek için tek tek in yazmak gerekmiyor. Set işlemleri imdada yetişiyor.

payload = {'id': 1, 'name': 'Ada', 'email': 'ada@example.com'}
required = {'id', 'name'}

if required <= payload.keys():
    print('zorunlu alanlar tamam')

eksikler = required - payload.keys()
print(eksikler)  # set()

<= burada 'alt küme' demek. dict.keys() zaten küme benzeri bir view döndürdüğü için doğrudan küme operatörlerini uygulayabiliyoruz. Eksikleri görmek için fark almak da çok pratik.

İç içe sözlüklerde güvenli erişim

API cevaplarında genelde iç içe sözlükler oluyor ve her seviyede in kontrolü yapmak yorucu. Küçük bir yardımcı fonksiyon işi kolaylaştırıyor:

def get_nested(data, *keys, default=None):
    cur = data
    for k in keys:
        if not isinstance(cur, dict) or k not in cur:
            return default
        cur = cur[k]
    return cur

resp = {'user': {'profile': {'name': 'Ada'}}}
print(get_nested(resp, 'user', 'profile', 'name'))     # 'Ada'
print(get_nested(resp, 'user', 'address', 'city', default='-'))  # '-'

Kapanış

Özetle: var-yok kontrolü için in, değer de lazımsa get, yoksa ekle istiyorsan setdefault, çoğu zaman dolu olduğunu biliyorsan try/except. Bana sorarsanız kodun çoğunda in ile get ikilisi yetiyor; diğerleri ise doğru senaryoda kullanıldığında kodu kısaltıyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Azure Spring Apps Üzerinde Dağıtık İzleme Kurmak

2026-05-08T00:00:00Z

Merhabalar, bu yazımda Azure Spring Apps üzerinde çalışan mikroservislerimize Application Insights ile dağıtık izleme (distributed tracing) nasıl bağlanır, ona bakacağız. Konu basit görünür ama 'checkout sayfası yavaş' raporu masaya geldiğinde tek tek loglara bakmakla işin içinden çıkamadığımı tecrübeyle söyleyebilirim. Hadi başlayalım.

Tipik bir akış şöyle: kullanıcı butona basıyor, istek API gateway'e geliyor, oradan order servisine, order payment'a, payment inventory'ye uzanıyor. Yavaşlık varsa kim suçlu? İşte trace context bunu söyleyen şey; her servisin loguna 'aynı isteğin parçasıyım' diyebilen bir kimlik koyuyor.

Application Insights nedir, neden Spring Apps ile?

Application Insights, Azure'ın APM (application performance monitoring) servisi. Java agent'ı sayesinde Spring Boot tarafında neredeyse hiç kod yazmadan SpringMVC çağrılarını, JDBC sorgularını, dış HTTP isteklerini ve log satırlarını otomatik enstrümante ediyor. Spring Apps tarafında ise platform-level bir entegrasyon var; uygulamayı yeniden paketlemenize gerek kalmadan agent'ı binding olarak ekliyor.

Bana sorarsanız buradaki en büyük kazanç, OpenTelemetry standardına oturmuş olması. Yarın provider'ı değiştirmek istesek, custom span'ları yeniden yazmıyoruz; sadece exporter değişiyor.

Resource'u oluşturup Spring Apps'e bağlamak

Önce bir Application Insights component'i açalım. --kind java demeyi unutmayın; portaldaki Java-spesifik panellerin gözükmesi buna bağlı:

az monitor app-insights component create \
  --app orders-insights \
  --location westeurope \
  --resource-group orders-rg \
  --kind java

az spring app-insights update \
  --name orders-spring \
  --resource-group orders-rg \
  --app-insights orders-insights \
  --sampling-rate 50

Sampling-rate konusunda küçük bir not: development'ta 100 mantıklı, her şeyi görmek istiyoruz. Production'da ise 25-50 arası bir değer hem maliyeti dizginliyor hem de istatistiksel olarak yeterli görünürlük sağlıyor. Şahsi tercihim, trafik düşük servisler için 100, yüksek olanlar için 25.

Logları trace ile korelasyonlamak

Burası çok atlanan bir nokta. Agent trace'i topluyor, logları topluyor, ama logback pattern'inize traceId ve spanId'yi koymadıysanız Kibana benzeri bir log aramasında trace'e geri dönemiyorsunuz. application.yml içinde:

logging:
  pattern:
    console: '%d{HH:mm:ss.SSS} [%thread] %-5level [traceId=%X{traceId} spanId=%X{spanId}] %logger{36} - %msg%n'

management:
  tracing:
    sampling:
      probability: 1.0

Bu kadarı bile End-to-End Transaction Details ekranında log satırını ilgili span'in altında görmek için yeterli.

Business operasyonları için custom span

Auto-instrumentation framework çağrılarını yakalar ama 'sipariş oluşturma' gibi domain operasyonlarınızı bilmez. Onları kendiniz isimlendirmelisiniz:

Span span = tracer.spanBuilder('createOrder')
    .setAttribute('order.customerId', customerId)
    .setAttribute('order.itemCount', items.size())
    .startSpan();

try (Scope scope = span.makeCurrent()) {
    return orderService.create(customerId, items);
} catch (Exception ex) {
    span.recordException(ex);
    span.setStatus(StatusCode.ERROR);
    throw ex;
} finally {
    span.end();
}

try/finally zorunlu; aksi halde exception yolunda span hiç kapanmaz ve Application Map'te uçuşan bir 'in-flight' kalır. Bunu ben de ilk başlarda iki üç kez unuttum.

Portalda ne göreceğiz?

Application Map size servis topolojisini çıkarıyor; ok kalınlıkları çağrı hacmini, kırmızılar hata oranını gösteriyor. Transaction Search zamana göre arama yapıyor. End-to-End Transaction Details ise bir isteğin waterfall görünümü; kim ne kadar bekletti, net olarak ortada. KQL ile de kendi sorgunuzu yazabilirsiniz, mesela en yavaş 20 endpoint:

requests
| where timestamp > ago(1h)
| top 20 by duration desc
| project name, duration, resultCode, operation_Id

Bağımlılıkların 95'inci yüzdelik gecikmesi:

dependencies
| where timestamp > ago(1d)
| summarize p95=percentile(duration, 95) by name
| order by p95 desc

Sık karşılaşılan tuzaklar

Connection string set edilmedi: Spring Apps binding'i yapılmamışsa agent telemetri gönderecek bir hedef bulamaz, sessiz sessiz dropluyor. Önce az spring app-insights show ile doğrulayın.
W3C trace context propagasyonu kopuk: Servislerden biri eski B3 header'ı kullanıyorsa trace iki parçaya bölünüyor. OpenTelemetry default'u W3C; tüm servislerin aynı standardı konuştuğundan emin olun.
Sampling-rate'i unutmak: Default genellikle düşük geliyor. Yeni resource'ta beklediğiniz trafiği göremezseniz ilk bakacağınız yer bu.
Custom span'i try/finally olmadan açmak: Exception olduğunda span kapanmaz, metric'ler çarpık çıkar.

Kapanış

Bu yazıda Azure Spring Apps üzerinde Application Insights ile dağıtık izlemenin temel kurulumunu, log korelasyonunu ve custom span üretimini gördük. Bence dağıtık izlemenin asıl değeri ilk incident'ta ortaya çıkıyor; o yüzden 'sonra kurarız' demek yerine projenin ilk haftasında devreye almak gerçekten zaman kazandırıyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python ve SQL

Azure SQL Database Serverless ile Maliyet Azaltma

Serverless Tier Nedir?#

Ne Zaman Kazandırır, Ne Zaman Kaybettirir?#

CLI ile Kurulum#

Uyanma Gecikmesi - En Sık Karşılaşılan Tuzak#

Sık Karşılaşılan Hatalar#

Kapanış#

MySQL'de Tablo Kilit Çakışmalarını İzlemek

Önce semptomu doğru okuyalım#

Global sayaçlara hızlı bakış#

Suçlu tabloyu bulmak#

Anlık çatışmayı yakalamak#

Sık karşılaşılan tuzaklar#

Kapanış#

OAuth2 Server Error'larını Çözmek

Server Error neye benziyor?#

Yeniden deneme stratejisi: üstel backoff#

Circuit breaker: dur dediğinde dur#

Sık karşılaşılan hatalar#

Kapanış#

Terraform Backend'ini Veri Kaybetmeden Geçirmek

Geçişten önce yapılması gerekenler#

Local'den S3'e#

S3'ten Terraform Cloud'a#

Cross-cloud: S3'ten GCS'e#

İşler ters giderse#

State hiçbir backend'de yok#

State iki backend'de birden var#

Lock takılı kaldı#

Sık karşılaşılan tuzaklar#

Doğrulama#

Kapanış#

AWS'te Talos Linux için Hazır AMI'leri Kullanmak

Talos AMI'leri kim yayınlıyor?#

Doğru AMI'yi bulmak#

Hangi varyant?#

Instance'ları başlatmak#

Cluster'ı bootstrap etmek#

Sık karşılaşılan tuzaklar#

Sürüm güncellemesi#

Kapanış#

GPU Üzerinde TensorFlow Serving'i Flux CD ile Dağıtmak

Ön hazırlık#

Namespace ve model config#

GPU'lu deployment#

Flux Kustomization#

Doğrulama#

Sık karşılaşılan tuzaklar#

Kapanış#

Python sınıflarında __slots__ ile bellek tasarrufu

Sınıflarda Bellek Kullanımı#

slots Kullanımı#

Bellek Kazancı#

Sonuç#

uv ile hızlı Python paket yönetimi

uv Nedir?#

uv’nin Avantajları#

Temel Kullanım#

Proje Yönetimi#

Sonuç#

MySQL'de CREATE TABLE AS SELECT ile Hızlı Tablo Üretmek

CTAS nedir, ne işe yarar?#

En basit hâli#

Hesaplanmış sütunlar ve takma adlar#

Boş bir tablo, sadece yapısı için#

CTAS mı, LIKE mı?#

Sık karşılaşılan tuzaklar#

Kapanış#

MySQL MEDIUMBLOB ile İkili Veri Saklamak

MEDIUMBLOB nedir?#

Tablo tasarımı#

Veri ekleme ve okuma#

max_allowed_packet ayarı#

Sık karşılaşılan hatalar#

Ne zaman MEDIUMBLOB, ne zaman dış depolama?#

Kapanış#

mysqlimport ile Toplu CSV Yüklemek

mysqlimport nedir?#

Temel kullanım#

Serverless Tier Nedir?

Ne Zaman Kazandırır, Ne Zaman Kaybettirir?

CLI ile Kurulum

Uyanma Gecikmesi - En Sık Karşılaşılan Tuzak

Sık Karşılaşılan Hatalar

Kapanış

Önce semptomu doğru okuyalım

Global sayaçlara hızlı bakış

Suçlu tabloyu bulmak

Anlık çatışmayı yakalamak

Sık karşılaşılan tuzaklar

Kapanış

Server Error neye benziyor?

Yeniden deneme stratejisi: üstel backoff

Circuit breaker: dur dediğinde dur

Sık karşılaşılan hatalar

Kapanış

Geçişten önce yapılması gerekenler

Local'den S3'e

S3'ten Terraform Cloud'a

Cross-cloud: S3'ten GCS'e

İşler ters giderse

State hiçbir backend'de yok

State iki backend'de birden var

Lock takılı kaldı

Sık karşılaşılan tuzaklar

Doğrulama

Kapanış

Talos AMI'leri kim yayınlıyor?

Doğru AMI'yi bulmak

Hangi varyant?

Instance'ları başlatmak

Cluster'ı bootstrap etmek

Sık karşılaşılan tuzaklar

Sürüm güncellemesi

Kapanış

Ön hazırlık

Namespace ve model config

GPU'lu deployment

Flux Kustomization

Doğrulama

Sık karşılaşılan tuzaklar

Kapanış

Python sınıflarında slots ile bellek tasarrufu

Sınıflarda Bellek Kullanımı

slots Kullanımı

Bellek Kazancı

Sonuç

uv Nedir?

uv’nin Avantajları

Temel Kullanım

Proje Yönetimi

Sonuç

CTAS nedir, ne işe yarar?

En basit hâli

Hesaplanmış sütunlar ve takma adlar

Boş bir tablo, sadece yapısı için

CTAS mı, LIKE mı?

Sık karşılaşılan tuzaklar

Kapanış

MEDIUMBLOB nedir?

Tablo tasarımı

Veri ekleme ve okuma

max_allowed_packet ayarı

Sık karşılaşılan hatalar

Ne zaman MEDIUMBLOB, ne zaman dış depolama?

Kapanış

mysqlimport nedir?

Temel kullanım

Ayraç ve tırnak ayarları

Başlık satırı, sütun sırası ve çakışmalar

Paralel yükleme ve LOAD DATA karşılığı

Sık karşılaşılan tuzaklar

Kapanış

Bağlantı için iki yol var

IAM ve servis hesabı

Uygulama tarafı

Private IP isteyenler için kısa not

Sık karşılaşılan tuzaklar

Kapanış