Oyun Kitabı

ERP (Enterprise Resource Planning) MySQL Neden Analitik Depo (Store) Değildir? (Erp Mysql Neden Analitik Store Degildir)

Şirket içi ERP’nin yazdığı MySQL operasyonel gerçektir; coğrafi analiz ve bekleme hotspot’ları için temiz bir analitik store gerekir.

PythonHTML 5HTML 5
data-platform mysql erp logistics architecture
1 dk okuma
Faru
Faru

Lojistik Çok Dilli Veri Platformu (Polyglot Data Platform)

Bolum 1 / 10

ERP MySQL’den PostGIS’e temizleme, telemetri için MongoDB ve arama için Elasticsearch ile çok dilli veri platformu.

Logistics polyglot data platform diagram

Yazma gerçeği ≠ okuma gerçeği

Lojistikte araç, sefer ve depo kayıtları çoğu zaman iç ERP üzerinden MySQL’e düşer. Bu store fatura ve stok için doğrudur; ama PostGIS sorguları, bekleme ısı haritası ve MFE okumaları için şema kirli, indeks yanlış, kilit pahalıdır.

Internal ERP
    ↓ writes
 MySQL (operational)
    ↓ cleanse / ETL
 PostgreSQL + PostGIS (analytics)
    ↓ read APIs
 Map UI / Wait Geofence / MFEs

Bu seri, ABC Logistics’te polyglot veri platformunu ve frontend’e temiz okuma sözleşmesini kurar.

Kavramlar ilk geçtiği yerde

📦 Operational Store
ERP’nin yazdığı MySQL — günlük işlem için doğru, analitik için kirli.

📦 Analytics Store
Temizlenmiş PostgreSQL/PostGIS — coğrafi sorgu ve rapor için.

📦 Telemetry Store
Yüksek frekanslı konum olayları için belge/store (MongoDB).

📦 Search Index
Çok varlıklı ops araması için Elasticsearch kümesi.

ERP adını ve şemasını dışarı sızdırmadan, desenini anlatmak yeterlidir.

Neden doğrudan MySQL’e bağlanılmaz

Ops paneli ve harita analitik sorgu atarsa ERP kilitleri uzar; rapor ‘geçici tablo’ya döner.

Temizleme zorunluluğu

Null coğrafya, çift plaka, saat dilimi sapması — ETL bunları PostGIS’e geçirmeden önce keser.

Frontend sözleşmesi

Wait geofence ve sefer haritası yalnızca temiz read API görür.

Frontend ↛ MySQL
Frontend → Analysis API → PostGIS/Mongo/ES

Bu bölümde en çok karışan eşleştirmeler

❌ ERP DB = BI DB
✓ ERP yazma store’udur; BI/GIS ayrıdır

❌ Harita JDBC ile MySQL’e gitsin
✓ Tarayıcı ve SPA asla operational DB görmez

❌ Temizlik opsiyoneldir
✓ Kirli geometri geofence’i bozar

Kendi sisteminizi denetleme listesi

  1. Hangi tablolar hâlâ ‘rapor için’ MySQL’de join ediliyor?
  2. Coğrafi alanlar hangi store’da zorunlu?
  3. Frontend’in gördüğü ilk API katmanı nedir?
  4. ETL gecikmesi operatöre nasıl yansıyor?
  5. PII hangi aşamada maskeleniyor?

Bu bölümden aklında kalması gerekenler

  1. Operational MySQL ile analytics PostGIS ayrılmalıdır.
  2. Frontend yalnızca temiz read model tüketir.
  3. Geofence ve ısı haritası kirli ERP satırına dayanamaz.

ERP’yi analitik sanmak, kasayı mikroskop sanmaktır.

SSS

Sık sorulan sorular

Operational Store nedir?

ERP’nin yazdığı MySQL — günlük işlem için doğru, analitik için kirli.

Analytics Store nedir?

Temizlenmiş PostgreSQL/PostGIS — coğrafi sorgu ve rapor için.

"ERP DB = BI DB" doğru mu?

ERP yazma store’udur; BI/GIS ayrıdır

Bu bölüm neyi sabitler?

Bu seri, ABC Logistics’te polyglot veri platformunu ve frontend’e temiz okuma sözleşmesini kurar. Lojistikte araç, sefer ve depo kayıtları çoğu zaman iç ERP üzerinden MySQL’e düşer. Bu store fatura ve stok için doğrudur; ama PostGIS sorguları, bekleme ısı haritası ve MFE okumaları için şema kirli, indeks yanlış, kilit pahalıdır.

Ogrenilen Muhendislik Prensipleri

  • ERP MySQL yazma gerçeğidir, analitik gerçeği değildir.
  • Coğrafi analiz PostGIS (veya eşdeğeri) ister.
  • SPA/MFE operational database’e bağlanmaz.

Okumaya devam et

Okumaya devam et

Seride sonraki yazi

Ayni seriden

Ayni seriden

Paylaş