Herkese merhabalar,

Aslında konuya “timescaleDB nedir?” ile başlamak belki biraz daha doğru olur. Çünkü TimescaleDB aslında bir PostgreSQL eklentisi. Eğer bir sensörün verisini takip etmek isterseniz, zamanla veritabanının şişmeye başladığını ve yazdığınız query lerin cevap süresinin hızla yükseldiğini farketmeye başlarsınız. Sorgularınızı daha hızlı hale getirmek için birkaç yöntem var, bu makalede TimescaleDB çözümünü ele alacağım…

TimescaleDB’yi özel kılan nedir?

Kullandığımız standart veritabanlarında (şema bazlı olanlarda) 2 özellikten sıkça faydalanırız;

1. Primary Key
2. Foreign Key

Bu iki temel özellik sayesinde, tablomuzu dizayn eder, diğer tablolar ile ilişkilerini sağlarız. Ancak elimizde zaman bazlı (ve hızlı çalışmasını istediğimiz) bir veritabanı yapısı olduğu için, stabil çalışabilmesi adına bunlardan tamamen olmasa da bir miktar feragat etmemiz gerekmektedir. Bir timescaleDB tablosunun primary key’i “time” kolonudur ve zorunludur. Bu şekilde oluşturulmuş özel tablolara HyperTable denmektedir. Bunun yerine de “iliskilitabloadi_id” şeklinde çözümler ile ilerlenmekte.

Bu sayede her TimescaleDB tablosu time kolonu üzerinden sorguları ilerletir. Yazacağını query’lerde distinct gibi sıkça ihtiyacınız olanlar içinse buradan performansını nasıl artıracağınıza göz atabilirsiniz. Resmi sitelerinde yayınlanan veriye göre, timescaleDB zaman bazlı verilerde 8000x daha hızlı çalışma kapasitesine sahip. İlgili makaleye buradan ulaşabilirsiniz.

Django ile Entegrasyonu

Standart bir django projesi başlatma adımlarını ekleyerek makaleyi gereksiz şişirmemek adına bu kısmı geçiyorum. Rastgele bir proje oluşturun ve bir app yaratın. Benim örnek projem “TimescaleDBwithDjango” isminde, app adım ise “example_timescaledb”

Projemin dosya hiyerarşisi şu an bu şekilde;

├── example_timescaledb
│   ├── admin.py
│   ├── apps.py
│   ├── __init__.py
│   ├── migrations
│   │   └── __init__.py
│   ├── models.py
│   ├── tests.py
│   └── views.py
├── manage.py
├── templates
└── TimescaleDBwithDjango
    ├── asgi.py
    ├── __init__.py
    ├── settings.py
    ├── urls.py
    └── wsgi.py

Şimdi projemize timescaleDB entegrasyonu yapmak için django-timescaledb paketini yüklüyoruz;

pip install django-timescaledb==0.2.12

Örnek bir veritabanı kurgulamak için bir docker ile timescaledb’yi ayağa kaldırabilirsiniz ya da sitesindeki 30 günlük deneme sürümünden faydalanabilirsiniz. Konuyu dağıtmamak adına cloud üzerinden anlatımıyla devam ediyorum, sitesine şuradan erişebilir, kaydolduktan sonra yeni bir DB nasıl oluşturabileceğinize buradan bakabilirsiniz.

Bir alışkanlık kazandırmak adına, veritabanı bilgilerimize direkt kodun içine yazmak yerine, .env içerisinde tutalım. Bunun için de django-environ kütüphanesinden faydalanabiliriz. TimescaleDB cloud üzerinden aldığımız bilgileri, .env dosyamız içerisine yazıyoruz, settings.py altındaki veritbanı bilgilerimizi de buradan okuyacak şekilde projemizi özelleştiriyoruz;

DATABASES = {
    'default': {
        'ENGINE': 'timescale.db.backends.postgresql',
        'NAME': env("TS_NAME"),
        'USER': env("TS_USER"),
        'PASSWORD': env("TS_PASSWORD"),
        'HOST': env("TS_HOST"),
        'PORT': env("TS_PORT"),
    }
}

Herşey yolunda gittiyse, projeyi başlattığınızda çalışmalı ancak migrationlar ile alakalı size bir uyarı vermelidir;

System check identified no issues (0 silenced).

You have 18 unapplied migration(s). Your project may not work properly until you apply the migrations for app(s): admin, auth, contenttypes, sessions.
Run 'python manage.py migrate' to apply them.
August 16, 2022 - 11:18:49
Django version 4.1, using settings 'TimescaleDBwithDjango.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Bu ekranı görebildiğinize göre, django veritbanına bağlanabildi ve migrationların uygulanmadığı bigisini bize veriyor, şimdi migrationlarımızı uygulayarak önce projenin temel migrationlarını uygulayalım;

python manage.py migrate

Herşey yolunda gittiyse, görmeniz gereken ekran migration ların yanında “OK” yazarak birer birer ilerlemesidir. Ve projeyi tekrar çalıştırdığınız üstteki uyarının kaybolması gerekir;

sezer@optimist ~/P/TimescaleDBwithDjango> python manage.py migrate
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying auth.0012_alter_user_first_name_max_length... OK
  Applying sessions.0001_initial... OK

Hadi ilk timescaleDB tablomuzu oluşturup test edelim, bunun için bir senaryoya ihtiyacımız var. Diyelim ki şu an bizler Tony Stark olarak göğsümüzde taşıdığımız ark reaktörünün güç bilgisini ölçmek istiyoruz. (eğer hala izlemediseniz Iron Man izlemeyerek çok şey kaybediyorsunuz 😀 )

models.py dosyamıza gidip, tablomuzu şu şekilde oluşturalım;

from django.db import models
from timescale.db.models.models import TimescaleModel


class ArcReactor(TimescaleModel):
    voltage = models.FloatField()

Harika! artık bir hypertable sahibiyiz. Hadi bunun veritabanına da kaydedelim;

python manage.py makemigrations
python manage.py migrate

Yeni tablomuzu da oluşturup veritabanına ekledik. Cloud üzerinden test ediyorsanız, arayüzde “services” altında kaç tablonuz olduğunu ve bunlardan kaç tanesinin hypertable olduğunu görüntüleyebilirsiniz;

Eğer ilgi olursa, yazımın 2. serisinde timescaleDB’nin geliştirilmiş SQL sorgularının Django ORM ile nasıl hazırlanabileceğini ve karşılaştırmalı benchmark sonuçlarını da bir makale haline getirmeyi planlıyorum.

Makalenin kodlarına şuradan ulaşabilirsiniz;

https://github.com/Natgho/timescale-with-django

Bir sonraki yazımda görüşmek üzere 🙂