Postgres vs ClickHouse: Hibrit Veri Mimarisinde 4 İpucu

Postgres vs ClickHouse: Hibrit Veri Mimarisinde 4 İpucu

Postgres ve ClickHouse’u birlikte kullanarak veri tabanı performansınızı nasıl artıracağınızı ve hibrit mimarideki 4 kritik ipucunu keşfedin.

Modern yazılım mimarilerinde tek bir veri tabanının tüm ihtiyaçları karşılamasını beklemek, genellikle performans darboğazlarına ve yüksek maliyetlere yol açar. Özellikle hem hızlı işlem yapılması gereken (OLTP – Çevrimiçi İşlem İşleme) hem de devasa veri yığınları üzerinde analitik sorgular çalıştırılması gereken (OLAP – Çevrimiçi Analitik İşleme) sistemlerde bu durum net bir şekilde görülür. Bu noktada devreye iki dev oyuncu giriyor: PostgreSQL ve ClickHouse. Bu iki teknolojiyi bir arada kullanarak verilerinizi doğru şekilde bölmek, sisteminizin performansını katlayabilir. Ancak bu bölünmeyi yönetmek ve iki sistemi senkronize tutmak göründüğü kadar kolay değildir. Bu makalede, Postgres ve ClickHouse birlikteliğinden edindiğimiz deneyimlerle geliştirdiğimiz 4 kritik ipucunu ve bu iki sistemi nasıl verimli bir şekilde konuşturacağınızı adım adım inceleyeceğiz.

Postgres ve ClickHouse Nedir?

PostgreSQL, uzun yıllardır kararlılığı, ACID (Atomiklik, Tutarlılık, İzolasyon, Dayanıklılık) uyumluluğu ve zengin özellik setiyle ilişkisel veri tabanı (relational database) dünyasının liderlerinden biridir. Kullanıcı üyelikleri, finansal işlemler, sipariş yönetimi gibi verilerin doğruluğunun ve tutarlılığının kritik olduğu operasyonel işlemler için biçilmiş kaftandır. Ancak milyarlarca satırdan oluşan log (günlük) verileri veya kullanıcı tıklama hareketleri üzerinde anlık analizler yapmaya çalıştığınızda Postgres zorlanmaya başlar.

İşte bu noktada ClickHouse devreye girer. ClickHouse, açık kaynak kodlu, sütun bazlı (column-oriented) bir analitik veri tabanı yönetim sistemidir. Verileri satırlar yerine sütunlar halinde sakladığı için, sadece sorgulanan sütunları diskten okur. Bu durum, milyarlarca satır içeren tablolarda bile milisaniyeler seviyesinde sorgu sonuçları almanızı sağlar. ClickHouse, veri sıkıştırma yetenekleri sayesinde disk alanından da büyük oranda tasarruf etmenize imkan tanır.

Bu iki veri tabanının güçlerini birleştirmek, sisteminizin hem operasyonel hem de analitik olarak kusursuz çalışmasını sağlar. Ancak bu hibrit mimariyi kurarken veriyi nasıl böleceğinizi ve nasıl yöneteceğinizi bilmeniz gerekir.

İlişkisel ve Sütun Bazlı Veri Tabanlarının Farkları Nelerdir?

Postgres ve ClickHouse arasındaki temel fark, verilerin disk üzerinde nasıl organize edildiğidir. Postgres geleneksel bir satır tabanlı veri tabanıdır. Yani bir tabloya yeni bir kayıt eklendiğinde, o kayda ait tüm sütunlar diskte yan yana yazılır. Bu yapı, tek bir kullanıcının bilgilerini güncellemek veya belirli bir siparişin detayını çekmek için mükemmeldir.

ClickHouse ise sütun tabanlı bir mimari kullanır. Aynı sütuna ait tüm veriler diskte ardışık olarak saklanır. Örneğin, “fiyat” sütunundaki tüm değerler bir arada durur. Eğer siz milyonlarca satış verisinin ortalamasını almak istiyorsanız, ClickHouse sadece “fiyat” sütununu okur ve diğer sütunları tamamen görmezden gelir. Bu durum disk G/Ç (Giriş/Çıkış) işlemlerini inanılmaz derecede azaltır.

Bu yapısal farklar nedeniyle, operasyonel verilerimizi Postgres üzerinde tutarken, tarihsel ve analitik verilerimizi ClickHouse üzerine taşımak en mantıklı mimari yaklaşımdır.

Postgres ve ClickHouse’u Birlikte Kullanmanın Avantajları

Bu iki veri tabanını entegre bir şekilde kullanmak, her iki dünyanın da en iyi özelliklerinden yararlanmanızı sağlar. Postgres, uygulamanızın kalbi olmaya devam ederken; ClickHouse, büyük veri analitiği, raporlama panelleri ve kullanıcı davranış analizleri gibi ağır yükleri üstlenir. Bu sayede Postgres üzerindeki CPU ve bellek yükü hafifler, operasyonel veritabanınız her zaman hızlı ve yanıt verebilir durumda kalır.

Ancak bu bölünme (the split) sonrasında karşımıza bazı teknik zorluklar çıkar. Veriler iki farklı yere dağıldığı için tutarlılığı sağlamak, verileri senkronize etmek ve iki farklı veri tabanından tek bir rapor üretmek zorlaşabilir. İşte bu zorlukları aşmanızı sağlayacak ve bu iki sistemi kusursuz bir şekilde birleştirecek 4 pratik ipucunu aşağıda detaylandırıyoruz.

4 Kritik İpucu: Postgres ve ClickHouse Ayrımını Yönetmek

1. Veri Senkronizasyonu (Data Sync) ve Değişim Verisi Yakalama (CDC)

Postgres üzerindeki operasyonel verilerin ClickHouse’a aktarılması sürecinde geleneksel ETL (Ayıkla, Dönüştür, Yükle) süreçleri genellikle yavaş kalır ve sistem kaynaklarını tüketir. Bunun yerine, Postgres’in Write-Ahead Log (WAL – Önceden Yazım Günlüğü) mekanizmasını kullanan CDC (Change Data Capture – Değişim Verisi Yakalama) yöntemlerini tercih etmelisiniz.

Debezium veya ClickHouse’un yerleşik MaterializedPostgreSQL motorunu kullanarak, Postgres’te meydana gelen her INSERT, UPDATE ve DELETE işlemini anlık olarak ClickHouse’a yansıtabilirsiniz. ClickHouse tarafında bu motoru kurmak için aşağıdaki gibi bir SQL komutu kullanabilirsiniz:

CREATE DATABASE postgres_replica
ENGINE = MaterializedPostgreSQL(
    'postgres-host:5432', 
    'db_name', 
    'user_name', 
    'password'
);

Bu motor sayesinde, Postgres üzerindeki tablolarınız otomatik olarak ClickHouse üzerinde replike (kopyalanmış) edilir. Ancak unutmayın, ClickHouse sık güncellemeleri sevmez. Bu nedenle sadece analiz edeceğiniz ve sık değişmeyen tabloları bu yöntemle aktarmak en sağlıklı yaklaşımdır.

2. Hibrit Sorgulama: PostgreSQL FDWs (Foreign Data Wrappers)

Bazı durumlarda, Postgres içindeki güncel kullanıcı verileriyle ClickHouse içindeki milyarlarca satırlık log verilerini birleştirmeniz (JOIN) gerekebilir. Tüm veriyi tek bir yere taşımak yerine, Postgres’in FDW (Foreign Data Wrapper – Yabancı Veri Bağlayıcısı) özelliğini kullanarak Postgres üzerinden ClickHouse’a doğrudan sorgu atabilirsiniz.

Bunun için clickhouse_fdw eklentisini (extension) Postgres sunucunuza kurmanız gerekir. Kurulumdan sonra Postgres içinden sanki yerel bir tabloymuş gibi ClickHouse tablolarına erişebilirsiniz:

-- Eklentiyi etkinleştirme
CREATE EXTENSION clickhouse_fdw;

-- ClickHouse sunucusunu tanımlama
CREATE SERVER clickhouse_server
FOREIGN DATA WRAPPER clickhouse_fdw
OPTIONS (host 'clickhouse-host', port '8123', dbname 'default');

-- Kullanıcı yetkilendirmesi
CREATE USER MAPPING FOR current_user
SERVER clickhouse_server
OPTIONS (user 'default', password 'password');

-- Dış tabloyu tanımlama
CREATE FOREIGN TABLE foreign_clickhouse_logs (
    user_id INT,
    action VARCHAR,
    created_at TIMESTAMP
)
SERVER clickhouse_server
OPTIONS (table_name 'user_logs');

Artık Postgres üzerinde yazacağınız bir sorguda, yerel users tablosu ile dışarıdaki foreign_clickhouse_logs tablosunu birleştirebilirsiniz. Bu yöntem, raporlama ekranlarında büyük bir esneklik sağlar.

3. Veri Tiplemesi (Data Typing) ve Şema Uyumsuzlukları

Postgres ve ClickHouse veri tipleri birebir uyuşmayabilir. Özellikle Postgres’teki esnek JSONB veri tipi ClickHouse tarafında doğrudan bir karşılığa sahip değildir. ClickHouse’da performans elde etmek için veri tiplerini mümkün olduğunca optimize etmelisiniz.

Örneğin, Postgres’teki VARCHAR veya TEXT alanları ClickHouse’da String olarak tanımlanır. Ancak tekrarlayan metin verileri için (örneğin ülke kodları, tarayıcı adları gibi) ClickHouse’un LowCardinality(String) veri tipini kullanmalısınız. Bu, hem disk alanından tasarruf sağlar hem de sorguları hızlandırır.

CREATE TABLE clickhouse_user_actions (
    event_id UUID,
    event_name LowCardinality(String), -- Performans optimizasyonu
    payload String, -- JSON verileri için
    created_at DateTime
) ENGINE = MergeTree()
ORDER BY (event_name, created_at);

Postgres’ten ClickHouse’a veri aktarırken, JSON verilerini düzleştirerek (flattening) ayrı sütunlara bölmek ClickHouse’un sorgu performansını ciddi şekilde artıracaktır.

4. TTL (Time-to-Live) ve Veri Temizliği Yönetimi

Analitik veriler zamanla eskir ve değerini yitirir. Örneğin, 2 yıl önceki kullanıcı tıklama loglarına anlık olarak ihtiyacınız olmayabilir. Postgres’te bu tür eski verileri silmek (VACUUM süreci nedeniyle) disk üzerinde büyük yüke sebep olur. ClickHouse ise bu işlemi yerleşik TTL (Time-to-Live – Yaşam Süresi) özelliği ile çok verimli bir şekilde çözer.

ClickHouse tablonuzu tanımlarken veya sonradan değiştireceğiniz bir tabloya TTL kuralı ekleyerek, belirli bir tarihten eski verilerin otomatik olarak silinmesini veya daha ucuz bir depolama alanına (örneğin AWS S3 gibi) taşınmasını sağlayabilirsiniz:

ALTER TABLE clickhouse_user_actions
MODIFY TTL created_at + INTERVAL 30 DAY;

Yukarıdaki komut, 30 günden eski olan tüm kayıtları arka planda diskten tamamen siler. Bu sayede ClickHouse kümeniz her zaman optimize kalır ve gereksiz disk büyümesinin önüne geçilir.

Gerçek Dünya Senaryosu: Türkiye E-Ticaret Analitiği

Geliştirdiğimiz mimariyi daha iyi anlamak için Türkiye pazarında faaliyet gösteren büyük bir e-ticaret platformunu ele alalım. Bu platformda saniyede binlerce sipariş veriliyor ve aynı zamanda milyonlarca kullanıcı ürün sayfalarını görüntülüyor.

Eğer tüm bu verileri tek bir PostgreSQL veri tabanında tutmaya çalışırsak ne olur? Kullanıcıların sepet adımlarını izleyen analitik sorgular, sipariş veri tabanını kilitleyebilir. Sonuç olarak müşteriler ödeme yapamaz hale gelir ve sistem çöker.

Çözüm Mimarisi:

• PostgreSQL: Sadece kullanıcı bilgileri, sepet içeriği, siparişler ve ödeme işlemlerini yönetir. ACID güvencesiyle finansal tutarlılık sağlanır.
• ClickHouse: Kullanıcıların hangi ürüne tıkladığı, hangi kategorileri gezdiği, arama çubuğuna ne yazdığı gibi tüm “clickstream” (tıklama akışı) verilerini tutar.

Kullanıcı sipariş verdiğinde, bu işlem Postgres’e yazılır. Arka plandaki bir servis (veya CDC mekanizması), sipariş detayını ve kullanıcının o siparişi vermeden önce tıkladığı ürünlerin geçmişini ClickHouse’a asenkron olarak yazar. Pazarlama ekibi bir kampanya başarısını ölçmek istediğinde, ClickHouse üzerindeki milyonlarca satırlık veriyi saniyeler içinde analiz ederek “En çok hangi kategoriden sepete ekleme yapıldı?” sorusunun yanıtını alır. Postgres ise bu sırada sadece yeni siparişleri almaya odaklanır.

İleri Düzey Optimizasyon Teknikleri

Hibrit mimariyi kurduktan sonra performansı daha da yukarı taşımak için bazı ileri düzey teknikleri uygulayabilirsiniz. Bunlardan ilki, ClickHouse’un Materialized Views (Maddileştirilmiş Görünümler) özelliğidir. ClickHouse’daki materialized view yapısı, Postgres’tekinden farklı çalışır. Postgres’te bu görünümleri manuel olarak yenilemeniz (refresh) gerekirken, ClickHouse’da veriler ana tabloya yazıldığı anda otomatik ve gerçek zamanlı olarak hesaplanıp görünüm tablosuna yazılır.

-- Günlük özet tablosu
CREATE TABLE daily_sales_summary (
    day Date,
    total_sales Decimal(18, 2)
) ENGINE = SummingMergeTree()
ORDER BY day;

-- Otomatik hesaplama yapan Materialized View
CREATE MATERIALIZED VIEW mv_daily_sales
TO daily_sales_summary AS
SELECT
    toDate(created_at) AS day,
    sum(price) AS total_sales
FROM clickhouse_user_actions
GROUP BY day;

Bu teknik sayesinde, ham veriler ne kadar büyük olursa olsun, raporlama ekranlarınız her zaman önceden hesaplanmış (pre-aggregated) verileri okur ve anında yanıt verir.

Postgres tarafında ise kısmi indeksler (partial indexes) kullanarak disk alanından ve bellekten tasarruf edebilirsiniz. Sadece aktif olan kullanıcıları veya son 1 aya ait siparişleri indeksleyerek Postgres’in operasyonel sorgu hızını maksimumda tutabilirsiniz.

Sıkça Sorulan Sorular (FAQ)

1. ClickHouse’u birincil veri tabanı (primary database) olarak kullanabilir miyim?
Hayır, ClickHouse bir OLAP veri tabanıdır. ACID işlemlerini (örneğin para transferi veya veri güncellemelerini) tam olarak desteklemez. ClickHouse’da verileri tek tek güncellemek çok maliyetlidir. Bu nedenle operasyonel verileriniz için her zaman Postgres gibi ilişkisel bir veri tabanı kullanmalısınız.

2. Postgres ve ClickHouse arasındaki veri transferi ne kadar gecikmeli (latency) olur?
Bu durum kullandığınız yönteme bağlıdır. Debezium ve Kafka tabanlı bir CDC mimarisi kullanırsanız gecikme süresi 1 saniyenin altında (sub-second) olur. ClickHouse’un MaterializedPostgreSQL motorunda da benzer şekilde saniyeler içinde veri aktarımı gerçekleşir.

3. ClickHouse disk alanını nasıl bu kadar iyi sıkıştırabiliyor?
ClickHouse verileri sütun bazlı sakladığı için benzer veri tipleri diskte yan yana gelir. Örneğin, ardışık binlerce satırda “TR” ülke kodu yazıyorsa, sıkıştırma algoritmaları (LZ4 veya ZSTD) bu tekrar eden verileri çok yüksek oranlarda (bazen 10 kata kadar) sıkıştırabilir.

4. Küçük ölçekli projeler için bu hibrit mimari gerekli midir?
Eğer projenizdeki toplam veri boyutu birkaç gigabaytı geçmiyorsa ve saniyede yüzlerce sorgu almıyorsanız, Postgres tek başına yeterli olacaktır. Postgres’in de analitik sorgular için indeksleme yetenekleri oldukça gelişmiştir. Bu hibrit mimari, veri boyutu yüzlerce gigabayta ulaştığında ve analitik sorgular Postgres’i yormaya başladığında tercih edilmelidir.

Sonuç

Postgres ve ClickHouse, modern veri mimarilerinde birbirini mükemmel şekilde tamamlayan iki harika araçtır. Postgres ile operasyonel verilerinizin güvenliğini ve tutarlılığını sağlarken, ClickHouse ile büyük veri analitiğinin getirdiği hızın keyfini çıkarabilirsiniz. Bu makalede paylaştığımız veri senkronizasyonu, FDW kullanımı, veri tiplemesi ve TTL yönetimi gibi 4 kritik ipucu, bu iki sistemi sorunsuz bir şekilde birleştirmenize yardımcı olacaktır. Unutmayın, en iyi veri tabanı yoktur; doğru iş için doğru şekilde yapılandırılmış veri tabanı kombinasyonu vardır.

#PostgreSQL #ClickHouse #VeriTabani #BigData #YazilimGeliştirme