OLTP vs raporlama şeması: denormalize mi yoksa özet tablolar mı eklemeli?

Neden OLTP ve raporlama şeması farklı yönlere çeker

OLTP (online transaction processing) uygulamanızın gün boyu yaptığı şeydir: hızlı ve güvenli olması gereken birçok küçük işlem. Bir sipariş oluşturmak, durum güncellemek, ödeme eklemek, bir mesaj kaydetmek. Veritabanı hızlı insert ve update'ler, sıkı kurallar (ör. foreign key'ler) ve sadece birkaç satırı okuyacak basit sorgular için optimize edilir.

Raporlama ise başka bir iştir. Bir pano ya da BI tarzı ekran genellikle pek çok satırı taramak, bunları gruplayıp dönemleri karşılaştırmak ister. “Bu müşteriyi göster” yerine “geliri haftalık, bölgeye göre, ürün kategorisine göre filtrelerle göster” gibi sorular sorar. Bu da geniş okumalar, agregasyonlar, birkaç tablo arasında join'ler ve tekrar eden hesaplamalar anlamına gelir.

İşte OLTP ile raporlama şeması kararlarının temel gerilimi: yazmaları temiz ve tutarlı yapan yapı (normalleştirilmiş tablolar, çok sayıda ilişki) genellikle analitiği ölçeklendiğinde yavaş veya maliyetli kılar.

Tek bir şema bazen ikisini de karşılayabilir, özellikle başlangıçta. Ancak veri büyüdükçe genellikle şu tür takasları hissetmeye başlarsınız:

• İşlem ekranları hızlı kalır, ama panolar her ay yavaşlar.
• “Tek bir basit grafik” birçok join içeren karmaşık bir sorguya dönüşür.
• Aynı metrik birden fazla yerde hesaplanır ve tutarsızlık başlar.
• Yeni bir filtre eklemek riskli sorgu değişiklikleri gerektirir.

Bu yüzden ekipler genellikle şu taktiklerden birini (veya birkaçını) seçer: sık kullanılan dilimler için belirli alanları denormalize etmek, tekrar eden toplamlar için özet tablolar eklemek ya da raporlama görünümlerini (bazen ayrı bir raporlama şeması ile) ayırmak. Böylece OLTP performansı korunurken sayılar tutarlı kalır.

İşlem ekranları ile BI ekranları arasında ne değişir

İşlem ekranları ve BI ekranları aynı iş gerçeklerini gösterebilir, ama veritabanınızdan zıt şekillerde davranmasını isterler. Bu gerilim OLTP ile raporlama şeması kararının özüdür.

İşlem ekranlarında çoğu istek az sayıda satıra dokunur. Bir kullanıcı sipariş oluşturur, müşteri düzenler, ödeme iadesi yapar ya da durum değiştirir. Veritabanı birçok küçük insert ve update ile meşguldür ve her birini hızlı ve güvenli şekilde onaylaması gerekir.

BI ekranları farklıdır. Okuma ağırlıklıdır. Tek bir pano görünümü haftalarca veriyi tarayabilir, bunları gruplayıp sıralayabilir ve çeşitli şekillerde filtreleyebilir. Bu sorgular genellikle geniş (çok sayıda sütun) olur ve birden fazla iş alanından veri çekebilir.

Sorgular nasıl değişir

OLTP ile normalleştirilmiş tablolar ve temiz ilişkiler işinize yarar. Veriyi tutarlı tutar, çoğaltmayı önler ve bir gerçeği tek bir yerde güncellersiniz.

BI ile join'ler darboğaz haline gelebilir. Panolar genellikle kullanıcıların filtrelediği alanları (tarih, bölge, ürün kategorisi, sahip) önceden içeren daha geniş tablolarla daha iyi çalışır. Bu, okuma zamanında join işini azaltır ve sorguları basitleştirir.

Farkı hızlıca şöyle özetleyebilirsiniz:

• İşlem ekranları: çok sayıda küçük yazma, hızlı nokta okumalar
• BI ekranları: daha az istek ama gruplayan ve filtreleyen ağır okumalar
• OLTP verisi: tutarlılığı korumak için normalleştirilmiş
• BI verisi: join ve taramaları azaltmak için yeniden şekillendirilmiş

Eşzamanlılık ve tazelik

OLTP güncellemeler için yüksek eşzamanlılığa ihtiyaç duyar. Uzun süren raporlama sorguları bu güncellemeleri engelleyebilir veya yavaşlatabilir, özellikle geniş aralıklar tarandığında.

Tazelik beklentileri de değişir. Bazı panolar neredeyse gerçek zamanlı olmalı (destek kuyrukları gibi). Diğerleri saatlik veya günlük yenileme ile yetinir (finans, performans). Zamanlanmış yenilemeye izin verirseniz, özet tablolar, materialized view'lar veya ayrı bir raporlama şeması kullanma özgürlüğü kazanırsınız.

AppMaster ile bu ekranları oluşturuyorsanız, erken planlamak yardımcı olur: işlem modelinizi temiz tutun, sonra raporlama verisini özellikle pano filtreleri ve agregatları için şekillendirin.

Raporlama için ayarlama yapmanız gerektiğini gösteren işaretler

Uygulamanız günlük işlemler için hızlı hissettirirken panolar yavaşsa, klasik OLTP vs raporlama şeması ayrımını görüyorsunuz demektir. İşlem ekranları genelde birkaç satıra hızlıca dokunur. BI tarzı ekranlar çok sayıda satırı tarar, gruplayıp aynı matematiği birçok şekilde tekrarlar.

Basit bir işaret zamanlamadır: geliştirmede kabul edilebilir olan pano sorguları üretimde sürünmeye başlar veya yoğun kullanımda zaman aşımına uğrar. Raporlama iş yükleri ayrıca “ani” veritabanı CPU artışı olarak da görülür, uygulama trafiği sabit kalırken. Bu genellikle veritabanının büyük tabloları join ve aggregate etmek için çok çalıştığı anlamına gelir, daha fazla kullanıcı hizmet etmek değil.

En yaygın işaretler şunlardır:

• Bir soruyu cevaplamak için panolar birçok tablo arasında join gerektiriyor.
• Aynı hesaplamalar (gelir, aktif kullanıcılar, ortalama işlem süresi) birden fazla grafik ve sayfada tekrarlanıyor.
• İnsanlar aynı toplamları gün, hafta, ay bazında sıkça istiyor ve her istek yeni bir ağır sorgu tetikliyor.
• BI sorguları normal kullanıcılar kayıt oluşturup düzenlerken yavaşlıyor veya zaman aşımına uğruyor.
• Veritabanı CPU'su artarken OLTP trafiği ve yazma hacmi sabit kalıyor.

Pratik bir örnek: satış ekibiniz bir “performans” ekranı açar ve siparişleri temsilci ve aya göre gruplar, sonra bölge, ürün ve kanal ile filtreler. Her filtre değişikliği aynı toplamları yeniden hesaplayan çoklu join sorgusunu tekrar çalıştırıyorsa, her seferinde tam maliyeti ödüyorsunuz demektir.

AppMaster gibi bir platformda dahili araçlar kuruyorsanız, raporlama sayfasının yanıtlı kalmak için karmaşık arka uç mantığı gerektirdiğini gördüğünüz nokta genellikle denormalizasyon, özet tablolar veya ayrı raporlama görünümlerinin “iyiye sahip olmak”tan gerekli hale geldiği andır.

Ne zaman denormalize etmek doğru tercih

Denormalizasyon, raporlama ihtiyaçlarınız öngörülebilirse mantıklıdır. Aynı birkaç pano sorusu her hafta sıkça soruluyorsa ve nadiren değişiyorsa, veriyi bu sorulara göre şekillendirmek; her grafiğin cevabını birçok tablodan birleştirmek zorunda bırakmaktan daha karlı olabilir.

Bu, OLTP ile raporlama şeması kararlarında sık karşılaşılan dönüm noktalarından biridir: işlem ekranları temiz, güncellemeye uygun tablolar isterken BI ekranları daha az join ile hızlı okumalar ister. Analitik için birkaç alanı kopyalamak, her sayfa yüklemesinde beş tabloyu join etmekten daha ucuz olabilir.

Denormalize edin quando bunun size hız ve daha basit sorgular kazandırdığından emin olun ve yazma yolunu güvenli tutabildiğiniz sürece. Anahtar, çoğaltılan alanları türetilmiş veri olarak görmek, kullanıcıların düzenleyebileceği “başka bir alan” olarak değil. Tek bir doğruluk kaynağı tutun ve her kopyanın kod veya kontrollü bir süreç tarafından güncellendiğinden emin olun.

İyi adaylar şunlardır:

• Panolarda sürekli okunan ama nadiren düzenlenen alanlar (müşteri adı, ürün kategorisi)
• Tekrarlayan şekilde pahalı join gerektiren ilişkiler (çoktan-çoğa ilişkiler, derin zincirler)
• Hızlı filtreleme ve gruplama için gereken alanlar (bölge, ekip, plan seviyesi)
• Güvenilir bir tablodan kopyalanabilecek ve kolayca doğrulanabilen alanlar (serbest metin değil)

Sahiplik önemlidir. Birisi (veya bir iş) çoğaltmaları tutarlı tutmaktan sorumlu olmalı ve kaynak değiştiğinde ne olacağını belirten net bir kural olmalı.

Örnek: bir satış panosu siparişleri temsilci ve bölgeye göre grupluyorsa, her seferinde Orders -> Customers -> Regions join'ini yapmak yerine sipariş oluşturulurken order üzerine region_id saklayabilirsiniz. Bir müşteri sonradan bölge değiştirirse kuralınız “tarihi siparişler orijinal bölgeyi korur” veya “geçmiş siparişler gececeleri arka planda güncellenir” olabilir. Birini seçin, belgeleyin ve uygulayın.

AppMaster ile PostgreSQL kullanıyorsanız, bu tür denormalize alanları Data Designer'da modellemek kolaydır; yeter ki kimlerin yazabileceğini kilitleyin ve tutarlı güncellemeyi sağlayın.

Denormalizasyonda kaçınılması gereken tuzaklar

Denormalizasyon BI ekranlarını hızlandırabilir, ama aynı zamanda “iki gerçeğin” ortaya çıkmasını kolaylaştırır. En yaygın hata, aynı gerçeği birden çok yerde tekrar etmek ve sayılar uyuşmadığında hangi alanın esas olduğunu belirtmemektir. Eğer hem order_total hem de satır öğeleri saklıyorsanız, order_total'ın hesaplanıp hesaplanmadığını, kullanıcının mı girdiğini yoksa ödeme sağlayıcısından mı kopyalandığını açıklayan tek bir kuralınız olmalı.

Bir diğer tuzak sık değişen alanları denormalize etmektir. Müşteri durumu, hesap sahibi, ürün kategorisi veya bölge atamaları zaman içinde değişme eğilimindedir. Bu alanları birçok tabloya kolaylık için kopyalarsanız, her değişiklik bir temizlik işi haline gelir ve kaçırılan güncellemeler yanlış pano dilimlerine yol açar.

OLTP yolunda çok geniş tablolarla dikkatli olun. Aynı tablonun üzerine çok sayıda denormalize sütun eklemek yazmaları yavaşlatabilir, kilit sürelerini arttırabilir ve basit güncellemeleri gereksiz ağırlaştırabilir. Bu, events, order lines veya support messages gibi yüksek hacimli tablolarda özellikle acı vericidir.

Dokümantasyon çoğu ekibin beklediğinden daha önemlidir. Bakım planı olmayan bir denormalize sütun zaman bombasına benzer: insanlar raporlarda buna bakıp güvenir ve iş akışı değiştikten sonra güncellenmeyi bıraktığını fark etmezler.

Pratik örnek: “Satışa göre temsilci” panosu için her order üzerine rep_name eklediniz. Bir temsilci yeniden adlandırıldığında veya yeniden atandığında geçen çeyreğin sayıları iki isim arasında bölünür. Eğer isim gösterimi gerçekten gerekiyorsa, stabil bir rep_id saklamayı ve isim çözümünü raporlama görünümünde yapmayı düşünün veya ismi kasıtlı olarak rep_name_at_sale gibi net bir etiketle snapshot'layın.

Denormalize etmeden önce şu temelleri doğrulayın:

• Her tekrar edilen değer için doğruluk kaynağını tanımlayın ve yazın.
• Değişken metin alanları yerine stabil ID'leri tercih edin.
• Güncel durum raporlaması mı yoksa zaman noktasında snapshot mı istediğinize karar verin.
• Net bir bakım mekanizması ekleyin (trigger, job veya iş akışı adımı) ve bir sahibi atayın.
• Uyumsuzlukları izleyecek basit mutabakat sorguları ekleyin, böylece hatalar erken ortaya çıkar.

AppMaster ile PostgreSQL kullanıyorsanız, bakımı bir Business Process adımına bağlamak işleri tutarlı hale getirir; yani güncellemeler “birisi hatırladığında” değil, tanımlı iş akışlarıyla gerçekleşir.

Özet veya agregat tabloları ne zaman eklemeli

Özet tablolar, BI tarzı ekranlarınız aynı toplamları tekrar tekrar istiyorsa mantıklıdır: günlük kayıtlar, plana göre gelir, aktif kullanıcılar, iadeler, kapatılan biletler ve benzeri KPI'lar.

Tekrar eden işler iyi bir işarettir. Birden çok pano kartı neredeyse aynı GROUP BY ile çalışıyorsa, veritabanı aynı işi sürekli tekrar eder. Bu 1.000 satırda iyi hissettirebilir, 10 milyon satırda acı verir. OLTP vs raporlama şeması tartışmasında bu genellikle indeksleri ince ayarlamayı bırakıp ön hesaplama yapmaya başladığınız andır.

Ayrıca özet tablolar tahmin edilebilir hız gerektiğinde eklenir. Grafiklerin saniyeler içinde yüklenmesi gerekir, bazen hızlı bazen yavaş değil. Özet tablo pahalı taramaları küçük aramalara çevirir.

Özet tablonun yardımcı olacağını gösteren tipik tetikleyiciler:

• Pano aynı GROUP BY'ı birçok ekranda veya filtrede tekrar ediyor.
• Zaman kovalarıyla sıkça sorgulama yapıyorsunuz (gün/hafta/ay) ve top-N listeleri.
• Temel tablolar ekleme-ağırlıklı (events, transactions, logs).
• Paydaşlar bilinen bir kesme zamanı için sabit KPI sayılarını bekliyor (ör. "gece yarısı itibarıyla").

Yenileme stratejisi kararın diğer yarısıdır. Tazelik ihtiyacına göre birkaç pratik seçenek var:

• Zamanlanmış yenileme (her 5 dakika, saatlik, gecelik) öngörülebilir iş yükü için.
• Anahtar işlemler sonrası olay tabanlı yenileme (yeni sipariş, abonelik değişikliği) neredeyse gerçek zamanlı gerektiğinde.
• Hibrit: zamanlanmış backfill + küçük artımlı güncellemeler.

Tabloyu odaklı ve sade tutun: granül açık olmalı (ör. gün başına plan başına bir satır) ve sütunlar panoların doğrudan okuduğu metrikler olmalı. AppMaster'da bunu PostgreSQL'de saklayıp Business Process ile zamanlanmış veya olay sonrası yenileme ile doldurmak yaygın bir yaklaşımdır.

Özet tablo tasarım adım adım

Özet tablo, OLTP ile raporlama şeması arasında kasıtlı bir uzlaşmadır: ham ayrıntılı tabloları tutar ve sıkça sorulan pano sorularını hızlı yanıtlayacak daha küçük bir tablo eklersiniz.

1) Önce granülü seçin

Bir satırın ne anlama geldiğine karar verin. Yanlış karar verirseniz, her metrik ileride açıklaması zor hale gelir. Yaygın granüller gün başına müşteri başına, sipariş başına veya ajan başına gün başına olabilir.

Granülü test etmek için basit bir yol: tek bir satır kesinlikle benzersiz şekilde tanımlanabiliyor mu? Eğer hayırsa, granül hâlâ belirsiz demektir.

2) Tabloyu sorulara göre tasarlayın, ham verilere göre değil

BI ekranlarının gerçek olarak gösterdiği birkaç sayıyı seçin. Sadece ihtiyacınız olanları saklayın: sum ve count genelde yeterlidir, ayrıca min/max gerektiğinde. "Benzersiz müşteriler" göstermeniz gerekiyorsa, kesin distinct ihtiyacı mı yoksa yaklaşık bir yöntem mi kullanılacağına karar verin ve bunu açıkça belgeleyin.

Pratik adım sırası:

• 5–10 pano sorusu yazın (ör. "ajana göre günlük satış")
• Çoğunu bir satırla cevaplayan granülü seçin
• Sütunları sadece agregatlar olarak tanımlayın (sum, count, min, max, belki distinct)
• Filtrelerinize uyan anahtarlar ve indeksler ekleyin (tarih, agent_id, customer_id)
• Geç gelen değişikliklerin nasıl ele alınacağını tanımlayın (iadeler, düzenlemeler, iptaller)

3) Güvenebileceğiniz bir yenileme yöntemi seçin

Batch yenileme en kolay anlaşılırdır (gecelik, saatlik). Artımlı yenileme daha hızlıdır ama "ne değişti" mantığını dikkatlice ele almayı gerektirir. Trigger tarzı güncellemeler neredeyse gerçek zamanlı olabilir, ama kontrolsüzse yazma performansına risk ekleyebilir.

AppMaster ile yaygın bir desen, dün ve bugünü yeniden hesaplayan zamanlanmış bir iş çalıştırmak, eski günleri donmuş bırakmaktır.

4) Mutabakat kontrolleri ekleyin

Özet tabloya güvenmeden önce ham tablolarla karşılaştıran birkaç temel kontrol ekleyin:

• Bir tarih aralığı için toplamlar kabul edilebilir bir tolerans içinde eşleşiyor mu
• Aynı filtreler için sayımlar (siparişler, kullanıcılar, biletler) eşleşiyor mu
• Birkaç varlığı uçtan uca elle kontrol edin (bir ajan, bir müşteri)
• Eksik günler (missing days) ve çift kayıtlar (aynı anahtar iki kez) tespit edin

Bu kontroller başarısızsa, başka metrikler eklemeden önce mantığı düzeltin. Hatalı ama hızlı bir pano, yavaş ama doğru olandan daha kötüdür.

Ayrı raporlama görünümleri ve şemalar: hangi sorunları çözer

OLTP tablolarınızı temiz tutmak büyük ölçüde doğrulukla ilgilidir. Net kurallar, güçlü kısıtlar ve kötü veri üretmeyi zorlaştıran bir yapı istersiniz. Raporlama ekranları ise daha az join, daha dostça isimler ve okunmaya hazır metrikler ister. Bu uyumsuzluk genellikle ekiplerin çekirdek tabloları değiştirmek yerine bir raporlama katmanı eklemesine sebep olur.

Bir raporlama görünümü (veya ayrı bir raporlama şeması) çeviri katmanı gibi davranır. Uygulamanız normalleştirilmiş tablolara yazmaya devam eder, BI tarzı ekranlar ise "aylık", "bölgeye göre" veya "en iyi 10 ürün" gibi sorulara yönelik tasarlanmış nesnelerden okur. Bu, OLTP vs raporlama şeması gerilimini işlem mantığını bozmadan çözmenin genellikle en basit yoludur.

Görünümler vs materialize edilmiş kopyalar

Mantıksal görünümler veri hacmi orta düzeyde ve sorgular öngörülebilir kaldığında iyidir. Tek doğruluk kaynağını korur ve pano sorgularındaki tekrar eden mantığı azaltır.

Materialize edilmiş kopyalar (materialized view'lar, özet tablolar veya replike edilmiş tablolar) raporlama yükü ağır, hesaplamalar pahalı veya tepe saatlerde kararlı performans gerektiğinde mantıklıdır.

Hızlı seçim kuralı:

• Okunabilirlik ve tutarlı tanımlar ön plandaysa mantıksal görünümler kullanın.
• Panolar yavaşsa veya çekirdek yazmalarla yarışıyorsa materialized kopyalar kullanın.
• Mantığın karmaşık olduğu veya net bir sahiplik sınırı istediğinizde ayrı raporlama şeması kullanın.
• Raporlama yazma gecikmesini etkiliyorsa replika veya ayrı veritabanı kullanın.

Raporlama yazmalarla rekabet ettiğinde

Eğer bir pano geniş taramalar veya büyük join'ler çalıştırıyorsa, aynı veritabanında işlemleri engelleyebilir veya yavaşlatabilir. Bir read replica veya ayrı raporlama veritabanı yazma yolunu korur. Tanımları raporlama tarafında görünüm olarak tutarak tutarlılığı koruyabilirsiniz.

Örnek: destek ekibinin her birkaç saniyede "SLA durumuna göre açık biletler" gösteren panosu varsa ve OLTP sistemi biletleri sürekli güncelliyorsa, görünümleri (veya önceden hesaplanmış durum sayımlarını) bir replika üzerine koymak panoyu hızlı tutar ve bilet güncellemelerini tehlikeye atmaz. AppMaster projelerinde bu desen, işlem veri modelinizi temiz tutarken raporlama dostu nesneleri panolara sunmaya yardımcı olur.

Gerçekçi bir örnek: satış performans panosu oluşturmak

İş bir Sales panosu ister: günlük gelir, günlük iadeler ve son 30 gün için "en iyi ürünler" listesi. İşlem ekranlarında OLTP veritabanı temiz ve normalleştirilmiştir: orders, payments, refunds ve line items ayrı tablolarda durur. Bu doğruluk ve güncellemeler için iyidir, ama pano şimdi birçok satırı tarayıp join'ler yapmalı ve günlere göre gruplaymalıdır.

İlk gün, dikkatli bir sorgu, iyi indeksler ve birkaç ince ayarla kabul edilebilir hız elde edebilirsiniz. Ama hacim arttıkça OLTP vs raporlama şeması takasları yapmaya başlarsınız.

Seçenek A: daha hızlı filtreleme için denormalize et

Pano çoğunlukla filtreleme ve dilimleme yapıyorsa, hafif bir denormalizasyon yardımcı olabilir. Örneğin, sorgunun ekstra join gerektirmeden filtreleyebilmesi için bazı stabil alanları order (veya line item) satırına kopyalayın.

İyi adaylar nadiren değişen alanlardır: ürün kategorisi veya satın alma anındaki satış bölgesi gibi. Kaynak doğruluğunu normalleştirilmiş tablolarda tutun, ama BI sorgularını hızlandırmak için sorgu-dostu bir kopya saklayın.

Seçenek B: grafikler ve sıralamalar için günlük özet tablolar

Pano grafik ve top listelerde ağırsa, özet tablolar genellikle kazanır. daily_sales gibi günlük bir fact tablosu oluşturun: date, gross_revenue, refunds, net_revenue, orders_count gibi sütunlar. "Top products" için date ve product_id anahtarıyla daily_product_sales tablosu ekleyin.

Tazelik ve maliyet seçimlerini şöyle düşünebilirsiniz:

• Dakikalar içindeki near-real-time gerekliyse: denormalize edip canlı sorgu ya da özetleri çok sık yenileyin.
• Saatlik veya gecelik güncelleme uygunsa: özetler sorgu süresini dramatik biçimde düşürür.
• Yüksek trafikli panolar: özetler OLTP tablardaki yükü azaltır.
• Karmaşık iş kuralları (iade zamanlaması, kısmi ödemeler): özetler sonuçları tutarlı ve test edilmesi kolay hale getirir.

AppMaster gibi araçlarda bu genellikle temiz bir işlem veri modeli ve hızlı panolar için özet tabloları dolduran ayrı, zamanlanmış bir işlem olarak eşleşir.

Yavaş panolara ve yanlış sayılara neden olan yaygın hatalar

En yaygın hata deseni OLTP yazmaları ile BI okumalarını aynı tablolar üzerinde karıştırmak ve birkaç ek indeksin her şeyi düzelteceğini varsaymaktır. Panolar genellikle çok sayıda satırı tarar, gruplayıp sıralar. Bu, bir siparişi kaydetmek veya bir bileti güncellemekten farklı bir iştir. Tek bir şemaya ikisini de zorladığınızda ya işlemler yavaşlar ya pano zaman aşımına uğrar.

Diğer sessiz bir problem, pahalı işi gizleyen "güzel" bir raporlama görünümüdür. Görünümler sorguyu basit gösterir, ama veritabanı yine de her seferinde join'leri, filtreleri ve hesaplamaları çalıştırmak zorunda kalır. Haftalar sonra biri "bir alan daha" ekleyince pano bir gecede yavaşlar. Görünüm yapılan işi gizlemiştir ama iş miktarını değiştirmemiştir.

Özet tablolar hızı çözer ama drift (sapma) riski yaratır. Agregatlar zamanlanmış olarak yeniden inşa ediliyorsa geride kalabilir. Artımlı güncelleniyorlarsa kaçırılan bir job veya hata toplamları günlerce yanlış bırakabilir. Bu yüzden ekipler panodaki sayılarla işlem ekranlarının sayılarının eşleşmemesinden şaşırırlar.

Metrik tanımı değişiklikleri en büyük kafa karışıklığını yaratır. "Gelir" başlangıçta ödenmiş faturalar iken sonra iadeler düşüldükten sonra olabilir, ardından "tahakkuk eden gelir" haline gelebilir. Mantığı versiyonlamadan üzerine yazarsanız geçen ayın grafiği değişir ve kimse panoya güvenmez.

Bunların çoğunu önleyen pratik kılavuzlar:

• Ağır pano sorgularını yazma-ağır işlem yollarından mümkünse ayırın (en azından ayrı raporlama tabloları olsun).
• Görünümleri kod gibi ele alın: değişiklikleri inceleyin, performansı test edin ve hangi join'leri yaptığını belgeleyin.
• Özet tablolar için tazelik kontrolleri ekleyin (son güncelleme zamanı, satır sayıları, temel toplamlar) ve bozulduğunda uyarı verin.
• Temel metrikleri versiyonlayın ve geçmiş raporlar için eski tanımları saklayın.

AppMaster üzerinde PostgreSQL kullanıyorsanız, bu kurallar daha da önem kazanır çünkü hızlı iterasyon yapmak kolaydır. Hız iyidir ama sayılar doğru kaldığı sürece.

Şemayı değiştirmeden önce hızlı kontrol listesi

Tabloları ellemeden önce panolarınızın gerçekten ne yaptığını yazın. En önemli pano sorgularınızla başlayın (yaklaşık 10 hedefleyin) ve her birinin ne sıklıkta çalıştığını not edin: her sayfa yüklemesi, her dakika veya biri filtreye tıkladığında mı. Günde 500 kez çalışan bir sorgu ile haftada iki kez çalışan bir sorgu için farklı çözümler gerekir.

Sonra matematiği kontrol edin. Hangi metriklerin toplanabilir (additive) ve hangilerinin özel mantık gerektirdiğini işaretleyin. Gelir, adet ve toplam çağrılar genelde toplanabilir. Dönüşüm oranı, ortalama sipariş değeri ve benzersiz müşteriler ise değildir. Bu adım en yaygın raporlama hatasını önler: hızlı ama yanlış sayılar.

Şimdi her sorgu tipine uygun bir tasarım seçin. OLTP vs raporlama şeması kararları için tek bir küresel cevaba ihtiyacınız yok. Erişim modeline uyanı seçin:

• Ekranlar birkaç alanı hızlıca istiyorsa denormalize edin.
• Aynı gruplayı (gün, temsilci, bölge) tekrar eden sorgular için özet tablo kullanın.
• Mantık karmaşıksa veya işlem yazmalarından temiz bir sınır istiyorsanız ayrı raporlama görünümleri veya şeması kullanın.

Her metrik için "yeterince taze" ne demek olduğunu belirleyin, sonra bir doğrulama kuralı koyun. Örnek: "Panodaki günlük siparişler, o tarihteki orders tablosundaki sayıyla %0.5 içinde eşleşmeli" veya "Toplam gelir yalnızca fatura-posted durumuna göre mutabık olmalı."

Son olarak sahipliği kararlaştırın. Kim (veya hangi küçük grup) şema değişikliklerini onaylar ve metrik tanımlarına sahip olur? AppMaster'da bu tanımları veri modeli ve iş süreçleriyle birlikte yakalarsanız aynı mantık ekranlar ve raporlar arasında tutarlı şekilde kullanılır.

Sonraki adımlar: bir yol seçin ve güvenli uygulayın

OLTP vs raporlama şeması kararlarını bir yeniden tasarım projesi değil, bir performans hatası gibi ele alın. Ölçümlerle başlayın. En yavaş 2–3 pano sorgusunu bulun, ne sıklıkta çalıştıklarını not edin ve şekillerini yakalayın: büyük join'ler, zaman filtreleri, top-N listeleri ve tekrar eden toplamlar.

Kullanıcı tarafından görülen sorunu düzelten en küçük değişikliği seçin. Eğer pano bir join nedeniyle yavaşsa hedefli bir denormalizasyon veya hesaplanmış bir sütun yeterli olabilir. Aynı toplamlar tekrar tekrar hesaplanıyorsa küçük bir özet tablosu işinizi görebilir. BI ekranları büyümeye devam edip işlem trafiğiyle yarışıyorsa ayrı bir raporlama görünümü veya şeması riski azaltır.

Sayılara güveni koruyan güvenli bir uygulama akışı:

• Panonun hedefini (zaman aralığı, gruplama, yenileme ihtiyaçları) ve bir kabul metriğini tanımlayın (ör. 2 saniyenin altında yükleme).
• Aynı anda sadece bir değişiklik yapın (bir denormalize alan, bir özet tablo veya bir raporlama görünümü).
• Toplamları OLTP kaynağına karşı sabit bir test penceresi ile doğrulayın (dün, son 7 gün, son tam ay).
• Kademeli olarak yayınlayın ve bir hafta boyunca performans ile doğruluğu izleyin.
• "Sorgu süresi" ve "satır sayıları" için uyarılar ekleyin, böylece sessiz drift erken yakalanır.

AppMaster ile çalışıyorsanız, OLTP varlıkları (işlem ekranları ve düzenlemeler için kullanılanlar) ile raporlama varlıkları (BI tarzı sayfaları besleyen okuma-odaklı modeller) arasında temiz bir ayrım planlayın. BI ekranlarını web UI oluşturucuda gerçekçi filtreler ve tarih aralıklarıyla prototipleyin, sonra kullanıcıların gerçekten tıkladığı şeylere göre veri modelini ayarlayın.

Gerçek kullanımın bir haftası sonra ne yapılacağına karar verin. Hızlı düzeltme işe yarıyorsa yineleyin. Toplamlar maliyetli olmaya devam ediyorsa özet tablolara yatırım yapın ve net bir yenileme planı belirleyin. Raporlama kritik ve ağır hale geldiyse, raporlama iş yüklerini ayrı bir depoya taşımayı düşünün ve OLTP'yi hızlı, güvenli yazmalara odaklayın.