
Bir tabloyu dönüştürmeniz, bir sistemden diğerine veri taşımanız veya toplu bir güncelleme yapmanız gerekiyor. Tek bir sorguyla denediniz — sunucu kilitlendi, işlem yarıda kaldı ve site erişilemez oldu.
Bu yazı, büyük ölçekli veri işlemlerini güvenle yapmayı ele alıyor.
Tek Seferde Neden Olmaz?
Milyonlarca kaydı tek işlemde işlemenin sorunları:
- Bellek tükenir. Tüm sonuç kümesi belleğe alınır.
- İşlem günlüğü şişer. Geri alma bilgisi tutulur.
- Tablo kilitlenir. Diğer sorgular bekler.
- Süre limitine takılır.
- Çökerse baştan başlar.
İkinci madde en az bilinen ve en tehlikeli olanıdır: tek bir işlemde milyonlarca satır güncellemek, veritabanının geri alma günlüğünü diski dolduracak kadar büyütebilir.
Bu durumda yalnızca işleminiz değil, tüm veritabanı durur. Ve işlem geri alınırken de aynı süre kadar beklemek gerekir.
Beşinci madde ise zaman kaybıdır. Dokuz saat süren bir işlem son dakikada çökerse, hiçbir ilerleme korunmaz.
Parçalara Bölmek
Temel çözüm işi küçük gruplara ayırmaktır:
- Belirli sayıda kayıt işleyin. Bin veya birkaç bin.
- Her partiyi ayrı işlem olarak tamamlayın.
- İlerlemeyi kaydedin.
- Aralarda kısa bekleme koyun.
- Devam edilebilir yapın.
Dördüncü madde sıkça atlanır ama sistemi ayakta tutar: partiler arasına kısa bir bekleme koymak, veritabanının diğer sorguları işlemesine ve kendini toparlamasına fırsat verir.
Beklemesiz bir döngü, teknik olarak parçalı çalışsa bile veritabanını sürekli doyurur ve kullanıcı deneyimi bozulur.
Doğru Sayfalama
Partileri seçme yöntemi performansı belirler:
| Yöntem | Sorun |
|---|---|
| Atlama ile sayfalama | Derinleştikçe yavaşlar |
| Kimlik aralığına göre | Hızlı ve sabit |
| Son işlenen kimlikten devam | En verimli |
Birinci satır klasik hatadır: atlanacak kayıtlar da okunmak zorunda olduğu için, milyonuncu partiyi almak milyonlarca kaydı taramak demektir.
İşlem ilerledikçe her parti bir öncekinden yavaş olur ve süre katlanarak artar.
Üçüncü satır bu sorunu tamamen ortadan kaldırır. Son işlenen kimlikten büyük olanları almak, indeks üzerinde doğrudan konumlanmayı sağlar ve her parti aynı hızda alınır.
İşlem Sırasında Değişen Veri
Uzun süren aktarımlarda kaynak veri değişmeye devam eder:
- Yeni kayıtlar eklenir. Aktarım kapsamı belirsizleşir.
- Mevcut kayıtlar güncellenir. Eski değer aktarılmış olur.
- Kayıtlar silinir. Aktarılan kayıt artık yok.
Bu sorunun çözümü bir kesme noktası belirlemektir: aktarımı başlattığınız andaki en yüksek kimliği not edip yalnızca ona kadar olan kayıtları işlemek, hedefi sabitler.
Sonrasında eklenen kayıtlar ikinci bir geçişte veya sürekli senkronizasyonla ele alınır.
İkinci madde için ise değişiklik zamanı sütunu kullanılabilir. Aktarım bittikten sonra, aktarım süresince güncellenmiş kayıtlar ikinci bir turda düzeltilir.
Doğrulama
Aktarım bittiğinde tamamlandığını varsaymak yetmez:
- Kaynak ve hedef kayıt sayısını karşılaştırın.
- Rastgele örnekler seçip içerik karşılaştırın.
- Toplam değerleri kontrol edin. Tutar toplamı gibi.
- Uç değerleri kontrol edin. En eski, en yeni.
- Boş kalan alanları arayın.
Üçüncü madde en güçlü doğrulamadır: sayısal bir sütunun toplamının iki tarafta eşit olması, kayıt sayısının eşitliğinden çok daha güçlü bir kanıttır — hem eksik hem hatalı dönüşümü yakalar.
Yalnızca sayı karşılaştırmak, aynı sayıda ama yanlış içerikli kayıtları göremez.
Geri Dönüş Planı
Aktarım yanlış giderse ne yapılacağı önceden belirlenmelidir:
| Yaklaşım | Uygunluk |
|---|---|
| Kaynağı silmeden bırakmak | En güvenli, ek alan gerekir |
| Yedekten dönmek | Aradaki veri kaybolur |
| Ters dönüşüm yazmak | Her zaman mümkün değil |
| Yeni sütuna yazmak | Eski değer korunur |
Dördüncü satır en pratik güvenlik ağıdır: mevcut sütunun üzerine yazmak yerine yeni bir sütuna yazmak, hatalı dönüşümde eski değeri elinizde tutar.
Eski sütun, dönüşümün doğruluğu doğrulandıktan haftalar sonra silinir. Bu, geri dönüşü tek bir sorguya indirger.
Ne Zaman Çalıştırmalı?
Büyük aktarımların zamanlaması önemlidir:
- Düşük trafik saatlerini seçin.
- Yedekleme ile çakıştırmayın.
- Diğer bakım işleriyle üst üste binmesin.
- Tahmini süreyi önceden ölçün.
- Durdurulabilir olsun.
Dördüncü madde planlama için gereklidir ve kolayca yapılır: küçük bir örneklem üzerinde çalıştırıp süreyi ölçmek, toplam sürenin makul bir tahminini verir.
Bin kayıt on saniye sürüyorsa, bir milyon kayıt yaklaşık üç saat sürecektir. Bu tahmin, bakım penceresi planlamak için yeterlidir.
Beşinci madde ise kontrol sağlar. İşlem beklenenden uzun sürerse veya sorun çıkarsa, güvenle durdurulup daha sonra devam edilebilmelidir.
Kaynak Kullanımını Sınırlamak
Aktarımın üretimi etkilememesi için:
- Süreç önceliğini düşürün. İşlemci ve disk.
- Parti boyutunu ayarlanabilir yapın.
- Yük arttığında yavaşlayın.
- Okuma kopyasından okuyun. Mümkünse.
Üçüncü madde uyarlanabilir bir davranış sağlar: veritabanı yanıt süresi yükseldiğinde parti aralığını otomatik artıran bir betik, yoğun anlarda kendiliğinden geri çekilir.
Bu, sabit bir hızla çalışan bir işlemden çok daha güvenlidir — gece hızlı, gündüz yavaş çalışır.
Kaynak önceliklerini sistem seviyesinde ayarlayabildiğiniz VDS altyapı çözümleri üzerinde, aktarım süreçlerine düşük öncelik vermek doğrudan mümkündür.
İlerleme Takibi
Uzun süren işlemler görünür olmalıdır:
| Bilgi | Faydası |
|---|---|
| İşlenen kayıt sayısı | İlerleme yüzdesi |
| Parti başına süre | Yavaşlama tespiti |
| Tahmini kalan süre | Planlama |
| Hata sayısı | Durma kararı |
İkinci satır erken uyarı verir: parti süresinin giderek artması, sayfalama yönteminin yanlış olduğunu veya hedef tablonun şiştiğini gösterir.
Bu eğilim fark edildiğinde işlem durdurulup yöntem düzeltilebilir — saatler sonra tamamen tıkanmasını beklemek yerine.
Sonuç
Büyük veri aktarımında tek seferde çalıştırmanın en tehlikeli yanı gözden kaçar: milyonlarca satırı tek işlemde güncellemek, veritabanının geri alma günlüğünü diski dolduracak kadar büyütebilir ve tüm veritabanı durur. Parçalara bölerken sayfalama yöntemine dikkat edin — atlama tabanlı sayfalama derinleştikçe yavaşlar, son işlenen kimlikten devam etmek ise sabit hız verir. Doğrulamada sayı değil toplam karşılaştırın. Ve üzerine yazmak yerine yeni bir sütuna yazmak, geri dönüşü tek sorguya indirger.
Sıkça Sorulan Sorular (SSS)
Parti boyutu ne olmalı?
Genellikle bin ile birkaç bin kayıt arasında. Kesin sayı, kayıt başına yapılan işin ağırlığına bağlıdır. Küçük bir örneklemle süreyi ölçüp ayarlayın ve partiler arasına kısa bir bekleme koyun — bu, veritabanının diğer sorguları işlemesine fırsat verir.
İşlem ilerledikçe yavaşlıyor, neden?
Muhtemelen atlama tabanlı sayfalama kullanıyorsunuz. Atlanacak kayıtlar da okunmak zorunda olduğu için, ilerledikçe her parti bir öncekinden yavaş olur. Son işlenen kimlikten büyük olanları almaya geçin — her parti aynı hızda alınır.
Aktarım sırasında veri değişiyor, ne yapmalıyım?
Başlangıçta bir kesme noktası belirleyin — o andaki en yüksek kimliği not edip yalnızca ona kadar olan kayıtları işleyin. Sonrasında eklenen ve güncellenen kayıtları ikinci bir turda ele alın; değişiklik zamanı sütunu bu turu kolaylaştırır.
Aktarımın doğru olduğunu nasıl doğrularım?
Yalnızca kayıt sayısı karşılaştırmayın — aynı sayıda ama yanlış içerikli kayıtları göremezsiniz. Sayısal bir sütunun toplamını iki tarafta karşılaştırmak çok daha güçlü bir kanıttır; hem eksik hem hatalı dönüşümü yakalar.