ClickHouse ile Petabayt Ölçekli Verilerde Yüksek Performanslı Analitik Sorgular

Büyük veri kümeleri üzerinde anlık analitik sorgular çalıştırmak, modern sistemlerin karşılaştığı en kritik zorluklardan biridir. Geleneksel ilişkisel veritabanları bu ölçek ve hız gereksinimlerini genellikle karşılayamazken, ClickHouse kolon bazlı mimarisi ve vektörleştirilmiş sorgu işleme yetenekleriyle bu paradigmayı değiştirmektedir. Bu makalede, ClickHouse'un mimarisi, temel optimizasyon teknikleri ve gerçek dünya senaryoları üzerinden yüksek performanslı analitik sorgulamayı nasıl mümkün kıldığını inceleyeceğiz.

ClickHouse Mimarisi: Hızın Temelleri

ClickHouse'un performansı, temel mimari prensiplerine dayanır:

• Kolon Depolama (Columnar Storage): Veriler satır bazlı yerine kolon bazlı depolanır. Bu, özellikle analitik sorgularda (SUM, AVG, COUNT) sadece ilgili kolonların okunmasını sağlar, I/O yükünü dramatik şekilde azaltır ve veri sıkıştırma oranlarını artırır. Aynı veri tipi bir arada depolandığı için daha efektif sıkıştırma algoritmaları uygulanabilir.
• Vektörleştirilmiş Sorgu İşleme: ClickHouse, sorguları tek tek satırlar üzerinde değil, veri blokları (vektörler) üzerinde işler. Bu, CPU önbelleğini daha verimli kullanır ve SIMD (Single Instruction, Multiple Data) komut setlerinden faydalanarak paralel işlem yeteneğini artırır.
• Paralel ve Dağıtık İşlem: Sorgular, küme içerisindeki birden fazla düğümde eş zamanlı olarak işlenir. Distributed tablo motoru, sorguları kümedeki tüm shard'lara dağıtır ve sonuçları birleştirir, böylece petabayt ölçekli verilere yatay ölçeklenebilirlik sağlar.

MergeTree Ailesi: Veri Yapılandırmasının Kalbi

ClickHouse'un temel tablo motoru ailesi MergeTree'dir. Performans ve veri yönetimi için kritik öneme sahip özellikleri barındırır:

CREATE TABLE my_events (    event_id UUID,    event_time DateTime,    user_id UInt64,    event_type LowCardinality(String),    duration_ms UInt32,    attributes Nested(key String, value String)) ENGINE = MergeTree()ORDER BY (user_id, event_time)PARTITION BY toYYYYMM(event_time)TTL event_time + INTERVAL 3 MONTH DELETE;

Yukarıdaki örnekte:

• ORDER BY (user_id, event_time): Verinin diskte nasıl sıralanacağını belirler. Bu, sıralama anahtarına göre filtreleme ve gruplama işlemlerini hızlandırır.
• PARTITION BY toYYYYMM(event_time): Veriyi aylık partisyonlara böler. Sorgular belirli tarih aralıklarını hedeflediğinde, ClickHouse sadece ilgili partisyonları okur, bu da I/O maliyetini düşürür.
• TTL event_time + INTERVAL 3 MONTH DELETE: 3 aydan eski verilerin otomatik olarak silinmesini sağlar, veri yaşam döngüsü yönetimini basitleştirir.

Veri Atlatma İndeksleri (Data Skipping Indexes)

MergeTree motorları, sorgu performansını artırmak için çeşitli veri atlatma indekslerini destekler. Bu indeksler, okuma maliyetini düşürmek için dosya parçalarını (granules) atlayarak çalışır.

ALTER TABLE my_events ADD INDEX event_type_idx event_type TYPE set(1000) GRANULARITY 1;ALTER TABLE my_events ADD INDEX duration_idx duration_ms TYPE minmax GRANULARITY 8;

• TYPE set(1000): Belirli değerlerin bir granule'de bulunup bulunmadığını hızlıca kontrol etmek için kullanılır. Örneğin, event_type IN ('login', 'logout') gibi sorgularda faydalıdır.
• TYPE minmax: Bir granule'deki minimum ve maksimum değeri depolar. duration_ms > 1000 gibi aralık sorgularında etkilidir.

Performans Optimizasyonu ve Sorgu İpuçları

ClickHouse'tan en yüksek verimi almak için sorgu yazımında dikkat edilmesi gereken bazı noktalar:

• PREWHERE Kullanımı: PREWHERE, WHERE koşulundan önce çalışır ve filtreleme için gerekli kolonları okuduktan sonra tüm satırı belleğe yüklemeden filtrelemeyi yapar. Bu, özellikle yüksek oranda filtrelenen ve geniş tablolarda I/O maliyetini önemli ölçüde azaltır.

  SELECT count()FROM my_eventsPREWHERE event_type = 'error'WHERE duration_ms > 500;

• FINAL Anahtar Kelimesinden Kaçınma: MergeTree motorları aynı Primary Key'e sahip satırları arka planda birleştirir. SELECT ... FINAL ifadesi, sorgu anında bu birleştirme işlemini zorlar ve özellikle büyük veri setlerinde ciddi performans maliyeti yaratabilir. Genellikle, en güncel veya benzersiz kayıtları almak için Materialized View'lar veya argMax/argMin gibi fonksiyonlar tercih edilmelidir.
• Aggregate Fonksiyonların Verimli Kullanımı: ClickHouse, birçok özel optimize edilmiş aggregate fonksiyonuna sahiptir (uniq, uniqExact, quantiles, groupArray). Bunları standart SQL fonksiyonlarına tercih etmek genellikle daha hızlı sonuçlar verir.
• Materialized Views: Yoğun okunan, önceden hesaplanmış agregasyonlar veya özetler için Materialized View'lar kullanılabilir. Temel tabloya veri eklendikçe otomatik olarak güncellenirler.

  CREATE MATERIALIZED VIEW mv_daily_errorsENGINE = SummingMergeTree()ORDER BY (event_date, event_type)AS SELECT    toDate(event_time) AS event_date,    event_type,    countIf(event_type = 'error') AS error_countFROM my_eventsGROUP BY event_date, event_type;

Gerçek Dünya Senaryosu: Yüksek Hacimli API Log Analizi

Bir e-ticaret platformunun API Gateway'i saniyede binlerce, günde milyarlarca çağrı alıyor. Her çağrı, yanıt süresi, HTTP durumu, API yolu, kullanıcı ID'si ve hata mesajı gibi verileri içeren bir log kaydı üretiyor. Takım, anlık olarak "son 5 dakikadaki 5xx hata oranları", "belirli bir API endpoint'inin ortalama yanıt süresi" veya "en çok hata üreten kullanıcılar" gibi soruları yanıtlamak istiyor.

Çözüm: ClickHouse ile Log Analizi

Geleneksel bir ilişkisel veritabanında bu tür sorgular saatler sürebilirken, ClickHouse ile saniyeler hatta milisaniyeler içinde sonuç almak mümkündür.

CREATE TABLE api_logs (    timestamp DateTime64(3),    request_id UUID,    http_method LowCardinality(String),    api_path LowCardinality(String),    status_code UInt16,    user_id Nullable(UInt64),    response_time_ms UInt32,    error_message Nullable(String),    client_ip IPv6) ENGINE = MergeTree()ORDER BY (api_path, timestamp)PARTITION BY toYYYYMMDD(timestamp)TTL timestamp + INTERVAL 1 MONTH DELETE;

Bu tablo yapısı, api_path ve timestamp üzerine sıralama yaparak belirli API'lar veya zaman aralıklarındaki sorguları optimize eder. Günlük partisyonlama ise eski verilerin hızlıca taranmasını sağlar.

Örnek Analitik Sorgular:

Son 5 dakikadaki 5xx hata oranları:

SELECT    toStartOfMinute(timestamp) AS minute,    countIf(status_code >= 500 AND status_code < 600) AS error_count,    count() AS total_count,    (error_count / total_count) * 100 AS error_rate_percentFROM api_logsWHERE timestamp >= now() - INTERVAL 5 MINUTEGROUP BY minuteORDER BY minute ASC;

Belirli bir API endpoint'inin ortalama yanıt süresi:

SELECT    api_path,    avg(response_time_ms) AS average_response_time_ms,    quantile(0.95)(response_time_ms) AS p95_response_time_msFROM api_logsPREWHERE api_path = '/api/v1/orders'WHERE timestamp >= today() - INTERVAL 1 DAYGROUP BY api_path;

Burada PREWHERE kullanımı, büyük bir tablonun sadece küçük bir kısmını ilgilendiren sorgularda I/O performansını artırır.

En çok hata üreten kullanıcılar (son 1 saat içinde):

SELECT    user_id,    countIf(status_code >= 500 AND status_code < 600) AS error_countFROM api_logsWHERE timestamp >= now() - INTERVAL 1 HOUR  AND user_id IS NOT NULLGROUP BY user_idORDER BY error_count DESCLIMIT 10;

Bu sorgular, milyarlarca kayıt üzerinde bile ClickHouse'un optimize edilmiş motorları sayesinde saniyeler içinde sonuç döner. Özellikle, zaman serisi verilerinde DateTime64 kullanımı hassasiyet sağlarken, LowCardinality tipi, api_path gibi tekrarlayan string değerlerinin depolanmasını ve işlenmesini optimize eder.

Sonuç

ClickHouse, petabaytlarca veriyi işleme yeteneği, optimize edilmiş kolon bazlı depolama motorları ve vektörleştirilmiş sorgu işleme mimarisiyle analitik sorgularda eşsiz bir performans sunar. Doğru tablo tasarımı, indeksleme stratejileri ve sorgu optimizasyon teknikleriyle, işletmelerin büyük veri yığınları üzerinden anlık içgörüler elde etmesi mümkün hale gelir. Geleneksel sistemlerin darboğaz oluşturduğu senaryolarda ClickHouse, veri analizi süreçlerinde devrim yaratan bir çözüm olarak öne çıkmaktadır.