SlideShare a Scribd company logo
1 of 20
Download to read offline
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?
İ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.
1980-2000'ler
- Çoğunlukla İlişkisel Veri tabanlarının hakimiyeti
aldında geçti.
- Oracle, Sybase, SQL Server, MariaDB,
PostgreSQL
İ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
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
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 ?
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 ?
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
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.
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
İ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.
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.
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.
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
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
Modern Dağıtık DB'lerin Çoğu
- Consistency kavramını biraz değiştirmişler ve
Eventual Consistency olarak algılıyorlar.
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.
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.
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ı.
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.

More Related Content

Similar to veri tabanları . sql vs nosql

İleri Seviye T-SQL Programlama - Chapter 08
İleri Seviye T-SQL Programlama - Chapter 08İleri Seviye T-SQL Programlama - Chapter 08
İleri Seviye T-SQL Programlama - Chapter 08Cihan Özhan
 
Berkeley Data Analytics Stack Genel Bakış
Berkeley Data Analytics Stack Genel Bakış Berkeley Data Analytics Stack Genel Bakış
Berkeley Data Analytics Stack Genel Bakış Veysel Taşcıoğlu
 
Berkeley Data Analytics Stack Genel Bakış
Berkeley Data Analytics Stack Genel BakışBerkeley Data Analytics Stack Genel Bakış
Berkeley Data Analytics Stack Genel Bakıştechbase
 
Kod günleri veritabnı
Kod günleri veritabnıKod günleri veritabnı
Kod günleri veritabnıMustafa Tepe
 
Bilgisayar Mimarisi 06, Feza BUZLUCA
Bilgisayar Mimarisi 06, Feza BUZLUCABilgisayar Mimarisi 06, Feza BUZLUCA
Bilgisayar Mimarisi 06, Feza BUZLUCAFeza BUZLUCA
 
Bilgisayar Ağları
Bilgisayar AğlarıBilgisayar Ağları
Bilgisayar AğlarıFaik GÜNAY
 
Big Data Analytics
Big Data AnalyticsBig Data Analytics
Big Data AnalyticsMudur Alkan
 
İleri Seviye T-SQL Programlama - Chapter 16
İleri Seviye T-SQL Programlama - Chapter 16İleri Seviye T-SQL Programlama - Chapter 16
İleri Seviye T-SQL Programlama - Chapter 16Cihan Özhan
 
Kurumsal Yazılım Geliştirme ve Visual Studio 2008
Kurumsal Yazılım Geliştirme ve Visual Studio 2008Kurumsal Yazılım Geliştirme ve Visual Studio 2008
Kurumsal Yazılım Geliştirme ve Visual Studio 2008mtcakmak
 
Oracle database architecture
Oracle database architectureOracle database architecture
Oracle database architectureHızlan ERPAK
 
OSI Standartları.pptx
OSI Standartları.pptxOSI Standartları.pptx
OSI Standartları.pptxCanBerkARMAN
 

Similar to veri tabanları . sql vs nosql (20)

Sukru_TRSUG2016
Sukru_TRSUG2016Sukru_TRSUG2016
Sukru_TRSUG2016
 
Nosql ve mongoDB
Nosql ve mongoDBNosql ve mongoDB
Nosql ve mongoDB
 
MongoDB Overview
MongoDB OverviewMongoDB Overview
MongoDB Overview
 
İleri Seviye T-SQL Programlama - Chapter 08
İleri Seviye T-SQL Programlama - Chapter 08İleri Seviye T-SQL Programlama - Chapter 08
İleri Seviye T-SQL Programlama - Chapter 08
 
Berkeley Data Analytics Stack Genel Bakış
Berkeley Data Analytics Stack Genel Bakış Berkeley Data Analytics Stack Genel Bakış
Berkeley Data Analytics Stack Genel Bakış
 
Berkeley Data Analytics Stack Genel Bakış
Berkeley Data Analytics Stack Genel BakışBerkeley Data Analytics Stack Genel Bakış
Berkeley Data Analytics Stack Genel Bakış
 
Riak ve RiakCS
Riak ve RiakCSRiak ve RiakCS
Riak ve RiakCS
 
NoSQL Sunumu
NoSQL SunumuNoSQL Sunumu
NoSQL Sunumu
 
Kod günleri veritabnı
Kod günleri veritabnıKod günleri veritabnı
Kod günleri veritabnı
 
Kod günleri veritabnı
Kod günleri veritabnıKod günleri veritabnı
Kod günleri veritabnı
 
Bilgisayar Mimarisi 06, Feza BUZLUCA
Bilgisayar Mimarisi 06, Feza BUZLUCABilgisayar Mimarisi 06, Feza BUZLUCA
Bilgisayar Mimarisi 06, Feza BUZLUCA
 
Bilgisayar Ağları
Bilgisayar AğlarıBilgisayar Ağları
Bilgisayar Ağları
 
Big Data Analytics
Big Data AnalyticsBig Data Analytics
Big Data Analytics
 
Cem kubilay
Cem kubilayCem kubilay
Cem kubilay
 
Php veritabani
Php veritabaniPhp veritabani
Php veritabani
 
Sesame
SesameSesame
Sesame
 
İleri Seviye T-SQL Programlama - Chapter 16
İleri Seviye T-SQL Programlama - Chapter 16İleri Seviye T-SQL Programlama - Chapter 16
İleri Seviye T-SQL Programlama - Chapter 16
 
Kurumsal Yazılım Geliştirme ve Visual Studio 2008
Kurumsal Yazılım Geliştirme ve Visual Studio 2008Kurumsal Yazılım Geliştirme ve Visual Studio 2008
Kurumsal Yazılım Geliştirme ve Visual Studio 2008
 
Oracle database architecture
Oracle database architectureOracle database architecture
Oracle database architecture
 
OSI Standartları.pptx
OSI Standartları.pptxOSI Standartları.pptx
OSI Standartları.pptx
 

veri tabanları . sql vs nosql

  • 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.