Çoğu kişi sitesinin zamanla yavaşlamasını sunucunun eskimesine bağlar. Hosting paketini yükseltir, birkaç hafta rahatlar, sonra aynı yavaşlık geri gelir. Oysa dijital ürün satışında yavaşlamanın en yaygın sebebi donanım değil, hiç kimsenin bakmadığı bir tablonun sessizce milyonlarca satıra ulaşmasıdır.
Bunun sinsi tarafı, büyümenin faydalı görünmesidir. Sipariş sayın arttıkça log satırların artar, ziyaretçin arttıkça oturum kayıtların birikir, kampanya yaptıkça bildirim kuyruğun şişer. Hepsi başarı göstergesidir ama hiçbiri temizlenmiyorsa aynı başarı bir süre sonra sitenin frenine dönüşür. Bu yazıda bir e-pin scriptinde hangi tabloların neden büyüdüğünü, hangisinin silinip hangisinin arşivleneceğini ve bunu veri kaybetmeden nasıl yapacağını anlatıyoruz.
Hangi tablolar büyür ve neden hepsi aynı değerde değildir?
Bir dijital ürün satış scriptinde tablolar üç gruba ayrılır. Birinci grup mali ve sözleşmesel kayıtlardır: siparişler, ödemeler, faturalar, bakiye hareketleri. Bunlara dokunamazsın, yasal saklama süresi boyunca erişilebilir olmak zorundadır. İkinci grup operasyonel izlerdir: giriş denemeleri, sistem logları, webhook kayıtları, e-posta gönderim geçmişi. Bunların değeri birkaç ay sonra hızla düşer. Üçüncü grup ise geçici verilerdir: oturumlar, sepetler, parola sıfırlama anahtarları, önbellek satırları. Bunlar günler içinde tamamen değersizleşir.
Sorunun kaynağı, çoğu kurulumda bu üç grubun aynı saklama politikasına, yani "hiç silme" politikasına tabi olmasıdır. Oysa doğru yaklaşım her gruba ayrı bir ömür tanımlamaktır. Böylece mali veri güvende kalırken, siteyi yavaşlatan asıl kütle küçülür.
| Veri türü | Büyüme hızı | Önerilen politika | Saklama |
|---|---|---|---|
| Sipariş ve ödeme kayıtları | Orta | Arşiv tablosuna taşı, asla silme | Yasal süre |
| Stok kod havuzu (kullanılmış) | Yüksek | Şifreli arşiv, ana tablodan çıkar | Yasal süre |
| Sistem ve hata logları | Çok yüksek | Dönemsel sil | 60-90 gün |
| Giriş ve güvenlik logları | Yüksek | Özetle, ham kaydı sil | 180 gün |
| Oturum kayıtları | Çok yüksek | Otomatik temizlik | 7-14 gün |
| Terk edilmiş sepetler | Yüksek | Raporla, sonra sil | 30-60 gün |
| Webhook / API çağrı kaydı | Çok yüksek | Başarılıları sil, hataları tut | 30 gün |
Silmek mi arşivlemek mi? İkisi farklı işlerdir
Silmek ve arşivlemek çoğu zaman birbirinin yerine kullanılır ama aynı şey değildir. Silmek, verinin bir daha lazım olmayacağına karar vermektir. Arşivlemek ise veriyi sıcak tablodan çıkarıp soğuk bir yere taşımaktır; hâlâ erişilebilir ama günlük sorguları yavaşlatmaz.
Pratik kural şu: bir yıldan eski tamamlanmış siparişleri ana tablodan ayrı bir arşiv tablosuna taşı. Panelde "geçmiş siparişler" filtresi bu tabloyu okur, günlük operasyon ise küçük ve hızlı ana tabloyla çalışır. Kullanılmış stok kodları için de aynısı geçerlidir; bunlar genellikle veri hacminin en büyük kalemidir ve satış sonrası sadece iade veya itiraz durumunda gerekir.
Arşivleme yaparken iki şeye dikkat et. Birincisi, taşıma işlemini tek seferde milyonlarca satırla değil, binlik parçalar halinde ve düşük trafik saatinde yap. İkincisi, taşımadan önce mutlaka yedek al ve taşıma sonrası satır sayılarını karşılaştır. Kaybolan tek bir mali kayıt, kazandığın hızdan çok daha pahalıya mal olur.
Olgun bir e-pin kurulumunda disk alanının dağılımı
- Log ve izleme tabloları 45%
- Stok kodu ve teslimat kayıtları 25%
- İndeksler 20%
- Sipariş, kullanıcı ve ürün verisi 10%
İndeksler neden hem çözüm hem sorun?
İndeks eklemek yavaş bir sorguyu anında hızlandırır, bu yüzden çok cazip görünür. Ancak her indeks, yazma işlemlerine ek maliyet bindirir ve disk alanı tüketir. Yıllar içinde "bir sorun çıkınca eklenmiş" ama artık hiçbir sorgunun kullanmadığı indeksler birikir.
Yapman gereken üç şey var. Önce kullanılmayan indeksleri tespit et; çoğu veritabanı motoru indeks kullanım istatistiği tutar. Sonra çakışan indeksleri birleştir; aynı sütunla başlayan iki ayrı indeks genellikle tek bir bileşik indekse indirgenebilir. Son olarak, sık filtrelenen sütun kombinasyonlarını doğru sırada indeksle. Sipariş tablosunda kullanıcı kimliği ve tarih birlikte sorgulanıyorsa, bu ikisini kapsayan tek bir bileşik indeks, iki ayrı indeksten çok daha etkilidir.
Bir e-pin yazılımının kurulum sonrası bakım adımlarında indeks denetimi yer alıyorsa bunu ciddiye al. Çoğu yavaşlama şikayetinin altından eksik değil, yanlış sıralanmış bir indeks çıkar.
Gece yedeğinin süresi aylar içinde 4 dakikadan 40 dakikaya çıktıysa bu bir performans uyarısıdır. Veritabanı büyümesini ilk fark ettiren şey çoğu zaman panel değil, uzayan yedekleme penceresidir.
Rapor sorguları canlı tabloyu neden bu kadar zorluyor?
Panelde "bu ay ne kadar sattım" sorusuna cevap veren ekran, arka planda genellikle yüz binlerce satırı tarayan bir toplama sorgusu çalıştırır. Tek başına sorun değildir; sorun bu ekranın her açılışta yeniden hesaplaması ve birden fazla kişinin aynı anda bakmasıdır.
Çözüm özet tablolarıdır. Günlük satış toplamlarını, ürün bazlı adetleri ve kategori kırılımlarını gece bir kez hesaplayıp küçük bir özet tablosuna yaz. Panel bu özetten okusun. Böylece rapor ekranı milisaniyelerde açılır ve canlı sipariş tablosuna hiç dokunmaz.
İkinci bir iyileştirme, rapor ekranlarına varsayılan tarih sınırı koymaktır. "Tüm zamanlar" seçeneğini varsayılan yapmak, her açılışta tüm tarihi taratır. Varsayılanı son 30 gün yap; geniş aralığı isteyen kullanıcı bilinçli olarak seçsin. Panel ve raporlama yapısının nasıl kurgulandığını özellikler bölümünde inceleyebilirsin.
Aylık bakım rutini: ne zaman neye bakacaksın?
Veritabanı büyümesi bir kriz anında çözülecek bir iş değil, düzenli bir bakım disiplinidir. Aşağıdaki tabloyu bir takvim gibi kullan; her maddeyi sorumluyla ve periyotla eşleştir.
| Periyot | Kontrol | Alarm eşiği |
|---|---|---|
| Günlük | Yedek süresi ve yedek boyutu | %20 ani artış |
| Günlük | Oturum ve geçici tablo temizliği çalıştı mı | Görev atlandıysa |
| Haftalık | Yavaş sorgu günlüğü ilk 10 kayıt | 1 sn üzeri sorgu |
| Haftalık | En büyük 5 tablonun satır sayısı | Haftalık %15 artış |
| Aylık | Log tablosu saklama politikası uygulaması | Politika dışı kayıt varsa |
| Aylık | Kullanılmayan indeks taraması | 3 ay hiç kullanılmamışsa |
| Çeyreklik | Eski sipariş ve kod arşivleme | 1 yıldan eski kayıtlar |
| Çeyreklik | Arşivden geri dönüş tatbikatı | Test başarısızsa |
Veri büyümesini baştan doğru kurgulanmış bir altyapıyla karşıla
Pinova, arşivleme dostu tablo tasarımı, otomatik temizlik görevleri ve özet tablolu raporlama ile gelir. Büyüdükçe yavaşlamayan bir kurulumla başla.
Eski siparişleri silmem yasal olarak sorun yaratır mı?
Mali kayıt niteliğindeki sipariş, ödeme ve fatura verilerini yasal saklama süresi dolmadan silmemelisin. Bunları silmek yerine arşiv tablosuna taşı. Silinebilecek olanlar log, oturum ve geçici kayıtlardır.
Veritabanım kaç GB olursa endişelenmeliyim?
Mutlak boyuttan çok büyüme eğrisi önemlidir. Toplam boyutun her ay istikrarlı biçimde artıyor ama sipariş sayın aynı oranda artmıyorsa, büyüme satıştan değil birikmiş loglardan geliyordur. Asıl uyarı işareti budur.
Arşiv tablosunu aynı veritabanında mı tutmalıyım?
Başlangıçta aynı veritabanında ayrı bir tablo yeterlidir ve yönetimi kolaydır. Arşiv hacmi canlı veriyi kat kat aştığında ayrı bir veritabanına ya da ayrı bir sunucuya taşımak yedekleme süresini ciddi biçimde kısaltır.
Temizlik görevlerini otomatikleştirmek riskli mi?
Doğru kurgulandığında riskli değildir, aksine unutmaktan güvenlidir. Üç kural yeterli: görev yalnızca tanımlı tablolarda çalışsın, her çalıştırmada kaç satır etkilediğini raporlasın ve ilk ay silme yerine sadece raporlama modunda çalışsın.
Veritabanı bakımı görünmeyen bir iştir; iyi yapıldığında kimse fark etmez, ihmal edildiğinde ise önce yavaşlık, sonra kesinti olarak geri döner. Elindeki altyapının arşivleme, temizlik ve özet raporlama tarafını nasıl karşıladığını görmek istersen panel akışını canlı demo üzerinden incele; ihtiyacına uygun paketi ise fiyat bölümünden karşılaştırabilirsin.