AFAD ham verisini kendi sunucumda arşivlerken öğrendiklerim

AFAD’ın event web servisini 2023’ten beri kendi makinemde günlük çekiyorum. Şu an arşivde yaklaşık 190 bin kayıt var; 2010 öncesi kayıtların büyük kısmı boş alanlarla geliyor. Asıl mesele depremi görmek değil, aynı kaydı iki kez saymamak ve şema değiştiğinde haberim olması.

Çekmeyi iki adımda yapıyorum. Önce günü tarih aralığıyla isteyip JSON’u diske yazıyorum, sonra ayrı bir betikle SQLite’a aktarıyorum. Böylece servis bozuk dönerse ham dosya elimde kalıyor.

curl -sS --max-time 90 \
  "https://deprem.afad.gov.tr/apiv2/event/filter?start=$(date -d yesterday +%F)&end=$(date +%F)&limit=2000" \
  -o "raw/afad-$(date +%F).json"

Aktarımda birincil anahtar olarak eventID kullanıyorum, INSERT OR IGNORE ile tekrarı kesiyorum. Sayısal alanları REAL’a çevirirken boş string gelenleri NULL yapıyorum; yoksa CAST('' AS REAL) sessizce 0 üretiyor ve haritada Ekvator üzerinde sahte noktalar çıkıyor. Bu benim ilk ayımda fark ettiğim hataydı, 40 kadar kayıt yanlış yerde duruyordu.

Neden bu kadar uğraşıyorum: servis her istekte son 24 saatin tamamını vermiyor, pencere kayıyor. Günlük çekim yapmazsam aradaki küçük olaylar (M2’nin altı) sessizce kayboluyor. Ayrıca derinlik ve büyüklük alanları revize edilebiliyor; aynı eventID’nin büyüklüğü sonradan değişebilir. Bu yüzden updated_at benzeri bir alan yoksa yalnızca ilk gördüğümü tutuyorum, revizyonu kaçırdığımı biliyorum. Bu bilinçli bir taviz: tam doğruluk yerine hızlı ve ucuz bir arşiv.

Nerede çöküyor: limit parametresi büyük olduğunda yanıt gecikiyor ve zaman aşımına düşüyor; 2000’i geçmemek gerekiyor. Tatil günlerinde ya da büyük bir olaydan sonra servis yavaşlıyor, cron işi üst üste binince aynı dosyayı iki kez yazıyor; bunu flock ile kestim. Bir de tarih dilimi meselesi var: date UTC ise gece yarısı civarı kayıtlar bir önceki dosyaya düşüyor, raporda gün sınırı kayıyor.

Sizin arşivleme tarafında eventID dışında hangi alanı anahtar olarak kullanıyorsunuz, revizyonları yakalamak için bir yönteminiz var mı?