OLAP ve OLTP aynı modelle düşünülmez
PostgreSQL gibi OLTP sistemlerde veri tutarlılığı ve küçük transactionlar ön plandadır. ClickHouse gibi OLAP sistemlerde ise büyük veri taraması, sıkıştırma, sıralama anahtarı ve okuma hızı öne çıkar.
Bu yüzden OLTP’de normalleştirdiğiniz veriyi ClickHouse’a birebir taşımak her zaman iyi fikir değildir. Analitik sorgu çoğu zaman “son 30 günde kategoriye göre gelir” gibi geniş taramalar yapar; bu sorguda gereken bazı boyutların fact tablo içinde bulunması işleri hızlandırabilir.
- OLTP modeli yazma tutarlılığına yakındır.
- OLAP modeli okuma ve agregasyon hızına yakındır.
- Denormalizasyon analitikte bilinçli performans tercihidir.
- Kopyalanan boyutların ne zaman güncelleneceği yine yazılmalıdır.
Wide table ne zaman mantıklı?
Event tablosuna tenant_name, plan_name, country, device_type gibi boyutları eklemek bazı raporları çok hızlandırabilir. Sorgu tek tabloyu okur, gereksiz join yapmaz ve ClickHouse sıkıştırması tekrar eden değerlerde genellikle iyi çalışır.
Ama wide table her şeyi içine atalım demek değildir. Sık değişen, büyük metin taşıyan veya raporda nadiren kullanılan alanları kopyalamak disk ve veri güncelleme borcu üretir.
Analitik event tablosu örneği
CREATE TABLE analytics.events ( event_date Date, tenant_id UInt64, tenant_plan LowCardinality(String), country LowCardinality(String), event_name LowCardinality(String), revenue_cents UInt64 ) ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (tenant_id, event_date, event_name);
Star schema ve dictionary hâlâ değerlidir
Her boyutu fact tabloya kopyalamak zorunda değilsiniz. Küçük ve daha sık güncellenen boyutlar için dictionary veya ayrı boyut tablosu daha iyi olabilir. Özellikle kullanıcı segmenti, ürün kategorisi veya kampanya bilgisi zamanla değişiyorsa karar dikkat ister.
ClickHouse dictionary, küçük boyut verisini hızlı lookup için kullanışlıdır. Bu, tamamen normalize model değil; analitik okuma hızını korurken bazı verileri ayrı yönetme yoludur.
- Sık kullanılan düşük kardinaliteli boyutlar wide table içinde iyi çalışabilir.
- Sık değişen boyutlar dictionary veya ayrı tabloyla daha yönetilebilir olabilir.
- Büyük metin alanlarını fact tabloya kopyalamak disk maliyetini artırabilir.
- Karar query_log ve gerçek rapor sorgularıyla doğrulanmalıdır.
Tutarlılık beklentisini doğru yazın
Analitik sistemde bazı değerlerin birkaç dakika gecikmeli güncellenmesi kabul edilebilir. Ama finans raporu, fatura veya müşteri sözleşmesi gibi alanlarda gecikme ve tutarsızlık kabul edilemeyebilir.
Bu yüzden ClickHouse modelinde normalizasyon tartışması teknik olduğu kadar ürün kararıdır. Rapor ne kadar güncel olmalı, eski event hangi boyut adıyla görünmeli, değişen kategori geçmiş raporu değiştirmeli mi? Bu sorular cevaplanmadan tablo tasarımı tamamlanmış sayılmaz.