Successfully reported this slideshow.
Your SlideShare is downloading. ×

NoSQL - Yazılımcı Bakışıyla

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
NoSQL Sunumu
NoSQL Sunumu
Loading in …3
×

Check these out next

1 of 38 Ad
Advertisement

More Related Content

Advertisement
Advertisement

NoSQL - Yazılımcı Bakışıyla

  1. 1. Başlangıç Veri(Data) Popüler Veri Depolama Modeli – RDBMS Sıkıntılar Mahallenin Yeni Delikanlısı - NoSQL RDBMS vs NoSQL Kaynaklar
  2. 2. no:sql(east) 2009 - Atlanta
  3. 3. ACID SQL Yetki bazlı veri verinin denetlenmesi Object-Relational Mapping(O/RM) Join zor Sharding zordur çeşitlilik gösteren verilerin Scale-Out saklanması
  4. 4. OrderDetails Orders CategoryID Title Description ID ProductId CustomerID Number Name Title Quantity LastName CustomerID AddressID CategoryID BirthDate AddressID Line1 Line2 City Street PostalCode
  5. 5. 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ü
  6. 6. 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
  7. 7. Veri hacmi Veri çeşitliliği işlem trafiği Yüksek transaction Ölçekleme teknolojik baskı
  8. 8. RDBMS modelini izlemeyen İlişkisel olmayan Atomicity Consistency Veri çeşitliliği SQL Scalability kullanmayan Availability
  9. 9. BASE O/RM Scale Scale-out kolay sıradan sunucular Yüksek çeşitlilikte veri hızlı arama
  10. 10. binlerce kolon karmaşık veri modeli Zengin Structure Bir araya getirme süratli
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. Keys hash map Şema yok Hızlı Kolay dağıtım DynamoDB basit veri çeşitliliği 105456 121105 895432
  15. 15. JSON Doküman içerisinde sorgu belirli bir parçasını tedarik Dokümanlar arası bağlantı Implicit Schema Standart bir sorgulama dili yok { "customerInfo" : { "customers" : [ { "firstName" : "Burak Selim", "lastName" : "Şenyurt", "age" : 37, "city" : "İstanbul", }, { }, … } } "firstName" : "Con", "lastName" : "Doe", "age" : 51, "city" : "London", ]
  16. 16. Graph algoritmalı Hızlı sorgulama Sosyal ağlar
  17. 17. Ü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
  18. 18. 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 :
  19. 19. 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.
  • Katılımcılarla karşılıkı etkileşim sağlanarak ilerlenir.Cem Yılmaz – 1- Dayak nedir? 2- Neden Atılı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.
  • Sosyal bir ağımız var ve bir arkadaşımızın profiline girdiğimizde bize "4 ORTAK ARKADAŞINIZ VAR" diyor. 4 ortak arkadaşımız olduğunu Map/Reduce ile nasıl bulabileceğimize bakalım.Map / Reduce algoritmasında iki temel fonksiyon vardır map(k1,v1) -> list(k2,v2) ve reduce(k2, list (v2)) -> list(v3)Aysun -> Behçet,Cevdet,DemetBehçet -> Aysun, Cevdet, Demet, EmreCevdet -> Aysun, Behçet, Demet, EmreDemet -> Aysun, Behçet, Cevdet, EmreEmre -> Behçet, Cevdet, Demetşimdi map(k1,v1) -> list(k2,v2) zamanımap(Aysun -> Behçet, Cevdet, Demet)(Aysun Behçet) -> (Behçet Cevdet Demet)(Aysun Cevdet) -> (Behçet Cevdet Demet)(Aysun Demet) -> (Behçet Cevdet Demet)map(Behçet -> Aysun,Cevdet,Demet,Emre)(Aysun Behçet) -> (Aysun Cevdet Demet Emre)(Behçet Cevdet) -> (Aysun Cevdet Demet Emre)(Behçet Demet) -> (Aysun Cevdet Demet Emre)(Behçet Emre) -> (Aysun Cevdet Demet Emre)map(Cevdet->Aysun,Behçet,Demet,Emre)(Aysun Cevdet) -> (Aysun Behçet Demet Emre)(Behçet Cevdet) -> (Aysun Behçet Demet Emre)(Cevdet Demet) -> (Aysun Behçet Demet Emre)(Cevdet Emre) -> (Aysun Behçet Demet Emre)map(Demet -> Aysun,Behçet,Cevdet,Emre)(Aysun Demet) -> (Aysun Behçet Cevdet Emre)(Behçet Demet) -> (Aysun Behçet Cevdet Emre)(Cevdet Demet) -> (Aysun Behçet Cevdet Emre)(Demet Emre) -> (Aysun Behçet Cevdet Emre)map(Emre->Behçet,Cevdet,Demet)(Behçet Emre) -> (Behçet Cevdet Demet)(Cevdet Emre) -> (Behçet Cevdet Demet)(Demet Emre) -> (Behçet Cevdet Demet)Şimdi bunları gruplayalım(Aysun Behçet) -> (Aysun Cevdet Demet Emre) (Behçet Cevdet Demet)(Aysun Cevdet) -> (Aysun Behçet Demet Emre) (Behçet Cevdet Demet)(Aysun Demet) -> (Aysun Behçet Cevdet Emre) (Behçet Cevdet Demet)(Behçet Cevdet) -> (Aysun Behçet Demet Emre) (Aysun Cevdet Demet Emre)(Behçet Demet) -> (Aysun Behçet Cevdet Emre) (Aysun Cevdet Demet Emre)(Behçet Emre) -> (Aysun Cevdet Demet Emre) (Behçet Cevdet Demet)(Cevdet Demet) -> (Aysun Behçet Cevdet Emre) (Aysun Behçet Demet Emre)(Cevdet Emre) -> (Aysun Behçet Demet Emre) (Behçet Cevdet Demet)(Demet Emre) -> (Aysun Behçet Cevdet Emre) (Behçet Cevdet Demet)Reduce(k2, list (v2)) -> list(v3)reduce((Aysun Behçet) -> (Aysun Cevdet Demet Emre) (Behçet Cevdet Demet)) (Aysun Behçet) -> (Cevdet Demet)(Aysun Cevdet) -> (Behçet Demet)(Aysun Demet) -> (Behçet Cevdet)(Behçet Cevdet) -> (Aysun Demet Emre)(Behçet Demet) -> (Aysun Cevdet Emre)(Behçet Emre) -> (Cevdet Demet)(Cevdet Demet) -> (Aysun Behçet Emre)(Cevdet Emre) -> (Behçet Demet)(Demet Emre) -> (Behçet Cevdet)Buna göre Behçet, Emre' nin profiline girdiğinde (Behçet Emre) key' inin karşısındaki (Cevdet Demet) e bakara iki ortak arkadaşları olduğunu ve hatta bunların kim olduklarını gösterebiliriz.
  • Single multi-processor computer
  • 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.

×