Neden Olmasın? : Merkezi Veri Modeli

database-partsNeden Olmasın? serisinin bu ikinci yazısında, farklı uygulamaların ortak bir fiziksel veritabanı ve veri modeli kullanmasını konu alan, kavramsal bir projemden bahsetmek istiyorum.

1940’lardan bu güne kadar programlama dilleri ve yaklaşımları ciddi bir evrim geçirdi. Makine dili ile başlayan bu serüven, yapay zeka kullanarak kodlamanın bilgisayarlar tarafından yaptırılmasına kadar devam eden bir olgunlaşma sürecine girdi. Gelinen son noktada ise; nesne odaklı programlama, servis odaklı mimari, BPEL gibi yazılımların karmaşıklığını azaltmayı ve işletilebilirliğini kolaylaştırmayı amaçlayan yöntemlerle ilgili tartışmalar, yerlerini verinin nasıl modellenmesi gerektiği tartışmalarına bırakmaya başladı. Bu durum ise yazılım dünyasında trendlerin, uygulama katmanı seviyesinden, veri katmanı seviyesine doğru kaymasına neden oldu.

Bilindiği üzere Büyük Hacimli Veri (Big Data) ve İş Zekası (Business Intelligence) gibi alanlar IT dünyasının parlayan yıldızı konumunda. Bu kavramların öne çıkması, verinin değerinin geç de olsa anlaşıldığının, asıl olanın uygulamanın kendisinin değil, sahip olduğu veri olduğunun güzel birer kanıtı.  (bkz: Harvey Nash CIO Anketi 2015)

data-flowİş uygulamalarının görevlerini yerine getirerek veri üretmesi, uçtan uca bakıldığında büyük resmin yalnızca küçük bir parçasını oluşturuyor. Asıl süreç şöyle devam ediyor: bu veriyi toplayan ETL (Extract-Transform-Load) uygulamaları ODS (Operational Data Source) katmanlarına veriyi taşır, buradan belirli biçimlendirme ve hesaplamalar yapılan veri, DWH (Data Warehouse) üzerinde tutulan özet tablolara (Data Mart) aktarılır. Son adım olarak raporlama uygulamaları üzerinden, son kullanıcılara basit arayüzler yardımıyla sunum yapılır. Bu uzun ve yorucu süreç, IT dünyasında aslında veri odaklı düşünmenin ne kadar önemli olduğunu ve eğer süreçleri kolaylaştırıp maliyetleri düşürmek istiyorsak, bu kısıma odaklanmamız gerektiğini gösteriyor.

bb887608.figure4(en-us)Geçmişe dönüp baktığımızda, şimdiye kadar kurgulanan mimarilerin, genelde iki farklı şekilde karşımıza çıktığını görüyoruz :

1- Aynı uygulamanın farklı arabirimleri (masaüstü, web, mobil vb) için bağımsız veritabanlarında tutulan verilerin, ortak bir merkezde toplanması. Bu çözüm ciddi bir replikasyon yükünü beraberinde getirse de, zamanın teknolojik kısıtları nedeniyle (düşük network hızları, sunucu donanımı yetersizlikleri vb) fazla alternatifi bulunmuyordu. Bu da, her ara birim için bağımsız olarak geliştirilen uygulamalara ait verileri, merkezi bir veri katmanında birleştirirken ciddi zorluklar yaşanmasına neden oluyordu.

2- Farklı ara birimlerin, fiziksel olarak bağımsız veritabanları tutmayıp, merkezi bir konumda bulunan ortak veritabanını kullanması. Java, .Net gibi yazılım dilleri sayesinde platformdan bağımsız uygulama geliştirme kolaylığı ve network altyapısındaki iyileşmeler bu modeli olgunlaştırsa da, mimariye bambaşka uygulamalar dahil olması durumunda ilk çözümdekine benzer sorunlar gözlemlenebiliyor. Ayrıca, bağımsız uygulamaların birbirleriyle iletişim kurmasını gerektiren bir entegrasyon mimarisinde, n * (n-1) adet bağlantıyı barındıran bir örümcek ağı ortaya çıkıyor.

Peki Çözüm Ne?

merkezi_veritabaniDeğindiğimiz sorunların en büyük nedeni, ekosistemde bulunan uygulamaların farklı veritabanlarına sahip olmaları. Eğer bütün uygulamalar ortak bir fiziksel veritabanını (ve tabi ki ortak bir şemayı) kullanıyor olsaydı; hem verinin yönetilmesi, hem de uygulamaların birbirleriyle konuşması için çok daha az efora ihtiyaç olacaktı.

Bu konuda bazı çalışmalar yürütülüyor ve SAP Hana gibi platformlar da mevcut. Uygulamaların ortak veritabanı olarak kullanabildiği, in-memory olarak ışık hızında çalışan ve bir OLAP (On-Line Analytical Processing) – OLTP (On-Line Transaction Processing) ortamı sunan bu platformların dezavantajları ise; lisans maliyetleri, donanım bağımlılıkları, firma tekeli oluşması ve aslında arkasında bir iş modeli değil teknoloji sunmaları.

Sonuç olarak, özellikle bünyesinde hatırı sayılır uygulama barındıran orta ve büyük ölçekli işletmelerde, bu tarz bir mimariyi benimsemenin çok fazla faydası olacaktır. Zira günümüzde ulaşılan network bant genişlikleri, sunucu donanım seviyeleri ve sanallaştırma imkanları; tüm uygulamalara hizmet veren ortak veritabanları kullanılabilmesi için uygun altyapılar sunmaya başladı. Bu fiziksel katmana iş modelini de ekleyerek, bütün işletmenin kullanımına açık merkezi veri modelleri oluşturmamak için çok fazla geçerli nedenimiz bulunmuyor.

Bu konuyu bir sonraki yazımızda detaylandırarak incelemeye devam edeceğiz..

Neden Olmasın? : Merkezi Veri Modeli” için 2 yorum

  1. Geri bildirim: Neden Olmasın? : OpenSID Altyapısı | Mustafa Ulus'un Kişisel Blogu

  2. şamil Yanıtla

    büyük şirketler yavaş yavaş bu modeli kullanmaya başladılar zaten. Microsoft da önümüzdeki günlerde ortak veri tabanı olayını hayata geçiricek. Hatta kullananan başka şirketlerde mevcut. Piyasa bu yönde ilerliyor.

Bir Cevap Yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir