Riak ve RiakCS hakkinda ozet bilgi icerir. Baslamadan once Nosql Veritabanlari sunumumu okumanizi siddetle tavsiye ederim.

1. Riak
&
RiakCS
6 Nisan 2013
Linux ve Özgür Yazılım Günleri, Bilgi Üniversitesi
Gökhan Boranalp
gokhan@zetaops.com

2. Riak?
●Özet geç...
●NoSQL veritabanı seçmek
●Sıkıntılar?
●Dağıtık bir sistemden ne istiyoruz?

3. Meşhur Dynamo teoreminden ilhamla yaratılmış bir K/V
veritabanıdır.
● full text search, mapreduce, secondary indices, link
traversal, commit hooks, HTTP ve binary interfaces,
pluggable backends
●Erlang ve C/C++ ile yazılmıştır, Apache 2 lisansına
sahiptir.
●Enterprise yetenekler (multi-datacenter replication,
snmp monitoring)
Özet Geç

4. NoSQL veritabanı seçmek
●Eğer projeniz küçük ölçekli ise hepsi uyar.
●NoSQL VTler, yeni kullanım sorunlarına cevap verirler
ancak RDBMS gibi geleneksel yapıların yeteneklerinin
yerine, yenilerini nasıl koyacağınıza çalışmak gerekir.
●Yazacağınız sistemi bilmek ZORUNDASINIZ!
●A lot of NoSQL marketing is bullshit

5. Riak'ı Seçerken
●MongoDB'yi Riak ile, CouchDB'yi Cassandra ile
karşılaştırmak üzere deneyler yapıyorsanız sorununuzu
hiç ANLAMAMIŞSINIZ demektir.
●Riak'ı seçmekle;
● Failure durumunda 'Consistency for availability'
seçeneğini
● Zengin veri sorgulama teknikleri yerine daha basit ve
ölçeklenebilir yöntemi
● Dinazorlaşmış teknikler yerine, yenilikçi bir yöntemi
tercih etmiş olursunuz.

6. Dağıtık Bir Sistemden Ne Bekliyoruz?
●High Available
●Low Latency
●Scalable
●Fault Tolerant
●Ops-Friendly
●Predictable

7. Gerçek Hayat Örnekleri

8. xfnityTV mobile uygulaması için kullanıcı profli
depolama
İçerik sağlayıcılardan gelen Metadata ve lisans
bilgisinin depolanması
Kesin 'latency' gereksinimi
User/Metadata
Comcast

9. Notifcation Service
Yammer

10. İlk Basho Müşterisi (2009 sonu)
Mochi web her bir talep = 1 read, aynı anda
duruma göre bir write
Unavailability, yüksek gecikme oranları =
kaybedilen reklam gelirleri
Session Store
Mochi Media

11. Github Pages için Web server olarak Riak
Webmachine HTTP server
Git.io URL shortener
Document Store
Github Pages / Git.io

12. Walkie Talkie
Voxer

13. 11 Riak Nodes
~500GB dataset
~20k peak concurrent kulllanıcı
~4MM günlük request
Voxer - İstatistik Bilgi
Ve bir anda değişen ihtiyaçlar!!!!!

15. > 100 nodes
~1TB günlük gelen veri
> 200k concurrent kullanıcı
> 2 milyar günlük request
Aralık-Ocak ayları arasında 11 node birden
80 node daha büyüdü!!!
Voxer - Son durum

16. Dağıtık Bir Sistemden Ne Bekliyoruz?
●High Available
●Low Latency
●Scalable
●Fault Tolerant
●Ops-Friendly
●Predictable

17. Read/Write esnasında başarısızlığın
sonuçları:
Gelir kaybı
Kullanıcı kaybı
Availability ve latency kavramları birbiri
içine geçmiş kavramlardır
High Availability

18. ●Bazı hallerde, gecikmiş bir cevabın en
küçük bir değeri yoktur.
●Kullanıcı yavaş sitelerin çalışmadığını
düşünür
●SLA gereksinimleri yerine getirilemez
●SOA için gereken SLA yerine getirilemez
Low Latency

19. Gecikme nelere malolur?
Kullanıcı olayı nasıl görüyor?

20. ●Her şey fail olabilir
● Özellikle cloud içinde!
●Host/disk/network sorunu ortaya çıkarsa
nelere etki eder;
● Availability sorunu oluşur
● Latency oluşur
● Operasyon ekibini etkiler
Fault Tolerance

21. Bu muhabbetler tanıdık geliyor mu?
●“bad shard key seçmişiz...”
●“master node gene patladı”
●“failover script yazdığımız gibi
çalışmadı...”
●“meğerse konfigürasyon hatası varmış...”
Bütün gece oturup DB ayağa kaldırmak,
sizi KAHRAMAN YAPMAZ.
Operasyonel Maliyet

25. Sorular

26. Kaynakça
Basho
http://www.basho.com
http://docs.basho.com/
NoSQL Veritabanları
http://www.slideshare.net/kunthar
Scaling to Millions of Simultaneous Connections
http://www.confreaks.com/videos/2051-erlangfactorysf2012-scaling-to-millions-of-simultaneous-connections
http://download.analysis3.com/Scaling-to-Millions-of-Simultaneous-Connections---Erlang-Factory-download-w7839.pdf
http://en.wikipedia.org/wiki/CAP_theorem

27. gokhan@zetaops.com