Veri Tabanları ve Veri Tabanı Mimarileri
Last updated
Was this helpful?
Last updated
Was this helpful?
Genelde veri tabanı çok önemsiz görülen (aslında çok önemli bir konu olduğunun dert çıkardıkça anlaşıldığı) bir konu olması biraz daha sürecek bir problem olarak kalacak görünüyor.
Tabii Mikroservis gibi servis tabanlı yapılarda stateless mimari ya da state in dışarıda saklanması gibi tasarım geliştirmelerinde ve veritabanlarının failover, distributed database, data warehouse gibi yaklaşımlarla öneminin arttığın farkına varılacaktır.
Katmanlı mimari de Data Layer ile Data Access Layer ayrımının yapılması ve bağımlılıkların azaltılmasıyla bir veri tabanından diğer bir veri tabanına geçiş kolayca yapılabilmekte olmaktadır. Hatta ileri de ayrı bir servis olarak sunmaya da yapımız müsait olacaktır.
Sonuç olarak frontend ile backend ayırabilenler için aslında backend ile database işlemlerinin ayrık olduğunu kavrayabilmek kolay olacaktır. Küçük projeler için Full Stack Developer kavramıyla da devam edilebilir olsa da buradaki konular o tarz bir çalışma için de önemli olacaktır.
Bu konuda kendimize sormamız gereken soruları aşağıda toplamaya çalıştım.
Bilinirliği olan veri tabanları hangileri?
İlişkisel veri tabanı mı yoksa NoSQL veri tabanı mı?
Monolitik veri tabanı mı yoksa dağıtık (distrubuted) veri tabanı mı?
Geliştirilecek proje Veri Ambarı gerektirmekte midir?
Oracle, MySQL, Microsoft SQL Server, PostgreSQL, MongoDB, IBM DB2, Redis, Elasticsearch, SQLite, Cassandra vs..
Dikey (Vertical) ölçekleme (Scale up): Sunucu kaynaklarını arttırmak (RAM, disk, CPU, vs) (Tek nokta) • Yatay (Horizontal) ölçekleme (scale out) : Kümeye yeni sunucu(lar) ekleme (maliyet)
Daha iyi servis
Daha çok kullanıcı hedefi
Mevcut kullanıcıların daha iyi servis alması
Daha çok veri sunulması
Yüksek bulunurluk! (HA)
Neye göre ölçekleyeyeyim?
Okuma
Yazma
Okuma / Yazma!
Polyglot Programming' de her yazılım dilinin uzman olduğu alanda kullanılması prensibine benzer olarak tüm servislere hizmet eden tek bir veri tabanı yerine her servis için yaptığı işte uzman olan veri tabanlarıyla mimari kurulması olarak bilinir. Veri depolama için tüm çözümlere uygun tek bir veri tabanının bulunmadığını kabul eden bir yaklaşımdır.
Yüksek veri içeren internet loglarının RDMS veri tabanlarında tutulması pek tavsiye edilmiyor.
Başka bir örnek olarak üstteki link de açıklanan aşağıdaki müzik enstrümanlarını ve aksesuarlarını çevrimiçi olarak (ve mağaza ağında) satan bir şirketi düşünelim. Üst düzey bir şirketin başarılı olması için çözmesi gereken bir takım sorunlar vardır:
Müşterileri mağazalarına (hem sanal hem de fiziksel) çekmesi.
Müşterilere ilgili oldukları ürünlerin sunulması (Piyaniste bateri seti satmaya çalışmamak gerekir).
Müşteriler satın almaya karar verdiklerinde, ödeme ve nakliyeyi işlerinin organize edilmesi.
Şirket bu sorunları çözmek için tasarlanmış bir dizi mevcut teknoloji arasından seçim yapabilir:
Tüm ürünleri MongoDB, Cassandra, DynamoDB veya DocumentDB gibi belge tabanlı bir veritabanında saklayın.
Belge veritabanlarının birçok avantajı vardır:
Esnek şema,
Parçalama (daha büyük veritabanlarını daha küçük, daha yönetilebilir kümelere bölme),
High availability, ve Replication yetekleri sağlar.
Grafik tabanlı bir veritabanı (Büyük veri işleme motoru Apache Spark için Neo4j, Tinkerpop/Gremlin veya GraphFrames gibi) kullanarak önerileri modelleyin:
Bu tür veritabanları müşteriler ve tercihleri arasındaki gerçek ve soyut ilişkileri yansıtır. Böyle bir grafiğin madenciliği paha biçilmezdir ve bir müşteri için daha uygun bir teklif üretebilir. Arama yapmak için bir şirket Apache Solr veya ElasticSearch gibi aramaya özel bir çözüm (search-tailored solution) kullanabilir. Böyle bir çözüm, hızlı, dizine alınmış metin arama özellikleri sağlar.
Bir ürün satıldıktan sonra, işlem normalde iyi yapılandırılmış bir şemaya (ürün adı, fiyat vb.) sahiptir. Bu tür verileri depolamak (ve daha sonra işlem ve raporlamak) ilişkisel veritabanları için en uygunudur.
Java, Go, .NET gibi diller yapıları gereği connection pooling’i uygulama içerisinden yapabilmektedir. PHP gibi script diller ise yapıları gereği tam anlamıyla connection pooling yapamadıkları için bu işi yapacak harici yazılımlara ihtiyaç duymaktadırlar.
Her gelen bağlantı isteğinde yeni bir DB connection açmak gerektiğinden ve limitlerin üstünde gelen yeni trafikleri karşılamak için üst limitlerini artırmak yerine kullanılan ideal çözüm PgBouncer gibi bir connection pooling aracı kullanmaktır. Connection Pooling kısaca DB bağlantılarını cacheleyip, gelen yeni bağlantılarda varolan DB bağlantısını kullananmaktır diyebiliriz. Bu sayede her seferinde yeni bir bağlantı açmaktan ötürü doğan zaman ve memory kaybınını azaltabiliriz.
Postgresql bir connectioni handle edebilmek için bir kaç MB memory kullanırken PgBouncer sadece 2KB memory kullanır. Ayrıca normal DB connection açmak süre bakımından da PgBouncer’a göre daha fazla zaman alır.
Her bir pool client’dan gelen connectionları karşılar ve clientlardan gelen sorguları sıraya sokup DB connection üzerinden çalıştırır.
Veri tabanlarını hem yedekleme hem de master daki yükü dengeleme için kullanılan yöntemler vardır.
Master yazılan veriler yedek veri tabanlarına da yazılmalıdır. SQL sorgularının yazma kısımları sadece master iletilir. Okuma olarak da slave den de okuyabilir. Böylece master ın iş yükü azaltılır.
PostgreSQL'in transaction loglama konusuna yaklaşımını gösteren WAL kavramı
“Veri dosyalarında tabloların ve dizinlerin bulunduğu yerlerdeki değişikliklerin yazılabilmesi (write) için, öncelikle bu değişikliklerin kaydedilmesi, yani değişiklikleri tanımlayan günlük kayıtların (log) kalıcı depolamaya alınması gerekir.”
Bu prosedürü takip edersek, her işlemde veri sayfalarını diske atmamız gerekmez, çünkü bir çökme durumunda veritabanını günlüğü kullanarak kurtarabiliriz.
Connection pooling için veya açık kaynak yazılımlarını kullanabilirsiniz. Eğer yük dengeleme (load balancing), failover, switchover gibi ihtiyaçlarınız bulunmuyor ve sadece connection pooling ihtiyacınız varsa daha lightweight bir araç olan PgBouncer’ı önerebilirim.
