Veritabanı seçimi bir marka tercihi değil, verinin biçimiyle ilgili bir karar. Aynı projede birden fazlasının bulunması da gayet olağan.
Dört aile
Pratikte karşınıza dört tür çıkıyor: ilişkisel, doküman, zaman serisi ve graf.
Aralarındaki fark hız ya da kapasite değil. Her biri farklı bir soruyu ucuza cevaplamak için kurulmuş. İlişkisel veritabanı “bu siparişin kalemleri neler” sorusuna, zaman serisi “şu iki saat arasında ne oldu” sorusuna, graf ise “bunun bununla bağlantısı nereden geçiyor” sorusuna hazırlıklı geliyor.
Bu yüzden “hangisi daha iyi” sorusunun cevabı yok. Cevabı olan soru şu: elinizdeki veri neye benziyor ve ona en sık ne soruyorsunuz.
İlişkisel veritabanı neden hâlâ varsayılan
Veri tablolara bölünüyor, her satır bir kayıt oluyor ve tablolar birbirine bağlanıyor. Müşteri bir tabloda, siparişleri başka bir tabloda, sipariş kalemleri üçüncüsünde duruyor.
Bu ailenin asıl gücü düzenden çok garantide. Bir işlem ya tamamen oluyor ya da hiç olmuyor. Stoktan düşerken elektrik kesilirse yarım kalmış bir kayıt kalmıyor. Para, stok, sipariş ve personel gibi tutarlılığın pazarlık konusu olmadığı yerlerde bu garanti tek başına belirleyici.
İkinci gücü sorgu dilinin ortak olması. Yıllardır aynı dil kullanıldığı için hem ekip bulmak hem de raporlama aracı bağlamak kolay. Kurumsal yazılımların büyük çoğunluğu bu yüzden hâlâ ilişkisel bir veritabanının üzerinde duruyor ve bunda tuhaf bir yan yok.
Zorlandığı yer, verinin biçiminin sürekli değiştiği ya da her kaydın farklı alanlar taşıdığı durumlar. Şema baştan tanımlandığı için değişiklik ucuz olmuyor.
Doküman veritabanı: her kayıt kendi biçimini taşıyor
Burada veri tabloya değil, kendi içinde bütün duran kayıtlara bölünüyor. Bir kayıt on alan taşıyabiliyor, yanındaki üç alan taşıyabiliyor ve bu bir sorun sayılmıyor.
İşe yaradığı yer, biçimi önceden bilinemeyen veri. Farklı markalardan gelen cihaz mesajları, her müşteride başka alanlar isteyen formlar, dış sistemlerden gelip yapısı zamanla değişen kayıtlar bu tarife uyuyor.
Yanlış anlaşıldığı nokta da burası. Doküman veritabanı çoğu zaman “şema tanımlamakla uğraşmayalım” diye seçiliyor. Tanımlanmayan şema ortadan kalkmıyor, sadece veritabanından çıkıp uygulama koduna taşınıyor. Bir yıl sonra aynı alanın üç farklı isimle yazıldığı ortaya çıkıyor ve o noktada kimse ne olduğunu bilmiyor.
Zaman serisi: ölçüm biriktiğinde
Bir sensör, bir sayaç ya da bir konum etiketi sürekli aynı biçimde kayıt üretiyor: zaman, kaynak, değer. Tek bir kayıt neredeyse hiçbir şey ifade etmiyor, anlam yığının kendisinde.
İlişkisel bir veritabanı bu veriyi de saklıyor, saklamasına. Sorun kapasitede değil, sorulan sorunun biçiminde. Bu veriye tek tek satır sorulmuyor; hep bir aralık soruluyor, hep özet isteniyor. Zaman serisi veritabanları tam bu erişim biçimi için kurulmuş, eski veriyi kendiliğinden özetleyip inceltmek gibi alışkanlıkları da var.
Ayrımı somutlaştıran şey şu: bir forkliftin bugün nerede olduğu ilişkisel bir kayıt. O forkliftin son altı ayda nerelerde durakladığı ise zaman serisi sorusu. Varlık ve ekipman takibi gibi sürekli konum üreten sistemlerde iki soru da aynı anda soruluyor.
Graf: bağlantının kendisi soru olduğunda
Graf veritabanında kayıtlar kadar aralarındaki bağlar da veri sayılıyor. İlişkisel bir yapıda “bu tedarikçiyle şu firma arasında kaç adım var” sorusu her adımda yeni bir bağlantı gerektiriyor ve derinlik arttıkça sorgu ağırlaşıyor. Grafta bağ zaten kayıtlı olduğu için sorunun derinleşmesi maliyeti aynı ölçüde artırmıyor.
Kurumsal işlerde en az rastlanan aile bu. Yetki zincirleri, tedarik ağındaki dolaylı bağlantılar ve dolandırıcılık tespiti gibi belirli yerlerde belirleyici oluyor, onun dışında zorlama duruyor.
Aynı projede birkaçının bulunması normal
Tek bir veritabanı seçip her şeyi ona sığdırma alışkanlığı, bu ailelerin ayrışmasından önceki dönemden kalma.
Bugün sık görülen kurgu şu: sipariş, stok ve personel ilişkisel tarafta duruyor; cihazlardan akan ölçüm ayrı bir yerde birikiyor; raporlama ikisini birleştirilmiş bir görünüm üzerinden okuyor. Üçü birbirine karışmadığı sürece bu bir karmaşıklık değil, sadeleşme oluyor.
Karmaşıklık, aynı bilginin iki yerde ayrı ayrı tutulmaya başlandığı anda geliyor. O noktadan sonra hangisinin doğru olduğu sorusu hiç kapanmıyor.
Yanlış seçim kendini nasıl belli ediyor
Veritabanı kararının yanlış olduğu genelde kararın verildiği gün anlaşılmıyor. İki yıl sonra, birbiriyle alakasız görünen şikayetler olarak çıkıyor.
Rapor ekranı açılırken bekletmeye başlıyor ve zamanla bu bekleme normal karşılanıyor. Gece çalışan bir aktarma işi var ve kimse ona dokunmak istemiyor. Yeni bir alan eklemek isteyince bunun yirmi ayrı yerde karşılığı olduğu ortaya çıkıyor. Veri büyüyor ama neyin silinebileceğini kimse bilmiyor, çünkü hangi kaydın hâlâ okunduğu belirsiz.
Bu belirtilerin ortak yanı, hiçbirinin veritabanı sorunu gibi görünmemesi. Hepsi rapor sorunu, performans sorunu ya da ekip sorunu diye adlandırılıyor.
Bir üretim firmasında nasıl görünüyor
Not: Aşağıdaki örnek gerçek bir müşteriye ait değildir; sahada sık karşılaşılan durumlardan oluşturulmuş bir senaryodur.
Orta ölçekli bir üretim firması, kurumsal yazılımını yıllardır ilişkisel bir veritabanı üzerinde çalıştırıyor. Sipariş, stok, üretim emri ve personel orada duruyor ve bu tarafta bir şikayet yok.
Sonra hatlara sayaç ve sensör konuyor. Yeni veri için ayrı bir yer düşünülmüyor, mevcut veritabanına birkaç tablo ekleniyor. İlk aylarda her şey yolunda görünüyor.
Şikayet raporlama tarafından geliyor. Vardiya raporu önce yavaşlıyor, sonra sabaha karşı çalışan bir işe dönüştürülüyor. Aynı dönemde sipariş ekranı da ağırlaşıyor ve bu ikisi arasında bağ kurulamıyor.
İnceleme yapıldığında ortaya çıkan şey bir hata değil, bir uyumsuzluk. Aynı veritabanının içinde iki farklı türde veri var. Biri gün içinde birkaç bin kayıt üreten, tek tek sorgulanan iş verisi. Diğeri saniyeler içinde biriken, hiçbir zaman tek tek okunmayan ölçüm verisi. İkincisi birincisini boğuyor.
Yapılan iş ölçüm verisini kendi yerine taşımak ve raporlamayı iki kaynağı birleştirip okuyacak şekilde yeniden kurmak oluyor. Kurumsal yazılım tarafında tek satır değişmiyor.
Buradaki asıl ders, seçilen ürünle ilgili değil. Firma bir karar vermediğini sanıyordu; oysa yeni veriyi mevcut yere eklemek de bir karardı ve bedeli iki yıl sonra ödendi.
Codigno tarafında
Kurumsal özel yazılım geliştirme tarafında bir işe başlarken verinin nerede duracağı, ekranlardan önce konuşulan başlıklardan biri oluyor. Sonradan taşımak, baştan doğru yerleştirmekten her zaman pahalı.
Raporlama ve analitik tarafında sık karşılaştığımız durum, verinin dağınık değil fazla toplu olması. Her şeyin tek yerde durması bir süre sonra kolaylık olmaktan çıkıyor.
Sahadan veri akan işlerde bu ayrım daha erken belirginleşiyor: edge ve bulut mimarisi tarafında ölçümün nerede işlenip nerede saklanacağı ayrı bir başlık. Konum verisiyle kurumsal kaydın buluştuğu yeri ise RTLS ve ERP entegrasyonu yazısında ayrıca ele aldık.
Mevcut bir ERP çözümünün üzerine yeni veri kaynağı eklenecekse, ilk soru genelde teknik değil: bu veriye ne sorulacak. Cevabı olmayan veri, nereye konursa konsun birikiyor.
Sık sorulan sorular
İlişkisel veritabanı artık eski mi sayılıyor?
Hayır. Kurumsal yazılımların büyük çoğunluğu hâlâ ilişkisel veritabanı üzerinde çalışıyor ve bunun geçerli bir sebebi var: tutarlılık garantisi. Yeni aileler ilişkiselin yerini almadı, onun zorlandığı yerleri devraldı.
Her şeyi tek veritabanında tutmak yanlış mı?
Kendi başına yanlış değil. Sorun, biçimi ve erişim şekli farklı iki veriyi aynı yere koymakla başlıyor. İş kayıtlarıyla sürekli akan ölçüm verisi bunun en sık görülen örneği.
NoSQL, SQL’den hızlı mı?
Böyle bir genelleme yapılamıyor. Karşılaştırma ancak belirli bir soru için anlamlı oluyor. Aynı iki sistemden biri bir soruda hızlı, başka bir soruda belirgin şekilde yavaş kalabiliyor.
Zaman serisi veritabanına ne zaman gerek duyulur?
Veri sürekli aynı biçimde birikiyorsa ve sorular hep bir zaman aralığı üzerineyse. Tek tek kayıtların değil, aralıkların sorulduğu her yerde bu ihtiyaç eninde sonunda çıkıyor.
Veritabanını sonradan değiştirmek mümkün mü?
Mümkün ama maliyeti verinin miktarından çok, uygulamanın ona ne kadar yapıştığına bağlı. Bu yüzden taşıma işlerinde ilk adım veri değil, mevcut durumun çıkarılması oluyor.
Veri ambarı ile veritabanı aynı şey mi?
Değil. Veritabanı işin yürümesi için, veri ambarı geçmişe bakmak için kuruluyor. İkisi aynı yere sıkıştırıldığında genelde raporlama tarafı önce şikayet ediyor.
Raporunuz ne zamandır bu kadar bekletiyor? Hangi verinin nerede durduğunu ve rapor ekranlarınızın ne zamandır yavaşladığını paylaşın; tıkanmanın gerçekten veri tarafında olup olmadığını birlikte çıkaralım.
