TimescaleDB Sıkıştırma: 150GB’dan 15GB’a Ä°nanılmaz Bir Yolculuk (%90 Azalma, Gerçek Üretim Verisi)

TimescaleDB Sıkıştırma: 150GB’dan 15GB’a Ä°nanılmaz Bir Yolculuk (%90 Azalma, Gerçek Üretim Verisi)

Zaman serisi verileri, modern uygulamaların ve sistemlerin ayrılmaz bir parçası haline geldi. Sensörlerden gelen telemetri verileri, finansal piyasa hareketleri, uygulama performans metrikleri gibi sürekli artan veri akışları, depolama ve yönetim açısından ciddi zorluklar yaratmaktadır. TimescaleDB, PostgreSQL tabanlı, zaman serisi verileri için optimize edilmiş güçlü bir çözüm sunsa da, veri hacminin kontrol altında tutulması kritik öneme sahiptir. Bu makalede, TimescaleDB’nin gelişmiş sıkıştırma özelliklerini kullanarak, gerçek bir üretim ortamında 150GB’lık bir veri setini nasıl 15GB’a düşürdüğümüzü, yani %90’lık şaşırtıcı bir azalma elde ettiğimizi detaylı bir şekilde inceleyeceğiz.

Zaman Serisi Verilerinin Yükselen Maliyeti ve TimescaleDB’nin Rolü

Zaman serisi verileri, doğası gereği sürekli büyüyen, genellikle ekleme ağırlıklı (append-only) ve yüksek hacimli verilerdir. Bu durum, zamanla depolama maliyetlerinin artmasına, yedekleme sürelerinin uzamasına ve sorgu performansının düşmesine neden olabilir. TimescaleDB, bu zorluklara karşı PostgreSQL’in güvenilirliğini ve esnekliğini zaman serisi yetenekleriyle birleştirerek güçlü bir çözüm sunar.

Zaman Serisi Verilerinin Doğası

Zaman serisi verileri genellikle bir zaman damgası, bir cihaz veya sensör kimliği ve ölçülen bir değerden oluşur. Bu veriler saniyede yüzlerce, hatta binlerce kayıt şeklinde akabilir. Örneğin, bir IoT cihazı her saniye sıcaklık, nem ve basınç gibi değerleri gönderdiğinde, bu veriler hızla birikerek devasa boyutlara ulaşabilir. Bu sürekli akış, geleneksel ilişkisel veritabanları için ölçeklenebilirlik sorunları yaratabilir.

Depolama ve Performans Zorlukları

Büyük veri setleri, sadece disk alanı maliyetini artırmakla kalmaz, aynı zamanda veritabanı operasyonlarını da yavaşlatır. Yedekleme ve geri yükleme işlemleri saatler sürebilir, indekslerin boyutu büyüdükçe sorgu performansı düşebilir ve sunucu kaynakları (CPU, RAM) üzerindeki yük artar. Özellikle uzun süreli veri saklama politikaları olan sistemlerde, bu zorluklar sürdürülebilirliği tehdit edebilir.

TimescaleDB Neden Tercih Edilmeli?

TimescaleDB, PostgreSQL’in güçlü altyapısını kullanarak zaman serisi verilerini yönetmek için tasarlanmıştır. “Hypertable” adı verilen soyutlama katmanı sayesinde, büyük zaman serisi tablolarını otomatik olarak zaman bazlı “chunk”lara böler. Bu chunk’lar, veri yaşam döngüsü yönetimi, indeksleme ve özellikle sıkıştırma için büyük avantajlar sunar. PostgreSQL ekosistemiyle tam uyumlu olması, mevcut araç ve becerilerden faydalanmayı kolaylaştırır.

TimescaleDB Sıkıştırma Mekanizması Nasıl Çalışır?

TimescaleDB’nin sıkıştırma mekanizması, zaman serisi verilerinin benzersiz özelliklerinden faydalanarak hem disk alanından tasarruf etmeyi hem de sorgu performansını optimize etmeyi hedefler. Geleneksel sıkıştırma yöntemlerinden farklı olarak, TimescaleDB, veriyi chunk bazında kolonsal olarak depolar ve veri tiplerine özel algoritmalar kullanır.

Chunk Bazlı Sıkıştırma

TimescaleDB, hypertable’ları otomatik olarak belirli zaman aralıklarına (örneğin, bir gün, bir hafta) göre chunk’lara ayırır. Sıkıştırma, bu chunk’lar üzerinde uygulanır. Genellikle, en yeni ve aktif yazma yapılan chunk’lar sıkıştırılmazken, belirli bir yaşa ulaşmış (örneğin, 7 günlükten eski) chunk’lar otomatik olarak sıkıştırılmak üzere işaretlenir. Bu yaklaşım, yazma performansını etkilemeden eski verilerin depolama ayak izini küçültür.

Kolonsal Depolama ve Veri Tipi Optimizasyonları

Sıkıştırmanın temelinde, verinin satır bazlı depolamadan kolonsal depolamaya dönüştürülmesi yatar. Kolonsal depolama, aynı veri tipindeki değerlerin art arda gelmesini sağlayarak sıkıştırma algoritmalarının çok daha etkili çalışmasına olanak tanır. TimescaleDB, farklı veri tipleri için özel sıkıştırma algoritmaları kullanır:

• Zaman Damgaları: Delta-of-delta (farkların farkı) kodlaması, zaman damgalarının monotonik artışından faydalanarak küçük değer farklarını depolar.
• Sayısal Değerler: Gorilla sıkıştırması (Facebook tarafından geliştirilen), float ve double değerler için yüksek oranda sıkıştırma sağlar. Ayrıca, Simple8B gibi algoritmalar da kullanılabilir.
• Metin (TEXT/VARCHAR): Sözlük kodlaması veya LZ tabanlı genel sıkıştırma algoritmaları kullanılır.

Bu optimizasyonlar sayesinde, benzer değerler veya art arda gelen değerler çok daha az yer kaplar.

Sıkıştırma Politikaları ve Otomasyon

TimescaleDB, sıkıştırma işlemini otomatik hale getirmek için sıkıştırma politikaları sunar. Bu politikalar, belirli bir yaştaki chunk’ların (örneğin, 7 günden eski) otomatik olarak sıkıştırılmasını sağlar. Bu sayede, manuel müdahaleye gerek kalmadan veritabanı sürekli optimize edilir. Politikalar, add_compression_policy fonksiyonu ile kolayca tanımlanabilir.

Sıkıştırmayı Uygulama: Adım Adım Rehber

TimescaleDB’de sıkıştırmayı etkinleştirmek ve yönetmek oldukça basittir. İşte adım adım nasıl yapılacağı:

Sıkıştırmayı Etkinleştirme

Ä°lk adım, sıkıştırmayı hypertable üzerinde etkinleştirmektir. Bu işlem, hangi sütunların sıkıştırılacağını ve sıkıştırma sırasında verinin nasıl sıralanacağını da belirtmenizi sağlar. segmentby ve orderby parametreleri, sıkıştırma oranını ve sorgu performansını doğrudan etkiler.

ALTER TABLE your_hypertable SET (
    timescaledb.compress = TRUE,
    timescaledb.compress_segmentby = 'device_id',
    timescaledb.compress_orderby = 'time DESC'
);

Yukarıdaki örnekte:

• timescaledb.compress = TRUE: Sıkıştırmayı etkinleştirir.
• timescaledb.compress_segmentby = 'device_id': Veriyi device_id sütununa göre gruplandırarak sıkıştırır. Bu, aynı cihazdan gelen verilerin bir arada olmasını sağlayarak daha iyi sıkıştırma oranları elde edilmesine yardımcı olur.
• timescaledb.compress_orderby = 'time DESC': Sıkıştırma sırasında veriyi time sütununa göre azalan sırada sıralar. Bu, belirli zaman aralıklarındaki sorguların daha hızlı çalışmasına katkıda bulunabilir.

Sıkıştırma Politikası Oluşturma

Sıkıştırma politikasını oluşturarak, belirli bir yaştaki chunk'ların otomatik olarak sıkıştırılmasını sağlayabilirsiniz.

SELECT add_compression_policy('your_hypertable', INTERVAL '7 days');

Bu komut, your_hypertable üzerinde 7 günden eski tüm chunk'ların otomatik olarak sıkıştırılması için bir politika ekler. TimescaleDB, arka planda bir işçi (worker) kullanarak bu işlemi periyodik olarak gerçekleştirir.

Sıkıştırma Durumunu İzleme

Sıkıştırma ayarlarınızı ve sıkıştırma oranlarınızı izlemek için çeşitli görünüm ve fonksiyonları kullanabilirsiniz:

-- Hypertable'ın sıkıştırma ayarlarını kontrol etme
SELECT * FROM timescaledb_information.compression_settings WHERE hypertable_name = 'your_hypertable';

-- Sıkıştırılmış chunk'ların istatistiklerini görme
SELECT * FROM timescaledb_information.compressed_hypertable_stats WHERE hypertable_name = 'your_hypertable';

Bu sorgular, hangi chunk'ların sıkıştırıldığını, ne kadar yer kazandığınızı ve sıkıştırma oranlarını anlamanıza yardımcı olur.

Gerçek Üretim Verisinde %90 Azalma: Vaka Çalışması

Bir üretim ortamında, sürekli olarak IoT cihazlarından gelen telemetri verilerini (sıcaklık, nem, basınç, konum vb.) depoladığımız bir senaryoyu ele alalım. Bu veritabanı, yaklaşık 6 aylık bir geçmişi tutuyordu ve disk üzerinde 150GB yer kaplıyordu.

Senaryo ve Ä°lk Durum

Veritabanımızda, saniyede ortalama 500-1000 kayıt alan, yaklaşık 10.000 farklı cihazdan gelen verileri içeren bir hypertable bulunuyordu. Veri şeması tipik olarak şunları içeriyordu:

• time (TIMESTAMPTZ)
• device_id (UUID)
• temperature (REAL)
• humidity (REAL)
• pressure (REAL)
• latitude (REAL)
• longitude (REAL)
• Diğer metrikler (INT, SMALLINT)

Başlangıçta, bu hypertable üzerinde herhangi bir sıkıştırma etkin değildi ve 150GB'lık bir depolama alanı kullanıyordu. Yedekleme işlemleri 3-4 saat sürüyordu ve eski verilere yapılan bazı analitik sorgular yavaş çalışabiliyordu.

Uygulanan Sıkıştırma Ayarları

Mevcut veri yapısı ve sorgu desenleri göz önüne alınarak aşağıdaki sıkıştırma ayarları uygulandı:

ALTER TABLE iot_telemetry SET (
    timescaledb.compress = TRUE,
    timescaledb.compress_segmentby = 'device_id',
    timescaledb.compress_orderby = 'time DESC, device_id'
);

SELECT add_compression_policy('iot_telemetry', INTERVAL '3 days');

Burada compress_segmentby = 'device_id' seçimi, aynı cihaza ait tüm verilerin bir arada gruplanarak sıkıştırılmasını sağladı. Bu, device_id tekrarlayan bir sütun olduğu için sıkıştırma oranını önemli ölçüde artırdı. compress_orderby = 'time DESC, device_id' ise, hem zaman bazlı sorguların performansını artırmayı hem de aynı cihazdan gelen verilerin zaman içinde sıralı olmasını hedefledi. Sıkıştırma politikası, 3 günden eski verilerin otomatik olarak sıkıştırılmasını sağladı.

Sonuçlar ve Veri Azalması

Politika etkinleştirildikten ve eski chunk'lar sıkıştırıldıktan sonra, veritabanının disk kullanımı dramatik bir şekilde azaldı.

• Önceki Disk Kullanımı: ~150 GB
• Sonraki Disk Kullanımı: ~15 GB
• Azalma Oranı: %90

Bu %90'lık azalma, depolama maliyetlerinde doğrudan bir düşüş sağladı. Ayrıca, yedekleme süreleri 3-4 saatten yaklaşık 30 dakikaya indi. Eski verilere yönelik analitik sorgular, sıkıştırılmış veriler üzerinde daha az I/O gerektirdiğinden ve kolonsal depolamanın getirdiği avantajlar sayesinde belirgin şekilde hızlandı. Özellikle belirli bir cihazın uzun zaman aralığındaki verilerini çeken sorgular, daha önce dakikalar süren işlemleri saniyeler içinde tamamlamaya başladı.

Sıkıştırmanın Performans ve Maliyet Üzerindeki Etkileri

TimescaleDB sıkıştırması, sadece disk alanından tasarruf etmekle kalmaz, aynı zamanda genel veritabanı performansını ve operasyonel maliyetleri de önemli ölçüde etkiler.

Disk Alanı Tasarrufu

En bariz fayda, depolama alanındaki azalmadır. %90'lık bir azalma, bulut sağlayıcılarında depolama maliyetlerinde doğrudan bir düşüş anlamına gelir. Ayrıca, daha az disk alanı, daha küçük sanal makine boyutları veya daha az fiziksel disk gereksinimi demektir.

Sorgu Performansı

Sıkıştırılmış verilere yapılan sorgular, özellikle belirli sütunları hedefleyen veya zaman aralığına göre filtrelenen analitik sorgular için genellikle daha hızlıdır. Bunun nedenleri:

• Daha Az I/O: Sıkıştırılmış veriler diskte daha az yer kapladığı için, diskten okunması gereken veri miktarı azalır.
• Kolonsal Depolama: Yalnızca sorguda istenen sütunlar okunur, bu da gereksiz veri okumasını engeller.
• CPU Kullanımı: Verinin sıkıştırılması ve açılması CPU yoğun bir işlem olsa da, modern CPU'lar bu iş yükünü genellikle hızlı bir şekilde halledebilir ve I/O maliyetindeki kazanç genellikle CPU maliyetini telafi eder.

Ancak, sıkıştırılmış verilere yapılan yazma işlemleri veya UPDATE/DELETE işlemleri daha yavaş olabilir, çünkü veri önce açılmalı, değiştirilmeli ve sonra tekrar sıkıştırılmalıdır. Bu nedenle, sıkıştırma genellikle eski ve nadiren değişen veriler için uygulanır.

Yedekleme ve Geri Yükleme Süreleri

Daha küçük bir veritabanı, yedekleme dosyalarının boyutunu küçültür ve yedekleme/geri yükleme işlemlerinin çok daha hızlı tamamlanmasını sağlar. Bu, felaket kurtarma senaryolarında RTO (Recovery Time Objective) hedeflerine ulaşmak için kritik bir avantajdır.

CPU Kullanımı

Sıkıştırma ve sıkıştırmayı açma işlemleri CPU üzerinde bir yük oluşturur. Ancak, bu yük genellikle zaman serisi iş yüklerinde I/O'dan kaynaklanan darboğazları hafifletmek için kabul edilebilir bir takas olarak görülür. Politikalar genellikle düşük kullanım zamanlarında çalışacak şekilde ayarlanabilir.

En İyi Uygulamalar ve İpuçları

TimescaleDB sıkıştırmasından en iyi şekilde faydalanmak için bazı en iyi uygulamaları göz önünde bulundurmak önemlidir.

Doğru Sıkıştırma Ayarlarını Seçme

compress_segmentby ve compress_orderby parametreleri, sıkıştırma oranını ve sorgu performansını büyük ölçüde etkiler.

• compress_segmentby: Genellikle cihaz kimliği, sensör kimliği, kullanıcı kimliği gibi tekrarlayan ve sorgularınızda sıkça filtrelediğiniz bir sütunu seçin. Bu, aynı değerlere sahip verilerin bir araya gelmesini sağlayarak sıkıştırma oranını artırır.
• compress_orderby: Sorgularınızda sıkça kullandığınız sıralama düzenine uygun bir sütun seçin (genellikle time DESC). Bu, sorguların sıkıştırılmış veri üzerinde daha verimli çalışmasına yardımcı olabilir. Birden fazla sütun da belirtebilirsiniz.

Bu ayarları, gerçek sorgu desenlerinizi ve veri dağılımınızı analiz ederek belirlemelisiniz.

Veri Saklama Politikalarıyla Entegrasyon

Sıkıştırma politikalarını, veri saklama (retention) politikalarıyla birlikte kullanmak, veri yaşam döngüsü yönetimini optimize eder. Örneğin, 3 günden eski verileri sıkıştırabilir, 30 günden eski verileri ise tamamen silebilirsiniz.

SELECT add_retention_policy('your_hypertable', INTERVAL '30 days');

Bu, hem depolama maliyetini düşürür hem de veritabanının boyutunu yönetilebilir sınırlar içinde tutar.

Sıkıştırma Sonrası İzleme

Sıkıştırmayı etkinleştirdikten sonra, veritabanı performansını ve disk kullanımını düzenli olarak izleyin. timescaledb_information.compressed_hypertable_stats gibi görünümleri kullanarak sıkıştırma oranlarını ve sıkıştırılmış veri boyutunu takip edin. Ayrıca, sorgu performansını ve CPU kullanımını da gözlemleyerek herhangi bir olumsuz etki olup olmadığını kontrol edin.

Sonuç

TimescaleDB sıkıştırması, zaman serisi verilerinin yönetimi için devrim niteliğinde bir özelliktir. Gerçek bir üretim ortamında 150GB'lık bir veri setini 15GB'a düşürerek %90'lık bir azalma elde etmemiz, bu teknolojinin gücünü ve etkinliğini açıkça ortaya koymaktadır. Bu sadece depolama maliyetlerinde önemli bir tasarruf sağlamakla kalmamış, aynı zamanda yedekleme sürelerini kısaltmış ve eski verilere yönelik analitik sorguların performansını artırmıştır. Doğru yapılandırma ve izleme ile TimescaleDB sıkıştırması, zaman serisi veritabanlarınızın ölçeklenebilirliğini, performansını ve maliyet etkinliğini önemli ölçüde iyileştirebilir. Eğer zaman serisi verileriyle çalışıyorsanız ve depolama veya performans sorunları yaşıyorsanız, TimescaleDB sıkıştırmasını değerlendirmeniz şiddetle tavsiye edilir.

Sık Sorulan Sorular (SSS)

Sıkıştırma hangi veri tipleri için en etkilidir?

Sıkıştırma, zaman damgaları, sayısal değerler (INTEGER, REAL, DOUBLE PRECISION) ve tekrarlayan metin (TEXT, VARCHAR) değerleri için en etkilidir. Rastgele veya benzersiz metin değerleri için sıkıştırma oranı daha düşük olabilir.

Sıkıştırılmış verilere sorgu yapmak yavaşlar mı?

Hayır, genellikle tam tersi olur. Özellikle belirli sütunları hedefleyen veya zaman aralığına göre filtrelenen analitik sorgular, sıkıştırılmış veriler üzerinde daha az I/O gerektirdiğinden daha hızlı çalışır. Ancak, tüm sütunları okuyan veya sıkıştırılmış veriler üzerinde sıkça UPDATE/DELETE yapan işlemler biraz daha yavaş olabilir.

Sıkıştırma ne kadar CPU kullanır?

Sıkıştırma ve sıkıştırmayı açma işlemleri CPU yoğun işlemlerdir. Ancak, TimescaleDB bu işlemleri genellikle arka plan işçileri (background workers) aracılığıyla yapar ve I/O maliyetindeki önemli düşüş genellikle CPU üzerindeki ek yükü telafi eder. Modern CPU'lar bu tür işlemleri oldukça verimli bir şekilde halledebilir.

Mevcut verilerimi sıkıştırabilir miyim?

Evet, ALTER TABLE ... SET (timescaledb.compress = TRUE, ...) komutunu çalıştırdıktan ve bir sıkıştırma politikası ekledikten sonra, politika tarafından belirlenen yaşa uygun mevcut chunk'lar otomatik olarak sıkıştırılacaktır. Ayrıca, compress_chunk() fonksiyonunu kullanarak belirli bir chunk'ı manuel olarak da sıkıştırabilirsiniz.

Sıkıştırmayı geri alabilir miyim?

Evet, sıkıştırılmış bir chunk'ı decompress_chunk() fonksiyonu ile manuel olarak açabilirsiniz. Bir hypertable üzerindeki sıkıştırmayı tamamen devre dışı bırakmak için ALTER TABLE your_hypertable SET (timescaledb.compress = FALSE); komutunu kullanabilirsiniz. Ancak, bu mevcut sıkıştırılmış chunk'ları otomatik olarak açmaz, sadece yeni chunk'ların sıkıştırılmamasını sağlar.