SQL Server ve Veri Madenciliği 1 – Temel raporlama tipleri ve farkları


OLTP

Veritabanlarının geçmişine baktığımızda, ilk ortaya çıkan hizmetin verilerle ilgili işlemlerin bir veritabanında tutulabilmesi ve sorgulanabilmesi olduğunu görürüz. Burada temel birim ‘transaction’ yani işlemdir. İşlem kelimesinin daha genel olması ve veritabanı jargonunda transaction kelimesinin özel bir anlam kazanmış olması sebepleriyle bundan sonra transaction kelimesini kullanıyor olacağım.

Veritabanlarının bu ilk hallerindeki temel yapı tablolar ve bunların arasındaki ilişkilerdir. 1970’lerden itibaren ortaya çıkmış olan ve halen kullanılmakta olan bu yaklaşıma OLTP adını veriyoruz. Yani OnLine Transaction Processing. Görüldüğü gibi temel kavram, transaction’ların işlenmesidir.

OLTP sistemlerinde dört temel eylem vardır: Select, Insert, Update, Delete. Eklenmiş kayıtlardan koşullarını belirttiklerimizi seçebiliriz (Select). Yeni kayıtlar ekleyebiliriz (Insert). Eklenmiş kayıtlarda güncelleme yapabiliriz (Update). Ve eklenmiş kayıtları silebiliriz (Delete). Bu temel komutlara (fonksiyonlar gibi alt unsurları gözardı edecek olursak) sonradan bir tek Merge’in eklendiğini söyleyebiliriz. Ki o da, kaynaktaki verilerle hedefteki verileri karşılaştırıp her bir satır için Insert, Update ya da Delete çalıştırmayı ya da herhangi bir şey yapmamayı içerir.

OLAP

1990’lardan itibaren özellikle çok mekanda işlem yapan ve hem coğrafi ölçekte hem de parasal olarak büyük şirketlerde on yılı aşkın bir süredir OLTP veritabanları kullanılıyordu. Birikmiş veri ortaya bir sorun çıkardı: Bu verilerle başka türlü işlemler de yapılmak isteniyordu. Özellikle raporlama alanında. Verilere tekil transactionlar olarak değil de özetler olarak bakabilmek büyük önem kazanmaya başlamıştı. Ürün gruplarının çeyrekler bazında performanslarının hızlıca karşılaştırılabilmesi… Mağazaların aylık ve yılbaşından beri (year to date) satış verilerinin ürün kategorisinde hızla alınabilmesi… Siparişlerin geçen yıl aynı döneme göre artış oranının hızla elde edilebilmesi… Bu gibi istekler çoğalmaya ve içerik olarak da karmaşıklaşmaya başlamıştı.

istekler iyiydi hoştu da, OLTP’nin T’siyle çelişiyordu. OLTP sistemleri tekil transactionların yönetimi ve takibi için geliştirilmişlerdi. Okuma sorguları kadar yazma sorgularını da desteklemeleri gerekiyordu ve bunlar düşman kardeşlerdi. Okumayı desteklemek için koyduğunuz bir indeks yazma performansını olumsuz etkileyebiliyordu.

İsteklerin ve eldeki sistemlerin yetenekleri arasındaki uyuşmazlık yeni bir kavramın doğmasına yol açtı: OLAP. OnLine Analytical Processing. Bu yeni yaklaşımın temel bakış açısı analitikti. Veriler üzerinde analitik işlemler yapabilmek. Temel olarak özet verilerle hızlı bir şekilde çalışabilmek.

Bir OLTP sistemine bir senedeki dört çeyrek bazında on ürün grubunun satış performasını sorduğunuz zaman, istediğiniz bu 40 veriyi hesaplayabilmek için milyonlarca satırı okuyup toplaması gerekebilir. Oysa OLAP sistemleri bu tür özetleri önceden hesaplamış olur ve arkada milyonlarca satır olsa bile size zaten hesaplanmış bekleyen 40 veriyi saniyeler içinde verebilir.

SQL Server’ın OLAP çözümü SSAS’tir (SQL Server Analysis Services).

OLTP ortamlarında OLAP tipi işler yapmaya çalışmanın sonu yoktur. OLTP ortamları analitik sorgulara cevap vermek üzere geliştirilmiş yapılar değildirler. Bunun birkaç sebebini sıralayalım:

– OLTP sistemleri temel olarak unutkandırlar. Çoğu veride değişiklik durumunda üzerinde güncelleme yaparız. Eski hal yok olmuş olur. Verinin tarihçesini takip etmek için log ya da tarihçe tabloları kullanmak mümkün olmakla birlikte, bu zahmetli bir süreçtir. Raporlanması için de özel çalışma yapmak gerekir. Bu tür çalışmalar da SQL ifadeleri kısıtında hem yazmak hem çalıştırma performansı bakımından zorlayıcıdır.

– OLTP sistemlerinde özet değerler oluşturmak ve bunları yaşatmak zordur. Özet tablolar yapmanızı kimse engellemez. Ama bir özet tabloyu yapmak, yaşatmak, değişiklik taleplerini gerçekleştirmek ciddi anlamda insan emeği ister ve sistem üzerinde de zorlayıcı yükler getirir.

– OLTP sistemlerinde okuma performansını artırmaya yönelik yaptığınız çalışmalar yazma performansında olumsuz sonuçlarla karşınıza çıkar.

– OLTP sistemlerinin temel dili olan SQL analitik ihtiyaçlarda çok temel olan önceki dönemle karşılaştırma, geçen sene aynı dönemle karşılaştırma, sene başından beri toplam alma gibi konularda bile hazır çözümler sunmaz.

Diyelim 100 GB’lık bir veritabanınız olsun. Kaç yıllık veri tuttuğunuza bağlı olarak OLTP türü sorgularda bu verinin yüzde 5 ila 20’sini falan kullanırsınız. 32 GB RAM’i olan bir sunucunuz varsa, max server memory’i diyelim ki 26 GB yaptıysanız, verinin kullanılan kısmının tamamının buffer cache’e alınması için yeterli kaynağınız var demektir. Oysa bu sunucuya biraz geniş aralıklı bir analitik özet sorgusu gelirse işler karışır. Diyelim ki son 5 yılda ürün grubu bazında satışların yıllık grafiğini almak istiyorsunuz. Normal OLTP sorgularının dokunmadığı binlerce sayfayı buffer cache’e almanız gerekir. Memory optimizasyonu bir anda darmadağın olabilir. Uzun süreli bir rapor sorgusuyla eş zamanlı çalışan yazma sorgularının kilitler gibi konular yüzünden uğrayabileceği sıkıntıları saymıyorum bile.

Bu tür analitik sorguları OLTP ortamlarında ne kadar kahramanca gerçekleştirirseniz, bataklığa o kadar çok batarsınız. Çünkü siz başarılı oldukça bir yandan veri miktarı artacak bir yandan da istenen raporların sayısı ve karmaşıklığı artacaktır. Pes edeceğiniz ana kadar devam edeceksiniz demektir bu. Ya da sistem performans açısından pes edene kadar… OLAP tipi bir çözüme gitmek doğru yol olacaktır.

Peki neden veri madenciliği?

Tamam OLAP’ı da yaptık. Peki veri madenciliği nereden çıktı?

Bu verilerden anlam çıkarmaya çalışanların iştahları öyle kabarıktır ki… Cevaplanması gereken o kadar çok soru vardır ki…

OLAP sadece belirli raporlar için değil, aynı veri grubuyla yapılabilecek (bazıları daha önce hiç düşünülmemiş) her türlü rapor için bir altyapı sağlar. Ama bu raporlar insan gözüyle değerlendirilebilecek raporlardır. Yani grupların özet değerlerinin karşılaştırması, trend eğrilerinin incelenmesi gibi insan gözüyle yapılabilecek çalışmalar içindirler.

Oysa bazı sorunlar insan gözüyle yapılabilecek incelemeler kapsamında çözülemezler.

1 milyon müşterim var. Bunlara tekrarlı satışlar yapıyorum. Acaba 6 ay sonra bu müşterilerden hangisinin benimle iş yapmayı bırakmasının ihtimali belirli bir sınırın üstündedir?

Daha önce yaptığım satış kampanyalarında 50 bin kişi ya müşterim oldu ya da bilgilerini edindim. Şimdi yeni bir site inşaatımız var. 2 bin konut satmamız gerekiyor. Acaba bu 50 bin kişiden hangilerine kampanya yapmalıyım. Kullandığım satış yöntemleri pahalı olduğu için tamamını hedeflemek istemiyorum….

100 bin ürünüm var. Bunlardan hangileri bir arada satılıyorlar. Hangi ürünü alanlara hangi ürünleri önermeliyim…

Bu tür sorguların ortak noktaları ne OLTP sorgularıyla ne de OLAP sistemlerinden çekilen özet raporlarla pratik bir şekilde yapılamamalarıdır. Ama neyse ki aslında biraz veritabanı dünyasının dışında gelişen bazı kavramlar, algoritmalar ve diğer çalışmalar karşımıza veri madenciliği diye bir seçenek çıkarmıştır. İşte bu veri madenciliği imkanı SQL Server’da hem de 10 yılı aşkın bir süredir bulunmaktadır.

Bu yazı dizimizin devamında veri madenciliğine daha yakından bakıp SQL Server’da veri madenciliğiyle ilgili neler yapabileceğimizi inceliyor olacağız.

Bu yazı MS İş Zekası, Veri madenciliği içinde yayınlandı. Kalıcı bağlantıyı yer imlerinize ekleyin.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s