Yan projelerimde ya da bir üretim ERP’sinde çalışırken, “ürün ağacı” denilen yapı hep karşıma çıkar. Temelde, bir ürünün hangi bileşenlerden oluştuğunu, o bileşenlerin de kendi içinde hangi alt bileşenlere ayrıldığını gösteren hiyerarşik bir yapıdır bu. Veritabanında genelde self-referencing bir tabloyla ya da ayrı bir ilişki tablosuyla modellenir.
Bu yapı, özellikle üretim planlama, maliyet hesaplama ve stok yönetimi gibi kritik süreçlerde kilit rol oynar. Ancak karmaşık sorgular ve performans sorunları baş gösterdiğinde, akla hemen denormalizasyon gelir. Peki, bu her zaman doğru çözüm mü, özellikle de kendi küçük projelerimizde?
Ürün Ağacı Karmaşası ve İlk Deneyimlerim
Ürün ağacının gerçek karmaşıklığını ilk kez büyük bir üretim firmasının ERP’sinde çalıştığım zamanlarda deneyimledim. Bir motorun yüzlerce parçadan oluştuğunu, her bir parçanın da kendi içinde onlarca alt parçası olduğunu düşünün. Bir parça değiştiğinde, tüm ağacın etkilenmesi ve bunun maliyetlere yansıması gerekiyordu.
Bu tür durumlarda yazılım mimarisi, çoğu zaman yazılımdan çok organizasyonel akışın bir yansıması oluyor. Veritabanı modelini tasarlarken, sadece verinin nasıl saklanacağını değil, aynı zamanda üretim hattındaki gerçek iş akışlarını da dikkate almak zorundasınız. Basit bir hammadde değişikliği, son ürünün fiyatını ve teslimat süresini doğrudan etkileyebilir.
Bir keresinde, bir müşteri projesinde, bir ürün ağacının oldukça derin seviyelere ulaştığını gördüm. Bu ağaç üzerinde yapılan her “nerede kullanılıyor” sorgusu, çok sayıda satırı tarayarak gözle görülür biçimde yavaşlıyordu. Raporlar gecikiyor, üretim planlama aksıyordu. Bu durum, bizi performans iyileştirmeleri düşünmeye iten ilk büyük işaretlerden biriydi.
Denormalizasyon Ne Zaman Akla Geliyor?
Denormalizasyon, genellikle performans darboğazları ortaya çıktığında bir kurtarıcı olarak görülür. Özellikle hiyerarşik verilerde, derinlemesine sorgular ve birleştirme (JOIN) işlemleri maliyetli olabilir. Bir ürün ağacının tüm bileşenlerini veya belirli bir bileşenin hangi üst ürünlerde kullanıldığını bulmak, veritabanı için zorlayıcıdır.
Örneğin, bir ürün ağacında belirli bir parçanın maliyetini hesaplamak için, o parçanın tüm alt bileşenlerinin maliyetlerini toplayıp üst seviyelere doğru ilerlemeniz gerekir. Bu recursive sorgular, özellikle büyük veri setlerinde, CPU ve I/O tüketimini artırır. PostgreSQL’de WITH RECURSIVE sorguları oldukça güçlüdür, ancak yine de belirli bir ölçekten sonra yavaşlayabilir.
WITH RECURSIVE part_hierarchy AS (
SELECT
p.part_id,
p.part_name,
p.cost,
p.part_id AS top_level_part_id
FROM parts p
WHERE p.parent_id IS NULL -- Root parts
UNION ALL
SELECT
cp.child_part_id AS part_id,
child_p.part_name,
child_p.cost,
ph.top_level_part_id
FROM part_components cp
JOIN part_hierarchy ph ON ph.part_id = cp.parent_part_id
JOIN parts child_p ON child_p.part_id = cp.child_part_id
)
SELECT * FROM part_hierarchy;Yukarıdaki gibi bir sorgu, ürün ağacını tamamen genişletmek için kullanılır. Eğer bu sorguyu her maliyet hesaplamasında veya her raporlama anında çalıştırırsanız, sistemin genel performansı düşer. İşte tam bu noktada, denormalize edilmiş bir “yol” ya da “derinlik” bilgisini ana tabloya ekleme fikri cazip gelmeye başlar. Mesela, her parça için “001.002.003” gibi bir ağaç yolu saklamak veya her düğümün hangi üst düğümlere sahip olduğunu bir dizi olarak tutmak gibi yaklaşımlar düşünülür.
Yan Projelerde Durum Farklı mı?
Kurumsal bir ERP’deki ölçek ve performans beklentileri ile kendi yan projelerimde karşılaştığım durumlar arasında dağlar kadar fark var. Bir üretim ERP’sinde günde on binlerce sipariş işlenirken, benim kendi yan ürünümün backend’i ayda belki birkaç yüz kullanıcıya hizmet veriyor. Bu durumda, denormalizasyon gibi karmaşık ve bakım maliyeti yüksek bir çözüme gitmek, çoğu zaman overkill oluyor.
Benim felsefemde, “olur o kadar” yaklaşımı yan projelerde çok değerlidir. Bir sorgu biraz daha yavaş çalışıyorsa ve bu, kullanıcının deneyimini gözle görülür şekilde etkilemiyorsa, o optimizasyon için haftalar harcamak mantıklı değil. Önemli olan, projenin hayatta kalması ve sürekli gelişmesidir. Büyük şirketlerdeki gibi “99.999% uptime” hedefleriyle yola çıkmıyorum.
Bir yan ürünümde, kullanıcıların kendi ürün ağaçlarını oluşturduğu bir görev yönetim uygulaması vardı. Başlangıçta, basit bir self-referencing tablo ile gittim ve performans konusunda endişelenmedim. Ağaç derinliği 3-4 seviyeyi geçmedi, eleman sayısı da yüzlerle sınırlıydı. WITH RECURSIVE sorguları gayet hızlı çalışıyordu. Eğer gelecekte, diyelim ki 10.000 kullanıcıya ulaşırsam ve raporlar yavaşlarsa, o zaman denormalizasyonu düşünürüm. Ama o zamana kadar, basit çözüm yeterli.
Maliyetleri ve Trade-off’ları Gözden Geçirmek
Denormalizasyonun getirileri olduğu kadar, önemli maliyetleri ve trade-off’ları da var. En başta, veri fazlalığı (data redundancy) ortaya çıkar. Aynı bilgi birden fazla yerde tutulduğu için, güncelleme anomalileri riski artar. Bir parça adı veya maliyeti değiştiğinde, sadece ana tabloyu değil, denormalize edilmiş tüm alanları da güncellemeniz gerekir.
Bu durum, özellikle sistemde birden fazla yazma işlemi yapan süreç varsa, tutarlılık (consistency) sorunlarına yol açabilir. ACID garantilerini korumak için daha karmaşık transaction yönetimi veya event-sourcing gibi yaklaşımlar gerekebilir. Bu da geliştirme süresini uzatır ve hata yapma olasılığını artırır.
-- Denormalize edilmiş bir maliyet alanını güncellemek
UPDATE products
SET denormalized_total_cost = (
SELECT SUM(p.cost) FROM parts_denormalized_path pdp
JOIN parts p ON p.part_id = pdp.part_id
WHERE pdp.product_id = products.product_id
)
WHERE products.product_id = 'XYZ';
-- Bu sorgu, denormalize edilmiş alanın manuel olarak güncellenmesi gerektiğini gösterir.
-- Gerçek hayatta bu, trigger'lar veya bir event işleyici tarafından yapılabilir.Bu tür maliyetler yan projelerde genellikle ağır basar. Birkaç milisaniye kazanmak için, gelecekteki bakım ve hata ayıklama yükünü artırmak istemem. Denormalize edilmiş bir alanın güncellenmesi unutulduğunda, fark edilmeyen yanlış raporlar üretilir; bu tür sessiz tutarsızlıkları sonradan bulup düzeltmek ciddi zaman alır.
Pragmatik Bir Yaklaşım: Kademe Kademe Optimizasyon
Benim denormalizasyona yaklaşımım genellikle kademe kademe optimizasyon şeklindedir. Yani, en baştan denormalizasyon yapmaktansa, performans sorunları gerçekten hissedildiğinde adım adım ilerlemeyi tercih ederim. İlk olarak, iyi indeksleme ve sorgu optimizasyonlarına odaklanırım.
PostgreSQL’de doğru B-tree veya GIN indeksleri, WITH RECURSIVE sorgularının performansını önemli ölçüde artırabilir. EXPLAIN ANALYZE çıktılarına bakarak, sorgunun nerede zaman harcadığını tespit edip ona göre indeks eklemek, çoğu zaman ilk ve en etkili adımdır. Örneğin, parent_id veya path alanlarına indeks eklemek, ağaç traversallarını hızlandırır.
-- Örnek bir indeksleme stratejisi
CREATE INDEX idx_parts_parent_id ON parts (parent_id);
CREATE INDEX idx_part_components_parent_child ON part_components (parent_part_id, child_part_id);Eğer indeksleme yeterli gelmezse, materialized view’lar harika bir ara çözüm sunar. Ürün ağacının belirli bir görünümünü veya toplam maliyetleri bir MATERIALIZED VIEW olarak saklayıp, düzenli aralıklarla yenileyebilirsiniz. Bu, okuma performansını artırırken, denormalizasyonun getirdiği karmaşık güncelleme mantığını biraz daha izole eder.
Caching de bir diğer güçlü alternatiftir. Sık erişilen ürün ağacı yollarını veya maliyet hesaplamalarını bir Redis instance’ında saklamak, veritabanına olan yükü azaltabilir. Örneğin, bir ürünün tam maliyetini hesapladıktan sonra bunu 1 saatlik bir TTL (Time-To-Live) ile Redis’e yazabilirim. Bir sonraki istek geldiğinde, Redis’ten okuyarak veritabanı sorgusundan kaçınmış olurum. Bu yaklaşım, sistemin tepki süresini belirgin biçimde kısaltır.
Benim Net Pozisyonum: Genellikle Hayır
Yan projelerimde veya küçük ölçekli sistemlerde ürün ağacı denormalizasyonu yapmak, genellikle “hayır” cevabını verdiğim bir konudur. Çok nadiren, gerçekten kritik bir performans darboğazı yaşamadıkça ve diğer tüm optimizasyon seçenekleri tükenmedikçe bu yola girmem. Geliştirme zamanı ve bakım kolaylığı, benim için çoğu zaman saf performansın önüne geçer.
Denormalizasyon, bir kez uygulandığında geri dönüşü zor ve maliyetli bir karardır. Veri modelini karmaşıklaştırır, tutarlılık garantilerini zayıflatır ve gelecekteki değişiklikleri zorlaştırır. Eğer projeniz henüz ölçeklenmemişse, bu ekstra yükü omuzlamanın bir anlamı yok. Genel ilke şu: başlangıçta her şeyi optimize etmeye çalışmak yerine, basit bir veri modeliyle başlayıp sonraki adımları gerçek performans ölçümlerine göre atmak çok daha mantıklıdır.
Denormalizasyonun haklı olabileceği senaryolar elbette var:
- Ekstrem Okuma Yükleri: Günde milyonlarca okuma işlemi yapılan ve yazma işlemlerinin çok nadir olduğu sistemler.
- Sabit Veri Yapıları: Ürün ağacının çok nadiren değiştiği veya hiç değişmediği durumlar.
- Belirli Raporlama İhtiyaçları: Anlık olarak tüm ağacın bir “snapshot”ına ihtiyaç duyulan ve bu snapshot’ın oluşturulmasının çok zaman aldığı durumlar.
Ancak bu senaryolar, benim yan projelerimin çoğunda geçerli değil. Benim için, bir sorgu gözle görülür biçimde hızlanacaksa ama bunu yapmak için günler süren ek geliştirme ve sürekli bakım gerekiyorsa, yavaş ama basit olanı tercih ederim. Zamanım kısıtlı ve bu zamanı projemin ana özelliklerini geliştirmeye harcamayı tercih ederim.
Sonuç: Basitlik Her Zaman Kazandırır
Özetle, ürün ağacı denormalizasyonu konusu, özellikle kendi yan projelerimde, her zaman “gerçekten gerekli mi?” sorusuyla başlar. Benim için, basitlik ve sürdürülebilirlik her zaman önceliklidir. Genellikle, iyi indeksleme, materialized view’lar ve caching gibi daha az invaziv çözümler, performans ihtiyaçlarımı karşılamaya yeterli olur.
Eğer projeniz yüz binlerce veya milyonlarca veri ile uğraşmıyorsa, denormalizasyonun getirdiği karmaşıklık ve maliyetler, sağlayacağı performanstan daha ağır basabilir. Unutmayalım ki, yazılım mimarisindeki en iyi kararlar, genellikle mevcut ihtiyaçlara en uygun ve gelecekteki esnekliği en az kısıtlayan kararlardır. Bir sonraki yazımda, systemd unit’lerinin üretim ortamında nasıl güvenilir çalıştığını ve benim başıma gelen bir cgroup limit hatasını anlatacağım.