Operasyonel mi, Analitik mi? Fiyat Verisini İki Veritabanında Tutmanın Mantığı

Operasyonel ve analitik veri nasıl ayrılır? Milyonlarca fiyat kaydında Senkrondata’nın OLTP ve OLAP katmanlarını neden ayırdığını anlatıyoruz.

Bir yanda 200'den fazla crawler, her gün milyonlarca fiyat satırı yazıyor. Diğer yanda bir müşteri, "son 6 ayda bu 50.000 üründeki fiyat trendini göster" diyen bir rapor istiyor. Bu iki iş, kulağa "aynı veri" gibi gelse de, veritabanına bindirdikleri yük tamamen farklıdır — ve bunları aynı sistemde karıştırmak, ikisini de yavaşlatır.

Bu, veri mühendisliğinin klasik bir ayrımıdır: operasyonel (OLTP) ve analitik (OLAP) iş yükleri farklı optimizasyon ister.

İki farklı yük, iki farklı doğa

Operasyonel yazma şöyle görünür: bir crawler bir ürünün fiyatını günceller — tek satır, sık tekrar eden, düşük gecikmeli bir işlem. Bunun garantisi şudur: yazma anında veri tutarlı olmalı, iki eşzamanlı güncelleme birbirini bozmamalı. Bu, satır bazlı güncellemeler için optimize edilmiş, ilişkisel bir veritabanının doğal alanıdır.

Analitik okuma şöyle görünür: "geçen ay fiyatı en çok değişen 1.000 ürün hangileri, kategoriye göre kırılımı nasıl?" Bu sorgu milyonlarca satırı tarar, gruplar, toplar. Satır bazlı bir veritabanında bu tür bir sorgu, sistemi dakikalarca kilitleyebilir — tam da crawler'ların o an yazmaya çalıştığı tabloların üstünde.

Aynı veritabanına her iki yükü de bindirmek, ikisi arasında bir çekişmeye yol açar: ağır bir rapor sorgusu çalışırken günlük veri toplama yavaşlar ya da tersi.

Çözüm: yaz bir yerde, oku başka bir yerde

Bu çekişmeyi çözmenin standart yolu, iki katmanı fiziksel olarak ayırmaktır:

1. Operasyonel katman: crawler'ların ve entegrasyonların yazdığı, "şu anki doğru durum"u tutan, satır bazlı ilişkisel veritabanı.
2. Analitik katman: operasyonel katmandan düzenli aralıklarla mirror'lanan (kopyalanan), kolon bazlı, büyük taramalar ve toplamalar için optimize edilmiş ayrı bir depo.

Mirror işlemi tek yönlüdür: veri operasyonelden analitiğe akar, tersi olmaz. Raporlama motoru neredeyse tamamen analitik katmandan okur — operasyonel veritabanına dokunmadan, onu yormadan.

Bunun pratikte kazandırdığı

• Raporlama hızı: milyonlarca satır üzerinde çalışan bir aylık rapor, saniyeler içinde döner çünkü kolon bazlı depo tam bu tür sorgular için tasarlanmıştır.
• Kesintisiz veri toplama: en ağır rapor çalışırken bile crawler'lar yazmaya devam eder; ikisi birbirini bloklamaz.
• Bağımsız ölçekleme: yazma yükü arttıkça (yeni crawler'lar eklendikçe) ya da okuma yükü arttıkça (daha fazla rapor/analiz) iki katman birbirinden bağımsız büyütülebilir.

Doğruluğu koruyan ilkeler

• Tek doğruluk kaynağı operasyonel katmandır. Analitik katman bir kopyadır; çakışma durumunda operasyonel katman esas alınır.
• Mirror'un kendi tazelik garantisi vardır. Analitik katman "az önce" değil, "en son senkronize edildiğinde" doğrudur — bu farkın bilinmesi, raporun ne kadar güncel olduğunu yorumlamak için gerekir.
• Yazma ve okuma birbirine karışmaz. Bir rapor sorgusu asla operasyonel katmana, veri toplamayı yavaşlatacak şekilde dokunmaz.

Sonuç

"Aynı veriyi" iki farklı amaç için iki farklı şekilde saklamak israf gibi görünebilir ama tam tersidir — bu ayrım, hem kesintisiz veri toplamayı hem de hızlı, ağır raporlamayı aynı anda mümkün kılan tasarımdır. Ölçek büyüdükçe bu ayrımın değeri de büyür.

Milyonlarca kayıt üzerinde hem hızlı toplama hem hızlı raporlama istiyorsanız, Senkrondata ekibiyle konuşun.