Riak &

RiakCS

6 Nisan 2013Linux ve Özgür Yazılım Günleri, Bilgi ÜniversitesiGökhan Boranalpgokhan@zetaops.com

Riak?

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

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ç

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

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öntemitercih etmiş olursunuz.

Dağıtık Bir Sistemden Ne Bekliyoruz?

●High Available●Low Latency●Scalable

●Fault Tolerant●Ops-Friendly●Predictable

Gerçek Hayat Örnekleri

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

Notifcation ServiceYammer

İ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 StoreMochi Media

Github Pages için Web server olarak Riak Webmachine HTTP serverGit.io URL shortener

Document StoreGithub Pages / Git.io

Walkie Talkie Voxer

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!!!!!

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

Voxer - Son durum

Dağıtık Bir Sistemden Ne Bekliyoruz?

●High Available●Low Latency●Scalable

●Fault Tolerant●Ops-Friendly●Predictable

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

●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

Gecikme nelere malolur?

Kullanıcı olayı nasıl görüyor?

●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

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

Sorular

Kaynakça

Bashohttp://www.basho.comhttp://docs.basho.com/

NoSQL Veritabanlarıhttp://www.slideshare.net/kunthar

Scaling to Millions of Simultaneous Connectionshttp://www.confreaks.com/videos/2051-erlangfactorysf2012-scaling-to-millions-of-simultaneous-connectionshttp://download.analysis3.com/Scaling-to-Millions-of-Simultaneous-Connections---Erlang-Factory-download-w7839.pdf

http://en.wikipedia.org/wiki/CAP_theorem

gokhan@zetaops.com