RedisPerformans ve kapasite 14 dk 14.06.2026

Redis’te normalizasyon olur mu: cache key tasarımı ve veri tekrarı nasıl yönetilir?

Redis ilişkisel veritabanı değildir; ama “aynı veriyi kaç yerde tutuyorum?” sorusu burada da vardır. Kötü key tasarımı ve kontrolsüz cache kopyaları, normalizasyon borcunun Redis versiyonudur.

Bu yazı sana şu durumda yardımcı olur

ürün bilgisi farklı cache keylerinde farklı görünüyor
TTL var ama eski veri kullanıcıya dönüyor
cache silinince uygulama aşırı yavaşlıyor
aynı kaynağın birçok Redis kopyası var
hangi keyin kaynak veriden beslendiği bilinmiyor

Yazıyı bitirince

Redis’te normalizasyonun klasik tablo anlamında olmadığını ama veri tekrarı ve tutarlılık kararının hâlâ geçerli olduğunu anlayacaksınız. Key tasarımı, TTL ve invalidation kararını daha bilinçli kurabileceksiniz.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB Redis operasyonunda kapasite, bağlantı ve yedekleme görünürlüğünü hedefler. Cache modelinizin tutarlılığı ise uygulama mimarisinin parçasıdır; platform bunu ölçmeye yardım edebilir ama kaynak gerçekliği sizin belirlemeniz gerekir.

Redis’te kaynak gerçeklik kim?

Redis çoğu sistemde kaynak gerçeklik değildir; PostgreSQL, MySQL veya başka bir kalıcı sistemden türetilmiş hızlı okuma katmanıdır. Bu durumda Redis’teki veri kopyadır ve kopyanın ne zaman silineceği veya yenileneceği yazılı olmalıdır.

Eğer Redis kaynak gerçeklik gibi kullanılmaya başladıysa karar daha ciddi hale gelir. AOF/RDB, geri dönüş, veri kaybı ve tutarlılık konuları cache ayarı olmaktan çıkar, ürün davranışına dönüşür.

Cache verisi kaybolursa yeniden üretilebilmelidir.
Kaynak gerçeklik başka sistemdeyse Redis keyleri o kaynağa bağlanmalıdır.
Aynı varlığın birçok keyde kopyası varsa invalidation planı gerekir.
TTL tek başına tutarlılık garantisi değildir.

Key tasarımı normalizasyonun Redis tarafıdır

İyi key tasarımı, verinin sahibini ve kullanım amacını gösterir. tenant, entity, id ve sürüm bilgisi key içinde okunabiliyorsa operasyon kolaylaşır. Rastgele key isimleri ise sorun anında hangi verinin silineceğini belirsizleştirir.

Aynı ürün bilgisini product:123, home:featured, search:popular gibi farklı keylerde tutabilirsiniz. Bu kötü değildir; ama ürün fiyatı değiştiğinde hangi keylerin temizleneceğini bilmeniz gerekir.

Okunabilir key deseni

redis-key-design.txt

tenant:{tenantId}:product:{productId}:summary
tenant:{tenantId}:product:{productId}:price
tenant:{tenantId}:homepage:featured-products
tenant:{tenantId}:search:popular:v3

Kaynak değişince temizlenecek key grubu:
product:{productId}:summary
product:{productId}:price
homepage:featured-products

String mi hash mi?

Küçük JSON objesini string olarak saklamak basit ve çoğu zaman yeterlidir. Ama objenin tek alanı sık güncelleniyorsa hash daha anlamlı olabilir. Yine de Redis hash kullanmak otomatik normalizasyon sağlamaz; sadece alan bazlı güncelleme kolaylığı verir.

Karar verirken okuma biçimine bakın. Uygulama her zaman tüm objeyi okuyorsa JSON string sade olabilir. Tek tek alanlar okunup yazılıyorsa hash düşünülebilir.

String ve hash örneği

redis-string-hash.sh

# Tüm özet birlikte okunuyorsa
SET tenant:42:product:9:summary '{"name":"Defter","price":12900}' EX 300

# Alan bazlı güncelleme gerekiyorsa
HSET tenant:42:product:9 name "Defter" price_cents 12900
EXPIRE tenant:42:product:9 300

Cache invalidation planı yazılmadan denormalizasyon tamamlanmaz

Redis’te veri tekrarı çoğu zaman hız için yapılır. Ama kaynak veri değiştiğinde cache temizlenmiyorsa kullanıcı eski fiyat, eski stok veya eski yetki görebilir. Bu durum performans optimizasyonu değil, tutarlılık hatasıdır.

En pratik yöntemlerden biri değişiklik olayında ilgili keyleri temizlemek, bulunamayan yerlerde kısa TTL kullanmak ve kritik alanlarda cache yerine doğrudan kaynak veriye dönmektir.

Değişiklik sonrası cache temizleme notu

redis-invalidation-plan.md

Kaynak tablo/koleksiyon:
Değişen alan:
Etkilenen key desenleri:
Temizleme tetikleyicisi:
TTL:
Eski veri kullanıcıya dönerse etkisi:
Kritik mi, tolere edilebilir mi:

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler