12. Atomic :
Consistent :
Ya hep ya hiç
Veritabanı bütünlüğü
Isolated :
Durable :
söyledim
* Aksi durumlar söz konusu olabilir. Bunun için izolasyon seviyeleri ele alınır.
İşime karışma *
Son sözümü
14. Firma
İstatistik
Aylık paylaşım sayısı
Facebook
Entegre çalışan Uygulama ve Web Sitesi Sayısı
Her gün kurulan uygulama sayısı
Wikipedia Wikipedia tarafından sunulan toplam makale sayısı
Her dakika yüklenen ortlama resim sayısı
Flickr
Youtube
Twitter
12.26.2013
Aylık olarak toplam gösterim sayısı
Dakika başına yüklenen toplam video süresi
Günlük ortalama tweet sayısı
Günlük Twitter Arama Motoru sorgu sayısı
Değer
70 Milyar
7 Milyon
20 Milyon
17 Milyon
3000
92 Milyar
65 Saat
190 Milyon
2.1 Milyar
Statistic Brain
23. Row ID
Column
Family
Row Key Timestamp
Column
Name
Name Family
First
Last
T4
T20
Jon
T45
Phone Number
Email
selim@buraksenyurt.com
444-55-66
Burak
T22
Connection Family
burak@blaba.com
122-54-64-555
jon@doe.doe.com
Şenyurt
T9
Row 2
Value
333-33-33
T1
Row 1
Timestamp
Do
Doe
Jon.doe@nosql.com.fr
24. Sepetim
Sepet ID Kullanıcı Oluşturulma
9005
Burki
4.12.2013
9006
ConDo
5.12.2013
Sepet Öğeleri
Öğe ID SepetID Miktar Ürün No
1001
9005
3
PRD-01
1002
9005
1
PRD-02
Ürün
Ürün No Adı
Fiyat Kategori
PRD-01
AyFone5
120
Telefon
PRD-02
Anduroit 190
Telefon
25. Row ID Time Kullanıcı SepetID Urun
stamp
Adı
T1
1506
Burki
Urun
No
Birim Adet Kategori
Fiyat
9005
T2
AyFone5 PRD-01 120
3
Telefon
T3
Anduroit PRD-02 190
1
Telefon
31. Ürün
Üretici
Tip
CAP Internal? Bazı Kullanıcıları
Dynamo
Amazon
Key Value
AP
Evet
Amazon
Cassandra
Facebook
Column Store
AP
Hayır
Facebook, Digg, Twitter, Rackspace, Cisco,
BigTable
Google
Column Store
CP
Evet
Google
MongoDB
10Gen
Document Store
CP
Hayır
EA, Newyork Times, Github, Sourceforge
CouchDB
Couchio
Document Store
AP
Hayır
BBC, Sauce Labs
SimpleDB
Amazon
Key Value
AP
Hayır
Alexa
Neo4J
Neo Technologies
Graph
??
Hayır
Adobe, Swedish Defence Forces,
Redis
VMware
Key Value
CP
Hayır
Twitter, The Guardian, Instagram, Stackoverflow
Voldemort
Linkedin
Key Value
AP
Hayır
Linkedin
Evet
LiveJournal, Flickr, Wikipedia, Youtube, Digg
Memcached LiveJournal
Key Value (In-Memory) CP
32. Eric Brewer
Symposium on Principles of Distributed Computing
Seth Gilbert
Nancy Lynch
güvenilir olmayan bir ağ üzerinde
aşağıdaki 3 özelliğin hepsini birden
Consistency :
Availability :
Partition Tolerance :
37. Bir yazma işlemini asla kesme.
Consistency’ ye değil işlem hacmine
odaklan (Big Data)
İyimser ol : Bir servis düşse bile doğal
olarak ayağa kalkacaktır.
Bazı raporlar bir süre için tutarsızlık
gösterebilir ama üzülme. Sonunda
doğru bilgiyi verir.
Lock’ lar dan uzak dur, basit düşün.
Editor's Notes
NoSQL kavramı ilk olarak 1998 de Carlo Strozzitarafından dile getirilmiştir. 2009’da Eric Evan tarafından yeniden tanıtılmıştır.
Live Journal, veritabanı sorgularının performansını arttırmak, (MemCached) - Youtube, Reddit, Facebook, Twitter, Tumblr, WikipediaGoogle, milyarlarca sayfa üzerinden yapılan arama sonuçlarını indekslerken düşük maliyetli sunucuları kullanabilmek, (MapReduce)Google, çok sayıda kolonla ifade edilebilecek veri tablolarını dağıtık mimaride olabildiğince esnek bir şekilde tutabilmek, (BigTable)Amazon, 7/24 bir web siparişini kabul edebilmek, (Dynamo)MarkLogic, standart sorgulama dilini kullanarak sıradan donanımlı sunucularda sakladığı devasa boyuttaki XML doküman koleksiyonları üzerinde sorgulama yapabilmek, (Müşterileri arasında Warner Bros, Citigroup, Dow Jones, Boeing) için kendi geliştirdikleri NoSQL sistemlerini tercih etmişlerdir.
1998 yılında tasarımcı Carlo Strozzi Unix sistemlerde çalışan shell tabanlı, SQL dilini kullanmayan bir veritabanı tasarlar. Kendisi RDBMS’ ler gibi ilişkisel olmayan bu veritabanı için NoREL ifadesinin kullanılmasını daha uygun bulur. Derken 2009 yılnda Atlanta’ da yapılan bir konferans’ da Eric Evans tarafından kavram tekrardan gündeme getirilir ve tanımlanır.Strozzi’ nin tasarladığı NoSQL sistemi ile ilişkili olarak http://www.strozzi.it/cgi-bin/CSA/tw7/I/en_US/nosql/Home%20Page adresinde detaylı bilgi bulunmaktadır.
Scalability(Ölçeklenebilirlik)Horizontal Scalability:Sistemin kapanmadan paralelinde yeni makineler eklenerek genişlemesi ve hacimsel olarak büyümesi.Vertical scalability:Tek makineye ek donanım takviyeleri yapılarak genişletilmesi.
CAP Teoremi Cluster üzerindeki Partition’ lar arasında iletişim kopmaları yaşanabilen vakalarda uygulanmaktadır!!!Consistency : ACID’ deki Consistency değildir. Burada tüm istemciler için tek, güncel ve okunabilir bir data söz konusudur. N sayıda istemci replicate edilmiş partition’ lardan aynı öğeleri okur ve tutarlı sonuçlar elde eder.High Availability : Dağıtık bir veritabanı sistemi istemcilerinin veriyi update ederken gecikme yaşamasına müsaade etmez. Replicate edilmiş partition’ lar arasında oluşabilecek iletişim aksaklıkları güncellemeleri kesmemelidir.PartitionTolerence : Database partition’ ları arasında iletişim aksasa bile sistem istemcilerine cevap vermeye devam eder. Bu ilke NoSQL sistemlerinin makine kapatmadan yatayda kolayca genişleyebilmesine olanak tanımaktadır.
http://en.wikipedia.org/wiki/CAP_theorem
Basic Availability: Her request başarısız icra edilse de bir Response almalıdır. Garanti Response.Soft State: Sistemin durumu zaman içerisinde hiçbir veri girişi olmadığı halde değişiklik gösterebilir(Eventual Consistency’ ye ithafen)Eventual Consistency: Veri tabanı geçici olarak tutarsız bir konuma gelebilir ama nihayetinde tutarlılık kazanacaktır.
Veri büyürken ihtiyaçları karşılayacak şekilde ölçeği arttırmak beraberinde bazı soruları da getirir. Veriyi nereye nasıl saklayacağız, nasıl eşleştireceğiz ya da eşleştirmeyecek miyiz, veriyi bölecek miyiz, neye göre böleceğiz veya böldüysek taşırken sunucu kapatacak mıyız?Bir örnek ile devam edelim.Kullanıcılarının kendi kişisel alanlarını yarattıkları bir web sitemiz olduğunu düşünelim. Söz gelimi kendilerine özgün bir Second Life kurdukları bir sosyal ağ olsun. Beğendikleri ürünleri koyabilsinler, profilleri bulunsun, bol bol text ekleyebilsinler. Site verilerini bir RDBMS üzerinde tuttuğumuzu varsayalım. MySQL olabilir. Tek bir CPU su olan bir DB server da çalıştığımızı düşünelim. Site tuttu. İnsanlar arkadaşlarını davet etmeye başladılar ve olan oldu. Disk kapasitesi dolmaya başladı. Sadece %10 luk bir alanı boş. Şimdi ne yapacağız?Büyük ihtimalle yeni bir sistem satın alıp verinin bir kısmını onun üstüne aktaracağız. Bu kısaca Sharding dediğimiz mekanizma aslında. Bu arada hangi sunucudan bilgi okunacağına dair uygulama seviyesinde geliştirme yapmalıyız. Bunu yaparken ne yazık ki eksi sunucu ve db bir süreliğine kapalı kalacak. Veriyi tekil db’den çoklu ve dağıtık yapıdaki db’ sistemine dağıtırken başka sorular da karşımıza çıkacak. Örneğin;Hangi makine de hangi veri aralıklarını tutacağız? Buna nasıl karar vereceğiz? Peki ya bir partition da duran veri de değişiklik olur ve onun karar verdiğimiz ayırma prensibine göre diğer bir partition’ a taşınması gerekirse? Söz gelimi isminin baş harfi A ile K aralığındakileri X sunucusundaki DB’ de diğerlerini de Y sunucusundaki DB’ de tuttuğumuz var sayalım. Adam ismini değiştirip diğer aralığa girerse tüm verisini o DB’ ye taşımalı mıyız? Şimdilik sadece iki sunucuya bölündük. Ya veri iki kat büyürse. Tekrar sunucuları kapatıp, uygulamalarda değişiklik yapıp yeni makineleri sisteme bu şekilde mi dahil edeceğiz?
Veri parçalanarak dağıtılır. Replication’ da olduğu gibi tüm alt db’ ler de verinin aynısı bulunmaz.
Daha çok High Availability adına uygundur. Uygulamalar sadece Master DB’ ye veri yazar ve oradan okurlar. Master DB lerden birinin çökmesi halinde Slave DB hemen sorumluluğu üstlenir ve cevap verir. Bu High Availability anlamına gelir. Tabi yine de bir soru vardır. Ya Slave sistemlerden biri çökerse Bu tip durumlarda Reliable Messaging veya Message Store gibi Queue tabanlı sistemler kullanılarak çökmelerin önüne geçilir. Master DB’ ye bir şeyler yazıldığında hemen Slave’ lere de kopyalama olur. Bu nedenle kopylama işlemleri sırasında sistemde bir yavaşlık olabilir ve okuma hızları düşebilir.ACID ilkelelerinin garanti edilmesi istendiği durumlarda transaction’ ların aksamaması, garanti edilmesi ve yedeklerin tutarlı ve birebir alınması noktasında Replication bir çözümdür. Bu noktada Sharding in High Availability sunmadığını söyleyebiliriz.