İlişkisel veri tabanı ve ilişkisel olmayan veri tabanları karşılaştırma.

İlişkisel veri tabanı ve ilişkisel olmayan veri tabanları karşılaştırma.

Uzun zamandır bu konuya kafa yorup NOSQL tarafında çalışmalar yapmaya başladım.

Hatta daha sonrasında yaptığım çalışmaları da sizlerle paylaşacağım.

Fakat öncelikle bu iki kavramı iyi anlamak ve iyi irdelemek gerekiyor diye düşünüyorum.

İlk olarak ilişkisel veri tabanlarının ne olduğunu irdelememiz gerekiyor,

En meşur ilişkisel(RDBMS) veri tabanları Sybase, MS SQL Server, Postgre SQL(Açık kaynak kodlu), MySQL(Açık kaynak kodlu), Oracle (Kendi alanında kraldır), IBM DB2 gibi sektörde iz bırakmış ve kendini ıspatlamış veri tabanlarıdır.

İlişkisel veri tabanları scale up veri tabanı tipidir. Yani veri büyüdükçe veri tabanının çeperi büyür. Öyle bir yapı düşünün ki içine veri attıkça bu daire büyür. Çok büyük veriler için bu yapı teorik ve pratik olarak büyümek zorundadır. Hatta bu tarz yapılarda en temel anlamda bir şehir tablosu yaparsınız ve şehirleri tabloda id numaralarıyla tutarsınız, ve üyeler tablosunda hangi üyenin hangi şehirde bulunduğunu id bağlantısıyla yaparsınız ki üye sayısı arttıkça üyeler tablosundaki şehir kolonunda string değer tutmadan sadece int değer tutarak verinin çok yer kaplamamasını sağlarsınız, Hatta okullarda veri tabanı derslerinde, veri tabanı optimizasyonlarında, ilişkisel veri tabanı kullanana yazılım birimlerinin db ownerleri bu yapıların sağlıklı çalışıp çalışmadığını kontrol etmek varsa yanlış bir tasarım tipi bunları düzeltmenle yükümlüdür.

İlişkisel olmayan veritabanlarında veri büyüdükçe yapı büyümez, yapılar çoğalır.

İlişkisel veri tabanlarında yapısal (structured data ) mantığı vardır. Burada amaç hangi verinin hangi kolona ve hangi sırada yazılacağı sabittir. Fakat ilişkisel olmayan veri tabanında Semi Structured yada unstructured yapı mantığı vardır. Örneğin bir metin, bir web sayfası, (Meta tagları olsun veya olmasın farketmez), pdf dökümanları, world dökümanları, video ve fotoğraflar gibi herhangi bir kategorizasyona bağlı olmayan

İlişkisel veri tabanlarında ACID(Atomik transactions) yani bir işlem bitmeden diğer işlem başlamaz kuralı geçerlidir. İşlemler birbirlerinden izole ve bağımsız olarak çalıştırılır. Veriler diske yazılır ve kalıcıdırlar.

İlişkisel olmayan veritabanları Eventual Consistency (BASE) Güncel veri olduğunu garanti etmez, Çünkü muhteşem bir hızla veri akışı olur, Ve verileri anlık olarak ram'de tutar ve elektrik kesintisi durumunda veriler kaybolmaya müsaittir, Fakat tabi bugünkü data centerleri düşündüğünüzde elektrik kesintisi olsa ne olur diye düşünebilirsiniz.

İlişkisel veri tabanları Schema on Write (Object Relational Impedance Mismatch) yapılardır. Genelde Nesne yönelimli programı kullananlar bilir, Yazılımdaki oop ilişkileriyle dbdeki schema ilişkileri birbiriyle uyumlu olmalı ve mimari buna uygun yapılmalıdır. Bence ilişkisel veri tabanının en sevmediğim yanı da budur :)

İlişkisel veritabanı olmayan uygulamalarda siz kendi kodlarınızı yazarsınız, db zaten kendisi okuma sırasında istediğimiz şemaya göre veriyi getirdiği için problem yaşanmayacaktır.

NoSQL, ilk olarak 1998 yılında Carlo Strozzi tarafından ortaya çıkarılan bir kavramdır.

NoSQL anlamlarından bazıları NonRel, NoRDBMS’dir (ilişkisel değil anlamında). NoSQL için “not only sql” tabiri de kullanılmaktadır. İlişkisel veritabanı sistemlerine alternatif bir çözüm olarak ortaya çıkmış, yatay olarak ölçeklendirilmiş bir veri depolama sistemi diyebiliriz.

İlişkisel veri tabanlarında maliyetlerin yükselmemesi adına önceden yapıyı çok iyi planlayıp, ona göre kodlama ve proje geliştirilirdi. Bugün sadece arkadaşlar birbirini eklesin amacıyla yapılan facebook'un tüm dünyanın kullandığı bir arkadaşlık sistemi olacağını eminim zuk önceden kestirememiştir. Belkide kestirdi bilmiyorum ama ben olsam kestiremezdim :)

Bir projeye başladığınızda bu işin kapsamı ve yapı biçimi nasıl büyüyecek bunu önceden sağlam bir şekilde kestirmek ve ona göre dizayn yapmak muhteşem bir yetenek ve kabiliyet isteyen bir özellik. Fakat İlişkisel olmayan veri tabanı türlerinde db owner'in IQ sunun 180 olmasına gerek yok :)

İşte ben buna mühendislik çözümü diyorum.

Veri büyüklüğü ve trafik olarak belirli büyüklüğe gelen ve hali hazırda açık kaynaklı veritabanı sistemleri kullanan firmalar bir noktada bu veritabanlarının kısıtlarına takılmaktadırlar. Dikey büyüme maliyetli olduğundan, yatayda büyüyebilmek için daha fazla önbellek (cache) kullanımı, verinin programatik olarak dağıtılması (sharding) gibi teknikleri denemektedirler.

Google bu gereksinimi Big Table adını verdiği NoSQL veritabanı sistemi ile Amazon ise DynamoDB ismini verdiği NoSQL veritabanı sistemi ile çözmektedir. İnternetteki en büyük veri hacmine sahip olduğu bilinen Google firması, internet verisini İlişkisel Veritabanları yerine BigTable’da tutmayı tercih etmektedir. Google firmasının bu tercihi yapma sebebi ise veriye ilişkisel veritabanı sistemlerine nazaran daha hızlı ve daha ucuza erişebiliyor olmasıdır. Daha ucuza erişebilmesini sağlayan önemli bir faktör de dikey büyüme yerine yatayda büyüme ile gereksiz ek maliyetten kurtulmalarıdır.

Yatay Büyüme ve Dikey Büyüme Arasındaki Fark Nedir?

Dikey büyüme sistem kaynaklarınızın yetersiz kalması durumunda sistemi yenilemeniz veya sisteme ek donanım almak ile olur iken yatay büyümede ek bir sunucu alarak işlem yüklerini sunuculara bölmek ile sağlanır. Böylelikle Sunucuyu üst versiyonlara çıkarmak için çıkan karşılaşılan maliyeti ek bir sunucu veya mainframe bir bilgisayarla sağlanmış olunur.

Özetle;

İlişkisel olmayan veri tabanlarının iyi tarafları

İlişkisel olmayan veritabanı sistemlerinde yatay olarak genişleyebilen bir yapı 100ler hatta 1000 lerce sunucuyu bir araya koyup disk ekleyerek sistemin çalışabilirliğini sağlamayı yapabilirsiniz. Bir rivayete göre google'nin okyanusta sunucularını barındırdığı bir gemi, ve deniz suyuyla soğutma yaptığı bir data center'inin olduğu konuşulur :)

Programcılar çok severler, bir class ta değişiklik yapıldığında db schema tarafında da veri tabanı bakımı, onarımı değişikliği gibi iş yükü ortadan kalkar.

Açık kaynak kodu destekler, bulut bilişime uyum sağlar bu yüzden tekelcilikten daha kolay uzaklaşabilirsiniz.

Kötü tarafları,

İlişkisel bir yapı kurduysanız, hadi bunu ilişkisel olmayan bir yapıya çevirelim demek çok zordur. Veri düzgün bir biçimde taşınsa bile JOIN kullandığınız her yer sizin için ekstra iş yükü olacaktır.

Sorgu tabanlı veri erişimi yerine anahtar tabanlı veri erişimi yapmak gerekir ki burada alışma süreci ayrı bir zorluktur.

En önemlisi, transaction yapısı olmadığı için önemli (banka hareketleri) gibi işlemlerde patlayabilirsiniz.

Tabii veri güvenliği konusunda ne kadar başarılıdır, tartışılır, Bugün MSSQL de satır bazında yetkilendirmeler bile mevcut, Yani db ownerlerinizi bile satır bazında yetkilendirmelerle bile kısıtlayabilirsiniz.

Uğur Turna

Senior Software Developer @ ICrypex

5y

Ellerinize sağlık Haktan Bey :) 

Yorumları görmek veya yorum eklemek için oturum açın

Haktan Akdağ adlı yazarın diğer makaleleri

  • Dashboard Raporlama

    Dashboard Raporlama

    Şöyle bir proje düşünün; Çok hızlı raporlama yapabiliyor, çok hızlı verilerinizi görselleştirebiliyor, hazır…

  • Dokuz Sistem & Sanal Santral Web API Entegrasyonu

    Dokuz Sistem & Sanal Santral Web API Entegrasyonu

    Merhaba arkadaşlar; Dokuz sistem olarak geliştirdiğimiz bir projede kurumun kullanmış olduğu bir erp yazılımından kvkk…

  • Üretimde Yüklenilen KDV Raporu (FIFO'ya Göre)

    Üretimde Yüklenilen KDV Raporu (FIFO'ya Göre)

    Bir projenin daha sonuna geldik. Benim için bir projenin sonu, bir dökümanın daha başlangıcı oluyor.

  • X ERP'den Mikro V16'ya Cari Kart Aktarımı

    X ERP'den Mikro V16'ya Cari Kart Aktarımı

    Merhaba; Bu yazımda size Herhangi bir ERP Sisteminden stok ve cari aktarımını anlatacağım. Bu dökümanda amacım aslında…

  • DevExpress ile Raporlama Scripti hazırlayalım.

    DevExpress ile Raporlama Scripti hazırlayalım.

    Merhaba arkadaşlar; Bu yazımda devexpress tool ile raporlama nasıl yapılır onu anlatacağım. Böyle bir rapor çıktısı…

  • Netsis'e Dış Sistemden Üretim Girişi (Dikey Çözüm)

    Netsis'e Dış Sistemden Üretim Girişi (Dikey Çözüm)

    Netsis & Logo & Mikro gibi yazılım sistemlerinde kullanıcı konusu tam bir kaostur. Bir sürü para verip sistem…

  • Netsis Maliyetlendirme Hesabı ve POWER BI Raporlama

    Netsis Maliyetlendirme Hesabı ve POWER BI Raporlama

    Merhaba; Şimdi sizin aklınızda şöyle bir soru işareti var. Bu adam netsis'in kendi maaliyetlendirmesini linkedinde…

  • Dia GET Data

    Dia GET Data

    Merhaba; Dokuz Sistem Bilişim'i kurduktan sonra, bu isim adı altında ticari olarak yaptığım ilk proje olan Dia get data…

    1 Yorum
  • Kerzzpos TO Logo

    Kerzzpos TO Logo

    Kerzzpos satış sistemlerini bilirsiniz. On numara bir restoran yönetim sistemleri var.

  • X ERP To Logo(NETSIS)

    X ERP To Logo(NETSIS)

    Merhaba arkadaşlar. Konuyu çok uzatmadan girişimi yapayım.

Diğer görüntülenenler