Denizcilik Verilerini Yönetmek: TimescaleDB'ye Geçişin Ardındaki Gerçek Hikaye

Dünya denizlerinde seyreden her gemi, sürekli olarak konum, hız, rota ve diğer kritik bilgileri radyo dalgalarıyla yayınlıyor. Bu veriler uydular ve kıyı istasyonları tarafından toplanarak, küresel deniz trafiğinin izlenmesini sağlıyor. VesselAPI olarak, bu devasa veri akışını yöneten bir platform geliştirdik ve ilk yılında MongoDB kullanıyorduk. Peki neden durduk? Aslında bu hikaye, yanlış yapılandırılmış bir etiketin tüm veri hattını nasıl durdurduğunu ve bizi nasıl altı aylık bir geçiş sürecine sürüklediğini anlatıyor.

Veri Akışının Gerçek Yüzü: Zaman ve Mekan Bağımlılığı

Otomatik Tanımlama Sistemi (AIS), denizcilik sektöründe konum takibi için yasal bir zorunluluktur. SOLAS anlaşmasına göre 300 gros tondan büyük ticari gemiler, uluslararası seferlerde bu sistemi kullanmak zorundadır. Sonuç? Her dakika, milyonlarca konum bildirimi sistemimize akıyor. Bu veriler yalnızca koordinat ve zaman bilgileri değil; aynı zamanda gemi kimliği, hız, rota ve diğer telemetri verilerini içeriyor.

MongoDB'de sakladığımız ilk aylarında, bu verileri JSON belgeleri olarak görmek kolaydı. Her konum bildirimi bir belgeydi ve sistemimiz hızla büyürken, esnek şema yapısı geliştirme sürecimizi hızlandırdı. Ancak kısa süre içinde, verilerin doğasıyla ilgili temel bir sorunla karşılaştık: konum verileri belge değil, zaman serisi ölçümleriydi.

Bu verilerle yapılan sorguların çoğu zamana ve mekana odaklıydı: İki saat önceki konumu neydi? Rotterdam Limanı'nın 50 kilometre çevresinde hangi gemiler bulunuyor? İngiliz Kanalı'ndan bu hafta geçen tüm gemiler hangileri? MongoDB, bu tür sorgular için optimize edilmemişti. Zaman aralıklarına göre otomatik olarak gruplandırma, eski verileri otomatik temizleme veya coğrafi olarak yakın noktaları bulma gibi temel ihtiyaçlarımızı karşılamak için ek bileşenlere ihtiyaç duyuyorduk. Tüm bu eklemeler, performansı olumsuz etkiledi ve maliyetleri artırdı.

Aradığımız Veritabanı: Birden Fazla Aracın Yerini Alan Tek Bir Çözüm

Bir öğleden sonra beyaz tahtaya ihtiyaçlarımızı yazarken, sistemimizin karşılaması gereken kritik özellikler ortaya çıktı:

• - Yüksek hacimli zaman serisi verilerini sürekli olarak işleyebilme
• - Verileri otomatik olarak zamana göre bölümlendirme
• - Eski verilerin otomatik olarak sıkıştırılması ve temizlenmesi
• - Küresel koordinatlar üzerinde coğrafi sorgular yapabilme
• - Tam metin aramaları ve ilişkisel sorgular
• - DBA gerektirmeyen, yönetimi kolay bir sistem

Bu gereksinimleri karşılayabilecek bir veritabanı bulmak zordu. InfluxDB zaman serileri için mükemmel olsa da, coğrafi sorgulama desteği sınırlıydı. ClickHouse performans açısından umut vaat etse de, operasyonel karmaşıklığı yüksekti. MongoDB zaten elimizdeydi ve yeterli değildi. TimescaleDB ise bu listedeki tüm ihtiyaçları karşılayan nadir çözümlerden biriydi.

TimescaleDB, PostgreSQL'in çekirdeğine gömülü bir zaman serisi motoru olarak çalışıyor. Bu sayede, hem ilişkisel veritabanı özelliklerinden hem de zaman serisi optimizasyonlarından aynı anda faydalanabiliyorsunuz. PostGIS entegrasyonu coğrafi sorguları kolaylaştırıyor, H3 altıgen indeksleme sistemleriyle mekansal analizler yapılabiliyor ve tam metin aramaları için GIN indeksleri kullanılabiliyor. Üstelik, 30 yıllık PostgreSQL mirası sayesinde son derece güvenilir bir altyapı sunuyor.

Süreçten Öğrendiklerimiz: Hipertablo ve Zaman Pencereleri

TimescaleDB'nin en önemli kavramlarından biri hipertablodur. Dışarıdan bakıldığında sıradan bir PostgreSQL tablosu gibi görünür; INSERT ve SELECT işlemleri yapılabilir, indekslenebilir. Ancak altında, veriler otomatik olarak parçalar (chunks) halinde saklanır. Her parça, belirli bir zaman dilimini temsil eden ayrı bir fiziksel tablodur.

Bu parçalama sistemi, veri yönetimini tamamen değiştiriyor. Örneğin, gemi konum verilerini 1 saatlik parçalara ayırdığımızda, her saatlik veri kümesi kendi içinde bağımsız bir bölüm olarak saklanıyor. 78 saatlik bir saklama politikası belirlediğimizde, TimescaleDB eski parçaları otomatik olarak silip yer açabiliyor. Bu işlem milisaniyeler içinde tamamlanıyor ve milyonlarca satırın tarandığı geleneksel yöntemlere kıyasla devasa bir performans avantajı sağlıyor.

ALTER TABLE vessel_positions SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'mmsi',
  timescaledb.compress_orderby = 'timestamp DESC'
);

SELECT add_compression_policy('vessel_positions', INTERVAL '2 hours');

Sıkıştırma mekanizması da aynı şekilde çalışıyor. Bir parçanın üzerinde iki saatten fazla zaman geçtiğinde, sistem otomatik olarak sıkıştırma işlemi başlatıyor. Bu sıkıştırma sırasında veriler, gemilerin tanımlayıcıları olan MMSI numaralarına göre gruplandırılıyor ve en yeni veriler en önde olacak şekilde sıralanıyor. Bu sayede, belirli bir geminin en son konumunu sorguladığımızda, tüm parçayı açmamıza gerek kalmıyor. Sadece ilgili parçanın ilgili bölümüne erişiyoruz. Bu hem depolama alanından hem de sorgulama performansından ciddi kazançlar sağlıyor.

MongoDB'de eski verileri temizlemek için cron görevleri kullanıyorduk. Bir kez bu görev bir hafta boyunca sessizce başarısız oldu ve kimse fark etmedi — ta ki disk kullanımı alarm verene kadar. TimescaleDB'deyse, sadece saklama politikasını tanımlıyor ve sistemin geri kalanını unutabiliyorsunuz. Veritabanı kendisi tüm yönetimi üstleniyor.

Sonuç: Geleceğe Yönelik Bir Strateji Oluşturmak

Altı ay süren geçiş sürecinde, TimescaleDB'nin vaat ettiği her şeyi yaşadık. Veri hacmimiz arttıkça sistemimiz ölçeklendi, performansımız düştü ve yönetim yükümüz azaldı. MongoDB'deki esneklik avantajı ilk aylarda değerli olsa da, uzun vadede ölçeklenebilirlik ve yönetim kolaylığı TimescaleDB'ye geçişi kaçınılmaz kıldı.

Bugün, küresel deniz trafiğinin izlenmesi için daha sağlam, daha hızlı ve daha verimli bir altyapıya sahibiz. Gelecekteyse, bu verileri yapay zeka destekli tahminler ve otomatik uyarı sistemleri için kullanmayı planlıyoruz. Denizcilik sektöründe veri odaklı kararlar almanın öneminin giderek arttığı bu dönemde, doğru veritabanı seçimlerinin ne kadar kritik olduğunu bir kez daha anladık.