kodcu.com webinerinde yapılan sunumdur.

1. Serdar Büyüktemiz
serdarb.com
github.com/serdarb
@hserdarb

2. İçerik
• NoSql nedir?
• Neden NoSql?
• Neden MongoDB?
• Nerde MongoDB kullanmalı?
• Write Concern
• Index
• Replica Set
• Sharding
• Map Reduce
• Backup

3. NoSql Nedir?
• İlk olarak «farklı veri yapıları» üzerine yapılmış bir «hacker meetup»
da kullanılan hashtag
• Tam bir tanım yapamasak da, NoSql veritabanlarının ortak
karakterlerinden bahsedebiliriz
• İlişkisiz (non-relational, not like OLTP relational)
• Açık kaynak
• Dağıtık yapı destekli (cluster-friendly)
• Şemasız (shema-less)
• 21. YY web yükünü kaldırabilecek kapasitede

4. Neden NoSql?
• It’s all about the money, like every other thing!
• Yüksek trafiğe ve hesaplama gereklerine daha verimli (ucuz, hızlı) cevap
verebilmek için
• Hızlı yazma için
• Hızlı okuma için
• Yüksek erişilebilirlik için
• Kolay geliştirme ortamı
• Büyük veri ile çalışabilme

5. Dağıtık veri tabanlarında SQL verimli değil

6. Veri Modelleri
1-> 65AD23DEFF
[{id:1,
name: ’veli’,
url: ‘veli.com’ },
{id:2,
name: ’ali’,
phone: ‘366 99 55’ }]

7. Google Big Table
http://research.google.com/archive/bigtable.html

8. Nabza Göre Şerbet – Polyglot Persistence
http://martinfowler.com/bliki/PolyglotPersistence.html

9. Veri tabanınından günümüzün beklentisi
• Kolay ol
• Ucuz ol
• Veriyi kaybetme
• Her zaman erişilebilir ol
• Şemasız da çalışabil
• Küçük projede de kullanabilelim, işimiz büyüdüğünde bizi yarı yolda
bırakma

10. Introduction to NoSQL by Martin Fowler
• http://www.youtube.com/watch?v=qI_g07C_Q5I

11. Transactions & nosql
• Transaction tutarlı verilere sahip olmamız için bir güzellik
• No sql ortamda tutarlı veri sağlamak için iş developer’a düşüyor…
• Ama zaten ilişkisel veri tabanlarında da biraz düşünürseniz transaction
otomatik bir pilot değil,
• Uygulamanın gereğine göre mümkün olduğunca kısa süreli bir scope’u olması
gerek, ve bu ideal ortam için bize gene iş düşüyor…

12. Transactions
http://martinfowler.com/eaaCatalog/optimisticOfflineLock.html
http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html

13. Neden MongoDB?
• Kolay Öğrenilebilir
• Açık Kaynak ve Ücretsiz
• Yüksek Erişilebilirlik
• Yüksek Performans
• TABLE JOIN durumları olmadan tasarlanan yapılar ve «embeded document»
sayesinde hızlı okuma
• «write concern» tercihine dayalı olarak hızlı yazma
• Gittikçe kalabalıklaşan komünite

14. Nerde MongoDB kullanmalı?
• Bloglar
• Posts -> Comments
• Ürün Katalogları
• ProductGroups -> Products -> ProductVariants
• Üye Bilgileri
• User -> UserDetail
• User.Addresses
• İçerik Yönetim Sistemleri
• Log Datası Saklamak
• Coğrafi Bilgi Saklamak (geo-spatial)
• Zaman içinde yapısı değişecek uygulamalar

15. «Relational» vs «Embeded»

16. Write Concern
• Errors Ignored
• Unacknowledged
• Acknowledged
• Journaled
• Replica Acknowledged
• http://docs.mongodb.org/manual/core/write-concern/

17. Write Concern - Unacknowledged

18. Write Concern - Acknowledged

19. Write Concern - Journaled

20. Write Concern - Replica Acknowledged

21. İndex
• İndexler B-tree yapısında tutuluyor

22. İndex Tipleri
• Default _id
• Tek Alan (Single Field)
• Çok Alan (Compound Index)
• Multikey Index (array’e index)
• Geospatial Index
• Text Indexes (text içinde arama için)
• Hashed Indexes (hash based sharding için)

23. Bazı index komutları
• db.collection.createIndex()
• db.collection.ensureIndex()
• db.collection.getIndexStats()
• db.collection.reIndex()
• cursor.explain()

24. indexed vs not-indexed

25. Compound Index
• En çok 31 alandan oluşan bir «compound index» oluşturulabilir
• «hashed index» tanımlı bir alan «compound index» grubunda yer alamaz
db.products.ensureIndex( { "item": 1, "stock": 1 } ) { "_id": ObjectId(...)
"item": "Banana"
"category": ["food", "produce", "grocery"]
"location": "4th Street Store"
"stock": 4
"type": cases
"arrival": (...) }
İki alanda index oluşturduğumuzda
2. alanda da çok sorgu olacaksa
ayrıca index oluşturmak gerekir

26. Multikey Index
• «embedded document» ve «array» alanlar için tanımlanan index
db.books.ensureIndex({ book.tags: 1 })
{
"_id" : ObjectId("..."),
"name" : "Warm Weather",
"author" : "Steve",
"tags" : [ "weather", "hot", "record", "april" ]
}

27. Replica Set
• Verilerinizin güvenliği için başka makinelere de
kopyalanması
• Asenkron çalışır
• Master Slave Modeli
• Veri değiştikçe bazı anlarda sadece tek bir
makinenin en güncel olduğu durumar sözkonusu
• http://docs.mongodb.org/manual/core/replication
-introduction/

28. Sharding’den Önce Düşünülmesi Gerekenler
• Sorguları optimize ettik mi?
• index optimization
• Aktif verilerin ve kullanılan indexlerin boyutunun tek makinenin
RAM’ine sığmayacağı bir noktaya geldik mi?
• İşletim sistemi ve dosya sistemi doğru ayarlarda mı?
• EXT4/XFS, «access time tracking» kapalı olmalı
• Mümkünse SSD disk ve RAID 10

29. Sharding
(veriyi parçalara ayırmak)
2013 verileri
2012 verileri
«shard key» olarak yıl seçip
verilerin tarihine göre
farklı «shard»’a gitmesi sağlanabilir
Mongodb shard’larda yaklaşık miktarda data olmasını ister
Eğer shard’larda veri boyutu arasında fark oluşursa
Veriyi taşıyarak eşitleme yapmaya çalışır
Bu durumda network’de çok büyük boyutda veri taşıma gerçekleşebilir
ve bu sisteminizin erişilebilirliğine zeval verebilir…
dolayısıyla «shard key» seçimi önemlidir!

30. Aggregation Framework
db.products.aggregate([{
$group: {_id: «$brand»,
total: «$sum:1}}
}]);
SELECT brand, count(*)
FROM Products
GROUP BY brand

31. Map Reduce

32. Backup
• Replicaset olarak backup
• mongodump & mongorestore
• https://mms.mongodb.com/ (MongoDB Backup in the Cloud)