1.
Veri Neden En Önemli Şey ?
- Veri yazılımdan daha uzun süre yaşayabiliyor
- 30-40 senelik veriler halen kullanımda. Örneğin
Türk Telekom
- Bu veriyi işleyen yazılımlar defalarca
güncellenmiş. Yazılımı değiştirmek daha kolay
ancak veriyi değiştirmek zor
- Biz bu veriyi depolarken neredeydik ve nereye
gidiyoruz?

2.
İlişkisel Veri tabanları
- 1970 yılında IBM'de yayınlanan bir paper ile
başladı
- En temel Relational Modeldeki kavramların
bazıları şöyle: Tables, Columns, Rows, Keys
(Primary, Foreign, Unique), Index, Stored
Procedures,Triggers
- Relational Model'in zamanındaki rakipleri olan
Network Model ve Hierarchical Model e galip
geldi. Hierarchical model Json gibiydi.

3.
1980-2000'ler
- Çoğunlukla İlişkisel Veri tabanlarının hakimiyeti
aldında geçti.
- Oracle, Sybase, SQL Server, MariaDB,
PostgreSQL

4.
İlişkisel Veri tabanları Uyumluluğu
- Hiç bir ilişkisel veri tabanı birbiriyle %100 uyumlu
değildir. Ancak aralarında çok büyük benzerlikler
bulunur
- Dolayısıyla Oracle'dan, Postgre'ye geçiş
mümkündür. NoSQL DB'lerde bu iş zor. Birazdan
konuşacağız.
- Her üretici birbiriyle fiyat/performans, çeşitli
yardımcı araçlar vs. gibi şeylerle rekabet etti.
- Ayrıca hepsi standartlarda olmaya "extension" lar
sundu

5.
Diğer Veri tabanları
- Nesne veri tabanları. Object–relational
impedance mismatch için denendi, tutmadı
- XML veri tabanları. 2000'lerde orta çıktılar ve
tutmadı.
- Graph veri tabanları. Günümüzde oldukça
popüler durumdalar

6.
NoSQL Veri tabanları
- 2000'lerde bu kelime duyulmaya başlandı
- NoSQL Ne Demek ? "Not Only SQL" ? :)
- Big Data mı ?
- Unstructured Data mı ?
- NoSQL Veri tabanlarının ortak özellikleri nedir ?

7.
Modern Veri tabanları
- unstructured veri girişine izin verir. XML, json,
text, blob
- Örneğin Postgre'deki json ve jsonb sütunları var
- İngiliz The Guardian gazetesi, verisini NoSql veri
tabanından Postgre'ye taşımıştır.
- Öyleyse : key + jsonb verisinden oluşan bir
verinin Mongo'daki Document yapısından ne farkı
var ?
Soru : Unstructured veri girişi mümkünse NoSql
veri tabanı niçin lazım ?

8.
NoSQL Veri tabanlarının Doğuşu
- 2000'li yıllarda ortaya çıkan çeşitli
baskılar/driving factors, NoSQL başlığı altında
ancak birbirleri ile ortak özellikleri olmayan yeni
yazılımların ortaya çıkmasına sebep oldu

9.
NoSQL Tabanlarına Doğru
- Bazı sebepler : transaction sayısı, veri miktarı,
high availability/scalability isteği vs.
- Büyüklüğü 30 TB olan bir veriyi az sayıda işlemci
ile sorgulamak çok vakit alır. Veriyi mecburen
dağıtmak gerekir. Big Data NoSql DB lazım.
- Çok fazla transaction işlemek için yine veriyi
dağıtmak gerekir. Bu durumda bazı transaction
özelliklerinden feragat etmek gerekir.

10.
NoSQL Tabanlarına Doğru
- İlişkisel veri tabanları bu istekleri karşılamakta
zorlanıyorlar, çünkü şimdiye kadar uydukları
kurallar (ACID) işi zorlaştırıyor. Overkill (aşırı
yükleme) var

11.
İlişkisel Veri tabanları ve Transaction
- Atomicity : Transaction Abort Edilebilir
- Consistency : Tanımlı kuralların her zaman
uygulanması. Constraints, triggers vs.
- Isolation : Race condition için geçerli kurallar.
Yani lock koyma ve kaldırma işleri
- Durability : Verinin kaybolmaması
Dağıtık veri tabanına doğru geçerken bunların
hepsini aynı anda sağlamaya çalışmak fayda
getirmiyor.

12.
Dağıtık İlişkisel DB'yi Bir Deneyelim
- Two Phase Commit : İki farklı veri tabanında
ACID özelliklerini muhafaza ederek yazma işlemi.
- TxC A ve B veri tabanlarında transaction başlatır
- TxC A ve B'den olumlu cevap bekler.
- TxC A ve B'ye commit mesajı gönderir veya TxC
A ve B'ye rollback mesajı gönderir.
Beklemeler ve ağ kopmaları yüzünden yavaştır.
Dolayısıyla ACID özelliklerini koruyarak dağıtık DB
yapılamıyor.

13.
Dağıtık DB'ler İçi CAP Teoremi
- Veriyi dağıtmaya karar verdiysek bu işin bir de
teorisi olmalı
- CAP Teoremi 1998 yılında yazılmıştır.
- CAP Teoremi der ki : Dağıtık bir veri tabanında
Consistency, Availability ve Partition Tolerance
(PT) özelliğinden aynı anda sadece 2'si
sağlanabilir.
- PT farklı ağlarda çalışmak demek. PT'yi
seçmeme şansım yok. Çünkü o zaman dağıtık
olmam.

14.
Availability ve Consistency
- Availability : T anında sisteme çağrı yapılırsa
cevap vermesi demek
Consistency : T anında yapılan okuma isteğinin
en son yazılan değeri getirebilmesi demek

15.
Dağıtık DB'ler İçin CAP Teoremi
- Availability seçersem (yani birden fazla master
düğüm) klasik Consistency'den feragat ederim.
Çünkü master node'a yazılan verinin, diğer
node'lara yazılması vakit alır
- Consistency seçersem, Availability'den feragat
ederim. Çünkü master düğüme yazılan verinin
diğer düğümlere dağıtıldığını garanti etmek
gerekir. Yani 2 Phase Commit ile aynı şey. Bunu
da zaten istemiyorduk

16.
Modern Dağıtık DB'lerin Çoğu
- Consistency kavramını biraz değiştirmişler ve
Eventual Consistency olarak algılıyorlar.

17.
Modern Dağıtık DB : Mongo
"In Mongo we can have one master and multiple
slaves where the master will be used for writes
and slaves will be used for reading operations."
- Yazma işleminde veriyi master işler. Veri daha
sonra diğer slave/read düğümlerle senkronize
edilecektir.
- Okuma işleminde de master/slave kullanılır.

18.
Modern Dağıtık DB : Cassandra
"The nodes in Cassandra are equal and all of them can
respond to user's query. That's because Cassandra picks
Availability and Partition Tolerance in the CAP Theorem,
whereas MongoDB picks Consistency and Partition
Tolerance. And Cassandra can have linear scalability by
simply adding new nodes into the node ring to handle
more data."
- Yazma işleminde Partitioner veriyi birden fazla düğüme
write için gönderir. Bir tane düğüm yazamasa bile
diğerleri yazabilirse problem olmaz. Veri daha sonra
senkronize edilecektir.

19.
Diğer NoSQL Veri tabanları
- Key/Value Store: Redis, Memcached, Hazelcast
- Graph : Neo4J
- Document : Mongo, CouchDB, CouchBase
- Wide Column : Cassandra, Hbase
Yani NoSQL adın altındaki DB'lerin hepsi farklı farklı.

20.
Gelecekte Ne Bekleyebiliriz?
- Muhtemelen daha fazla hibrit ortamlar göreceğiz
- Verinin depolanması, sorgulanması, yorumlanması,
stream edilmesi, stream'in process edilmesi için çok fazla
yeni teknoloji üretiliyor.
- Bu teknolojinin bir kısmı zamanla sönecektir.
- Ancak daha yükseliş dönemindeyiz.
- Bir komite/standart ufukta görünmüyor
- Milsoft projelerinde Architectureal DAR'da DB seçimi
gerekçesi bence mutlaka belirtilmeli.