<

Araç Takip Sistemlerinde Konum Verisi Mimarisi: Yazma Yükünü Yönetmek

Araç takip sistemleri, yazılım tarafında ilginç bir sorun sunuyor: veri modeli çok basit, yük profili çok zor. Bir konum kaydı yalnızca birkaç alandan oluşur; ama 500 araçlık bir filo, 10 saniyelik aralıkla, günde 4 milyondan fazla satır üretir. Yıllar içinde bu tip projelerde öğrendiğimiz şeyleri toparlayalım.

İlk hata: her şeyi tek tabloda tutmak

En sık gördüğümüz kalıp, tüm konum geçmişinin tek bir konumlar tablosunda büyümesi. İlk altı ay sorunsuz geçer, sonra harita ekranı yavaşlar, ardından raporlar zaman aşımına düşer. Sebep basit: aynı tablo hem çok yoğun yazma hem de zaman aralığı sorguları için kullanılıyor ve indeksler ikisini birlikte iyi yapamıyor.

Uyguladığımız ayrım şu: anlık durum ile geçmiş farklı yerlerde durur. Her araç için tek satır tutan küçük bir "son konum" tablosu, harita ekranını besler ve her zaman hızlı kalır. Geçmiş ise zaman bazlı bölümlenmiş (partitioned) yapıda birikir.

Bölümleme ve saklama politikası

  • Geçmiş tablosunu tarihe göre bölümleyin; aylık bölümler çoğu filo ölçeği için yeterli.
  • Eski bölümleri silmek, satır satır DELETE çalıştırmaktan kat kat hızlı ve şişme üretmiyor.
  • Saklama süresini iş gereksinimiyle ve mevzuatla birlikte kararlaştırın; "her şeyi sonsuza kadar sakla" bir politika değil, kararı erteleme biçimi.
  • Ham kaydı belirli bir süre sonra özetlenmiş hale indirin: dakikalık ortalama, durak ve rölanti özetleri raporların çoğunu karşılıyor.
Üç katman: harita için son konum tablosu, aylık bölümlenmiş geçmiş tablosu ve raporlar için özetlenmiş kayıtlar.
Anlık durum küçük tabloda, geçmiş bölümlenmiş yapıda, rapor verisi özet halinde tutulur.

Yazma yükünü sindirmek

Cihazdan gelen her paketi tek tek INSERT etmek, ölçek büyüdüğünde veritabanını bağlantı ve işlem (transaction) yüküyle boğuyor. İki müdahale neredeyse her projede işe yarıyor. Birincisi toplu yazma: gelen paketleri kısa bir pencerede (bir–iki saniye) tampona alıp tek seferde yazmak, yazma sayısını onda bire indiriyor. İkincisi kuyruk ayrımı: cihaz uçları yalnızca doğrulama yapıp mesajı kuyruğa bırakır, ağır iş (coğrafi sınır kontrolü, hız ihlali, rota eşleme) arka planda çalışır. Böylece cihaz iletişimi, iş kurallarının yavaşlığından etkilenmiyor.

Her cihaz paketini tek tek INSERT etmekle, kısa pencerede toplu yazma ve kuyruk ayrımı kullanmanın karşılaştırması.
Toplu yazma ve kuyruk ayrımı, cihaz iletişimini iş kurallarının yavaşlığından korur.

Coğrafi sorgular ve indeksler

"Bu poligonun içindeki araçlar" veya "şu noktanın 500 metre yakınındaki duraklar" tipi sorgular için enlem/boylam üzerinde sıradan indeksler yetmiyor. PostgreSQL + PostGIS ile mekânsal indeks kullanmak, aynı sorgunun çalışma süresini saniyelerden milisaniyelere indiriyor. MySQL tarafında da mekânsal veri tipleri ve indeksler mevcut; kritik olan, sorgunun indeksi gerçekten kullandığını sorgu planıyla doğrulamak. Bu doğrulamayı atlayan ekipler, indeks eklediklerini sanıp aynı yavaşlıkla yaşamaya devam ediyor.

Bir de dürüst bir uyarı

Konum verisi kişisel veridir. Sürücü bazlı takip yapan bir sistem kurarken erişim yetkilerini, saklama süresini ve kimin hangi raporu görebileceğini baştan tasarlamak gerekiyor. Bunu sonradan eklemek, hem teknik olarak hem kurumsal olarak çok daha pahalı. Rol bazlı erişimi veri modeline en başta yazın.

Cihaz tarafının gerçekleri

Yazılım tarafı ne kadar iyi tasarlanırsa tasarlansın, sahadaki cihazlar ideal davranmıyor. Hesaba katmanız gereken üç durum var. Birincisi kopukluk: araç kapsama alanı dışına çıktığında cihaz veriyi kendi belleğinde biriktirip bağlantı kurulduğunda topluca gönderiyor. Yani "şu anki zaman" ile "kaydın zamanı" aynı olmayabiliyor ve sunucu bunu doğru sıralamak zorunda.

İkincisi saat kayması: cihaz saatine güvenmeyin. Kaydın zamanını cihaz saatine göre alırken, sunucu alış zamanını da ayrı bir kolonda tutun. Aradaki fark, sorun giderirken en çok işe yarayan veri oluyor.

Üçüncüsü gürültü: duran bir araç, GPS hassasiyeti nedeniyle küçük hareketler üretmeye devam ediyor. Bu kayıtları filtrelemeden depolarsanız, hem gereksiz veri birikiyor hem de "kilometre" raporlarınız gerçeğin üzerinde çıkıyor. Basit bir eşik filtresi (örneğin hız sıfırken ve yer değişimi belirli bir mesafenin altındayken kayıt atlama) veri hacmini ciddi oranda düşürüyor.

Araç takip veya filo yönetimi tarafında büyümekte olan bir sisteminiz varsa ya da sıfırdan kuruyorsanız, bu bizim uzmanlık alanlarımızdan biri. İletişim sayfamızdan bize yazın; mevcut yük profilinize bakıp hangi müdahalenin en çok kazandıracağını önceliklendirebiliriz.

📅 Yayınlanma:  ·  Yakup Zengin