Kubernetes Üzerinde Az Veri İçeren Veritabanı İçin PostgreSQL ve TimescaleDB Storage Kıyaslaması

Source: Dev.to

Amaç

Kubernetes üzerinde iki ayrı kurulum yapıp (vanilla PostgreSQL + TimescaleDB) küçük bir veri setiyle storage kullanımını kıyaslamak.

Not: TimescaleDB zaten PostgreSQL üzerinde çalışır. Burada “TimescaleDB kurulumu” dediğimiz şey, içinde PostgreSQL + Timescale extension bulunan ayrı bir kurulumdur. “Vanilla PostgreSQL” de kuruyoruz ki sonuçlar daha net olsun.

Ön koşullar

• Çalışan bir Kubernetes cluster’ı ve kubectl erişimi
• Helm
• Kurulum tek‑node’lu bir cluster’da yapılmıştır ve StorageClass local‑path’tir.

1. Aşama – Kurulum

1.1 Namespace

kubectl create namespace database

1.2 Helm repo’ları

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add timescaledb https://charts.timescale.com
helm repo update

2. Aşama – Vanilla PostgreSQL (Bitnami) kurulumu

postgres-values.yaml oluşturun

# postgres-values.yaml içeriği burada tanımlanacak

Not: İki ayrı pod’a bağlanıyoruz. Aynı işlemleri iki farklı DB kurulumunda da çalıştıracağız.

5. Aşama – Küçük veri setiyle test

Aşağıdaki SQL’i her iki ortamda da uygulayacağız:

• PostgreSQL’de sensor_pg normal tablo olacak.
• TimescaleDB’de sensor_ts hypertable olacak.

Veri az olsun diye 1 gün üretelim.

5.1 PostgreSQL

psql içinde:

CREATE TABLE sensor_pg (
  time        TIMESTAMPTZ NOT NULL,
  device_id  INT,
  temperature FLOAT
);

CREATE INDEX sensor_pg_time_idx ON sensor_pg(time);

INSERT INTO sensor_pg
SELECT
  generate_series(NOW() - INTERVAL '1 day', NOW(), INTERVAL '1 minute'),
  (random() * 10)::int,
  random() * 100;

SELECT count(*) FROM sensor_pg;

5.2 TimescaleDB

psql içinde:

CREATE EXTENSION IF NOT EXISTS timescaledb;

CREATE TABLE sensor_ts (
  time        TIMESTAMPTZ NOT NULL,
  device_id  INT,
  temperature FLOAT
);

SELECT create_hypertable('sensor_ts', 'time');

CREATE INDEX sensor_ts_time_idx ON sensor_ts(time);

INSERT INTO sensor_ts
SELECT
  generate_series(NOW() - INTERVAL '1 day', NOW(), INTERVAL '1 minute'),
  (random() * 10)::int,
  random() * 100;

SELECT count(*) FROM sensor_ts;

Not: TimescaleDB’de hypertable tek tablo gibi görünür ama arka planda chunk’lara ayrılır. Az veri testinde bile en az bir chunk oluşur.

6. Aşama – Storage ölçümü

İki seviyede ölçüm yaparak daha somut sonuçlar elde ederiz:

1. Relation size (SQL ile) – tablo + index boyutları
2. Data directory (filesystem ile) – gerçek disk kullanımı

6.1 PostgreSQL – SQL ile tablo boyutu

SELECT
  pg_size_pretty(pg_table_size('sensor_pg'))        AS table_only,
  pg_size_pretty(pg_indexes_size('sensor_pg'))      AS indexes,
  pg_size_pretty(pg_total_relation_size('sensor_pg')) AS total;

6.2 TimescaleDB – SQL ile hypertable (chunk bazında) boyutu

SELECT
  pg_size_pretty(SUM(pg_table_size(chunk.id::regclass)))   AS table_only,
  pg_size_pretty(SUM(pg_indexes_size(chunk.id::regclass))) AS indexes,
  pg_size_pretty(SUM(pg_total_relation_size(chunk.id::regclass))) AS total
FROM show_chunks('sensor_ts') AS chunk(id);

Açıklama: Hypertable fiziksel olarak chunk tablolardan oluşur; bu yüzden gerçek data + index boyutu chunk’ların toplamıdır.

7. Benim ortamımdaki çıktı

PostgreSQL

postgres=# SELECT count(*) FROM sensor_pg;
 count 
-------
 1441
(1 row)

TimescaleDB

postgres=# SELECT count(*) FROM sensor_ts;
 count 
-------
 1441
(1 row)

(Devam eden ölçüm sonuçları ve karşılaştırmalar burada eklenebilir.)

7.1 SQL (relation) boyutları

Tabloların ve indexlerin PostgreSQL içinde kapladığı alanlar.

PostgreSQL (sensor_pg)

 table_only | indexes | total  
------------+---------+--------
 112 kB     | 48 kB   | 160 kB
(1 row)

TimescaleDB (sensor_ts)

 table_only | indexes | total  
------------+---------+--------
 112 kB     | 72 kB   | 184 kB
(1 row)

table_only iki tarafta da aynı iken indexes kısmı Timescale tarafında daha fazla.

8. Neden Timescale küçük veride daha büyük çıkabiliyor?

• TimescaleDB tarafında hypertable fiziksel olarak chunk tablolardan oluşur. Her chunk kendi tablo/index yapısını taşır.
• Küçük veri setlerinde bu yapı “overhead” olarak daha görünür olur.

Sonuç: Üzerinde çok veri olmayan bir tablo senaryosunda, Timescale hypertable’ın chunk/index overhead’i yüzünden PostgreSQL biraz daha küçük göründü.