Successfully reported this slideshow.

Nosql ve mongoDB

2,956 views

Published on

Bahçeşehir Üniversitesi'ndeki kodcu.com toplantısında sunduğum NoSql ve MongoDB

Published in: Technology
  • Be the first to comment

Nosql ve mongoDB

  1. 1. NoSql ve MongoDB Saygın Topatan
  2. 2. NoSql ve MongoDB NoSql nedir  Neden ihtiyaç duyuldu  Tipleri MongoDb  Kavramlar  Sharding Şema Tasarımı NoSql’in geleceği
  3. 3. NoSql Nedir? Nedir 2009 başlarında ortaya çıkmış bir kavram İlişkisel Olmayan Veritabanı Yönetim Sistemi Özellikleri Sabit tablo şemaları gerektirmeyebilir Join işlemlerinden kaçınır Yatay ölçeklenir!
  4. 4. No to Sql ?
  5. 5. Neden NoSql? Veri Miktarı Yıllara Göre Saklanan Veri Miktarı ExaByte (10¹⁸) Kaynak: IDC 20119000 79108000700060005000400030002000 9881000 397 623 161 253 0 2006 2007 2008 2009 2010 2015
  6. 6. Neden NoSql? Uygulama Mimarileri1980 ler: Mainframe Uygulamaları Uygulama Veritabanı
  7. 7. Neden NoSql? Uygulama Mimarileri1990 ler: Entegrasyon merkezi olarak veritabanı Uygulama Uygulama Uygulama Veritabanı
  8. 8. Neden NoSql? Uygulama Mimarileri2000 ler: Artan saklama ve performans ihtiyaçları Uygulama Uygulama Uygulama Veritabanı Veritabanı Veritabanı
  9. 9. Neden NoSql?
  10. 10. Neden Ölçekleme?PowerEdge T110 II (Basic) – 8 GB, 3.1 Ghz Quad $1, 350.004TPowerEdge T110 II (Basic) – 32 GB, 3.4 Ghz Quad $12, 103.008TPowerEdge C2100 - 192 GB, 2 x 3 Ghz $19, 960.00IBM System x3850 X5 – 8 x 2.4 Ghz, 2048 GB $645, 605.00K Computer (süper bilgisayar) - 10 petaflops, 705, $10, 000, 000 yıllık işletim ücreti024 cores, 1, 377 TB Setup ücreti ile ilgili bilgi yok
  11. 11. Neden NoSql? MongoDb vs. Sql Server 2008 MongoDB C# API vs. LINQ to SQL
  12. 12. Neden NoSql? MongoDb vs. Sql Server 2008 MongoDB C# API vs. LINQ to SQL
  13. 13. Neden NoSql? MongoDb vs. Sql Server 2008 Gerçek Dünya verileriMongoDb SQL Server
  14. 14. Neden NoSql? MongoDb vs. Sql Server 2008
  15. 15. NoSql Tipleri Anahtar-Değer Ambarı (Key-Value Stores)  Dynomite, Voldemort, Riak, Tokyo Cabinet Doküman Ambarı (Document Store)  MongoDB, CouchDB, RavenDB Geniş Sütun Ambarı/Sütun Aileleri (Wide Column Store/Column Families, BigTable Clones)  Apache Hbase, HyperTable, Cassandra Graf Veritabanları (Graph Databases)  Neo4j, AllegroGraph, InfoGrid
  16. 16. Anahtar Değer Ambarı Tek anahtar – tek değer Son derece hızlı Değer ikili (binary) olarak tutulur.Veritabanı değerin verisini anlamaz, anlamak istemez Nesneye erişim anahtar üzerinden olur değer … anahtar Baslik_€#_NoSql^ ^ ^ Yazar _€#_Saygın ^ ^ ^ BlogPost_127 GonderiTarihi%/// 133546849998) …
  17. 17. Doküman Ambarı (Document Store) Anahtar-değer ambarı, ama değer veritabanı tarafından anlaşılabilir Değer üzerinden sorgu yapmak mümkün doküman { anahtar Baslik: “NoSql”, Yazar: “Saygin”, BlogPost_127 Tarih: “04-02-2012” }
  18. 18. Geniş Sütun Ambarı/Sütun Aileleri(BigTable Clones) Google BigTable yayınından esinlenilmiştir Dağıtık, çok boyutlu, sıralanmış eşleme Her anahtar birden çok sütun ile eşleştirilir Sütun Sütun ailesi Başlık BlogPost Baslik NoSql Row_id BlogPost YazarBlogPost_127 Saygın BlogPost GönderiTarihi 04-02-2012 Comment text Paylaşım için teşekkürler
  19. 19. Geniş Sütun Ambarı/Sütun Aileleri(BigTable Clones) Google BigTable 2006 verileri
  20. 20. Graf Veritabanları Veri ilişkilerine odaklanmış graf yapısıdır. Düğümler(nodes) ve bunları bağlayan kenarlar(edges) Her ikisinde de anahtar-değer ikilileri bulunur Yusuf Gizem Emre Aslı
  21. 21. Graf Veritabanları Veri ilişkilerine odaklanmış graf yapısıdır. Düğümler(nodes) ve bunları bağlayan kenarlar(edges) Her ikisinde de anahtar-değer ikilileri bulunur Yaş: 23 Yaş: 22 Okul: “İTÜ” Okul: “İTÜ” Yusuf Gizem Yaş: 22 Yaş: 23 Okul: “YTÜ” Twitter:”@delikiz” Emre Aslı
  22. 22. Graf Veritabanları Veri ilişkilerine odaklanmış graf yapısıdır. Düğümler(nodes) ve bunları bağlayan kenarlar(edges) Her ikisinde de anahtar-değer ikilileri bulunur Yaş: 23 Yaş: 22 sever Okul: “İTÜ” Okul: “İTÜ” sever Yusuf Gizem Ödevlerini YaparBirlikte Yaşar Kuzen Yaş: 22 Yaş: 23 Okul: “YTÜ” Twitter:”@delikiz” Emre Aslı sever
  23. 23. NoSql Tipleri Boyut-Karmaşıklık karşılaştırmasıVeri Boyutu Anahtar/Değer ambarı BigTable Klonları Key/Value Stores Doküman Ambarları Graf Veritabanları Karmaşıklık (Complexity)
  24. 24.  Doküman Tabanlı veritabanı  JSON türevi (BSON) bir format kullanır Şemasız Performans  C++ da yazılmış  Index desteği Ölçeklenebilir  Replication  Auto-Sharding Ticari destekli (10gen)  Bolca doküman
  25. 25.  Database == Database Table == Collection Index == Index Row == BSON Document Column == BSON Field
  26. 26. mongoDBCREATE TABLE USERS (a Number, b Number) Tabledb.createCollection("mycoll")ALTER TABLE users ADD ...
  27. 27. mongoDBSELECT * FROM usersdb.users.find()SELECT a, b FROM usersdb.users.find({ }, {a:1, b:1})SELECT * FROM users WHERE age>33db.users.find({age:{$gt:33}})SELECT * FROM users WHERE age=33 ORDER BY namedb.users.find({age:33}).sort({name:1})
  28. 28. mongoDBSELECT DISTINCT last_name FROM usersdb.users.distinct(last_name)SELECT COUNT(*) FROM usersdb.users.count()SELECT COUNT(AGE) from usersdb.users.find({age: {$exists: true}}).count()
  29. 29. mongoDB Indexleri// Artandb.users.ensureIndex({name:1})// Eşsizdb.users.ensureIndex({name:1}, {unique:true})//Sessiz, Bloklamayandb.users.ensureIndex({name:1}, {background:true})//Bileşikdb.users.ensureIndex({name:1}, {age:-1})
  30. 30. mongoDB Auto Sharding Verinin her parçası ayrı bir sunucu (shard) tarafından yönetilir Her bir sunucu da verinin bir alt kümesi üzerinde tam kontrole sahiptir Veritabanı işlemleri mümkünse bir shard üzerinde, değilse birden çok sunucu üzerinde yapılır Sistem yükü değiştikçe, verinin sunuculara dağıtılması otomatik olarak dengelenir
  31. 31. Auto Sharding Mimari Görünümü 0 <= userId < 2000 2000<= userId < 5000 5000 <= userId < 9000 mongod mongod mongod mongos istemci
  32. 32. Auto Sharding Mimari Görünümü
  33. 33. Şema Tasarımı Erişim?  OLAP – OLTP  Güncelleme tipleri  Sorgu Tipleri Dikkat!  Join yok  Transaction yok Şema performansı etkileyen en önemli faktör  RDBMS e göre daha fazla tasarım seçeneği var  Embedding, indexler, shard anahtarları
  34. 34. Şema Tasarımı  ŞemasızId Tip Alan Yaricap Kenar Genislik Uzunluk1 Çember 3.14 12 Kare 4 23 Dikdörtgen 10 2 5db.sekil.find(){id:"1", tip:“çember", alan:3.14, yaricap:1}{id:“2", tip:“kare", alan:4, kenar:1}{id:“3", tip:“dikdortgen", alan:10, genislik:2, uzunluk:5}
  35. 35. Blog Post - Gömülü{ id:"post/saygin/2012-02-04/", yazar:"saygin", baslik:"NoSql ve MongoDB", etiketler:["mongodb","nosql"], yorumlar:[ { yazar:"Yusuf", baslik:"Harika !", tarih:"2012-02-04" } ] } Okuma performansı için çok iyi Tüm nesneyi tek seferde yüklüyor Veritabanına tek git-gel yapılıyor Sürekli yazma ihtiyacı varsa, yazma yavaş olabilir
  36. 36. Blog Post – Gömülü DeğilBlog.posts{ id:"post/saygin/2012-02-04/", yazar:"saygin", baslik:"NoSql ve MongoDB", etiketler:["mongodb","nosql"] }Blog.yorumlar{ post:"post/saygin/2012-02-04/", yazar:"Yusuf", baslik:"Harika !", tarih:"2012-02-04"}
  37. 37. Blog Post - HibridBlog.yorumlar{ id: "post/saygin/2012-02-04/1----1", yorumlar:[ { yazar:"Yusuf", baslik:"Harika !", tarih:"2012-02-04" }, { yazar:“Hasan", baslik:“Güzel Paylaşım", tarih:"2012-02-04" }, ]}
  38. 38. Indeksler Ortak sorgulara göre indeksler oluşturulmalı Duplike indeksler olmamalı : (A,B) varsa (A) gereksiz Gereksiz indeksler yazma-güncelleme performansını etkiler
  39. 39. Shard Anahtarı Seçmek Shard anahtarı verinin nasıl dağıtılacağını belirler Değiştirmesi zordur En önemli performans kararı (Sharding)
  40. 40. NoSql in geleceği RDBMS  Veri bütünlüğü  Normalizasyon  Mevcut sistemler, üreticiler (Oracle, microsoft..)  Veritabanı araçları (Raporlama, analiz, 3rd party)  Ölçekleme problemleri
  41. 41. Doğru Aracı Seçmek
  42. 42. TeşekkürlerSaygın TopatanSaygin@sirkethaberleri.com@saygin

×