WooCommerce Sipariş Arşivleme ve Veritabanı Temizliği

WooCommerce Sipariş Arşivleme ve Veritabanı Temizliği Neden Bu Kadar Önemli?

WooCommerce ile çalışan bir e-ticaret sitesini birkaç yıl boyunca aktif tuttuğunuzda, veritabanınız adım adım büyür. İlk yıl birkaç bin siparişle başlayan tablo, üçüncü veya beşinci yılda yüz binlerce sipariş kaydına, milyonlarca meta satırına ve rapor tablolarına dönüşür. Bu büyüme sadece disk alanını tüketmekle kalmaz; MySQL sorgularınız yavaşlar, backup süreleri uzar, checkout ve sepet adımlarında kullanıcıların hissettiği gecikme artar. Özetle, “veriyi sonsuza kadar tutma” refleksi, zamanla mağazanızın performansını aşağı çeker.

DCHost tarafında yüzlerce WooCommerce mağazasını yönetirken en sık gördüğümüz sorunlardan biri, yıllarca hiç dokunulmamış sipariş tabloları ve dağınık veritabanı yapıları. Bu yazıda, hem KVKK gibi mevzuatları gözeterek veriyi yıllarca saklamayı, hem de sipariş arşivleme ve veritabanı temizliği ile mağazanızı yavaşlatmamanın somut yollarını adım adım ele alacağız. Odak noktamız: Pratik, tekrarlanabilir ve otomasyona uygun bir strateji kurmak.

WooCommerce Sipariş Verisinin Anatomisi: Hangi Tablo Neyi Tutuyor?

Sağlıklı bir arşiv stratejisi kurmak için önce WooCommerce sipariş verisinin nerede ve nasıl tutulduğunu netleştirmek gerekir. Basitleştirilmiş haliyle bir sipariş şu tablolara yayılır:

• wp_posts: Siparişin ana kaydı (post_type = ‘shop_order’).
• wp_postmeta: Fatura bilgileri, kargo adresi, ödeme gateway alanları, özel alanlar.
• wp_woocommerce_order_items: Siparişteki her satır (ürün, kargo, kupon vb.).
• wp_woocommerce_order_itemmeta: Her satırın miktar, fiyat, vergi gibi detayları.
• wc_order_stats ve wc_order_product_lookup: Raporlama ve hızlı sorgu için WooCommerce 3.0 sonrası eklenen lookup tabloları.
• Farklı ödeme/kargo eklentilerinin oluşturduğu log veya geçici tablolar.

Sipariş sayınız arttıkça, özellikle wp_postmeta ve order_itemmeta tabloları milyonlarca satıra ulaşır ve indeksleriniz şişer. Bu noktada sadece arşivleme değil, indeks ve sorgu yapınızı da gözden geçirmek gerekir. Bu konuyu daha derinlemesine incelemek isterseniz, WooCommerce ve büyük katalog siteleri için MySQL indeksleme ve sorgu optimizasyonu rehberini mutlaka okumanızı öneririz.

Saklama Politikası Tasarlamak: Ne Kadar, Neyi, Neden Tutuyorsunuz?

Sipariş arşivleme, “eski siparişleri silelim” seviyesinde ele alınırsa hem hukuki hem de operasyonel açıdan riskli hale gelir. İlk adım, net bir veri saklama politikası yazmaktır. DCHost müşterilerinde genelde şu sorulardan yola çıkıyoruz:

• Finansal kayıtlar: Fatura ve muhasebe kayıtlarını yasal olarak kaç yıl saklamak zorundasınız?
• Müşteri hizmetleri: İade, garanti, destek süreçleriniz ortalama ne kadar süreye yayılıyor?
• Pazarlama ve analiz: Eski sipariş davranışına geriye dönük ne kadar ihtiyacınız var? 3 yıl, 5 yıl, 10 yıl?
• KVKK / GDPR: Müşteri veri minimizasyonu ve unutulma hakkı açısından hangi bilgilerin anonimleştirilmesi gerekiyor?

Çoğu senaryoda ortaya çıkan pratik model şöyle:

• 0–2 yıl: Canlı sistemde, tam detaylı kayıt (adresler, IP, cihaz bilgisi vb.).
• 2–5 yıl: Canlı sistemde ama kısmen anonimleştirilmiş (IP maskelenmiş, gereksiz kişisel alanlar temizlenmiş).
• 5+ yıl: Canlı sistemden taşınmış, sadece hukuki ve muhasebesel ihtiyaçları karşılayacak minimal özet veri.

Bu katmanlı yaklaşım, hem performans hem de KVKK uyumu açısından güçlü bir denge sağlar. Bundan sonraki bölümlerde bu modeli WooCommerce üzerinde nasıl somutlaştırabileceğimizi konuşacağız.

Sipariş Arşivleme Stratejileri: Üç Farklı Yaklaşım

1. Yumuşak Arşiv (Soft Archive): Canlı Veritabanında Hafifletme

Yumuşak arşiv, siparişleri canlı veritabanında tutmaya devam edip, onları sorgulardan dışarıda bırakan bir yöntemdir. Örneğin:

• 2 yıldan eski “tamamlandı” statüsündeki siparişleri “archived” gibi özel bir duruma çekmek,
• Bu statüdeki siparişleri raporlar, listelemeler ve müşteri hesabı ekranlarından filtrelemek,
• Gerekirse sadece yönetim panelinde, ayrı bir “Arşiv Siparişler” sayfası üzerinden erişilebilir kılmak.

Bu yöntemin avantajı, veriyi tek bir veritabanında tutmaya devam etmenizdir; ekstra altyapı gerektirmez. Ancak tablo boyutları büyümeye devam ettiği için indeks ve backup maliyetleriniz düşmez; sadece sorgu yükünüzü hafifletmiş olursunuz.

Uygulamada tipik olarak şu adımları atıyoruz:

1. Özel bir sipariş durumu tanımlanır (örneğin ‘wc-archived’).
2. Belirli bir tarihten eski siparişleri bu duruma alan planlı bir görev (cron) yazılır.
3. Mağaza tarafındaki sorgular, bu durumu varsayılan filtrelerden hariç tutacak şekilde güncellenir.

Bu yaklaşımı seçiyorsanız, mutlaka MySQL indekslerinizi ve sorgu planlarınızı gözden geçirin. Büyük WooCommerce siteleri için indeks tasarımını detaylandırdığımız MySQL indeksleme ve sorgu optimizasyonu rehberimiz, hangi sütunlarda ek indeksler kullanmanız gerektiği konusunda net fikir verecektir.

2. Ayrı Arşiv Tablosu veya Ayrı Veritabanı

Orta ve büyük hacimli mağazalarda asıl kazanım, eski sipariş verisini fiziksel olarak başka tablolara veya başka bir veritabanına taşımaktan gelir. Bu senaryoda tipik model şöyle çalışır:

• Canlı veritabanında sadece son 2–3 yıl içindeki siparişler tutulur.
• Eski siparişler periyodik bir görevle _archive ekine sahip tablolara taşınır (örneğin wp_posts_archive, wp_postmeta_archive).
• İhtiyaç olduğunda raporlar, arşiv tablosuna bağlanan ayrı bir admin ekranı veya BI aracı üzerinden alınır.

Daha ileri bir adım olarak, arşiv tablolarını ayrı bir veritabanına taşıyabilirsiniz. Altyapı büyüdükçe, canlı sipariş verisini tutan veritabanı ile arşivi ayırmak anlamlı hale gelir. Bunun ne zaman mantıklı olduğu ve WooCommerce için nasıl bir mimari kurulabileceği konusu için, WooCommerce için ayrı veritabanı ve önbellek sunucusu ne zaman mantıklı başlıklı rehberimizi inceleyebilirsiniz.

Basit bir tablo taşıma görevi için örnek bir SQL akışı şöyle olabilir (her zaman önce yedek almayı unutmayın):

CREATE TABLE wp_posts_archive LIKE wp_posts;
INSERT INTO wp_posts_archive
  SELECT * FROM wp_posts
  WHERE post_type = 'shop_order'
    AND post_status = 'wc-completed'
    AND post_date < DATE_SUB(NOW(), INTERVAL 3 YEAR);

DELETE FROM wp_posts
  WHERE post_type = 'shop_order'
    AND post_status = 'wc-completed'
    AND post_date < DATE_SUB(NOW(), INTERVAL 3 YEAR);

Benzer işlemi wp_postmeta, order_items ve diğer ilgili tablolar için de zincirleme olarak uygulamanız gerekir. Burada en kritik nokta, ilişkili satırları eksiksiz taşımak ve işlemi mutlaka bakım modunda veya düşük trafik saatlerinde yapmak.

3. Dışa Aktar ve Sil (Cold Archive)

Daha agresif bir strateji, belirli bir sürenin üzerindeki sipariş verilerini tamamen canlı sistemin dışına çıkarmak ve sadece arşiv dosyası veya dış bir depolamada tutmaktır. Örneğin:

• 5 yıldan eski siparişleri CSV/JSON formatında dışa aktarmak,
• Bu dosyaları imzalı şekilde saklamak (örneğin hash ile bütünlük kontrolü),
• Ardından ilgili satırları WooCommerce veritabanından silmek.

Bu yöntemi seçiyorsanız, depolama tarafında da bir strateji tasarlamanız gerekir. DCHost tarafında sıklıkla, sıcak, soğuk ve arşiv depolama stratejisine çok benzeyen bir model kullanıyoruz: canlı veritabanı NVMe disklerde, son 1–2 yılın backup’ları daha ekonomik disklerde, çok eski sipariş arşivleri ise object storage benzeri çözümlerde tutuluyor.

Dışa aktarılan veriyi ne kadar hızlı geri almak istediğinizi de tanımlamanız önemli. “Yılda bir kez lazım olabilir” seviyesindeki siparişlere anlık erişim için pahalı kaynak ayırmak yerine, birkaç saatlik geri yükleme süresini kabul etmek genelde daha mantıklı olur.

Veritabanı Temizliği: Sadece Sipariş Tablosu Değil

Sipariş arşivlerken çoğu zaman sadece wp_posts ve wp_postmeta odaklı düşünüyoruz. Oysa WooCommerce, zaman içinde bir dizi ek tabloyu ve WordPress çekirdeğinin bazı alanlarını da şişiriyor:

• wp_options: Otomatik yülenen (autoload) seçenekler, geçici veriler.
• Transients: Önbellek benzeri geçici kayıtlar (çoğu zaman otomatik temizlenmiyor).
• actionscheduler_* tabloları: Cron benzeri görev kuyruğu, özellikle büyük sitelerde milyonlarca satıra çıkabiliyor.
• Log ve geçici tablolar: Bazı gateway ve kargo eklentileri, kendi log tablolarını oluşturup asla temizlemiyor.

Biz DCHost ekibinin sıkça yaptığı bir hata analizi, büyük sitelerdeki wp_options ve autoload alanının aşırı şişmesiyle ilgili. Sipariş arşivlerken mutlaka genel veritabanı sağlığınızı da ele alın. Bunun için hazırlanmış WordPress veritabanı optimizasyonu ve wp_options/autoload şişmesini temizleme rehberimiz, WooCommerce siteleri için de birebir uygulanabilir.

Temizlikte dikkat etmeniz gereken temel adımlar:

1. Önce tam veritabanı yedeği alın (mysqldump veya XtraBackup gibi araçlarla).
2. wp_options tablosunda autoload = ‘yes’ olup, çok büyük veri tutan kayıtları belirleyin.
3. WooCommerce eklenti tablolarını tarayıp, 6–12 aydan eski log/transient kayıtlarını silin.
4. actionscheduler tablolarında tamamlanmış ve çok eski görevleri periyodik olarak temizleyin.

Temizlikten Önce ve Sonra: Yedekleme Stratejisi Olmadan Asla

Herhangi bir arşivleme veya silme işlemi, doğrudan gelir getiren bir sistem üzerinde çalıştığınız için geri dönüşü zor riskler barındırır. Bu yüzden DCHost tarafında prensibimiz çok net: “Temizlikten önce en az bir tam, bir de nokta atışı tablo bazlı yedek olmadan işlem yapmayız.”

MySQL/MariaDB için farklı yedekleme yöntemlerini; mysqldump, Percona XtraBackup ve snapshot bazlı yaklaşımları karşılaştırdığımız MySQL/MariaDB yedekleme stratejileri rehberinde, WooCommerce gibi canlı sistemler için Point-in-Time Recovery (anlık geri dönebilme) senaryolarını da detaylı anlattık.

Özet bir kontrol listesi:

• Canlı veritabanının tam yedeğini alın.
• Özellikle wp_posts, wp_postmeta, order_items, order_itemmeta gibi kritik tablolar için ayrıca ayrı bir dump alın.
• Yedeğin gerçekten çalıştığını test ortamına geri yükleyerek doğrulayın.
• Temizlik/taşıma işlemini yaptıktan sonra, kısa bir süre boyunca eski yedeği silmeyin (en az birkaç hafta).

Otomasyon: Cron ile Düzenli Arşiv ve Temizlik Akışı Kurmak

Bir kereye mahsus temizlik yapmak, kısa vadede nefes aldırır; ama birkaç ay sonra tablo boyutları tekrar büyümeye başlar. Asıl hedefiniz, tamamen otomatik çalışan bir arşivleme ve temizlik akışı kurmak olmalı.

Genel yaklaşım:

1. “2 yıldan eski ve tamamlanmış siparişler” gibi bir kritere karar verin.
2. Bu kriteri SQL veya WP-CLI ile uygulayan küçük bir komut/skript yazın.
3. Bu komutu, sunucu tarafında gerçek bir cron job ile haftalık veya aylık çalışacak şekilde planlayın.
4. Her çalışmada taşınan/silinen sipariş sayısını bir log tablosuna veya dosyaya yazın.

Cron job’ları zaten düzenli işleriniz için kullanıyorsanız, WooCommerce arşivleme scriptinizi de aynı yapıya ekleyebilirsiniz. Zamanlama ve güvenli otomasyon mantığı, genel olarak diğer otomatik görevlerle aynıdır; bu konuda deneyim kazanmak için hazır görevlerinizi gözden geçirmenizi özellikle öneririz.

Performans Üzerindeki Somut Etkiler: Neleri Ölçmelisiniz?

Sipariş arşivleme ve veritabanı temizliği, hissiyat seviyesinde değil, ölçülebilir metriklerle değerlendirildiğinde gerçekten değerini gösterir. Biz DCHost tarafında tipik olarak şu metrikleri izliyoruz:

• Sorgu süresi: Özellikle sipariş listesi, müşteri hesabı ve rapor sorgularının ortalama yanıt süresi.
• Veritabanı boyutu: Toplam veritabanı boyutu ve en büyük tabloların boyutları.
• Backup süresi: Tam yedek alma süresinde arşivleme sonrası oluşan kısalma.
• Disk IOPS ve gecikme: Özellikle yoğun kampanya dönemlerinde disk üzerinde oluşan yük.

Disk ve IOPS tarafı, büyük WooCommerce sitelerinde kritik bir konu. Bu alanı daha detaylı ele aldığımız WooCommerce ve büyük WordPress siteleri için disk, IOPS ve inode planlama rehberi, özellikle NVMe diskli VPS veya dedicated sunucu planlarken işinize yarayacaktır.

Arşivleme öncesi ve sonrası şu tip karşılaştırmalar yapmak iyi bir pratik:

• wp_postmeta tablosu boyutu: Örneğin 12 GB’den 4 GB’e düşmesi.
• checkout sayfası TTFB değeri: 800 ms’den 400 ms seviyelerine gerilemesi.
• mysqldump süresi: 20 dakikadan 5 dakikaya inmesi.

Bu iyileşmeler hem kullanıcı deneyimine hem de altyapı maliyetlerine doğrudan yansır; daha düşük kaynakla daha yüksek trafik kaldırabilirsiniz.

DCHost Altyapısında Önerilen Mimari: Farklı Ölçekler İçin Yol Haritası

Sipariş arşivleme stratejisi her zaman mevcut altyapınızla birlikte düşünülmeli. DCHost tarafında sık gördüğümüz üç senaryo üzerinden gidelim:

Küçük Mağazalar (Yılda < 10.000 Sipariş)

• Genelde paylaşımlı hosting veya giriş seviyesi VPS üzerinde çalışırlar.
• Soft archive yaklaşımı (özel sipariş durumu) çoğu zaman yeterlidir.
• Yılda 1 kez manuel temizlik + düzenli yedekleme ile sorunsuz ilerlenebilir.

Orta Ölçekli Mağazalar (Yılda 10.000–100.000 Sipariş)

• NVMe diskli güçlü VPS veya küçük dedicated sunucu önerilir.
• 2–3 yıldan eski siparişleri ayrı arşiv tablosuna taşıyan otomatik bir cron job kullanmak anlamlıdır.
• MySQL indekslerinin ve sorgu planlarının düzenli gözden geçirilmesi gerekir.

Büyük Mağazalar (Yılda 100.000+ Sipariş)

• Uygulama ve veritabanı sunucusunun ayrılması, hatta arşiv verisinin tamamen ayrı bir veritabanına taşınması mantıklı hale gelir.
• Raporlama için read-replica veya ayrı bir analitik veritabanı (örneğin yalnızca arşiv verisini barındıran) kullanmak iyi bir yaklaşımdır.
• Sipariş arşivini, iş zekası araçlarına veya veri ambarına periyodik olarak aktarabilirsiniz.

Altyapınız büyüdükçe, sipariş arşivleme sadece bir temizlik işi olmaktan çıkıp, tüm veri mimarisinin parçası haline gelir. Bu noktada DCHost üzerinde kullanacağınız VPS, dedicated veya colocation çözümlerini; sipariş hacmi, raporlama ihtiyaçları ve yedekleme stratejinizle birlikte planlamanızı öneriyoruz.

Adım Adım Uygulanabilir Plan

Teoriyi pratiğe dökmek için, WooCommerce mağazanızda uygulayabileceğiniz özet bir yol haritası bırakalım:

1. Envanter çıkarın: MySQL’de en büyük tabloları listeleyin, siparişle ilgili olanları tespit edin.
2. Saklama politikasını yazın: Hukuk, muhasebe ve pazarlama ekipleriyle birlikte yıllara göre hangi detayın tutulacağını netleştirin.
3. Yedekleme stratejisini güncelleyin: Temizlikten önce ve sonra test geri yükleme yapabileceğiniz bir yapı kurun.
4. İlk büyük arşivleme: Örneğin 3 yıldan eski tamamlanmış siparişleri arşiv tablolarına taşıyın veya dışa aktarın.
5. Genel veritabanı temizliği: wp_options, transients, actionscheduler tablolarını optimize edin; gerekirse wp_options optimizasyon rehberindeki adımları uygulayın.
6. Otomasyon kurun: Aylık/haftalık çalışan cron job’larla yeni eskiyen siparişleri otomatik arşive taşıyın.
7. Performansı ölçün: Arşivleme öncesi ve sonrası sorgu süreleri, disk kullanımı ve backup sürelerini kıyaslayın.

Sonuç: Yıllarca Veri Saklayıp Mağazanızı Yavaşlatmamak Mümkün

WooCommerce sipariş arşivleme ve veritabanı temizliği, çoğu zaman ertelenen ama ertelendikçe maliyeti katlanan bir iş. Doğru saklama politikası, sağlam bir yedekleme stratejisi ve iyi tasarlanmış bir arşiv mimarisiyle; hem KVKK uyumlu kalmak hem de onlarca, hatta yüz binlerce siparişi sorunsuz yönetmek mümkün.

DCHost olarak gördüğümüz en büyük fark, bu işe bir kerelik temizlik projesi olarak değil, sürekli çalışan bir operasyon süreci olarak bakıldığında ortaya çıkıyor. Eski siparişleri periyodik olarak arşive taşıyan, veritabanını düzenli optimize eden ve yedeklerini gerçekten test eden mağazalar; kampanya dönemlerinde çok daha az sorun yaşıyor, altyapı maliyetlerini daha iyi kontrol ediyor ve ölçeklenme kararlarını veriye dayalı olarak alabiliyor.

Eğer siz de WooCommerce mağazanızda sipariş sayınızın hızla arttığını, veritabanınızın şişmeye başladığını ve yedekleme/performans tarafında sinyaller aldığınızı hissediyorsanız; uygun bir DCHost altyapısı üzerinde bu arşivleme stratejisini hayata geçirmek için geç kalmış sayılmazsınız. Mevcut veritabanı boyutunuzu, sipariş hacminizi ve büyüme planınızı birlikte analiz ederek; hem bugün hem de birkaç yıl sonrası için sürdürülebilir bir mimari tasarlayabiliriz.