Add Turkish translation
Selin Cosar
parent
d87fa715db
commit
b4a1b89af7
1837
README-tr.md
1837
README-tr.md
|
|
@ -0,0 +1,1837 @@
|
|||
*[English](README.md) ∙ [日本語](README-ja.md) ∙ [简体中文](README-zh-Hans.md) ∙ [繁體中文](README-zh-TW.md) | [العَرَبِيَّة](https://github.com/donnemartin/system-design-primer/issues/170) ∙ [বাংলা](https://github.com/donnemartin/system-design-primer/issues/220) ∙ [Português do Brasil](https://github.com/donnemartin/system-design-primer/issues/40) ∙ [Deutsch](https://github.com/donnemartin/system-design-primer/issues/186) ∙ [ελληνικά](https://github.com/donnemartin/system-design-primer/issues/130) ∙ [עברית](https://github.com/donnemartin/system-design-primer/issues/272) ∙ [Italiano](https://github.com/donnemartin/system-design-primer/issues/104) ∙ [한국어](https://github.com/donnemartin/system-design-primer/issues/102) ∙ [فارسی](https://github.com/donnemartin/system-design-primer/issues/110) ∙ [Polski](https://github.com/donnemartin/system-design-primer/issues/68) ∙ [русский язык](https://github.com/donnemartin/system-design-primer/issues/87) ∙ [Español](https://github.com/donnemartin/system-design-primer/issues/136) ∙ [ภาษาไทย](https://github.com/donnemartin/system-design-primer/issues/187) ∙ [Türkçe](README-tr.md) ∙ [tiếng Việt](https://github.com/donnemartin/system-design-primer/issues/127) ∙ [Français](https://github.com/donnemartin/system-design-primer/issues/250) | [Add Translation](https://github.com/donnemartin/system-design-primer/issues/28)*
|
||||
|
||||
**Bu kaynağın [çeviri](TRANSLATIONS.md)sine yardım edebirsiniz!**
|
||||
|
||||
# Sistem Tasarım Rehberi
|
||||
|
||||
<p align="center">
|
||||
<img src="images/jj3A5N8.png">
|
||||
<br/>
|
||||
</p>
|
||||
|
||||
## Amaç
|
||||
|
||||
> Büyük ölçekli sistemler için sistem tasarımını öğrenmek.
|
||||
>
|
||||
> Sistem tasarımı mülakatlarına hazırlanmak.
|
||||
|
||||
### Büyük sistemlerin nasıl tasarlacağını öğrenin
|
||||
|
||||
Ölçeklenebilir sistemlerin nasıl tasarlanacağını öğrenmek, daha iyi bir mühendis olmanıza yardımcı olacaktır.
|
||||
|
||||
Sistem tasarımı, çok geniş bir konudur. İnternette sistem tasarım ilkelerine ilişkin sayısız kaynak bulunmaktadır. **
|
||||
|
||||
Bu repo, ölçeklenebilir sistemlerin nasıl oluşturulacağını öğrenmenize yardımcı olabilecek düzenli bir kaynak koleksiyonudur.
|
||||
|
||||
### Açık kaynak topluluğundan bilgi edinin
|
||||
|
||||
Bu, sürekli güncellenen açık kaynak projesinin ilk sürümüdür.
|
||||
|
||||
[Katkı](#katkı)da bulunabilirsiniz!
|
||||
|
||||
### Sistem tasarımı görüşmelerine hazırlanın
|
||||
|
||||
Pek çok teknoloji şirketinde, görüşmeleri kodlamanın yanı sıra sistem tasarımı da **teknik görüşme sürecinde** **gerekli bir adımdır**.
|
||||
|
||||
**Sistem tasarımıyla ilgili yaygın mülakat sorularını pratik yapın** ve **örnek çözümler** ile yanıtlarınızı karşılaştırın: tartışmalar, kodlar ve diyagramlar.
|
||||
|
||||
Mülakata hazırlık için diğer konular:
|
||||
|
||||
* [Çalışma rehberi](#Çalışma-rehberi)
|
||||
* [Sistem tasarımı mülakat sorusu nasıl ele alınır](#sistem-tasarımı-mülakat-sorusu-nasıl-ele-alınır)
|
||||
* [Sistem tasarımı mülakat soruları ve **çözümleri**](#sistem-tasarımı-mülakat-soruları-ve-çözümleri)
|
||||
* [Nesne yönelimli tasarım mülakat soruları ve **çözümleri**](#nesne-yönelimli-tasarım-mülakat-soruları-ve-çözümleri)
|
||||
* [Diğer sistem tasarımı mülakat soruları](#diğer-sistem-tasarımı-mülakat-soruları)
|
||||
|
||||
## Anki bilgi kartları
|
||||
|
||||
<p align="center">
|
||||
<img src="images/zdCAkB3.png">
|
||||
<br/>
|
||||
</p>
|
||||
|
||||
[Anki bilgi kartları](https://apps.ankiweb.net/)nı temel sistem tasarımı kavramlarını ezberlemenize yardımcı olmak için kullanabilirsiniz.
|
||||
|
||||
* [Sistem tasarımı kartları](resources/flash_cards/System%20Design.apkg)
|
||||
* [Sistem tasarımı alıştırma kartları](resources/flash_cards/System%20Design%20Exercises.apkg)
|
||||
* [Nesneye yönelik tasarım alıştırma kartları](resources/flash_cards/OO%20Design.apkg)
|
||||
|
||||
Her zaman ve her yerde kullanılabilir.
|
||||
|
||||
### Kod Kaynakları: Etkileşimli Kodlama Yarışmaları
|
||||
|
||||
[**Kodlama Mülakatları**](https://github.com/donnemartin/interactive-coding-challenges)na hazırlanmak için kaynak mı arıyorsunuz?
|
||||
|
||||
<p align="center">
|
||||
<img src="images/b4YtAEN.png">
|
||||
<br/>
|
||||
</p>
|
||||
|
||||
Lütfen ek bilgi kartlarını içeren [**Etkileşimli Kodlama Yarışmaları**](https://github.com/donnemartin/interactive-coding-challenges) reposuna göz atın:
|
||||
|
||||
* [Kodlama kartları](https://github.com/donnemartin/interactive-coding-challenges/tree/master/anki_cards/Coding.apkg)
|
||||
|
||||
## Katkı
|
||||
|
||||
> Topluluktan öğrenin.
|
||||
|
||||
Yardım etmek için değişiklik gönderme talebi(pull request) göndermekten çekinmeyin:
|
||||
|
||||
* Hataları düzeltmek
|
||||
* Bölümleri geliştirmek
|
||||
* Yeni bölüm eklemek
|
||||
* [Çeviri Yardımı](https://github.com/donnemartin/system-design-primer/issues/28)
|
||||
|
||||
Hala geliştirilmesi gereken bazı içerikler, [Geliştirme aşamasında](#geliştirme-aşamasında) bölümünde bulunmaktadır.
|
||||
|
||||
Lütfen [katkı kurallarını](CONTRIBUTING.md) inceleyin.
|
||||
|
||||
## Sistem tasarımı konuları dizini
|
||||
|
||||
> Avantajlar ve dezavantajlar da dahil olmak üzere çeşitli sistem tasarımı konularının özeti. **Her şeyin bir karşılığı vardır.**. (Ek çeviri notu: Karşılaştırma sonucunda bir şeyden feragat etmek gerektiği vurgulanmaktadır.)
|
||||
>
|
||||
> Her bölüm, ek kaynaklara bağlantılar içerir.
|
||||
|
||||
<p align="center">
|
||||
<img src="images/jrUBAF7.png">
|
||||
<br/>
|
||||
</p>
|
||||
|
||||
* [Sistem tasarımı konuları: buradan başlayın](#sistem-tasarımı-konuları-buradan-başlayın)
|
||||
* [1. Adım: Ölçeklenebilirlik video dersini inceleyin](#1-adım-ölçeklenebilirlik-video-dersini-inceleyin)
|
||||
* [2. Adım: Ölçeklenebilirlik makalesini inceleyin](#2-adım-ölçeklenebilirlik-makalesini-inceleyin)
|
||||
* [Sonraki adımlar](#sonraki-adımlar)
|
||||
* [Performans veya ölçeklenebilirlik](#performans-veya-ölçeklenebilirlik)
|
||||
* [Gecikme veya verim](#gecikme-veya-verim)
|
||||
* [Kullanılabilirlik veya tutarlılık](#kullanılabilirlik-veya-tutarlılık)
|
||||
* [CAP teoremi](#cap-teoremi)
|
||||
* [CP - Tutarlılık ve bölüm toleransı](#cp--tutarlılık-ve-bölüm-toleransı)
|
||||
* [AP - Kullanılabilirlik ve bölüm toleransı](#ap--kullanılabilirlik-ve-bölüm-toleransı)
|
||||
* [Tutarlılık modelleri](#tutarlılık-modelleri)
|
||||
* [Zayıf tutarlılık](#zayıf-tutarlılık)
|
||||
* [Nihai tutarlılık](#Nihai-tutarlılık)
|
||||
* [Güçlü tutarlılık](#güçlü-tutarlılık)
|
||||
* [Kullanılabilirlik modları](#kullanılabilirlik-modları)
|
||||
* [Yük devretme](#yük-devretme)
|
||||
* [Çoğaltma](#çoğaltma)
|
||||
* [Sayılarla erişilebilirlik](#sayılarla-erişilebilirlik)
|
||||
* [Alan adı sistemi (DNS)](#alan-adı-sistemi-dns)
|
||||
* [İçerik dağıtım ağı (CDN)](#içerik-dağıtım-ağı-cdn)
|
||||
* [Push CDN](#push-cdn)
|
||||
* [Pull CDN](#pull-cdn)
|
||||
* [Yük dengeleyici (Load balancer)](#yük-dengeleyici-load-balancer)
|
||||
* [Aktif-pasif)](#aktif-pasif)
|
||||
* [Aktif-aktif)](#aktif-aktif)
|
||||
* [Katman 4 yük dengeleyicisi](#katman-4-yük-dengeleyicisi)
|
||||
* [Katman 7 yük dengeleyicisi](#katman-7-yük-dengeleyicisi)
|
||||
* [Yatay ölçekleme](#yatay-ölçekleme)
|
||||
* [Ters proxy (web sunucusu)](#ters-proxy-web-sunucusu)
|
||||
* [Yük dengeleyici ve ters proxy](#yük-dengeleyici-ve-ters-proxy)
|
||||
* [Uygulama katmanı](#uygulama-katmanı)
|
||||
* [Mikroservisler](#mikroservisler)
|
||||
* [Servis keşfi](#servis-keşfi)
|
||||
* [Veritabanı](#veritabanı)
|
||||
* [İlişkisel veritabanı yönetim sistemi (RDBMS)](#ilişkisel-veritabanı-yönetim-sistemi-rdbms)
|
||||
* [Master-slave çoğaltma](#master-slave-çoğaltma)
|
||||
* [Master-master çoğaltma](#master-master-çoğaltma)
|
||||
* [Federasyon](#federasyon)
|
||||
* [Parçalama](#parçalama)
|
||||
* [Denormalizasyon](#denormalizasyon)
|
||||
* [SQL ayarlama (SQL tuning)](#sql-ayarlama-sql-tuning)
|
||||
* [NoSQL](#nosql)
|
||||
* [Anahtar/değer deposu](#anahtar-değer-deposu)
|
||||
* [Belge deposu](#belge-deposu)
|
||||
* [Geniş sütun deposu](#geniş-sütun-deposu)
|
||||
* [Grafik veritabanı](#grafik-veritabanı)
|
||||
* [SQL veya NoSQL](#sql-veya-nosql)
|
||||
* [Önbellek](#önbellek)
|
||||
* [İstemci önbelleği](#istemci-önbelleği)
|
||||
* [CDN önbelleği](#cdn-önbelleği)
|
||||
* [Web sunucusu önbelleği](#web-sunucusu-önbelleği)
|
||||
* [Veritabanı önbelleği](#veritabanı-önbelleği)
|
||||
* [Uygulama Önbelleği](#uygulama-önbelleği)
|
||||
* [Veritabanı sorgu düzeyinde önbellekleme](#veritabanı-sorgu-düzeyinde-önbellekleme)
|
||||
* [Nesne düzeyinde önbellekleme](#nesne-düzeyinde-önbellekleme)
|
||||
* [Önbellek ne zaman güncellenmeli](#önbellek-ne-zaman-güncellenmeli)
|
||||
* [Cache-aside](#cache-aside)
|
||||
* [Üzerine yazma (write-through)](#üzerine-yazma-write-through)
|
||||
* [Geri yazma (write-behind)](#geri-yazma-write-behind)
|
||||
* [Önbelleği önceden yenileme (refresh-ahead)](#önbelleği-önceden-yenileme-refresh-ahead)
|
||||
* [Asenkronizm](#asenkronizm)
|
||||
* [Mesaj kuyrukları](#mesaj-kuyrukları)
|
||||
* [Görev kuyrukları](#görev-kuyrukları)
|
||||
* [Back pressure](#back-pressure)
|
||||
* [İletişim](#iletişim)
|
||||
* [İletim kontrol protokolü (TCP)](#iletim-kontrol-protokolü-tcp)
|
||||
* [Kullanıcı datagram protokolü (UDP)](#kullanıcı-datagram-protokolü-udp)
|
||||
* [Uzaktan yordam çağrısı (RPC)](#uzaktan-yordam-çağrısı-rpc)
|
||||
* [Temsili durum transferi (REST)](#temsili-durum-transferi-rest)
|
||||
* [Güvenlik](#güvenlik)
|
||||
*[EK](#ek)
|
||||
* [İkinin kuvveti tablosu](#ikinin-kuvveti-tablosu)
|
||||
* [Her programcının bilmesi gereken gecikme sayıları](#her-programcının-bilmesi-gereken-gecikme-sayıları)
|
||||
* [Diğer sistem tasarımı mülakat soruları](#diğer-sistem-tasarımı-mülakat-soruları)
|
||||
* [Gerçek dünya mimarileri](#gerçek-dünya-mimarileri)
|
||||
* [Şirketlerin sistem mimarileri](#şirketlerin-sistem-mimarileri)
|
||||
*[Şirketlerin mühendislik blogları](#şirketlerin-mühendislik-blogları)
|
||||
*[Geliştirme aşamasında](#geliştirme-aşamasında)
|
||||
* [Katkıda bulunanlar](#katkıda-bulunanlar)
|
||||
* [İletişim](#iletişim)
|
||||
* [Lisans](#lisans)
|
||||
|
||||
## Çalışma rehberi
|
||||
|
||||
> Mülakat zaman çizelgenize (kısa, orta, uzun) göre önerilen konuları gözden geçirin.
|
||||
|
||||
|
||||
|
||||
**S: Mülakatlar için buradaki her şeyi bilmem gerekiyor mu? **
|
||||
|
||||
**C: Hayır, mülakata hazırlanmak için buradaki her şeyi bilmenize gerek yok. **
|
||||
|
||||
Bir mülakatta size ne sorulacağı aşağıdaki faktörlere bağlıdır:
|
||||
|
||||
* Tecrübeniz
|
||||
* Teknik geçmişiniz
|
||||
* Görüşme yapacağınız pozisyon(lar)
|
||||
* Görüşme yapacağınız firma(lar)
|
||||
* Şans
|
||||
|
||||
Daha fazla deneyime sahip adayların genellikle sistem tasarımı konusunda daha fazla bilgiye sahip olmaları beklenir. Yazılım mimarlarından veya ekip liderlerden diğer adaylara göre daha fazlasını bilmeleri beklenebilir. En iyi teknoloji şirketleri, genellikle bir veya daha fazla sistem tasarımı mülakatı yapmaktadır.
|
||||
|
||||
Geniş bir perspektifle başlayın ve daha derine inmek için birkaç alana odaklanın. Önemli bazı sistem tasarım konuları hakkında biraz bilgi sahibi olmak faydalı olacaktır. Aşağıdaki rehberi, zaman çizelgenize, deneyiminize, hangi pozisyonlar için hangi şirketlerle mülakat yapacağınıza göre ayarlayın.
|
||||
|
||||
* **Kısa zaman çizelgesi** - Sistem tasarımı konularında **geniş bir bakış açısı** hedefleyin. **Birkaç** mülakat sorusu çözerek pratiğinizi artırın.
|
||||
* **Orta zaman çizelgesi** - Sistem tasarımı konularında **geniş bir bakış açısı** ve **biraz derinlik** elde etmeyi hedefleyin. **Birçok** mülakat sorusunu çözerek pratiğinizi artırın.
|
||||
* **Uzun zaman çizelgesi** - Sistem tasarımı konularında **geniş bir bakış açısı** ve **daha fazla derinlik** elde etmeyi hedefleyin. Mülakat sorularının **çoğu**nu çözerek pratiğinizi artırın.
|
||||
|
||||
| | Kısa | Orta | Uzun |
|
||||
|---------------------------------------------------------------------------------------------------------------------------|--------|--------|------|
|
||||
| [Sistem tasarımı konuları dizini](#sistem-tasarımı-konuları-dizini)ni okuyarak geniş bir fikir edinin | :+1: | :+1: | :+1: |
|
||||
| Mülakat yapacağınız şirketlerin bazı [mühendislik blog yazılarını](#şirketlerin-mühendislik-blogları) okuyun | :+1: | :+1: | :+1: |
|
||||
| Bazı [Gerçek dünya mimarileri](#gerçek-dünya-mimarileri) başlıklarını inceleyin | :+1: | :+1: | :+1: |
|
||||
| [Sistem tasarımı mülakat sorusu nasıl ele alınır](#sistem-tasarımı-mülakat-sorusu-nasıl-ele-alınır) başlığını inceleyin | :+1: | :+1: | :+1: |
|
||||
| [Sistem tasarımı mülakat soruları ve çözümleri](#sistem-tasarımı-mülakat-soruları-ve-çözümleri)ne çalışın | Birkaç | Birçok | Çoğu |
|
||||
| [Nesne yönelimli tasarım mülakat soruları ve cevapları](#nesne-yönelimli-tasarım-mülakat-soruları-ve-çözümleri)ne çalışın | Birkaç | Birçok | Çoğu |
|
||||
| [Diğer sistem tasarımı mülakat soruları](#diğer-sistem-tasarımı-mülakat-soruları)nı gözden geçirin | Birkaç | Birçok | Çoğu |
|
||||
|
||||
## Sistem tasarımı mülakat sorusu nasıl ele alınır?
|
||||
|
||||
Sistem tasarımı mülakatı **açık uçlu bir görüşmedir**. Konuşmayı sizin yönlendirmeniz beklenir.
|
||||
|
||||
Tartışmayı yönlendirmek için aşağıdaki adımları kullanabilirsiniz. Bu süreci sağlamlaştırmak için lütfen aşağıdaki adımları kullanarak [Sistem tasarımı mülakat soruları ve çözümleri](#sistem-tasarımı-mülakat-soruları-ve-çözümleri) bölümüne bakınız.
|
||||
|
||||
### Adım 1: Kullanım senaryolarını, kısıtlamaları ve varsayımları açıklayın
|
||||
|
||||
İhtiyacınız olan her şeyi bir araya toplayın ve soruna bakın. Kullanım senaryolarını ve kısıtlamaları net bir şekilde anlayabilmek için sorular sormaya devam edin. Varsayımları tartışın.
|
||||
|
||||
* Kim kullanacak?
|
||||
* Nasıl kullanacaklar?
|
||||
* Kaç kullanıcı var?
|
||||
* Sistemin işlevi nedir?
|
||||
* Sistemin girişi ve çıkışı nelerdir?
|
||||
* Ne kadar veri işlenmek isteniyor?
|
||||
* Saniyede kaç isteğin işleme alınması bekleniyor?
|
||||
* İstenilen okuma-yazma oranı nedir?
|
||||
|
||||
### Adım 2: Üst düzey bir tasarım oluşturun
|
||||
|
||||
Üst düzey bir tasarımın ana hatlarını çizmek için tüm önemli bileşenleri kullanın.
|
||||
|
||||
* Ana bileşenleri ve bağlantıları çizin
|
||||
* Fikrinizi gerekçelendirin
|
||||
|
||||
### Adım 3: Temel bileşenleri tasarlayın
|
||||
|
||||
Her bir temel bileşenin ayrıntılı ve derinlemesine analizini gerçekleştirin. Örneğin, sizden [URL kısaltma hizmeti tasarlamanız](solutions/system_design/pastebin/README.md) istendiyse, bunları tartışın:
|
||||
|
||||
* Tam URL'nin hash değerini oluşturmak ve saklamak
|
||||
* [MD5](solutions/system_design/pastebin/README.md) ve [Base62](solutions/system_design/pastebin/README.md)
|
||||
* Hash çakışmaları (Hash collisions)
|
||||
* SQL veya NoSQL
|
||||
* Veritabanı modeli
|
||||
* Hash edilmiş URL'yi tam bir URL'ye çevirmek
|
||||
* Veritabanı araması
|
||||
* API ve nesne yönelimli tasarım
|
||||
|
||||
### Adım 4: Tasarımı genişletin
|
||||
|
||||
Sistemin performansını etkileyen durumları ve sınırlamaları belirleyin ve ele alın. Örneğin, genişletme sorununu(address scalability issue) tanımlamak için aşağıdakilere ihtiyacınız var mı?
|
||||
|
||||
* Yük dengeleme (Load balancer)
|
||||
* Yatay genişleme (Horizontal scaling)
|
||||
* Önbellek (Caching)
|
||||
* Veritabanı parçalama (Database sharding)
|
||||
|
||||
Olası çözümleri ve maliyetleri tartışın. Her şeyin bir karşılığı vardır. (Ek çeviri notu: Karşılaştırma sonucunda bir şeyden feragat etmek gerektiği vurgulanmaktadır.) [Ölçeklenebilir sistemler için tasarım ilkeleri](#sistem-tasarımı-konuları-dizini)ni kullanarak tasarımdaki performans veya kapasite kısıtlamalarını belirleyin.
|
||||
|
||||
### Tahmini hesaplama
|
||||
|
||||
Elle bazı tahminler yapmanız istenebilir. [Ek](#ek) olarak aşağıdaki kaynaklara bakabilirsiniz:
|
||||
|
||||
* [Use back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html)
|
||||
* [2'nin kuvvet tablosu](#ikinin-kuvveti-tablosu)
|
||||
* [Her programcının bilmesi gereken gecikme sayıları](#Her-programcının-bilmesi-gereken-gecikme-sayıları)
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
Daha iyi bir fikir edinmek için aşağıdaki bağlantılara göz atın:
|
||||
|
||||
* [How to ace a systems design interview](https://www.palantir.com/2011/10/how-to-rock-a-systems-design-interview/)
|
||||
* [The system design interview](http://www.hiredintech.com/system-design)
|
||||
* [Intro to Architecture and Systems Design Interviews](https://www.youtube.com/watch?v=ZgdS0EUmn70)
|
||||
* [System design template](https://leetcode.com/discuss/career/229177/My-System-Design-Template)
|
||||
|
||||
## Sistem tasarımı mülakat soruları ve çözümleri
|
||||
|
||||
> Genel sistem tasarımı mülakat soruları ve çözümler, kodlar ve diyagramlar.
|
||||
>
|
||||
|
||||
> Çözümler, `solutions/` klasöründe bulunmaktadır.
|
||||
|
||||
| Soru | |
|
||||
|----------------------------------------------------------------------------------|--------------------------------------------------------------|
|
||||
| Pastebin.com(veya Bit.ly) tasarlayın | [Çözüm](solutions/system_design/pastebin/README-zh-Hans.md) |
|
||||
| Twitter zaman çizelgesi ve arama(veya Facebook haber akışı ve arama) tasarlayın | [Çözüm](solutions/system_design/twitter/README.md) |
|
||||
| Bir web tarayıcısı tasarlayın | [Çözüm](solutions/system_design/web_crawler/README.md) |
|
||||
| Mint.com tasarlayın | [Çözüm](solutions/system_design/mint/README.md) |
|
||||
| Sosyal ağ için veri yapılarını tasarlayın | [Çözüm](solutions/system_design/social_graph/README.md) |
|
||||
| Arama motorları için bir anahtar/değer(key-value) deposu tasarlayın | [Çözüm](solutions/system_design/query_cache/README.md) |
|
||||
| Amazon'un satış sıralamasını kategori özellikleri aracılığıyla tasarlayın | [Çözüm](solutions/system_design/sales_rank/README.md) |
|
||||
| AWS'de milyon kullanıcılı bir sistem tasarlayın | [Çözüm](solutions/system_design/scaling_aws/README.md) |
|
||||
| Sistem tasarımı sorusu ekleyin | [Katkı](#katkı) |
|
||||
|
||||
### Pastebin.com(veya Bit.ly) tasarlayın
|
||||
|
||||
[Alıştırma ve çözümü görüntüleyin](solutions/system_design/pastebin/README.md)
|
||||
|
||||
|
||||
|
||||
### Twitter zaman çizelgesi ve arama(veya Facebook haber akışı ve arama) tasarlayın
|
||||
|
||||
[Alıştırma ve çözümü görüntüleyin](solutions/system_design/twitter/README.md)
|
||||
|
||||
|
||||
|
||||
### Bir web tarayıcısı tasarlayın
|
||||
|
||||
[Alıştırma ve çözümü görüntüleyin](solutions/system_design/web_crawler/README.md)
|
||||
|
||||
|
||||
|
||||
### Mint.com tasarlayın
|
||||
|
||||
[Alıştırma ve çözümü görüntüleyin](solutions/system_design/mint/README.md)
|
||||
|
||||
|
||||
|
||||
### Sosyal ağ için veri yapılarını tasarlayın
|
||||
|
||||
[Alıştırma ve çözümü görüntüleyin](solutions/system_design/social_graph/README.md)
|
||||
|
||||
|
||||
|
||||
### Arama motorları için bir anahtar/değer(key-value) deposu tasarlayın
|
||||
|
||||
[Alıştırma ve çözümü görüntüleyin](solutions/system_design/query_cache/README.md)
|
||||
|
||||
|
||||
|
||||
### Amazon'un satış sıralamasını kategori özellikleri aracılığıyla tasarlayın
|
||||
|
||||
[Alıştırma ve çözümü görüntüleyin](solutions/system_design/sales_rank/README.md)
|
||||
|
||||
|
||||
|
||||
### AWS'de milyon kullanıcılı bir sistem tasarlayın
|
||||
|
||||
[Alıştırma ve çözümü görüntüleyin](solutions/system_design/scaling_aws/README.md)
|
||||
|
||||
|
||||
|
||||
## Nesne yönelimli tasarım mülakat soruları ve çözümleri
|
||||
|
||||
> Genel nesne yönelimli tasarım mülakat soruları ve çözümler, kodlar ve diyagramlar.
|
||||
> >
|
||||
> Çözümler, `solutions/` klasöründe bulunmaktadır.
|
||||
|
||||
>**Not: Bu bölüm halen geliştirilme aşamasındadır**
|
||||
|
||||
| Soru | |
|
||||
|------------------------------------------|-------------------------------------------------------------------------------|
|
||||
| Karma tablo(Hash map) tasarlayın | [Çözüm](solutions/object_oriented_design/hash_table/hash_map.ipynb) |
|
||||
| LRU önbelleğini tasarlayın | [Çözüm](solutions/object_oriented_design/lru_cache/lru_cache.ipynb) |
|
||||
| Çağrı merkezi tasarlayın | [Çözüm](solutions/object_oriented_design/call_center/call_center.ipynb) |
|
||||
| Kart destesi tasarlayın | [Çözüm](solutions/object_oriented_design/deck_of_cards/deck_of_cards.ipynb) |
|
||||
| Park yeri tasarlayın | [Çözüm](solutions/object_oriented_design/parking_lot/parking_lot.ipynb) |
|
||||
| Sohbet hizmeti tasarlayın | [Çözüm](solutions/object_oriented_design/online_chat/online_chat.ipynb) |
|
||||
| Dairesel dizi(circular array) tasarlayın | [Katkı](#katkı) |
|
||||
| Nesne yönelimli tasarım sorusu ekleyin | [Katkı](#katkı) |
|
||||
|
||||
## Sistem tasarımı konuları: buradan başlayın
|
||||
|
||||
Sistem tasarımına aşina değil misiniz?
|
||||
|
||||
Öncelikle; genel ilkeler, bunların ne olduğu, nasıl kullanılacağı, artıları ve eksileri hakkında temel bir anlayışa sahip olmanız gerekir.
|
||||
|
||||
### 1. Adım: Ölçeklenebilirlik video dersini inceleyin
|
||||
|
||||
[Scalability Lecture at Harvard](https://www.youtube.com/watch?v=-W9F__D3oY4)
|
||||
|
||||
* İşlenen konular:
|
||||
* Dikey ölçeklendirme(Vertical scaling)
|
||||
* Yatay ölçeklendirme(Horizontal scaling)
|
||||
* Önbellek(Caching)
|
||||
* Yük dengeleme(Load balancing)
|
||||
* Veritabanı çoğaltma(Database replication)
|
||||
* Veritabanı bölümü(Database partitioning)
|
||||
|
||||
### 2. Adım: Ölçeklenebilirlik makalesini inceleyin
|
||||
|
||||
[Scalability](http://www.lecloud.net/tagged/scalability/chrono)
|
||||
|
||||
* İşlenen konular:
|
||||
* [Klonlar(Clones)](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
|
||||
* [Veritabanları(Databases)](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
|
||||
* [Önbellekler(Caches)](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
|
||||
* [Asenkronizm(Asynchronism)](http://www.lecloud.net/post/9699762917/scalability-for-dummies-part-4-asynchronism)
|
||||
|
||||
### Sonraki adımlar
|
||||
|
||||
Daha sonra, üst düzey karşılaştırmalara bakacağız:
|
||||
|
||||
* **Performans** veya **Ölçeklenebilirlik**
|
||||
* **Gecikme** veya **Verim**
|
||||
* **Kullanılabilirlik** veya **Tutarlılık**
|
||||
|
||||
Her şeyin bir karşılığı olduğunu unutmayın. (Ek çeviri notu: Karşılaştırma sonucunda bir şeyden feragat etmek gerektiği vurgulanmaktadır.)
|
||||
|
||||
Daha sonra alan adı sistemi(DNS), içerik dağıtım ağları(CDNs) ve yük dengeleyiciler(load balancers) gibi daha spesifik konuları inceleyeceğiz.
|
||||
|
||||
## Performans veya ölçeklenebilirlik
|
||||
|
||||
Bir hizmetin **performansı** kaynaklardaki artışla orantılı olarak artıyorsa ölçeklenebilirdir. Performansı artırmak genellikle daha fazla iş birimine hizmet etmek anlamına gelir ancak diğer yandan veri seti büyüdüğünde daha büyük iş birimlerini de işleyebilir. <sup><a href="http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html">1</a></sup>
|
||||
|
||||
Performans veya ölçeklenebilirliğe başka bir bakış açısı:
|
||||
|
||||
* Sisteminizde **performans** sorunları varsa, tek bir kullanıcı için yavaş olacaktır.
|
||||
* Sisteminizde **ölçeklenebilirlik** sorunları varsa, tek kullanıcı için daha hızlı olacaktır ancak yüksek yük altında yavaşlayacaktır.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [A word on scalability](http://www.allthingsdistributed.com/2006/03/a_word_on_scalability.html)
|
||||
* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
|
||||
## Gecikme veya verim
|
||||
|
||||
**Gecikme**, bir işlemin veya bir hesaplamanın sonucunun gerçekleştirilmesi için gereken süredir.
|
||||
|
||||
**Verim**, birim zamanda gerçekleştirilen bu tür işlemlerin veya işlemlerin sayısıdır.
|
||||
|
||||
Genel olarak, kabul edilebilir gecikme süresiyle verimi en üst düzeye çıkarmayı hedeflemelisiniz.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Understanding latency vs throughput](https://community.cadence.com/cadence_blogs_8/b/fv/posts/understanding-latency-vs-throughput)
|
||||
|
||||
## Kullanılabilirlik veya tutarlılık
|
||||
|
||||
### CAP Teoremi
|
||||
|
||||
<p align="center">
|
||||
<img src="images/bgLMI2u.png">
|
||||
<br/>
|
||||
<i><a href=http://robertgreiner.com/2014/08/cap-theorem-revisited>Kaynak: CAP theorem revisited</a></i>
|
||||
</p>
|
||||
|
||||
Dağıtılmış bir bilgisayar sisteminde aynı anda yalnızca aşağıdaki iki nokta karşılanabilir:
|
||||
|
||||
* **Tutarlılık** ─ Her okuma, en güncel yazıyı veya bir hatayı alır.
|
||||
* **Ulaşılabilirlik** ─ Her istek bir yanıt alır, ancak bu yanıtın en güncel bilgiyi içerme garantisi yoktur.
|
||||
* **Bölüm Toleransı** ─ Sistem, ağ hatalarından kaynaklanan keyfi bölünmelere rağmen çalışmaya devam eder.
|
||||
|
||||
*Ağlar güvenilir değil, bu nedenle bölüm toleransını desteklemeniz gerekecektir. Tutarlılık ve erişilebilirlik arasında bir yazılım takası yapmanız gerekecektir.*
|
||||
|
||||
#### CP ─ Tutarlılık ve Bölüm Toleransı
|
||||
|
||||
Bölünmüş bir düğümden yanıt beklemek, bir zaman aşımı hatasına neden olabilir. CP, iş gereksinimleriniz atomik okuma ve yazma gerektiriyorsa iyi bir seçenektir.
|
||||
|
||||
#### AP ─ Kullanılabilirlik ve Bölüm Toleransı
|
||||
|
||||
Yanıtlar, herhangi bir düğümde bulunan en hızlı mevcut veri sürümünü döndürür, bu her zaman en güncel olmayabilir. Yazılar, bölüm çözüldüğünde yayılmak için bir süre alabilir.
|
||||
|
||||
AP, iş gereksinimlerinin [nihai tutarlılığı](#nihai-tutarlılık)na izin vermesi veya sistem dış hatalara rağmen çalışmaya devam etmesi gerekiyorsa iyi bir seçenektir.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [CAP theorem revisited](http://robertgreiner.com/2014/08/cap-theorem-revisited/)
|
||||
* [A plain english introduction to CAP theorem](http://ksat.me/a-plain-english-introduction-to-cap-theorem)
|
||||
* [CAP FAQ](https://github.com/henryr/cap-faq)
|
||||
* [The CAP theorem](https://www.youtube.com/watch?v=k-Yaq8AHlFA)
|
||||
|
||||
## Tutarlılık modelleri
|
||||
|
||||
Aynı verinin birden fazla kopyasıyla, bu verileri nasıl senkronize edeceğimize dair seçeneklerle karşılaşırız, böylece istemciler verilerin tutarlı bir görünümüne sahiptir. [CAP Teoremi](#cap-teoremi)ndeki tutarlılık tanımını hatırlayalım - Her okuma, en güncel yazıyı veya bir hatayı alır.
|
||||
|
||||
### Zayıf tutarlılık
|
||||
|
||||
Bir yazma işleminden sonra, okumalar bunu görebilir veya görmeyebilir. Burada bir çaba sarf edilir.
|
||||
|
||||
Bu yaklaşım, memcached gibi sistemlerde görülür. Zayıf tutarlılık, VoIP, video sohbet ve gerçek zamanlı çok oyunculu oyunlar gibi gerçek zamanlı kullanım durumlarında iyi çalışır. Örneğin, bir telefon görüşmesinde birkaç saniyeliğine bağlantı kaybı yaşarsanız, bağlantıyı tekrar sağladığınızda bağlantı kaybı sırasında söylenenleri duymazsınız.
|
||||
|
||||
### Nihai tutarlılık
|
||||
|
||||
Bir yazma işleminden sonra, okumalar bunu nihayetinde görecektir (genellikle milisaniyeler içinde). Veri asenkron olarak replike edilir.
|
||||
|
||||
Bu yaklaşım, DNS ve e-posta gibi sistemlerde görülür. Nihai tutarlılık, yüksek düzeyde erişilebilir sistemlerde iyi çalışır.
|
||||
|
||||
### Güçlü tutarlılık
|
||||
|
||||
Bir yazma işleminden sonra, okumalar bunu görecektir. Veri senkron olarak replike edilir.
|
||||
|
||||
Bu yaklaşım, dosya sistemleri ve RDBMS gibi sistemlerde görülür. Güçlü tutarlılık, işlemlere ihtiyaç duyan sistemlerde iyi çalışır.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Transactions across data centers](http://snarfed.org/transactions_across_datacenters_io.html)
|
||||
|
||||
## Kullanılabilirlik modları
|
||||
|
||||
Yüksek kullanılabilirliği destekleyen iki mod vardır: yük devretme(fail-over) ve çoğaltma(replication).
|
||||
|
||||
### Yük devretme
|
||||
|
||||
#### Aktif-pasif
|
||||
|
||||
Aktif-pasif yük devretme(fail-over) durumunda, aktif ve pasif durumda bekleyen sunucular arasında kalp atışları(heartbeats) gönderilir. Eğer kalp atışı kesilirse, pasif sunucu aktifin IP adresini devralır ve hizmete devam eder.
|
||||
|
||||
Downtime süresi, pasif sunucunun zaten 'sıcak' beklemede çalışıp çalışmadığına veya 'soğuk' beklemeden başlaması gerekip gerekmediğine bağlıdır. Trafik sadece aktif sunucuyu işler.
|
||||
|
||||
Aktif-pasif yük devretme(fail-over), aynı zamanda master-slave yük devretme(fail-over) olarak da adlandırılabilir.
|
||||
|
||||
#### Aktif-aktif
|
||||
|
||||
Aktif-aktif durumunda, her iki sunucu da trafik yönetir ve yükü aralarında paylaşır.
|
||||
|
||||
Eğer sunucular genel erişimliyse, DNS her iki sunucunun genel IP'lerini bilmelidir. Eğer sunucular içerideyse, uygulama mantığı her iki sunucuyu bilmelidir.
|
||||
|
||||
Aktif-aktif yük devretme(fail-over) aynı zamanda master-master yük devretme(fail-over) olarak da adlandırılabilir.
|
||||
|
||||
### Dezavantaj: Yük Devretme
|
||||
|
||||
* Fail-over, daha fazla donanım ekler ve ek karmaşıklık getirir..
|
||||
* Aktif sistem başarısız olmadan önce yeni yazılan veriler pasife replike edilemezse veri kaybı potansiyeli bulunur.
|
||||
|
||||
### Çoğaltma
|
||||
|
||||
#### Master-slave ve master-master
|
||||
|
||||
Bu konu, [veritabanı](#veritabanı) bölümünde daha ayrıntılı olarak incelenmiştir:
|
||||
|
||||
* [Master-slave çoğaltma](#master-slave-çoğaltma)
|
||||
* [Master-master çoğaltma](#master-master-çoğaltma)
|
||||
|
||||
### Sayılarla erişilebilirlik
|
||||
|
||||
Erişilebilirlik genellikle hizmetin kullanılabilir(veya kullanılamaz) olduğu sürenin bir yüzdesi olarak ölçülür. Genellikle erişilebilirlik, 9 sayısıyla ifade edilir - %99.99 erişilebilirliğe sahip bir hizmet, "4 tane 9'a sahip" olarak tanımlanabilir.
|
||||
|
||||
#### 99.9% erişilebilirlik - 3 tane 9'a sahip hizmet
|
||||
|
||||
| Süre | Kabul edilebilir kesinti süresi |
|
||||
|-------------------|---------------------------------|
|
||||
| Yıllık | 8h 45min 57s |
|
||||
| Aylık | 43m 49.7s |
|
||||
| Haftalık | 10m 4.8s |
|
||||
| Günlük | 1m 26.4s |
|
||||
|
||||
#### 99.99% erişilebilirlik - 4 tane 9'a sahip hizmet
|
||||
|
||||
| Duration | Kabul edilebilir kesinti süresi |
|
||||
|---------------|---------------------------------|
|
||||
| Yıllık | 52min 35.7s |
|
||||
| Aylık | 4m 23s |
|
||||
| Haftalık | 1m 5s |
|
||||
| Günlük | 8.6s |
|
||||
|
||||
#### Paralel ve sıralı erişilebilirlik
|
||||
|
||||
Bir hizmet, birden çok hataya duyarlı bileşenden oluşuyorsa, hizmetin genel erişilebilirliği, bileşenlerin sıralı mı yoksa paralel mi olduğuna bağlıdır.
|
||||
|
||||
###### Sıralı
|
||||
|
||||
Erişilebilirliği %100'den küçük iki bileşenin sıralı olduğu durumda toplam erişilebilirlik düşecektir:
|
||||
|
||||
```
|
||||
Erişilebilirlik (Toplam) = Erişilebilirlik (Bileşen 1) * Erişilebilirlik (Bileşen 2)
|
||||
```
|
||||
|
||||
Eğer "Bileşen 1" ve "Bileşen 2" %99.9 erişilebilirliğe sahiplerse toplam erişilebilirlik %99.8 olacaktır.
|
||||
|
||||
###### Paralel
|
||||
|
||||
Erişilebilirliği %100'den küçük iki bileşenin paralel olduğu durumda toplam erişilebilirlik artacaktır:
|
||||
|
||||
```
|
||||
Erişilebilirlik (Toplam) = 1 - (1 - Erişilebilirlik (Bileşen 1)) * (1 - Erişilebilirlik (Bileşen 2))
|
||||
```
|
||||
|
||||
Eğer "Bileşen 1" ve "Bileşen 2" %99.9 erişilebilirliğe sahiplerse toplam erişilebilirlik %99.9999 olacaktır.
|
||||
|
||||
## Alan Adı Sistemi (DNS)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/IOyLj4i.jpg">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/srikrupa5/dns-security-presentation-issa>Kaynak: DNS security presentation</a></i>
|
||||
</p>
|
||||
|
||||
Alan adı sistemi(DNS), www.example.com gibi alan adlarını IP adreslerine dönüştürür.
|
||||
|
||||
DNS hiyerarşik bir yapıya sahiptir ve en üst düzeyde birkaç yetkili sunucu bulunur. Modeminiz veya İSS'niz, bir sorgu yaparken hangi DNS sunucusuyla iletişim kurmanız gerektiği konusunda bilgi sağlar. Daha düşük seviyedeki DNS sunucuları eşlemeleri önbelleğe alır ve DNS yayılma gecikmeleri nedeniyle eski hale gelebilir. DNS sonuçları, [Time to Live TTL](https://en.wikipedia.org/wiki/Time_to_live) tarafından belirlenen belirli bir süre boyunca tarayıcınız veya işletim sisteminiz tarafından önbelleğe alınabilir.
|
||||
|
||||
* **Ad sunucuları(NS) kaydı (name server)** ─ Alanınız/alt alanınız için DNS sunucularını belirtir.
|
||||
* **MX Kaydı (mail exchange)** ─ Mesajları alacak posta sunucusunu belirtir.
|
||||
* **Kayıt (adres)** ─ Belirtilen alan adına karşılık gelen IP adresi kaydı.
|
||||
* **CNAME (kanonik)** ─ Başka bir alan adı veya "CNAME" kaydıyla (example.com, www.example.com'u işaret eder) veya bir "A" kaydıyla eşleşen bir alan adı.
|
||||
|
||||
[CloudFlare](https://www.cloudflare.com/dns/) ve [Route 53](https://aws.amazon.com/route53/) gibi servisler, yönetilen DNS hizmetleri sağlar. Bazı DNS hizmetleri, trafiği çeşitli yöntemlerle yönlendirebilir:
|
||||
|
||||
* [Ağırlıklı round robin](https://www.jscape.com/blog/load-balancing-algorithms)
|
||||
* Bakım altındaki sunuculara trafik gitmesini engelleme
|
||||
* Farklı küme boyutları arasında denge sağlama
|
||||
* A/B testi
|
||||
* [Gecikme tabanlı](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-latency)
|
||||
* [Coğrafi konum tabanlı](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-geo)
|
||||
|
||||
### Dezavantaj(lar): Alan adı sistemi(DNS)
|
||||
|
||||
* Bir DNS sunucusuna erişim, yukarıda açıklanan önbellekleme işlemlerinden dolayı hafif bir gecikmeye neden olabilir.
|
||||
* DNS sunucu yönetimi karmaşık olabilir ve genellikle [hükümetler, İSS'ler ve büyük şirketler](http://superuser.com/questions/472695/who-controls-the-dns-servers/472729) tarafından yönetilir.
|
||||
* DNS hizmetleri, [DDoS saldırısı](http://dyn.com/blog/dyn-analiz-summary-of-friday-october-21-attack/)na maruz kalabilir, bu da kullanıcıların Twitter gibi web sitelerine erişmesini Twitter'ın IP adres(ler)ini bilmeden engelleyebilir.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [DNS architecture](https://technet.microsoft.com/en-us/library/dd197427(v=ws.10).aspx)
|
||||
* [Wikipedia](https://en.wikipedia.org/wiki/Domain_Name_System)
|
||||
* [DNS articles](https://support.dnsimple.com/categories/dns/)
|
||||
|
||||
## İçerik Dağıtım Ağı (CDN)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/h9TAuGI.jpg">
|
||||
<br/>
|
||||
<i><a href=https://www.creative-artworks.eu/why-use-a-content-delivery-network-cdn/>Kaynak: Why use a CDN</a></i>
|
||||
</p>
|
||||
|
||||
İçerik Dağıtım Ağı(CDN), kullanıcılara yakın konumlardan içerik sunan, küresel olarak dağıtılmış bir proxy sunucu ağıdır. Tipik olarak HTML/CSS/JS gibi statik içerikler, resimler ve videolar bir CDN tarafından sunulur, ancak bazı CDNler(örneğin Amazon'un CloudFront dağıtım ağı) dinamik içerik destekler. Sitenin DNS çözümlemesi, istemcilerin hangi sunucuyla iletişim kurması gerektiğini belirtir.
|
||||
|
||||
CDN'den içerik sunmak, performansı önemli ölçüde arttırır:
|
||||
|
||||
* Kullanıcılar içeriği kendilerine yakın veri merkezlerinden alır.
|
||||
* Sunucularınız, CDN'nin karşıladığı istekleri karşılamak zorunda kalmaz.
|
||||
|
||||
### Push CDN
|
||||
|
||||
Push CDN'leri, sunucunuzda değişiklikler olduğunda yeni içerik alır. İçeriği sağlama, doğrudan CDN'ye yükleme ve URL'leri CDN'ye işaret etmek için yeniden yazma konusunda tam sorumluluk alırsınız. İçeriğin ne zaman süresinin dolduğunu ve ne zaman güncellendiğini yapılandırabilirsiniz. İçerik, yeni veya değiştiğinde yalnızca yüklenir, bu da trafiği en aza indirir, ancak depolamayı maksimize eder.
|
||||
|
||||
Düşük trafiğe sahip siteler veya içeriği sık güncellenmeyen siteler, push CDN'lerle iyi çalışır. İçerik, düzenli aralıklarla tekrar çekilmek yerine bir kez CDN'lere yerleştirilir.
|
||||
|
||||
### Pull CDN
|
||||
|
||||
Pull CDN'leri, ilk kullanıcı içeriği istediğinde yeni içeriği sunucunuzdan alır. İçeriği sunucunuzda bırakır ve URL'leri CDN'ye işaret etmek için yeniden yazarsınız. Bu, içerik CDN üzerinde önbelleğe alındığında daha yavaş bir isteğe neden olur.
|
||||
|
||||
[Yaşam süresi (TTL)](https://en.wikipedia.org/wiki/Time_to_live), içeriğin ne kadar süreyle önbelleğe alınacağını belirler. Pull CDN'leri, CDN üzerinde depolama alanını en aza indirir, ancak dosyaların süresi dolarsa ve gerçekte değiştirilmeden çekilirse gereksiz trafiğe neden olabilir.
|
||||
|
||||
Yüksek trafikli siteler, trafiği daha düzenli bir şekilde dağıttığı için pull CDN'lerle iyi çalışır. CDN'de yalnızca son zamanlarda istenen içerik kalır.
|
||||
|
||||
### Dezavantaj(lar): CDN
|
||||
|
||||
* CDN maliyetleri, trafiğe bağlı olarak önemli olabilir, ancak bu, CDN kullanmamanız durumunda karşılaşacağınız ek maliyetlerle karşılaştırılmalıdır.
|
||||
* İçerik, TTL süresi dolmadan önce güncellenirse eski kalabilir.
|
||||
* CDN'ler, statik içeriğin URL'lerini CDN'ye işaret etmek için değiştirmeyi gerektirir.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Globally distributed content delivery](https://figshare.com/articles/Globally_distributed_content_delivery/6605972)
|
||||
* [The differences between push and pull CDNs](http://www.travelblogadvice.com/technical/the-differences-between-push-and-pull-cdns/)
|
||||
* [Wikipedia](https://en.wikipedia.org/wiki/Content_delivery_network)
|
||||
|
||||
## Yük dengeleyici (Load balancer)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/h81n9iK.png">
|
||||
<br/>
|
||||
<i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Kaynak: Scalable system design patterns</a></i>
|
||||
</p>
|
||||
|
||||
Yük dengeleyicileri, gelen istemci isteklerini uygulama sunucuları ve veritabanları gibi bilgi işlem kaynaklarına dağıtır. Her durumda, yük dengeleyici, bilgi işlem kaynağından gelen yanıtı uygun istemciye döndürür. Yük dengeleyicileri şu konularda etkilidir:
|
||||
|
||||
* İsteklerin hatalı sunuculara girmesini önlemek
|
||||
* Kaynak aşırı yüklenmesini önlemek
|
||||
* Tek hata noktalarını ortadan kaldırmaya yardımcı olmak
|
||||
|
||||
Yük dengeleyicileri, donanım (pahalı) veya HAProxy gibi yazılım ile uygulanabilir.
|
||||
|
||||
Ek avantajlar şunları içerir:
|
||||
|
||||
* **SSL Sonlandırma** ─ Gelen isteklerin şifresini çözer ve sunucu yanıtlarını şifreler, böylece arka uç sunucusunun(back-end) artık bu potansiyel olarak pahalı işlemleri gerçekleştirmesi gerekmez.
|
||||
* Her sunucuya [X.509 sertifikasını](https://en.wikipedia.org/wiki/X.509) yüklemek gerekmez.
|
||||
* **Oturum Tutma** ─ Web uygulaması oturumları izlemiyorsa, bir çerez yayınlar ve belirli istemci isteklerini aynı örneğe yönlendirir.
|
||||
|
||||
Hataları önlemek için [aktif-pasif](#aktif-pasif) veya [aktif-aktif](#aktif-aktif) modunda birden fazla yük dengeleyicinin kurulması yaygındır.
|
||||
|
||||
Yük dengeleyiciler trafiği çeşitli şekillerde yönlendirebilir:
|
||||
|
||||
* Rastgele (Random)
|
||||
* En düşük yüklü (Least loaded)
|
||||
* Oturum/çerez (Session/cookies)
|
||||
* [Round robin or ağırlıklı round robin](https://www.g33kinfo.com/info/round-robin-vs-weighted-round-robin-lb)
|
||||
* [Katman 4](#katman-4-yük-dengeleyicisi)
|
||||
* [Katman 7](#katman-7-yük-dengeleyicisi)
|
||||
|
||||
### Katman 4 yük dengeleyicisi
|
||||
|
||||
Katman 4 yük dengeliyicileri, istekleri nasıl dağıtacaklarına karar vermek için [iletişim katmanındaki](#iletişim) bilgilere bakarlar. Genellikle, bu başlıkta bulunan kaynak, hedef IP adresleri ve portları içerir, ancak paketin içeriğini içermez. 4. Katman yük dengeleyicileri, ağ paketlerini yukarı akış sunucuya ve ondan yönlendirirken [Ağ Adresi Çevirisi (NAT)](https://www.nginx.com/resources/glossary/layer-4-load-balancing/) işlemini gerçekleştirirler.
|
||||
|
||||
### Katman 7 yük dengeleyicisi
|
||||
|
||||
Katman 7 yük dengeleyicileri, [uygulama katmanına](#iletişim) bakarak istekleri nasıl dağıtacaklarına karar verirler. Bu, başlık, mesaj ve çerez içeriğini içerebilir. Katman 7 yük dengeleyicileri, ağ trafiğini sonlandırır, mesajı okur, bir yük dengeleme kararı alır ve ardından seçilen sunucuya bir bağlantı açar. Örneğin, Katman 7 yük dengeleyici, video trafiğini videoları barındıran sunuculara yönlendirirken, daha hassas kullanıcı fatura trafiğini güvenlik açısından güçlendirilmiş sunuculara yönlendirebilir.
|
||||
|
||||
Esneklik maliyetine karşılık olarak, Katman 4 yük dengeleme, 7. Katmana göre daha az zaman ve hesaplama kaynağı gerektirir, ancak performans etkisi modern ticari donanımlarda minimal olabilir.
|
||||
|
||||
### Yatay ölçekleme
|
||||
|
||||
Yük dengeleyicileri, yatay ölçeklendirmeye de yardımcı olabilir, performansı ve erişilebilirliği artırabilir. Ticari makineler kullanarak ölçeklendirmek, daha pahalı donanımda tek bir sunucuyu ölçeklendirmekten daha uygun maliyet ve daha yüksek erişilebilirlik sağlar; bu duruma **dikey olarak ölçeklendirme** denir. Ayrıca, ticari donanımda çalışan yetenekleri bulmak, özel kurumsal sistemlerde çalışan yetenekleri bulmaktan daha kolaydır.
|
||||
|
||||
#### Dezavantaj(lar): yatay ölçekleme
|
||||
|
||||
* Yatay ölçeklendirme karmaşıklığa neden olur ve sunucunun çoğaltılmasını gerektirir.
|
||||
* Sunucular durum bilgisiz olmalıdır: Ayrıca oturum veya profil resimleri gibi kullanıcıyla ilgili veriler içermemelidir.
|
||||
* Oturumlar merkezi olarak veritabanında veya kalıcı [önbellek](#önbellek) (Redis, Memcached) veri depolama alanında saklanabilir.
|
||||
* Önbellekler ve veritabanları gibi aşağı akış(downstream) sunucularının, daha fazla eş zamanlı bağlantıyı yönetebilmek için yukarı akış(upstream) sunucularıyla ölçeklendirilmesi gerekir.
|
||||
|
||||
### Dezavantaj(lar): Yük Dengeleyici
|
||||
|
||||
* Yeterli kaynak yapılandırılmazsa veya yanlış yapılandırılırsa yük dengeleyici performans darboğazı haline gelebilir.
|
||||
* Tek hata noktalarını ortadan kaldırmaya yardımcı olmak için yük dengeleyiciler tanıtıldı ancak ek karmaşıklığa yol açtı.
|
||||
* Tek bir yük dengeleyici tek bir hata noktası oluşturur ancak birden fazla yük dengeleyiciyi yapılandırmak daha fazla karmaşıklık katar.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [NGINX architecture](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
|
||||
* [HAProxy architecture guide](http://www.haproxy.org/download/1.2/doc/architecture.txt)
|
||||
* [Scalability](http://www.lecloud.net/post/7295452622/scalability-for-dummies-part-1-clones)
|
||||
* [Wikipedia](https://en.wikipedia.org/wiki/Load_balancing_(computing))
|
||||
* [Layer 4 load balancing](https://www.nginx.com/resources/glossary/layer-4-load-balancing/)
|
||||
* [Layer 7 load balancing](https://www.nginx.com/resources/glossary/layer-7-load-balancing/)
|
||||
* [ELB listener config](http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html)
|
||||
|
||||
## Ters proxy (web sunucusu)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/n41Azff.png">
|
||||
<br/>
|
||||
<i><a href=https://upload.wikimedia.org/wikipedia/commons/6/67/Reverse_proxy_h2g2bob.svg>Kaynak: Wikipedia</a></i>
|
||||
<br/>
|
||||
</p>
|
||||
|
||||
Ters proxy, dahili hizmetleri merkezi olarak arayabilen ve genel istemcilere birleşik bir arayüz sağlayabilen bir web sunucusudur. İstemciden gelen istek, önce ters proxy sunucusu tarafından isteğe yanıt verebilecek sunucuya iletilir ve ardından proxy, sunucunun yanıt sonucunu istemciye döndürür.
|
||||
|
||||
Faydaları şunları içerir:
|
||||
|
||||
* **Artırılmış güvenlik** - Arka uç(backend) sunucu bilgilerini gizler, kara listedeki IP'leri engeller ve istemci başına bağlantı sayısını sınırlar.
|
||||
* **Geliştirilmiş ölçeklenebilirlik ve esneklik** - İstemciler yalnızca ters proxy sunucusunun IP'sini görebilir, bu da sunucuları eklemenize veya kaldırmanıza veya yapılandırmalarını değiştirmenize olanak tanır.
|
||||
* **SSL Oturumlarının Yerel Sonlandırılması** - Gelen isteklerin şifresini çözer ve sunucu yanıtlarını şifreler, böylece arka uç(backend) sunucusunun maliyetli olabilecek işlemleri tamamlamasına gerek kalmaz.
|
||||
- Her sunucuya bir [X.509](https://en.wikipedia.org/wiki/X.509) sertifikası yükleme ihtiyacını ortadan kaldırır.
|
||||
* **SIKIŞTIRMA** - Sunucu yanıtını sıkıştır.
|
||||
* **Önbellek** - Doğrudan isabet önbellek sonucunu döndürür.
|
||||
* **Statik İçerik** - Statik içeriği doğrudan yayınlar.
|
||||
* HTML/CSS/JS
|
||||
* Resimler
|
||||
* Videolar
|
||||
* vs
|
||||
|
||||
### Yük dengeleyici ve ters proxy
|
||||
|
||||
* Birden fazla sunucunuz olduğunda yük dengeleyici dağıtmak kullanışlıdır. Tipik olarak bir yük dengeleyici, trafiği aynı işlevselliğe sahip bir dizi sunucuya yönlendirir.
|
||||
* Yalnızca bir web sunucusu veya uygulama sunucusu olduğunda bile ters proxy faydalıdır.Bir önceki bölümde tanıtılan avantajlara bakabilirsiniz.
|
||||
* NGINX ve HAProxy gibi çözümler hem Katman 7 ters proxy'yi hem de yük dengelemeyi destekleyebilir.
|
||||
|
||||
### Dezavantaj(lar): Ters proxy
|
||||
|
||||
* Ters proxy'nin eklenmesi sistemin karmaşıklığını artıracaktır.
|
||||
* Tek bir ters proxy sunucusu yine de tek bir hata noktası olabilir ve birden fazla ters proxy sunucusunun ([yük devretme(failover)](https://en.wikipedia.org/wiki/Failover) gibi) yapılandırılması karmaşıklığı daha da artıracaktır.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Reverse proxy vs load balancer](https://www.nginx.com/resources/glossary/reverse-proxy-vs-load-balancer/)
|
||||
* [NGINX architecture](https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/)
|
||||
* [HAProxy architecture guide](http://www.haproxy.org/download/1.2/doc/architecture.txt)
|
||||
* [Wikipedia](https://en.wikipedia.org/wiki/Reverse_proxy)
|
||||
|
||||
## Uygulama katmanı
|
||||
|
||||
<p align="center">
|
||||
<img src="images/yB5SYwm.png">
|
||||
<br/>
|
||||
<i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Kaynak: Intro to architecting systems for scale</a></i>
|
||||
</p>
|
||||
|
||||
Web hizmetleri katmanının uygulama katmanından (platform katmanı olarak da bilinir) ayırmak, her iki katmanı bağımsız olarak ölçeklendirmenize ve yapılandırmanıza olanak tanır. Yeni bir API eklemek, genellikle ek web sunucuları eklemeye gerek olmadan uygulama sunucularını eklemek anlamına gelir.
|
||||
|
||||
**Tek Sorumluluk İlkesi**, birbirleriyle birlikte çalışan küçük ve otonom hizmetleri savunur. Küçük ekipler, küçük hizmetlerle hızlı büyüme için daha agresif planlama yapabilirler.
|
||||
|
||||
Uygulama katmanındaki iş süreçleri aynı zamanda [asenkronizm](#asenkronizm)i mümkün kılar.
|
||||
|
||||
### Mikroservisler
|
||||
|
||||
Bu tartışma ile ilgili olan [mikroservisler](https://en.wikipedia.org/wiki/Microservices), bağımsız bir şekilde dağıtılabilen, küçük, modüler hizmetlerin bir paketidir. Her servis, bir iş hedefini karşılamak için iyi tanımlanmış, hafif bir mekanizma aracılığıyla iletişim kuran benzersiz bir süreç çalıştırır. <sup><a href=https://smartbear.com/learn/api-design/what-are-microservices>1</a></sup>
|
||||
|
||||
Örneğin, Pinterest aşağıdaki mikroservislere sahip olabilir: kullanıcı profili, takipçi, haber akışı, arama, fotoğraf yükleme, vb.
|
||||
|
||||
### Servis keşfi
|
||||
|
||||
[Consul](https://www.consul.io/docs/index.html), [Etcd](https://coreos.com/etcd/docs/latest) ve [Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) gibi sistemler, hizmetlerin kayıtlı isimlerini, adreslerini ve bağlantı noktalarını takip ederek birbirlerini bulmalarına yardımcı olabilir. [Sağlık kontrolü](https://www.consul.io/intro/getting-started/checks.html), hizmet bütünlüğünü doğrulamaya yardımcı olur ve genellikle bir [HTTP](#köprü-metni-aktarım-protokolü-http) uç noktası kullanılarak gerçekleştirilir. Hem Consul hem de Etcd, konfigürasyon değerleri ve diğer paylaşılan verileri depolamak için kullanışlı olabilen bir [anahtar-değer deposu](#anahtar-değer-deposu)na sahiptir.
|
||||
|
||||
### Dezavantaj(lar): Uygulama katmanı
|
||||
|
||||
* Gevşek bağlı hizmetlerle bir uygulama katmanı eklemek, mimari, işletme ve süreç açısından (monolitik bir sistemle karşılaştırıldığında) farklı bir yaklaşım gerektirir.
|
||||
* Mikroservisler, dağıtımlar ve operasyonlar açısından karmaşıklığı arttırabilir.
|
||||
|
||||
### Kaynaklar ve ek okuma
|
||||
|
||||
* [Intro to architecting systems for scale](http://lethain.com/introduction-to-architecting-systems-for-scale)
|
||||
* [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
|
||||
* [Service oriented architecture](https://en.wikipedia.org/wiki/Service-oriented_architecture)
|
||||
* [Introduction to Zookeeper](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper)
|
||||
* [Here's what you need to know about building microservices](https://cloudncode.wordpress.com/2016/07/22/msa-getting-started/)
|
||||
|
||||
## Veritabanı
|
||||
|
||||
<p align="center">
|
||||
<img src="images/Xkm5CXz.png">
|
||||
<br/>
|
||||
<i><a href=https://www.youtube.com/watch?v=kKjm4ehYiMs>Kaynak: Scaling up to your first 10 million users</a></i>
|
||||
</p>
|
||||
|
||||
### İlişkisel veritabanı yönetim sistemi (RDBMS)
|
||||
|
||||
SQL gibi ilişkisel bir veritabanı, tablolar halinde düzenlenmiş veri öğelerinin bir koleksiyonudur.
|
||||
|
||||
**ACID**, ilişkisel veritabanı [işlemlerinin](https://en.wikipedia.org/wiki/Database_transaction) özelliklerini bir kümeyi ifade eder.
|
||||
|
||||
* **Atomluk (Atomicity)** - Her işlem tamamen gerçekleşir veya hiçbiri gerçekleşmez.
|
||||
* **Tutarlılık (Consistency)** - Herhangi bir işlem, veritabanını bir geçerli durumdan başka bir geçerli duruma getirir.
|
||||
* **İzolasyon (Isolation)** - İşlemlerin eşzamanlı yürütülmesinin sonuçları, işlemlerin sıralı yürütülmesinin sonuçlarıyla aynıdır.
|
||||
* **Dayanıklılık (Durability)** - Bir işlem gerçekleştirildikten sonra sistem üzerindeki etkisi kalıcı olur.
|
||||
|
||||
İlişkisel bir veritabanını ölçeklendirmek için birçok teknik vardır: **master-slave çoğaltma**, **master-master çoğaltma**, **federasyon**, **parçalama**, **denormalizasyon** ve **SQL Tuning**.
|
||||
|
||||
#### Master-slave çoğaltma
|
||||
|
||||
Master sunucu, okuma ve yazma hizmeti sunar, yazma işlemlerini bir veya daha fazla slave sunucalara replike eder ve slave sunucular yalnızca okuma işlemleri sunar. Slave sunucular aynı zamanda daha fazla slave sunucuya ağaç benzeri bir şekilde replike edebilir. Master sunucu çevrimdışıysa; bir slave sunucu, ana bilgisayar olarak atanana veya yeni bir master sunucu tahsis edilene kadar; sistem okuma modunda çalışmaya devam edebilir.
|
||||
|
||||
<p align="center">
|
||||
<img src="images/C9ioGtn.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Kaynak: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
##### Dezavantaj(lar): master-slave çoğaltma
|
||||
|
||||
* Bir slave sunucuyu, master sunucuya yükseltmek ek bir iş gerektirir.
|
||||
* Master-slave çoğaltma ve master-master çoğaltma ile ilgili bilgiler için [Dezavantaj(lar): çoğaltma] (#dezavantajlar-çoğaltma) bölümüne bakınız.
|
||||
|
||||
#### Master-master çoğaltma
|
||||
|
||||
Her iki ana sunucu da okuma ve yazma işlemlerinden sorumludur ve yazma işlemleri sırasında birbirleriyle koordineli çalışırlar. Ana sunuculardan biri kapanırsa sistem okumaya ve yazmaya devam edebilir.
|
||||
|
||||
<p align="center">
|
||||
<img src="images/krAHLGg.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Kaynak: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
##### Dezavantaj(lar): master-master
|
||||
|
||||
* Hangi veritabanına yazacağınızı belirlemek için yük dengeleyiciye(load balancer) veya uygulama mantığınızda değişiklik yapmanız gerekecektir.
|
||||
* Çoğu master-master sistem ya tutarlılığı garanti edemez (ACID'i ihlal eder) veya senkronizasyon nedeniyle artan yazma gecikmesine sahiptir.
|
||||
* Yazma düğümleri(write nodes) ekledikçe ve gecikme arttıkça çatışma çözümü daha fazla devreye girer.
|
||||
* Master-slave çoğaltma ve master-master çoğaltma ile ilgili bilgiler için [Dezavantaj(lar): çoğaltma] (#dezavantajlar-çoğaltma) bölümüne bakınız.
|
||||
|
||||
##### Dezavantaj(lar): çoğaltma
|
||||
|
||||
* Yeni yazılan verileri diğer düğümlere kopyalanamadan önce master sunucu kapanırsa veri kaybı olasılığı vardır.
|
||||
* Yazma işlemleri, okuma işleminden sorumlu kopyaya yeniden dağıtılır. Aşırı yazma işlemleri nedeniyle slave sunucular etkilenebilir ve bu da okuma işlemlerine engel olabilir.
|
||||
* Ne kadar çok slave sunucu var ise o kadar çoğaltma işlemi yapılması gerekir, bu da ciddi gecikme sorunlarına sebep verecektir.
|
||||
* Bazı veritabanı sistemlerinde master sunucuya yazma işlemi birden fazla iş parçacığı kullanılarak paralel olarak yazılabilir ancak slave sunucu yalnızca tek iş parçacıklı sıralı yazmayı destekler.
|
||||
* Çoğaltma, daha fazla donanım ve ek karmaşıklık anlamına gelir.
|
||||
|
||||
##### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
* [Multi-master replication](https://en.wikipedia.org/wiki/Multi-master_replication)
|
||||
|
||||
#### Federasyon
|
||||
|
||||
<p align="center">
|
||||
<img src="images/U3qV33e.png">
|
||||
<br/>
|
||||
<strong><a href="https://www.youtube.com/watch?v=w95murBkYmU">Kaynak: Kullanıcılarınızı İlk On Milyona Kadar Ölçeklendirme</a></strong>
|
||||
</p>
|
||||
|
||||
Federasyon (veya fonksiyonel bölümleme), veritabanını ilgili işlevlere göre böler. Örneğin, tek bir veritabanı yerine üç veritabanınız olabilir: **forumlar**, **kullanıcılar** ve **ürünler**; böylece veritabanı başına okuma ve yazma trafiğini ve çoğaltma gecikmesini azaltırsınız. Daha küçük bir veritabanı, belleğe sığan daha fazla veri anlamına gelir; bu da daha yüksek önbellek isabeti şansı anlamına gelir. Sadece seri olarak yazabilen merkezi bir master sunucu yoktur, yük kapasitesini arttırmak için paralel olarak yazabilirsiniz.
|
||||
|
||||
##### Dezavantaj(lar): federasyon
|
||||
|
||||
* Veritabanı şemanız çok sayıda işlev ve veri tablosu gerektiriyorsa, federasyon iyi değildir.
|
||||
* Hangi veritabanından okunacağını ve hangi veritabanına yazılacağını belirlemek için uygulamanızın mantığını güncellemeniz gerekir.
|
||||
* İki veritabanından gelen veri güncellemelerini birleştirmek [sunucu bağlantısı](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers) ile daha karmaşıktır.
|
||||
* Federasyon daha fazla donanım ve ek karmaşıklık gerektirir.
|
||||
|
||||
##### Kaynak(lar) ve ek okuma: federasyon
|
||||
|
||||
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs)
|
||||
|
||||
#### Parçalama
|
||||
|
||||
<p align="center">
|
||||
<img src="images/wU8x5Id.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Kaynak: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
Parçalama, veriyi farklı veritabanları arasında dağıtan bir yöntemdir, böylece her bir veritabanı yalnızca verinin bir alt kümesini yönetebilir. Kullanıcı veritabanını örnek olarak alalım, kullanıcı sayısı arttıkça kümelere daha fazla parça(shard) eklenir.
|
||||
|
||||
[Federasyon](#federasyon)un avantajlarına benzer şekilde, parçalama daha az okuma ve yazma trafiği, daha az çoğaltma ve daha fazla önbellek isabeti sağlar. Ayrıca, genellikle sorguları hızlandırarak performansı artırır. Bir parça(shard) devre dışı kalırsa, diğer parçalar(shard) hala işlevseldir, ancak veri kaybını önlemek için bir tür çoğaltma eklemek isteyebilirsiniz. Federasyon gibi, yazıları seri hale getiren tek bir merkezi ana yoktur, bu da artan bir işlem hızıyla paralel olarak yazma imkanı sağlar.
|
||||
|
||||
Kullanıcı tablosunu parçalamak için yaygın yöntemler, kullanıcının soyadının baş harfi veya kullanıcının coğrafi konumu gibi faktörlere dayanmaktadır.
|
||||
|
||||
##### Dezavantaj(lar): parçalama
|
||||
|
||||
* Parçalamayı uygulamak için uygulama mantığını değiştirmeniz gerekebilir, bu da karmaşık SQL sorgularına yol açabilir.
|
||||
* Makul olmayan parçalama, dengesiz veri yüküne yol açabilir. Örneğin sık erişilen kullanıcı verileri, kendi parçasının yükünün diğer parçalara göre daha fazla olmasına neden olacaktır.
|
||||
* Yeniden dengeleme, ek karmaşıklık getirir. [Tutarlı hashing(Consistent hashing)](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html)'e dayalı parçalama işlemleri, transfer edilen veri miktarını azaltabilir.
|
||||
* Birden fazla parçadan veri birleştirmek daha karmaşıktır.
|
||||
* Parçalama daha fazla donanım ve ek karmaşıklık gerektirir.
|
||||
|
||||
#### Kaynak(lar) ve ek okuma: parçalama
|
||||
|
||||
* [The coming of the shard](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html)
|
||||
* [Shard database architecture](https://en.wikipedia.org/wiki/Shard_(database_architecture))
|
||||
* [Consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html)
|
||||
|
||||
#### Denormalizasyon
|
||||
|
||||
Denormalizasyon, bazı yazma performansı kaybı karşılığında okuma performansını artırmaya çalışır. Pahalı birleştirme işlemlerini önlemek için; veriler, birden fazla tabloya yazılır. [PostgreSQL](https://en.wikipedia.org/wiki/PostgreSQL) ve Oracle gibi bazı ilişkisel veritabanları, gereksiz bilgileri depolamanın ve gereksiz kopyaları tutmanın işini yapan [materyalleştirilmiş görünümleri](https://en.wikipedia.org/wiki/Materialized_view) destekler.
|
||||
|
||||
Veriler, [federasyon](#federasyon) ve [parçalama](#parçalama) gibi teknikler kullanılarak dağıtıldığında, veri merkezleri arasında birleştirmeleri yönetmek karmaşıklığı daha da artırır. Denormalizasyon, bu tür karmaşık birleştirmeler için ihtiyacı ortadan kaldırabilir.
|
||||
|
||||
Çoğu sistemde, okuma işlemlerinin sıklığı, 100:1 ve hatta 1000:1 oranında, yazma işlemlerinden çok daha yüksektir. Karmaşık veritabanı birleştirmeleri gerektiren okuma işlemleri çok maliyetlidir ve disk işlemlerinde çok fazla zaman harcar.
|
||||
|
||||
##### Dezavantaj(lar): Denormalizasyon
|
||||
|
||||
* Tekrar eden(yinelenen) veri.
|
||||
* Kısıtlamalar, bilgilerin gereksiz kopyalarının senkronize olmasına yardımcı olabilir, bu da veritabanı tasarımının karmaşıklığını artırır.
|
||||
* Yoğun yazma yükü altındaki bir denormalize veritabanı, normalleştirilmiş karşıtına göre daha kötü performans gösterebilir.
|
||||
|
||||
##### Kaynak(lar) ve ek okuma: Denormalizasyon
|
||||
|
||||
* [Denormalization](https://en.wikipedia.org/wiki/Denormalization)
|
||||
|
||||
#### SQL ayarlama (SQL tuning)
|
||||
|
||||
SQL ayarlama geniş kapsamlı bir konudur ve bu konuyla ilgili pek çok [kitap](https://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=sql+tuning) yazılmıştır.
|
||||
|
||||
Sistem darboğazlarını(bottleneck) simüle etmek ve ortaya çıkarmak için **benchmark** ve **profile**'dan yararlanmak önemlidir.
|
||||
|
||||
* **Benchmark** - [ab](http://httpd.apache.org/docs/2.2/programs/ab.html) gibi araçları kullanarak yüksek yük durumlarını simüle eder.
|
||||
* **Profile** - [Yavaş sorgu log(Slow query log)](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html) gibi araçları etkinleştirerek performans sorunlarının izlenmesine yardımcı olur.
|
||||
|
||||
Performans analizi(benchmarking) ve profilleme(profiling), aşağıdaki optimizasyonlara yönlendirebilir.
|
||||
|
||||
##### Şemayı sınırlandırın
|
||||
|
||||
* Hızlı erişim için MySQL, verileri diskteki bitişik bloklarda saklar.
|
||||
* Sabit uzunluklu alanlar için `VARCHAR` yerine `CHAR` türünü kullanın.
|
||||
* 'CHAR' hızlı, rastgele erişim için etkilidir. Eğer `VARCHAR` kullanıyorsanız, bir sonraki stringi okumak istiyorsanız öncelikle mevcut stringin sonuna kadar okumanız gerekir.
|
||||
* Blog metni gibi büyük metin bloklarını depolamak için `TEXT` kullanın. `TEXT` ayrıca boolean aramalarına da izin verir. `TEXT` alanının kullanılması, diskte metin bloğunun yerini belirleyen bir işaretçinin saklanmasını gerektirir.
|
||||
* 2^32 veya 4 milyara kadar daha büyük sayıları depolamak için `INT` kullanın.
|
||||
* Para birimlerini saklamak için `DECIMAL` tipini kullanmak, kayan nokta gösterim hatalarını önler.
|
||||
* Büyük `BLOBS`'leri depolamaktan kaçının, bunun yerine nesnenin alınabileceği konumu depolayın.
|
||||
* `VARCHAR(255)`, bazı RDBMS'lerde bir baytın kullanımını maksimuma çıkaran bir 8 bit sayısında sayılabilecek en büyük karakter sayısıdır.
|
||||
* [Arama performansını iyileştirmek](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performans-in-a-database-search) için geçerli senaryolarda `NOT NULL` kısıtlamalarını ayarlayın.
|
||||
|
||||
##### Doğru dizini kullanın
|
||||
|
||||
* Sorgulanan sütunlar ("SELECT", "GROUP BY", "ORDER BY", "JOIN") bir indekleme kullanıyorsa daha hızlı olacaktır.
|
||||
* İndeksler genellikle veriyi sıralı tutan ve logaritmik zamanda aramalara, ardışık erişime, ekleme ve silmeye olanak tanıyan öz-dengeli [B-ağacı](https://en.wikipedia.org/wiki/B-tree) olarak temsil edilir.
|
||||
* Bir indeks yerleştirmek, veriyi bellekte tutabilir ve daha fazla alan gerektirebilir.
|
||||
* İndekslerin güncellenmesi gerektiğinden yazma işlemleri daha yavaş olabilir.
|
||||
* Büyük miktarda veri yüklenirken indeksleri devre dışı bırakmak, verileri yüklemek ve ardından indeksleri yeniden oluşturmak daha hızlı olabilir.
|
||||
|
||||
##### Pahalı birleştirme işlemlerinden kaçının
|
||||
|
||||
* Performans gerekiyorsa [denormalizasyon](#denormalizasyon) yapılabilir.
|
||||
|
||||
##### Veri tablosunu bölün
|
||||
|
||||
* Tabloyu parçalayarak sıcak noktaları ayrı bir tabloya yerleştirmek, veriyi bellekte tutmaya yardımcı olabilir.
|
||||
|
||||
##### Sorgu önbelleğini ayarlayın
|
||||
|
||||
* Bazı durumlarda; [sorgu önbelleği](http://dev.mysql.com/doc/refman/5.7/en/query-cache), [performans sorunlarına](https://www.percona.com/blog/2016/10/12/mysql-5-7-performance-tuning-immediately-after-installation/) neden olabilir.
|
||||
|
||||
##### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Tips for optimizing MySQL queries](http://aiddroid.com/10-tips-optimizing-mysql-queries-dont-suck/)
|
||||
* [Is there a good reason i see VARCHAR(255) used so often?](http://stackoverflow.com/questions/1217466/is-there-a-good-reason-i-see-varchar255-used-so-often-as-opposed-to-another-l)
|
||||
* [How do null values affect performance?](http://stackoverflow.com/questions/1017239/how-do-null-values-affect-performance-in-a-database-search)
|
||||
* [Slow query log](http://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html)
|
||||
|
||||
### NoSQL
|
||||
|
||||
NoSQL, **anahtar-değer deposu**, **belge deposu**, **geniş sütun deposu** veya **grafik veritabanı** içinde temsil edilen veri öğelerinin bir koleksiyonudur. Veri denormalize edilmiş ve genellikle birleştirmeler uygulama kodu içinde yapılır. Çoğu NoSQL deposu gerçek ACID işlemlerine sahip değildir ve sonunda [nihai tutarlılık](#nihai-tutarlılık) lehine olur.
|
||||
|
||||
**BASE**, genellikle NoSQL veritabanlarının özelliklerini tanımlamak için kullanılır. [CAP teoremi](#cap-teoremi) ile karşılaştırıldığında BASE, tutarlılıktan ziyade kullanılabilirliği vurgular.
|
||||
|
||||
* **Temel Olarak Kullanılabilir** - sistem, kullanılabilirliği garanti eder.
|
||||
* **Yumuşak durum** - sistem durumu, giriş yapılmasa bile zaman içinde değişebilir.
|
||||
* **Nihai tutarlılık** - sistem, belirli bir süre içinde giriş almadığı takdirde zamanla tutarlı hale gelir.
|
||||
|
||||
[SQL veya NoSQL](#sql-veya-nosql) arasında seçim yapmanın yanı sıra, NoSQL veritabanı türlerinden hangisinin kullanım durumlarınıza en iyi uyduğunu anlamak da faydalıdır. Sonraki bölümde **anahtar-değer depoları**, **belge depoları**, **geniş sütun depoları** ve **grafik veritabanları**nı gözden geçireceğiz.
|
||||
|
||||
#### Anahtar-değer deposu
|
||||
|
||||
> Soyutlama: Hash tablosu
|
||||
|
||||
Anahtar/değer deposu, genellikle O(1) okuma ve yazma işlemlerine izin verir ve genellikle bellek veya SSD tarafından desteklenir. Veri deposu, anahtarları [sözlük sırasına göre](https://en.wikipedia.org/wiki/Lexicographical_order) tutabilir ve bu da anahtar aralıklarının verimli bir şekilde alınmasına olanak tanır. Anahtar-değer depoları, bir değerle ilişkilendirilmiş meta verilerin depolanmasına izin verebilir.
|
||||
|
||||
Anahtar-değer depoları yüksek performans sağlar ve genellikle basit veri modelleri veya hızla değişen veriler için kullanılır, örneğin bellekte tutulan önbellek katmanı. Yalnızca sınırlı bir işlem kümesi sundukları için, ek işlemler gerekiyorsa karmaşıklık uygulama katmanına kaydırılır.
|
||||
|
||||
Anahtar-değer deposu, belge deposu gibi daha karmaşık sistemlerin temelini oluşturur ve bazı durumlarda grafik veritabanı olarak da kullanılabilir.
|
||||
|
||||
#### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Key-value database](https://en.wikipedia.org/wiki/Key-value_database)
|
||||
* [Disadvantages of key-value stores](http://stackoverflow.com/questions/4056093/what-are-the-disadvantages-of-using-a-key-value-table-over-nullable-columns-or)
|
||||
* [Redis architecture](http://qnimate.com/overview-of-redis-architecture/)
|
||||
* [Memcached architecture](https://adayinthelifeof.nl/2011/02/06/memcache-internals/)
|
||||
|
||||
#### Belge deposu
|
||||
|
||||
> Soyutlama: değerler olarak depolanan belgelerle anahtar-değer deposu
|
||||
|
||||
Bir belge deposu, belgeler (XML, JSON, ikili, vb.) etrafında odaklanmıştır, bir belge bir nesne için tüm bilgileri depolar. Belge depolar, belgenin kendi iç yapısına dayalı sorgular yapmak için API'lar veya bir sorgu dilini sağlar. *Not, birçok anahtar-değer deposu, bir değerin meta verileriyle çalışma özellikleri içerir, bu da bu iki depolama türü arasındaki çizgileri bulanıklaştırabilir.*
|
||||
|
||||
Kullanılan uygulamaya bağlı olarak belgeler, koleksiyonlar, etiketler, meta veriler veya dizinler tarafından düzenlenir. Belirli bir araya getirilebilecek veya gruplandırılabilecek olsa da belgeler, birbirinden tamamen farklı alanlara sahip olabilir.
|
||||
|
||||
[MongoDB](https://www.mongodb.com/mongodb-architecture) ve [CouchDB](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/) gibi bazı belge depoları ayrıca karmaşık sorguları gerçekleştirmek için bir SQL benzeri dil sağlar. [DynamoDB](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf), hem anahtar-değerleri hem de belgeleri destekler.
|
||||
|
||||
Belge depoları yüksek esneklik sağlar ve genellikle zaman zaman değişen verilerle çalışmak için kullanılır.
|
||||
|
||||
#### Kaynak(lar) ve ek okuma: belge deposu
|
||||
|
||||
* [Document-oriented database](https://en.wikipedia.org/wiki/Document-oriented_database)
|
||||
* [MongoDB architecture](https://www.mongodb.com/mongodb-architecture)
|
||||
* [CouchDB architecture](https://blog.couchdb.org/2016/08/01/couchdb-2-0-architecture/)
|
||||
* [Elasticsearch architecture](https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up)
|
||||
|
||||
#### Geniş sütun deposu
|
||||
|
||||
<p align="center">
|
||||
<img src="images/n16iOGk.png">
|
||||
<br/>
|
||||
<i><a href=http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html>Kaynak: SQL & NoSQL, a brief history</a></i>
|
||||
</p>
|
||||
|
||||
> Soyutlama: İç içe geçmiş harita(nested map) `ColumnFamily<RowKey, Columns<ColKey, Value, Timestamp>>`
|
||||
|
||||
Geniş sütun depolama biriminin temel veri birimi bir sütundur (ad/değer çifti). Bir sütun, sütun ailelerine (SQL tablosuna benzer) gruplanabilir. Süper sütun aileleri, sütun ailelerini daha da gruplar. Her sütuna bir satır anahtarıyla bağımsız olarak erişebilirsiniz ve aynı satır anahtarına sahip sütunlar bir satır oluşturur. Her değer, sürümleme ve çakışma çözümü için bir zaman damgası içerir.
|
||||
|
||||
Google, [Bigtable'ı](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) ilk geniş sütun depolama olarak tanıttı, bu da Hadoop ekosisteminde sıkça kullanılan açık kaynaklı [HBase](https://www.mapr.com/blog/in-third-look-hbase-architecture) ve Facebook tarafından geliştirilen [Cassandra](http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archIntro.html) üzerinde etkili oldu. BigTable, HBase ve Cassandra gibi depolama sistemleri anahtarları leksikografik(alfabetik) sırayla tutar, bu da seçici anahtar aralıklarının etkili bir şekilde alınmasına olanak tanır.
|
||||
|
||||
Geniş sütun depolamaları yüksek kullanılabilirlik ve ölçeklenebilirlik sunar. Genellikle çok büyük veri setleri için kullanılırlar.
|
||||
|
||||
##### Kaynak(lar) ve ek okuma: geniş sütun depolama
|
||||
|
||||
* [SQL & NoSQL, a brief history](http://blog.grio.com/2015/11/sql-nosql-a-brief-history.html)
|
||||
* [Bigtable architecture](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf)
|
||||
* [HBase architecture](https://www.edureka.co/blog/hbase-architecture/)
|
||||
* [Cassandra architecture](http://docs.datastax.com/en/cassandra/3.0/cassandra/architecture/archIntro.html)
|
||||
|
||||
#### Grafik veritabanı
|
||||
|
||||
<p align="center">
|
||||
<img src="images/fNcl65g.png">
|
||||
<br/>
|
||||
<i><a href=https://en.wikipedia.org/wiki/File:GraphDatabase_PropertyGraph.png>Kaynak: Graph database</a></i>
|
||||
</p>
|
||||
|
||||
> Soyutlama: grafik(graph)
|
||||
|
||||
Grafik veritabanlarında, her düğüm bir kayıtı temsil eder ve her yay bir düğüm arasındaki ilişkiyi ifade eder. Grafik veritabanları, birçok yabancı anahtar veya çoktan çoklu ilişkiyi temsil etmek için optimize edilmiştir.
|
||||
|
||||
Grafik veritabanları, sosyal ağ gibi karmaşık ilişkilere sahip veri modelleri için yüksek performans sunar. Nispeten yeni bir teknoloji olmalarına rağmen, henüz geniş çapta kullanılmamaktadırlar; bu nedenle geliştirme araçları ve kaynakları bulmak daha zor olabilir. Birçok grafik veritabanına yalnızca REST API'leri aracılığıyla erişilebilir.
|
||||
|
||||
##### Kaynak(lar) ve ek okuma: grafik
|
||||
|
||||
* [Graph database](https://en.wikipedia.org/wiki/Graph_database)
|
||||
* [Neo4j](https://neo4j.com/)
|
||||
* [FlockDB](https://blog.twitter.com/2010/introducing-flockdb)
|
||||
|
||||
#### Kaynak(lar) ve ek okuma: NoSQL
|
||||
|
||||
* [Explanation of base terminology](http://stackoverflow.com/questions/3342497/explanation-of-base-terminology)
|
||||
* [NoSQL databases a survey and decision guidance](https://medium.com/baqend-blog/nosql-databases-a-survey-and-decision-guidance-ea7823a822d#.wskogqenq)
|
||||
* [Scalability](http://www.lecloud.net/post/7994751381/scalability-for-dummies-part-2-database)
|
||||
* [Introduction to NoSQL](https://www.youtube.com/watch?v=qI_g07C_Q5I)
|
||||
* [NoSQL patterns](http://horicky.blogspot.com/2009/11/nosql-patterns.html)
|
||||
|
||||
### SQL veya NoSQL
|
||||
|
||||
<p align="center">
|
||||
<img src="images/wXGqG5f.png">
|
||||
<br/>
|
||||
<i><a href=https://www.infoq.com/articles/Transition-RDBMS-NoSQL/>Kaynak: Transitioning from RDBMS to NoSQL</a></i>
|
||||
</p>
|
||||
|
||||
**SQL**'i seçme nedenleri:
|
||||
|
||||
* Yapılandırılmış veri
|
||||
* Katı şema
|
||||
* İlişkisel veri
|
||||
* Karmaşık birleştirmelere ihtiyaç
|
||||
* İşlemler
|
||||
* Ölçeklendirme için açık kalıplar
|
||||
* Mevcut kaynaklar daha zengindir: geliştiriciler, topluluklar, kod kitaplıkları, araçlar vb.
|
||||
* İndeksleme ile aramalar çok hızlıdır
|
||||
|
||||
**NoSQL**'i seçme nedenleri:
|
||||
|
||||
* Yarı yapılandırılmış veri
|
||||
* Dinamik veya esnek şema
|
||||
* İlişkisel olmayan veri
|
||||
* Karmaşık birleştirmelere ihtiyaç yok
|
||||
* Birkaç terabayt (veya petabayt) veri depolama ihtiyacı
|
||||
* Çok veri yoğun iş yükü
|
||||
* IOPS için çok yüksek işlem kapasitesi
|
||||
|
||||
NoSQL'e uygun örnek veriler:
|
||||
|
||||
* Tıklama akışı ve günlük verilerinin hızlı alımı
|
||||
* Sıralama veya puanlama verileri
|
||||
* Geçici veriler, örneğin bir alışveriş sepeti
|
||||
* Sıkça erişilen ('sıcak') tablolar
|
||||
* Metadata/arama tabloları
|
||||
|
||||
##### Kaynak(lar) ve ek okuma: SQL veya NoSQL
|
||||
|
||||
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=kKjm4ehYiMs)
|
||||
* [SQL vs NoSQL differences](https://www.sitepoint.com/sql-vs-nosql-differences/)
|
||||
|
||||
## Önbellek
|
||||
|
||||
<p align="center">
|
||||
<img src="images/Q6z24La.png">
|
||||
<br/>
|
||||
<i><a href=http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html>Kaynak: Scalable system design patterns</a></i>
|
||||
</p>
|
||||
|
||||
Önbellekleme, sayfa yükleme sürelerini iyileştirir ve sunucularınız ile veritabanlarınıza olan yükü azaltabilir. Bu modelde, yönlendirici önce isteğin daha önce yapılmış olup olmadığını kontrol eder ve önceki sonucu bulmaya çalışır, böylece gerçek yürütümü kaydetmeye çalışır.
|
||||
|
||||
Veritabanları, okuma ve yazma işlemlerinin bölümler arasında homojen bir şekilde dağılımından genellikle fayda sağlar. Popüler öğeler, dağılımı bozarak darboğazlara neden olabilir. Bir önbelleği bir veritabanının önüne koymak, düzensiz yükleri ve trafiğin ani artışlarını absorbe etmeye yardımcı olabilir.
|
||||
|
||||
### İstemci önbelleği
|
||||
|
||||
Önbellekler, istemci tarafında (işletim sistemi veya tarayıcı), [sunucu tarafında](#ters-proxy-web-sunucusu) veya ayrı bir önbellek katmanında bulunabilir.
|
||||
|
||||
### CDN önbelleği
|
||||
|
||||
[İçerik dağıtım ağları (CDNs)](#içerik-dağıtım-ağı-cdn) aynı zamanda bir önbellek türü olarak kabul edilir.
|
||||
|
||||
### Web sunucusu önbelleği
|
||||
|
||||
[Ters proxyler](#ters-proxy-web-sunucusu) ve ([Varnish](https://www.varnish-cache.org/)) gibi önbellekler, statik ve dinamik içerikleri doğrudan sunabilir. Web sunucuları ayrıca istekleri önbelleğe alabilir ve uygulama sunucularına başvurmadan yanıtları döndürebilir.
|
||||
|
||||
### Veritabanı önbelleği
|
||||
|
||||
Veritabanınız genellikle genel bir kullanım durumu için optimize edilmiş varsayılan bir yapılandırmada bir düzeyde önbelleği içerir. Bu ayarları belirli kullanım modelleri için ayarlamak, performansı daha da artırabilir.
|
||||
|
||||
### Uygulama önbelleği
|
||||
|
||||
Memcached ve Redis gibi in-memory önbellekler, uygulamanız ile veri depolama arasında bulunan anahtar-değer depolama sistemleridir. Veri RAM'de tutulduğundan, veri disk üzerinde depolandığı tipik veritabanlarından çok daha hızlıdır. RAM, diskten daha sınırlıdır, bu nedenle [önbellek geçersiz kılma algoritmaları](https://en.wikipedia.org/wiki/Cache_algorithms), örneğin [en az kullanılan (LRU)](https://en.wikipedia.org/wiki/Cache_replacement_policies#Least_recently_used_(LRU)), 'soğuk' girişleri geçersiz kılmaya ve 'sıcak' veriyi RAM'de tutmaya yardımcı olabilir.
|
||||
|
||||
Redis aşağıdaki ek özelliklere sahiptir:
|
||||
|
||||
* Kalıcılık seçeneği
|
||||
* Sıralı kümeler ve listeler gibi yerleşik veri yapıları
|
||||
|
||||
İki ana kategoriye ayrılmış birden çok önbellek düzeyi vardır: **veritabanı sorguları** ve **nesneler**:
|
||||
|
||||
* Satır seviyesi
|
||||
* Sorgu seviyesi
|
||||
* Tamamen oluşturulmuş(fully-formed) serilenebilir(serializable) nesneler
|
||||
* Tamamen işlenmiş(fully-rendered) HTML
|
||||
|
||||
Genel olarak dosya tabanlı önbelleğe alma işleminden kaçınmaya çalışmalısınız; çünkü bu, çoğaltmayı ve otomatik ölçeklendirmeyi zorlaştırır.
|
||||
|
||||
### Veritabanı sorgu düzeyinde önbellekleme
|
||||
|
||||
Veritabanını sorguladığınız her zaman, sorguyu bir anahtar olarak kullanın ve sonucu önbelleğe depolayın. Bu yaklaşımın süresi dolma sorunlarına neden olabilir:
|
||||
|
||||
* Karmaşık sorgularla önbelleğe alınmış sonuçları silmek zordur.
|
||||
* Tablodaki bir öğe gibi bir veri parçası değiştirilirse, değiştirilen öğeyi içerebilecek önbelleğe alınmış tüm sonuçların silinmesi gerekir.
|
||||
|
||||
### Nesne düzeyinde önbellekleme
|
||||
|
||||
Verinizi, uygulama kodunuzdaki objeler gibi düşünün. Uygulamanın veritabanındaki verileri sınıf örneklerine veya veri yapılarına birleştirmesine izin verin:
|
||||
|
||||
* Nesnenin temel verileri değiştiyse nesneyi önbellekten silin.
|
||||
* Asenkron işleme izin verin: çalışanlar, önbelleğe alınmış en son nesneleri kullanarak nesneleri birleştirin.
|
||||
|
||||
Önbellekleme için öneriler:
|
||||
|
||||
* Kullanıcı oturumları
|
||||
* Tamamen render edilmiş web sayfaları
|
||||
* Aktivite akışları
|
||||
* Kullanıcı grafik verileri
|
||||
|
||||
### Önbellek ne zaman güncellenmeli
|
||||
|
||||
Önbellekte yalnızca sınırlı veri depolayabildiğiniz için, kullanım durumunuza uygun bir önbellek güncelleme stratejisi seçmeniz gerekir.
|
||||
|
||||
#### Cache-aside
|
||||
|
||||
<p align="center">
|
||||
<img src="images/ONjORqk.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Kaynak: From cache to in-memory data grid</a></i>
|
||||
</p>
|
||||
|
||||
Uygulama, bellekten okumak ve yazmaktan sorumludur. Önbellek, doğrudan bellekle bağlantısı/etkileşimi yoktur. Uygulama, aşağıdaki işlemleri gerçekleştirir:
|
||||
|
||||
* Önbellekte veriyi arar; veri, önbellekte bulunmadığı için "cache miss" durumu oluşur.
|
||||
* Veritabanından veriyi yükler.
|
||||
* Bulunan sonuçları önbellekte saklar.
|
||||
* İhtiyacı olunan veriyi döndürür.
|
||||
|
||||
```python
|
||||
def get_user(self, user_id):
|
||||
user = cache.get("user.{0}", user_id)
|
||||
if user is None:
|
||||
user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
|
||||
if user is not None:
|
||||
key = "user.{0}".format(user_id)
|
||||
cache.set(key, json.dumps(user))
|
||||
return user
|
||||
```
|
||||
|
||||
[Memcached](https://memcached.org/) genellikle bu şekilde kullanılır.
|
||||
|
||||
Önbelleğe eklenen veriler çok hızlı okunur. Önbellek moduna tembel yükleme de denir. Yalnızca istenen veriler önbelleğe alınır; bu, önbelleğin istenmeyen verilerle doldurulmasını önler.
|
||||
|
||||
##### Dezavantaj(lar): cache-aside
|
||||
|
||||
* Önbellekte olmayan verileri talep etmek, verileri almak için üç adım gerektirir ve bu da önemli gecikmelere neden olabilir.
|
||||
* Veritabanındaki veriler güncellenirse önbellekteki veriler güncelliğini yitirir. Bu sorunun, TTL'nin önbellek güncellemelerini veya doğrudan yazma modunu zorlayacak şekilde ayarlanmasıyla hafifletilmesi gerekir.
|
||||
* Bir düğüm başarısız olduğunda, onun yerini yeni bir düğüm alır, bu da gecikmeyi artırır.
|
||||
|
||||
#### Üzerine yazma (write-through)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/0vBc0hN.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Kaynak: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
Uygulama, önbelleği ana veri deposu olarak kullanır ve veriyi okuma ve yazma işlemlerini buraya gerçekleştirir, bu sırada önbellek, veritabanına okuma ve yazma işlemlerini gerçekleştirmekten sorumludur:
|
||||
|
||||
* Uygulama, önbelleğe giriş ekler/günceller.
|
||||
* Önbellek, girişi senkron bir şekilde veri deposuna yazar.
|
||||
* Geri dönüş.
|
||||
|
||||
Uygulama kodu:
|
||||
|
||||
```python
|
||||
set_user(12345, {"foo":"bar"})
|
||||
```
|
||||
|
||||
Önbellek kodu:
|
||||
|
||||
```python
|
||||
def set_user(user_id, values):
|
||||
user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
|
||||
cache.set(user_id, user)
|
||||
```
|
||||
|
||||
Depolama ve yazma işlemleri nedeniyle, üzerine yazma yöntemi genel olarak çok yavaş bir işlemdir, ancak yeni yazılan verilerin okunması çok hızlıdır. Kullanıcılar genellikle veriyi okurken veriyi güncelleme sırasındaki gecikmeye daha toleranslıdır. Önbellekteki veriler eski değildir.
|
||||
|
||||
##### Dezavantaj(lar): üzerine yazma (write-through)
|
||||
|
||||
* Bir hata veya ölçeklendirme nedeniyle oluşturulan yeni düğümler, veritabanı güncellenene kadar önbelleğe alınmayacaktır. Cache-aside'in yanı sıra üzerine yazma yöntemini kullanmak, bu sorunu hafifletebilir.
|
||||
* Yazılan verilerin çoğu hiç okunmayabilir, bu durum bir TTL ile minimize edilebilir.
|
||||
|
||||
#### Geri yazma (write-behind)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/rgSrvjG.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Kaynak: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
Geri yazma yönteminde, uygulama aşağıdaki adımları gerçekleştirir:
|
||||
|
||||
* Önbelleğe giriş ekler/günceller
|
||||
* Girişi veri deposuna asenkron bir şekilde yazarak yazma performansını artırır
|
||||
|
||||
##### Dezavantaj(lar): geri yazma (write-behind)
|
||||
|
||||
* Önbelleğin içeriği veri deposuna yazılmadan; önbellek devre dışı bırakılırsa veri kaybı olabilir.
|
||||
* Geri yazma yöntemini uygulamak, cache-aside veya üzerine yazma yöntemini uygulamaktan daha karmaşıktır.
|
||||
|
||||
#### Önbelleği önceden yenileme (refresh-ahead)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/kxtjqgE.png">
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast>Kaynak: From cache to in-memory data grid</a></i>
|
||||
</p>
|
||||
|
||||
Önbelleği, süresi dolmadan önce erişilen herhangi bir önbellek girişini; otomatik olarak yenileyecek şekilde yapılandırabilirsiniz.
|
||||
|
||||
Refresh-ahead, önbelleğin gelecekte hangi öğelere ihtiyaç duyulma olasılığını doğru bir şekilde tahmin edebiliyorsa, okuma işlemine göre daha az gecikmeye neden olabilir.
|
||||
|
||||
##### Dezavantaj(lar): önbelleği önceden yenileme (refresh-ahead)
|
||||
|
||||
* Gelecekte hangi öğelerin muhtemelen ihtiyaç duyulacağını doğru bir şekilde tahmin edememek, refresh-ahead olmadan daha düşük performansa neden olabilir.
|
||||
|
||||
### Dezavantaj(lar): önbellek
|
||||
|
||||
* Önbellek ile veritabanı gibi gerçek kaynak arasındaki tutarlılığı sürdürmek için [önbellek geçersiz kılma](https://en.wikipedia.org/wiki/Cache_algorithms) gerekebilir.
|
||||
* Önbellek geçersiz kılma, zorlu bir sorundur ve önbelleği ne zaman güncellemek gerektiğiyle ilgili ek karmaşıklıklar içerir.
|
||||
* Redis veya memcached gibi öğeleri eklemek gibi uygulama değişiklikleri yapmak gerekebilir.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [From cache to in-memory data grid](http://www.slideshare.net/tmatyashovsky/from-cache-to-in-memory-data-grid-introduction-to-hazelcast)
|
||||
* [Scalable system design patterns](http://horicky.blogspot.com/2010/10/scalable-system-design-patterns.html)
|
||||
* [Introduction to architecting systems for scale](http://lethain.com/introduction-to-architecting-systems-for-scale/)
|
||||
* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
* [Scalability](http://www.lecloud.net/post/9246290032/scalability-for-dummies-part-3-cache)
|
||||
* [AWS ElastiCache strategies](http://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/Strategies.html)
|
||||
* [Wikipedia](https://en.wikipedia.org/wiki/Cache_(computing))
|
||||
|
||||
## Asenkronizm
|
||||
|
||||
<p align="center">
|
||||
<img src="images/54GYsSx.png">
|
||||
<br/>
|
||||
<i><a href=http://lethain.com/introduction-to-architecting-systems-for-scale/#platform_layer>Kaynak: Intro to architecting systems for scale</a></i>
|
||||
</p>
|
||||
|
||||
Asenkron iş akışları, maliyetli işlemler için talep sürelerini azaltmaya yardımcı olur ve aksi takdirde içeride gerçekleştirilecek olan işlemleri iyileştirir. Ayrıca, verinin periyodik olarak bir araya getirilmesi gibi zaman alıcı işleri önceden gerçekleştirerek de yardımcı olabilir.
|
||||
|
||||
### Mesaj kuyrukları
|
||||
|
||||
Message queues, mesajları alır, tutar ve iletiler. Bir işlem, içeride yürütülmek için çok yavaşsa, aşağıdaki iş akışını kullanarak bir mesaj kuyruğu kullanabilirsiniz:
|
||||
|
||||
* Bir uygulama bir işi kuyruğa gönderir ve ardından kullanıcıya iş durumu bildirilir
|
||||
* Bir çalışan (worker), işi kuyruktan alır, işler, ardından işin tamamlandığını bildirir.
|
||||
|
||||
Kullanıcı engellenmez ve iş arka planda işlenir. Bu süre zarfında istemci, görevin tamamlandığı gibi görünmesi için isteğe bağlı olarak küçük bir işlem yapabilir. Örneğin, bir tweet gönderiyorsanız, tweet hemen zaman akışınıza gönderilebilir, ancak tweet'iniz gerçekten tüm takipçilere ulaşması biraz zaman alabilir.
|
||||
|
||||
**Redis** basit bir mesaj aracı olarak kullanışlıdır, ancak mesajlar kaybolabilir.
|
||||
|
||||
**RabbitMQ** popülerdir, ancak 'AMQP' protokolüne uyum sağlamanızı ve kendi düğümlerinizi yönetmenizi gerektirir.
|
||||
|
||||
**Amazon SQS** yüksek gecikme süresine sahip olabilir ve mesajların iki kez teslim edilme olasılığı vardır.
|
||||
|
||||
### Görev kuyrukları
|
||||
|
||||
Görev kuyrukları, görevleri ve ilgili verileri alır, bunları çalıştırır ve ardından sonuçlarını teslim eder. Zamanlamayı destekleyebilirler ve hesaplama yoğun işleri arka planda çalıştırmak için kullanılabilirler.
|
||||
|
||||
**[Celery](https://docs.celeryproject.org/en/stable/)** planlamayı destekler ve Python desteği sunar.
|
||||
|
||||
### Back pressure
|
||||
|
||||
Eğer kuyruk önemli ölçüde büyümeye başlarsa, sıra boyutu bellek boyutunu aşabilir. Bu durum, önbellek kayıplarına, disk okumalarına ve hatta performansın yavaşlamasına neden olabilir. [Back pressure](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-press-when-overloaded.html), kuyruk boyutunu sınırlandırarak bize yardımcı olabilir. Böylece, yüksek düzeyde işlemlerin korunmasını sağlayarak kuyruk verimini ve iyi yanıt süresini artırabiliriz. Kuyruk dolu olduğunda, istemci bir Sunucu Meşgul veya HTTP 503 durum kodu alacak ve isteği daha sonra, belki de [üstel geri çekilme](https://en.wikipedia.org/wiki/Exponential_backoff) ile yeniden denemek üzere tekrar deneyebilir.
|
||||
|
||||
### Dezavantaj(lar): asenkronizm
|
||||
|
||||
* Maliyetsiz hesaplamalar ve gerçek zamanlı iş akışları gibi durumlar, senkron işlemler için daha uygun olabilir, çünkü kuyrukların eklenmesi gecikmelere ve karmaşıklığa neden olabilir.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [It's all a numbers game](https://www.youtube.com/watch?v=1KRYH75wgy4)
|
||||
* [Applying back pressure when overloaded](http://mechanical-sympathy.blogspot.com/2012/05/apply-back-pressure-when-overloaded.html)
|
||||
* [Little's law](https://en.wikipedia.org/wiki/Little%27s_law)
|
||||
* [What is the difference between a message queue and a task queue?](https://www.quora.com/What-is-the-difference-between-a-message-queue-and-a-task-queue-Why-would-a-task-queue-require-a-message-broker-like-RabbitMQ-Redis-Celery-or-IronMQ-to-function)
|
||||
|
||||
## İletişim
|
||||
|
||||
<p align="center">
|
||||
<img src="images/5KeocQs.jpg">
|
||||
<br/>
|
||||
<i><a href=http://www.escotal.com/osilayer.html>Kaynak: OSI 7 layer model</a></i>
|
||||
</p>
|
||||
|
||||
### Köprü metni aktarım protokolü (HTTP)
|
||||
|
||||
HTTP, bir istemci ve bir sunucu arasında veri kodlama ve iletimi için bir yöntemdir. Bu, bir istek/yanıt protokolüdür: istemciler talepler gönderir ve sunucular taleplere ilişkin içerik ve tamamlama durumu bilgileri ile yanıtlar verir. HTTP, kendi içinde bağımsızdır, bu da taleplerin ve yanıtların birçok ara yönlendirici ve yük dengeleme, önbellekleme, şifreleme ve sıkıştırma işlemi yapan sunucu üzerinden geçmesine olanak tanır.
|
||||
|
||||
Temel bir HTTP isteği, bir fiil (metot) ve bir kaynak (nokta) içerir. Aşağıda yaygın HTTP fiilleri bulunmaktadır:
|
||||
|
||||
| Metotlar | Açıklama | Tekrarlanabilir* | Güvenli | Önbelleğe Alınabilir |
|
||||
|----------|--------------------------------------------------------------|------------------|---------|--------------------------------------------------------|
|
||||
| GET | Bir kaynağı okur | Evet | Evet | Evet |
|
||||
| POST | Bir kaynak oluşturur veya veriyi işleyen bir süreci tetikler | Hayır | Hayır | Evet,eğer yanıt taze bilgi(freshness info) içeriyorsa |
|
||||
| PUT | Bir kaynak yaratır veya değiştirir | Evet | Hayır | Hayır |
|
||||
| PATCH | Bir kaynağı kısmen günceller | Hayır | Hayır | Evet,eğer yanıt taze bilgi(freshness info) içeriyorsa |
|
||||
| DELETE | Bir kaynağı siler | Evet | Hayır | Hayır |
|
||||
|
||||
**Birden çok kez çağrılabilir, ve farklı sonuçlar elde edilmeyecektir.**.
|
||||
|
||||
HTTP, **TCP** ve **UDP** gibi alt düzey protokollere dayanan bir uygulama katmanı protokolüdür.
|
||||
|
||||
#### Kaynak(lar) ve ek okuma: HTTP
|
||||
|
||||
* [What is HTTP?](https://www.nginx.com/resources/glossary/http/)
|
||||
* [Difference between HTTP and TCP](https://www.quora.com/What-is-the-difference-between-HTTP-protocol-and-TCP-protocol)
|
||||
* [Difference between PUT and PATCH](https://laracasts.com/discuss/channels/general-discussion/whats-the-differences-between-put-and-patch?page=1)
|
||||
|
||||
### İletim kontrol protokolü (TCP)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/JdAsdvG.jpg">
|
||||
<br/>
|
||||
<i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Kaynak: How to make a multiplayer game</a></i>
|
||||
</p>
|
||||
|
||||
TCP, [IP ağı](https://en.wikipedia.org/wiki/Internet_Protocol) üzerinde bağlantı odaklı bir protokoldür. [El Sıkışma](https://en.wikipedia.org/wiki/Handshaking) yöntemi kullanılarak bağlantı kurulur ve sonlandırılır. Gönderilen tüm veri paketlerinin hedefe orijinal sırasıyla, zarar görmeden ulaşması aşağıdaki maddeler ile garanti edilir:
|
||||
|
||||
* Her paket için sıra numaraları ve [checksum alanları](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Checksum_computation).
|
||||
* [Onaylama](https://en.wikipedia.org/wiki/Acknowledgement_(data_networks)) paketleri ve otomatik yeniden iletim
|
||||
|
||||
Eğer gönderici doğru bir yanıt almazsa, paketleri yeniden gönderir. Birden fazla zaman aşımı durumunda bağlantı kapatılır. TCP aynı zamanda [akış kontrolü](https://en.wikipedia.org/wiki/Flow_control_(data)) ve [tıkanıklık kontrolü](https://en.wikipedia.org/wiki/Network_congestion#Congestion_control) de uygular. Bu garantiler gecikmelere neden olur ve genellikle UDP'den daha az verimli iletim sonuçları doğurur.
|
||||
|
||||
Yüksek verimlilik sağlamak için web sunucuları, büyük bir TCP bağlantısı sayısını açık tutabilir, bu da yüksek bellek kullanımına neden olabilir. Web sunucu iş parçacıkları ile örneğin bir [memcached](https://memcached.org/) sunucusu arasında çok sayıda açık bağlantıya sahip olmak maliyetli olabilir. [Bağlantı havuzu (connection pooling)](https://en.wikipedia.org/wiki/Connection_pool), uygun olan yerlerde UDP'ye geçişe ek olarak yardımcı olabilir.
|
||||
|
||||
TCP, yüksek güvenilirlik gerektiren ancak zaman açısından daha az kritik olan uygulamalar için kullanışlıdır. Bazı örnekler arasında web sunucuları, veritabanı bilgileri, SMTP, FTP ve SSH bulunur.
|
||||
|
||||
Aşağıdaki durumlarda UDP yerine TCP tercih ediniz:
|
||||
|
||||
* Tüm verilerin sağlam bir şekilde varmasına ihtiyacınız varsa.
|
||||
* Ağ bant genişliğini otomatik olarak en iyi şekilde kullanmak istiyorsanız.
|
||||
|
||||
### Kullanıcı datagram protokolü (UDP)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/yzDrJtA.jpg">
|
||||
<br/>
|
||||
<i><a href=http://www.wildbunny.co.uk/blog/2012/10/09/how-to-make-a-multi-player-game-part-1/>Kaynak: How to make a multiplayer game</a></i>
|
||||
</p>
|
||||
|
||||
UDP bağlantısızdır. Datagramlar (paketlere benzer) yalnızca datagram düzeyinde garanti edilir. Datagramlar hedeflerine sırasız veya hiç ulaşmayabilir. UDP, tıkanıklık kontrolünü desteklemez. TCP'nin sunduğu garantiler olmadan, UDP genellikle daha verimlidir.
|
||||
|
||||
UDP, datagramları alt ağdaki tüm cihazlara göndererek yayın yapabilir. Bu, [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol) ile kullanışlıdır çünkü istemci henüz bir IP adresi almamıştır, bu nedenle TCP'nin IP adresi olmadan akış yapmasını engeller.
|
||||
|
||||
UDP daha az güvenilir olsa da, VoIP, video sohbet, yayın ve gerçek zamanlı çok oyunculu oyunlar gibi gerçek zamanlı kullanım durumlarında kullanışlıdır.
|
||||
|
||||
Aşağıdaki durumlarda TCP yerine UDP kullanın:
|
||||
|
||||
* Düşük gecikmeye ihtiyacınız var
|
||||
* Verinin gecikmesi, veri kaybından daha önemli
|
||||
* Kendi hata düzeltme yönteminizi uygulamak istiyorsunuz
|
||||
|
||||
#### Kaynak(lar) ve ek okuma: TCP ve UDP
|
||||
|
||||
* [Networking for game programming](http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/)
|
||||
* [Key differences between TCP and UDP protocols](http://www.cyberciti.biz/faq/key-differences-between-tcp-and-udp-protocols/)
|
||||
* [Difference between TCP and UDP](http://stackoverflow.com/questions/5970383/difference-between-tcp-and-udp)
|
||||
* [Transmission control protocol](https://en.wikipedia.org/wiki/Transmission_Control_Protocol)
|
||||
* [User datagram protocol](https://en.wikipedia.org/wiki/User_Datagram_Protocol)
|
||||
* [Scaling memcache at Facebook](http://www.cs.bu.edu/~jappavoo/jappavoo.github.com/451/papers/memcache-fb.pdf)
|
||||
|
||||
### Uzaktan yordam çağrısı (RPC)
|
||||
|
||||
<p align="center">
|
||||
<img src="images/iF4Mkb5.png">
|
||||
<br/>
|
||||
<i><a href=http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview>Kaynak: Crack the system design interview</a></i>
|
||||
</p>
|
||||
|
||||
Bir RPC'de, bir istemci genellikle uzak bir sunucuda olmak üzere farklı bir adres alanında bir prosedürün yürütülmesine neden olur. Prosedür, istemci programından sunucu ile iletişim kurma ayrıntılarını soyutlar şekilde kodlanmıştır, sanki yerel bir prosedür çağrısı gibi. Uzak çağrılar genellikle yerel çağrılardan daha yavaş ve güvenilir olabilir, bu nedenle RPC çağrılarını yerel çağrılardan ayırmak faydalıdır. Popüler RPC çerçeveleri arasında [Protobuf](https://developers.google.com/protocol-buffers/), [Thrift](https://thrift.apache.org/) ve [Avro](https://avro.apache.org/docs/current/) bulunmaktadır.
|
||||
|
||||
RPC, bir istek-yanıt protokolüdür:
|
||||
|
||||
* **İstemci program** - İstemci tanımlama prosedürünü çağırır. Parametreler, yerel bir prosedür çağrısı gibi yığına itilir.
|
||||
* **İstemci tanımlama prosedürü** ─ Prosedür kimliğini ve argümanları bir istek mesajına paketler (marshal).
|
||||
* **İstemci iletişim modülü** ─ İşletim sistemi, mesajı istemciden sunucuya gönderir.
|
||||
* **Sunucu iletişim modülü** ─ İşletim sistemi, gelen paketleri sunucu tanımlama prosedürüne iletilir.
|
||||
* **Sunucu tanımlama prosedürü** ─ Sonuçları açar (unmarshal), prosedür kimliği ile eşleşen sunucu prosedürünü çağırır ve verilen argümanları iletilir.
|
||||
* Sunucu yanıtı, yukarıdaki adımları ters sırayla tekrarlar.
|
||||
|
||||
* Örnek RPC çağrısı:
|
||||
|
||||
```
|
||||
GET /someoperation?data=anId
|
||||
|
||||
POST /anotheroperation
|
||||
{
|
||||
"data":"anId";
|
||||
"anotherdata": "another value"
|
||||
}
|
||||
```
|
||||
|
||||
RPC, davranışları ortaya çıkarmaya odaklanmıştır. RPC'ler, genellikle iç iletişimde performans nedenleriyle kullanılır, çünkü kullanım durumlarınıza daha iyi uyan özelleştirilmiş çağrıları el ile oluşturabilirsiniz.
|
||||
|
||||
Aşağıdaki durumlarda yerel kitaplığı (yani SDK'yı) seçin:
|
||||
|
||||
* Hedef platformunuzu biliyorsunuz.
|
||||
* "Mantığınızın" nasıl erişileceğini kontrol etmek istiyorsunuz.
|
||||
* Kitaplığınızda oluşan hatalar üzerinde kontrol sahibi olmak istiyorsunuz.
|
||||
* Performans ve kullanıcı deneyimi birincil endişeniz.
|
||||
|
||||
**REST** uyumlu HTTP API'ları, genellikle genel API'lar için daha sık kullanılır.
|
||||
|
||||
#### Dezavantajları: RPC
|
||||
|
||||
* RPC istemcileri, servis uygulamasına sıkı bir şekilde bağlı olur.
|
||||
* Her yeni işlem veya kullanım durumu için yeni bir API tanımlanmalıdır.
|
||||
* RPC'de hata ayıklanması(debug) zordur.
|
||||
* Mevcut teknolojiyi kolayca değiştiremeyebilirsiniz. Örneğin, [RPC çağrılarının önbelleğe alınmasının](http://etherealbits.com/2012/12/); [Squid](http://www.squid-cache.org/) gibi bir önbellek sunucularında) uygun bir şekilde yapılması ek çaba gerekebilir.
|
||||
|
||||
### Temsili Durum Transferi (REST)
|
||||
|
||||
REST, bir istemci/sunucu modelini zorlayan bir mimari tarzıdır, burada istemci, sunucu tarafından yönetilen bir dizi kaynak üzerinde işlem yapar. Sunucu, kaynakların temsilini sağlar ve kaynakları ya manipüle edebilen ya da yeni bir temsil alabilen eylemleri içerir. Tüm iletişim durumsuz ve önbelleğe alınabilir olmalıdır.
|
||||
|
||||
RESTful arayüzün dört temel özelliği vardır:
|
||||
|
||||
* **Kaynakları tanımlama (HTTP'deki URI)** - herhangi bir işlemle ilgili olmaksızın aynı URI'yi kullanır.
|
||||
* **Temsillemelerle değiştirme (HTTP'deki metotlar)** - metotları, başlıkları ve gövdeyi kullanır.
|
||||
* **Kendi açıklamalı(Self-descriptive) hata mesajları (HTTP'deki durum yanıtları)** - Durum kodlarını kullanır, tekerleği yeniden icat etmeyin.
|
||||
* **[HATEOAS](http://restcookbook.com/Basics/hateoas/) (HTTP için HTML arayüzü)** - Web servisiniz tarayıcıda tamamen erişilebilir olmalıdır.
|
||||
|
||||
Örnek REST isteği:
|
||||
|
||||
```
|
||||
GET /someresources/anId
|
||||
|
||||
PUT /someresources/anId
|
||||
{"anotherdata": "another value"}
|
||||
```
|
||||
|
||||
REST, veri sunmaya odaklanmıştır. İstemci/sunucu arasındaki bağı minimuma indirir ve genellikle genel HTTP API'leri için kullanılır. REST, kaynakları URI'lar aracılığıyla, [başlıklar](https://github.com/for-GET/know-your-http-well/blob/master/headers.md) aracılığıyla temsil edilme ve GET, POST, PUT, DELETE ve PATCH gibi metotlar aracılığıyla metotları açma konusunda daha genel ve birleşik bir yöntem kullanır. Durum bilgisi olmayan(stateless) yapısı nedeniyle, REST yatay ölçeklendirme ve bölütleme için uygundur.
|
||||
|
||||
#### Dezavantaj(lar): REST
|
||||
|
||||
* REST, veri sunmaya odaklandığından, kaynaklar doğal olarak düzenlenmiyorsa veya basit bir hiyerarşi içinde erişilmiyorsa iyi bir tercih olmayabilir. Örneğin, belirli bir etkinlik kümesiyle eşleşen son bir saat içinde güncellenmiş tüm kayıtları döndürmek, kolayca bir yol olarak ifade edilemez. REST ile muhtemelen URI yolu, sorgu parametreleri ve belki de istek gövdesinin bir kombinasyonuyla uygulanacaktır.
|
||||
* REST genellikle kullanım durumunuza uymayan birkaç metoda (GET, POST, PUT, DELETE ve PATCH) dayanır. Örneğin, süresi dolmuş belgeleri arşiv klasörüne taşımak, bu metotların içine temiz bir şekilde sığmayabilir.
|
||||
* Karmaşık kaynakları iç içe geçmiş hiyerarşilerle almak, tek bir görünümü oluşturmak için istemci ve sunucu arasında çok sayıda tur yapmayı gerektirir; örneğin, bir blog girişinin içeriğini ve o giriş üzerindeki yorumları almak vs. Değişken ağ koşullarında çalışan mobil uygulamalar için bu çoklu tur işlemleri istenmeyen durumlardır.
|
||||
* Zamanla, bir API yanıtına daha fazla alan eklenebilir ve eski istemciler tüm yeni veri alanlarını, ihtiyaç duymadıkları halde alacakları için veri boyutunu şişirir.
|
||||
|
||||
### RPC ve REST karşılaştırması
|
||||
|
||||
| İşlem | RPC | REST |
|
||||
|--------------------------------|-------------------------------------------------------------------------------------------|--------------------------------------------------------------|
|
||||
| Kayıt ol | **POST** /signup | **POST** /persons |
|
||||
| Ayrıl | **POST** /resign<br/>{<br/>"personid": "1234"<br/>} | **DELETE** /persons/1234 |
|
||||
| Bir kişinin bilgilerini okuma | **GET** /readPerson?personid=1234 | **GET** /persons/1234 |
|
||||
| Bir kişinin öğe listesini oku | **GET** /readUsersItemsList?personid=1234 | **GET** /persons/1234/items |
|
||||
| Bir kişinin öğelerine öğe ekle | **POST** /addItemToUsersItemsList<br/>{<br/>"personid": "1234";<br/>"itemid": "456"<br/>} | **POST** /persons/1234/items<br/>{<br/>"itemid": "456"<br/>} |
|
||||
| Bir öğeyi güncelle | **POST** /modifyItem<br/>{<br/>"itemid": "456";<br/>"key": "value"<br/>} | **PUT** /items/456<br/>{<br/>"key": "value"<br/>} |
|
||||
| Bir öğeyi sil | **POST** /removeItem<br/>{<br/>"itemid": "456"<br/>} | **DELETE** /items/456 |
|
||||
|
||||
<p align="center">
|
||||
<i><a href=https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/>Kaynak: Do you really know why you prefer REST over RPC</a></i>
|
||||
</p>
|
||||
|
||||
#### Kaynak(lar) ve ek okuma: REST ve RPC
|
||||
|
||||
* [Do you really know why you prefer REST over RPC](https://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/)
|
||||
* [When are RPC-ish approaches more appropriate than REST?](http://programmers.stackexchange.com/a/181186)
|
||||
* [REST vs JSON-RPC](http://stackoverflow.com/questions/15056878/rest-vs-json-rpc)
|
||||
* [Debunking the myths of RPC and REST](http://etherealbits.com/2012/12/debunking-the-myths-of-rpc-rest/)
|
||||
* [What are the drawbacks of using REST](https://www.quora.com/What-are-the-drawbacks-of-using-RESTful-APIs)
|
||||
* [Crack the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
|
||||
* [Thrift](https://code.facebook.com/posts/1468950976659943/)
|
||||
* [Why REST for internal use and not RPC](http://arstechnica.com/civis/viewtopic.php?t=1190508)
|
||||
|
||||
## Güvenlik
|
||||
|
||||
Bu bölümün biraz değiştirilmeye ihtiyacı var. [Katkı yapmayı değerlendirebilirsiniz](#katkı)!
|
||||
|
||||
Güvenlik geniş bir konudur. Eğer önemli bir deneyiminiz yoksa, güvenlik geçmişiniz yoksa veya güvenlik bilgisi gerektiren bir pozisyon için başvuruda bulunmuyorsanız, muhtemelen temel bilgilerden daha fazlasını bilmeye ihtiyaç duymayacaksınız:
|
||||
|
||||
* İletim ve dinlenme sırasında şifreleme kullanın.
|
||||
* [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting) ve [SQL enjeksiyonunu](https://en.wikipedia.org/wiki) önlemek için tüm kullanıcı girdilerini veya kullanıcıya açık parametreleri gizleyin.
|
||||
* SQL enjeksiyonunu önlemek için parametreli sorgular kullanın.
|
||||
* [En az ayrıcalık ilkesi](https://en.wikipedia.org/wiki/Principle_of_least_privilege)ni kullanın.
|
||||
|
||||
### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [API security checklist](https://github.com/shieldfy/API-Security-Checklist)
|
||||
* [Security guide for developers](https://github.com/FallibleInc/security-guide-for-developers)
|
||||
* [OWASP top ten](https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet)
|
||||
|
||||
## Ek
|
||||
|
||||
Bazen sizden geçerli tahminler yapmanız istenecektir. Örneğin, diskten 100 görüntünün küçük resimlerini oluşturmanın ne kadar süreceğini veya bir veri yapısının ne kadar bellek gerektireceğini tahmin etmeniz gerekebilir. **İkinin kuvveti tablosu** ve **Her geliştiricinin bilmesi gereken bazı zaman verileri** bazı kullanışlı referans materyalleridir.
|
||||
|
||||
### İkinin kuvveti tablosu
|
||||
|
||||
```
|
||||
Kuvvet Gerçek değer Yaklaşık değer Bytes
|
||||
---------------------------------------------------------------
|
||||
7 128
|
||||
8 256
|
||||
10 1024 1 thousand 1 KB
|
||||
16 65,536 64 KB
|
||||
20 1,048,576 1 million 1 MB
|
||||
30 1,073,741,824 1 billion 1 GB
|
||||
32 4,294,967,296 4 GB
|
||||
40 1,099,511,627,776 1 trillion 1 TB
|
||||
```
|
||||
|
||||
#### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Powers of two](https://en.wikipedia.org/wiki/Power_of_two)
|
||||
|
||||
### Her programcının bilmesi gereken gecikme sayıları
|
||||
|
||||
```
|
||||
Latency Comparison Numbers
|
||||
--------------------------
|
||||
L1 cache reference 0.5 ns
|
||||
Branch mispredict 5 ns
|
||||
L2 cache reference 7 ns 14x L1 cache
|
||||
Mutex lock/unlock 25 ns
|
||||
Main memory reference 100 ns 20x L2 cache, 200x L1 cache
|
||||
Compress 1K bytes with Zippy 10,000 ns 10 us
|
||||
Send 1 KB bytes over 1 Gbps network 10,000 ns 10 us
|
||||
Read 4 KB randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD
|
||||
Read 1 MB sequentially from memory 250,000 ns 250 us
|
||||
Round trip within same datacenter 500,000 ns 500 us
|
||||
Read 1 MB sequentially from SSD* 1,000,000 ns 1,000 us 1 ms ~1GB/sec SSD, 4X memory
|
||||
Disk seek 10,000,000 ns 10,000 us 10 ms 20x datacenter roundtrip
|
||||
Read 1 MB sequentially from 1 Gbps 10,000,000 ns 10,000 us 10 ms 40x memory, 10X SSD
|
||||
Read 1 MB sequentially from disk 30,000,000 ns 30,000 us 30 ms 120x memory, 30X SSD
|
||||
Send packet CA->Netherlands->CA 150,000,000 ns 150,000 us 150 ms
|
||||
|
||||
Notes
|
||||
-----
|
||||
1 ns = 10^-9 seconds
|
||||
1 us = 10^-6 seconds = 1,000 ns
|
||||
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns
|
||||
```
|
||||
|
||||
Yukarıdaki sayılar temelinde kullanışlı ölçümler:
|
||||
|
||||
* HDD'den sıralı okuma hızı: 30 MB/s
|
||||
* 1 Gbps Ethernet üzerinden sıralı okuma hızı: 100 MB/s
|
||||
* SSD'den sıralı okuma hızı: 1 GB/s
|
||||
* Ana bellekten sıralı okuma hızı: 4 GB/s
|
||||
* Dünya çapında 6-7 tur/saniye arası dolaşımlar
|
||||
* Bir veri merkezi içinde 2,000 tur/saniye dolaşımlar
|
||||
|
||||
#### Gecikme numarası görselleştirmesi
|
||||
|
||||
|
||||
|
||||
#### Kaynak(lar) ve ek okuma
|
||||
|
||||
* [Latency numbers every programmer should know - 1](https://gist.github.com/jboner/2841832)
|
||||
* [Latency numbers every programmer should know - 2](https://gist.github.com/hellerbarde/2843375)
|
||||
* [Designs, lessons, and advice from building large distributed systems](http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf)
|
||||
* [Software Engineering Advice from Building Large-Scale Distributed Systems](https://static.googleusercontent.com/media/research.google.com/en//people/jeff/stanford-295-talk.pdf)
|
||||
|
||||
### Diğer sistem tasarımı mülakat soruları
|
||||
|
||||
> Genel sistem tasarımı mülakat soruları, ve çözümleri
|
||||
|
||||
| Soru | Kaynak(lar) |
|
||||
|------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Dropbox benzeri bir dosya senkronizasyon hizmeti tasarlayın | [youtube.com](https://www.youtube.com/watch?v=PE4gwstWhmc) |
|
||||
| Google benzeri bir arama motoru tasarlayın | [queue.acm.org](http://queue.acm.org/detail.cfm?id=988407)<br/>[stackexchange.com](http://programmers .stackexchange.com/questions/38324/interview-question-how-would-you-implement-google-search)<br/>[ardendertat.com](http://www.ardendertat.com/2012/01/11 /implementing-search-engines/)<br/>[stanford.edu](http://infolab.stanford.edu/~backrub/google.html) |
|
||||
| Google benzeri ölçeklenebilir web tarayıcısı(scalable web crawler) tasarlayın | [quora.com](https://www.quora.com/How-can-I-build-a-web-crawler-from-scratch) |
|
||||
| Google Dokümanlar'ı tasarlama | [code.google.com](https://code.google.com/p/google-mobwrite/)<br/>[neil.fraser.name](https://neil.fraser. ad/yazma/senkronizasyon/) |
|
||||
| Redis benzeri anahtar-değer(key-value) deposu tasarlayın | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
|
||||
| Memcached'e benzer önbellekleme sistemi tasarlayın | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
|
||||
| Amazon'a benzer öneri sistemi tasarlayın | [hulu.com](http://tech.hulu.com/blog/2011/09/19/recommendation-system.html)<br/>[ijcai13.org](http : //ijcai13.org/files/tutorial_slides/td3.pdf) |
|
||||
| Bitly'ye benzer kısa bağlantı sistemi tasarlayın | [n00tc0d3r.blogspot.com](http://n00tc0d3r.blogspot.com/) |
|
||||
| WhatsApp gibi sohbet uygulaması tasarlayın | [highscalability.com](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) |
|
||||
| Instagram'a benzer fotoğraf paylaşım sistemi tasarlayın | [highscalability.com](http://highscalability.com/flickr-architecture)<br/>[highscalability.com](http://highscalability.com/blog/2011/ 12 /6/instagram-architecture-14-million-users-terabytes-of-photos.html) |
|
||||
| Facebook'un haber öneri yöntemini tasarlama | [quora.com](http://www.quora.com/What-are-best-practices-for-building-something-like-a-News-Feed)<br/> [ quora.com](http://www.quora.com/Activity-Streams/What-are-the-scaling-issues-to-keep-in-mind-while-developing-a-social-network-feed) < br/>[slideshare.net](http://www.slideshare.net/danmckinley/etsy-activity-feeds-architecture) |
|
||||
| Facebook'un zaman çizelgesi sistemini tasarlama | [facebook.com](https://www.facebook.com/note.php?note_id=10150468255628920)<br/>[highscalability.com](http://highscalability.com/ blog/ 2012/1/23/facebook-zaman çizelgesi-denormaliza.html'nin-gücüyle-size-getirildi) |
|
||||
| Facebook'un sohbet sistemini tasarlayın | [erlang-factory.com](http://www.erlang-factory.com/upload/sunumlar/31/EugeneLetuchy-ErlangatFacebook.pdf)<br/>[facebook.com](https : //www.facebook.com/note.php?note_id=14218138919&id=9445547199&index=0) |
|
||||
| Facebook benzeri grafik arama sistemi tasarlayın | [facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-building-out-the-infrastructure-for-graph- arama /10151347573598920)<br/>[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-indexing-and-ranking-in-graph-search/10151361720763920) < br/>[facebook.com](https://www.facebook.com/notes/facebook-engineering/under-the-hood-the-natural-language-interface-of-graph-search/10151432733048920) |
|
||||
| CloudFlare gibi içerik dağıtım ağı tasarlama | [cmu.edu](http://repository.cmu.edu/cgi/viewcontent.cgi?article=2112&context=compsci) |
|
||||
| Twitter'a benzer trend konu sistemi tasarlama | [michael-noll.com](http://www.michael-noll.com/blog/2013/01/18/implementing-real-time-trending-topics-in- fırtına /)<br/>[snikolov .wordpress.com](http://snikolov.wordpress.com/2012/11/14/early-detection-of-twitter-trends/) |
|
||||
| Rastgele bir kimlik oluşturma sistemi tasarlayın | [blog.twitter.com](https://blog.twitter.com/2010/announcing-snowflake)<br/>[github.com](https://github.com/ twitter/kar tanesi/) |
|
||||
| Belirli bir süre içinde en sık yapılan k isteklerini döndürün | [ucsb.edu](https://icmi.cs.ucsb.edu/research/tech_reports/reports/2005-23.pdf)<br/>[wpi. edu](http://davis.wpi.edu/xmdv/docs/EDBT11-diyang.pdf) |
|
||||
| Birden çok veri merkezinden gelen verilerle bir hizmet sistemi tasarlayın | [highscalability.com](http://highscalability.com/blog/2009/8/24/how-google-serves-data-from-multiple-datacenters.html) |
|
||||
| Çok oyunculu çevrimiçi kart oyunu tasarlayın | [indieflashblog.com](https://web.archive.org/web/20180929181117/http://www.indieflashblog.com/how-to-create-an-asynchronous-multiplayer- game.html)<br/>[buildnewgames.com](http://buildnewgames.com/real-time-multiplayer/) |
|
||||
| Borsa sistemi tasarlayın | [stuffwithstuff.com](http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/)<br/>[washington.edu](http: //courses.cs.washington.edu/courses/csep521/07wi/prj/rick.pdf) |
|
||||
| Daha fazla sistem tasarımı sorunu ekleyin<br/> | [katkı](#katkı) |
|
||||
|
||||
### Gerçek dünya mimarileri
|
||||
|
||||
> Sistemlerin gerçekte nasıl tasarlandığına dair makaleler.
|
||||
|
||||
<p align="center">
|
||||
<img src="images/TcUo2fw.png">
|
||||
<br/>
|
||||
<i><a href=https://www.infoq.com/presentations/Twitter-Timeline-Scalability>Kaynak: Twitter timelines at scale</a></i>
|
||||
</p>
|
||||
|
||||
**Aşağıdaki makalenin ayrıntılarına odaklanmayın, onun yerine bunlara odaklanın:**
|
||||
|
||||
* Bu makalelerdeki ortak ilkeleri, teknikleri ve kalıpları keşfedin
|
||||
* Her bileşenin hangi sorunları çözdüğünü, ne zaman kullanılacağını ve ne zaman kullanılamayacağını öğrenin
|
||||
* Öğrendiklerinizi tekrar gözden geçirin
|
||||
|
||||
| Tür | Sistem | Referans(lar) |
|
||||
|---------------|------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Veri işleme | **MapReduce** - Google'da dağıtık veri işleme | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/mapreduce-osdi04.pdf) |
|
||||
| Veri işleme | **Spark** - Databricks'te dağıtık veri işleme | [slideshare.net](http://www.slideshare.net/AGrishchenko/apache-spark-architecture) |
|
||||
| Veri işleme | **Storm** - Twitter'da dağıtık veri işleme | [slideshare.net](http://www.slideshare.net/previa/storm-16094009) |
|
||||
| | | |
|
||||
| Veri deposu | **Bigtable** - Google'da dağıtık sütun-tabanlı(column-oriented) veritabanı | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/chang06bigtable.pdf) |
|
||||
| Veri deposu | **HBase** - Bigtable'ın açık kaynak kodu | [slideshare.net](http://www.slideshare.net/alexbaranau/intro-to-hbase) |
|
||||
| Veri deposu | **Cassandra** - Facebook'ta dağıtık sütun-tabanlı(column-oriented) veritabanı | [slideshare.net](http://www.slideshare.net/planetcassandra/cassandra-introduction-features-30103666) |
|
||||
| Veri deposu | **DynamoDB** - Amazon'da doküman-tabanlı(document-oriented) veritabanı | [harvard.edu](http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decandia07dynamo.pdf) |
|
||||
| Veri deposu | **MongoDB** - Doküman-tabanlı(document-oriented) veritabanı | [slideshare.net](http://www.slideshare.net/mdirolf/introduction-to-mongodb) |
|
||||
| Veri deposu | **Spanner** - Google'da küresel(globally-distributed) dağıtılmış veritabanı | [research.google.com](http://research.google.com/archive/spanner-osdi2012.pdf) |
|
||||
| Veri deposu | **Memcached** - Dağıtık bellek önbellek sistemi | [slideshare.net](http://www.slideshare.net/oemebamo/introduction-to-memcached) |
|
||||
| Veri deposu | **Redis** - Kalıcılık ve değer türleri ile dağıtık önbellekleme(distributed caching) sistemi | [slideshare.net](http://www.slideshare.net/dvirsky/introduction-to-redis) |
|
||||
| | | |
|
||||
| Dosya sistemi | **Google File System (GFS)** - Dağıtık dosya sistemi | [research.google.com](http://static.googleusercontent.com/media/research.google.com/zh-CN/us/archive/gfs-sosp2003.pdf) |
|
||||
| Dosya sistemi | **Hadoop File System (HDFS)** - GFS'in açık kaynak kodu | [apache.org](https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html) |
|
||||
| | | |
|
||||
| Diğer | **Chubby** - Google'dan gevşek bağlı dağıtık sistemler için kilit hizmeti | [research.google.com](http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en/us/archive/chubby-osdi06.pdf) |
|
||||
| Diğer | **Dapper** - Dağıtık sistemler izleme altyapısı | [research.google.com](http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36356.pdf) |
|
||||
| Diğer | **Kafka** - LinkedIn'de yayın/abone mesaj kuyruğu | [slideshare.net](http://www.slideshare.net/mumrah/kafka-talk-tri-hug) |
|
||||
| Diğer | **Zookeeper** - Senkronizasyonu sağlayan merkezi altyapı ve hizmetler | [slideshare.net](http://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper) |
|
||||
| | Daha fazla yazılım mimari örneği ekleyin | [katkı](#katkı) |
|
||||
|
||||
### Şirketlerin sistem mimarileri
|
||||
|
||||
| Şirket | Referans(lar) |
|
||||
|----------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Amazon | [Amazon architecture](http://highscalability.com/amazon-architecture) |
|
||||
| Cinchcast | [Producing 1,500 hours of audio every day](http://highscalability.com/blog/2012/7/16/cinchcast-architecture-producing-1500-hours-of-audio-every-d.html) |
|
||||
| DataSift | [Realtime datamining At 120,000 tweets per second](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html) |
|
||||
| Dropbox | [How we've scaled Dropbox](https://www.youtube.com/watch?v=PE4gwstWhmc) |
|
||||
| ESPN | [Operating At 100,000 duh nuh nuhs per second](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html) |
|
||||
| Google | [Google architecture](http://highscalability.com/google-architecture) |
|
||||
| Instagram | [14 million users, terabytes of photos](http://highscalability.com/blog/2011/12/6/instagram-architecture-14-million-users-terabytes-of-photos.html)<br/>[What powers Instagram](http://instagram-engineering.tumblr.com/post/13649370142/what-powers-instagram-hundreds-of-instances) |
|
||||
| Justin.tv | [Justin.Tv's live video broadcasting architecture](http://highscalability.com/blog/2010/3/16/justintvs-live-video-broadcasting-architecture.html) |
|
||||
| Facebook | [Scaling memcached at Facebook](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/key-value/fb-memcached-nsdi-2013.pdf)<br/>[TAO: Facebook’s distributed data store for the social graph](https://cs.uwaterloo.ca/~brecht/courses/854-Emerging-2014/readings/data-store/tao-facebook-distributed-datastore-atc-2013.pdf)<br/>[Facebook’s photo storage](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Beaver.pdf)<br/>[How Facebook Live Streams To 800,000 Simultaneous Viewers](http://highscalability.com/blog/2016/6/27/how-facebook-live-streams-to-800000-simultaneous-viewers.html) |
|
||||
| Flickr | [Flickr architecture](http://highscalability.com/flickr-architecture) |
|
||||
| Mailbox | [From 0 to one million users in 6 weeks](http://highscalability.com/blog/2013/6/18/scaling-mailbox-from-0-to-one-million-users-in-6-weeks-and-1.html) |
|
||||
| Netflix | [A 360 Degree View Of The Entire Netflix Stack](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)<br/>[Netflix: What Happens When You Press Play?](http://highscalability.com/blog/2017/12/11/netflix-what-happens-when-you-press-play.html) |
|
||||
| Pinterest | [From 0 To 10s of billions of page views a month](http://highscalability.com/blog/2013/4/15/scaling-pinterest-from-0-to-10s-of-billions-of-page-views-a.html)<br/>[18 million visitors, 10x growth, 12 employees](http://highscalability.com/blog/2012/5/21/pinterest-architecture-update-18-million-visitors-10x-growth.html) |
|
||||
| Playfish | [50 million monthly users and growing](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) |
|
||||
| PlentyOfFish | [PlentyOfFish architecture](http://highscalability.com/plentyoffish-architecture) |
|
||||
| Salesforce | [How they handle 1.3 billion transactions a day](http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html) |
|
||||
| Stack Overflow | [Stack Overflow architecture](http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html) |
|
||||
| TripAdvisor | [40M visitors, 200M dynamic page views, 30TB data](http://highscalability.com/blog/2011/6/27/tripadvisor-architecture-40m-visitors-200m-dynamic-page-view.html) |
|
||||
| Tumblr | [15 billion page views a month](http://highscalability.com/blog/2012/2/13/tumblr-architecture-15-billion-page-views-a-month-and-harder.html) |
|
||||
| Twitter | [Making Twitter 10000 percent faster](http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster)<br/>[Storing 250 million tweets a day using MySQL](http://highscalability.com/blog/2011/12/19/how-twitter-stores-250-million-tweets-a-day-using-mysql.html)<br/>[150M active users, 300K QPS, a 22 MB/S firehose](http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html)<br/>[Timelines at scale](https://www.infoq.com/presentations/Twitter-Timeline-Scalability)<br/>[Big and small data at Twitter](https://www.youtube.com/watch?v=5cKTP36HVgI)<br/>[Operations at Twitter: scaling beyond 100 million users](https://www.youtube.com/watch?v=z8LU0Cj6BOU)<br/>[How Twitter Handles 3,000 Images Per Second](http://highscalability.com/blog/2016/4/20/how-twitter-handles-3000-images-per-second.html) |
|
||||
| Uber | [How Uber scales their real-time market platform](http://highscalability.com/blog/2015/9/14/how-uber-scales-their-real-time-market-platform.html)<br/>[Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories](http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html) |
|
||||
| WhatsApp | [The WhatsApp architecture Facebook bought for $19 billion](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html) |
|
||||
| YouTube | [YouTube scalability](https://www.youtube.com/watch?v=w5WVu624fY8)<br/>[YouTube architecture](http://highscalability.com/youtube-architecture) |
|
||||
|
||||
### Şirketlerin mühendislik blogları
|
||||
|
||||
> Mülakat yaptığınız şirketlerin yazılım mimarileri.
|
||||
>
|
||||
> Mülakatta karşılaşacağınız sorular, şirketlerin çalışma alanından gelebilir.
|
||||
|
||||
* [Airbnb Engineering](http://nerds.airbnb.com/)
|
||||
* [Atlassian Developers](https://developer.atlassian.com/blog/)
|
||||
* [AWS Blog](https://aws.amazon.com/blogs/aws/)
|
||||
* [Bitly Engineering Blog](http://word.bitly.com/)
|
||||
* [Box Blogs](https://blog.box.com/blog/category/engineering)
|
||||
* [Cloudera Developer Blog](http://blog.cloudera.com/)
|
||||
* [Dropbox Tech Blog](https://tech.dropbox.com/)
|
||||
* [Engineering at Quora](https://www.quora.com/q/quoraengineering)
|
||||
* [Ebay Tech Blog](http://www.ebaytechblog.com/)
|
||||
* [Evernote Tech Blog](https://blog.evernote.com/tech/)
|
||||
* [Etsy Code as Craft](http://codeascraft.com/)
|
||||
* [Facebook Engineering](https://www.facebook.com/Engineering)
|
||||
* [Flickr Code](http://code.flickr.net/)
|
||||
* [Foursquare Engineering Blog](http://engineering.foursquare.com/)
|
||||
* [GitHub Engineering Blog](https://github.blog/category/engineering)
|
||||
* [Google Research Blog](http://googleresearch.blogspot.com/)
|
||||
* [Groupon Engineering Blog](https://engineering.groupon.com/)
|
||||
* [Heroku Engineering Blog](https://engineering.heroku.com/)
|
||||
* [Hubspot Engineering Blog](http://product.hubspot.com/blog/topic/engineering)
|
||||
* [High Scalability](http://highscalability.com/)
|
||||
* [Instagram Engineering](http://instagram-engineering.tumblr.com/)
|
||||
* [Intel Software Blog](https://software.intel.com/en-us/blogs/)
|
||||
* [Jane Street Tech Blog](https://blogs.janestreet.com/category/ocaml/)
|
||||
* [LinkedIn Engineering](http://engineering.linkedin.com/blog)
|
||||
* [Microsoft Engineering](https://engineering.microsoft.com/)
|
||||
* [Microsoft Python Engineering](https://blogs.msdn.microsoft.com/pythonengineering/)
|
||||
* [Netflix Tech Blog](http://techblog.netflix.com/)
|
||||
* [Paypal Developer Blog](https://medium.com/paypal-engineering)
|
||||
* [Pinterest Engineering Blog](https://medium.com/@Pinterest_Engineering)
|
||||
* [Reddit Blog](http://www.redditblog.com/)
|
||||
* [Salesforce Engineering Blog](https://developer.salesforce.com/blogs/engineering/)
|
||||
* [Slack Engineering Blog](https://slack.engineering/)
|
||||
* [Spotify Labs](https://labs.spotify.com/)
|
||||
* [Twilio Engineering Blog](http://www.twilio.com/engineering)
|
||||
* [Twitter Engineering](https://blog.twitter.com/engineering/)
|
||||
* [Uber Engineering Blog](http://eng.uber.com/)
|
||||
* [Yahoo Engineering Blog](http://yahooeng.tumblr.com/)
|
||||
* [Yelp Engineering Blog](http://engineeringblog.yelp.com/)
|
||||
* [Zynga Engineering Blog](https://www.zynga.com/blogs/engineering)
|
||||
|
||||
#### Kaynak(lar) ve ek okuma
|
||||
|
||||
Bir blog eklemek mi istiyorsunuz? Şirket blogunuzu aşağıdaki repoya eklemeyi düşünebilirsiniz:
|
||||
|
||||
* [kilimchoi/engineering-blogs](https://github.com/kilimchoi/engineering-blogs)
|
||||
|
||||
## Geliştirme aşamasında
|
||||
|
||||
Bazı başlıklar eklemek veya bazı başlıkların iyileştirilmesine yardımcı olmak mı istiyorsunuz? [Katkıda bulunun](#katkı)!
|
||||
|
||||
* Distributed computing with MapReduce
|
||||
* Tutarlı hashing (Consistent hashing)
|
||||
* Scatter gather
|
||||
* [Katkıda bulunun](#katkı)
|
||||
|
||||
## Katkıda bulunanlar
|
||||
|
||||
Bu repo, katkıda bulunanlar ve kaynakların desteğiyle oluşmuştur.
|
||||
|
||||
Bu sayfalara ayrıca teşekkürler:
|
||||
|
||||
* [Hired in tech](http://www.hiredintech.com/system-design/the-system-design-process/)
|
||||
* [Cracking the coding interview](https://www.amazon.com/dp/0984782850/)
|
||||
* [High scalability](http://highscalability.com/)
|
||||
* [checkcheckzz/system-design-interview](https://github.com/checkcheckzz/system-design-interview)
|
||||
* [shashank88/system_design](https://github.com/shashank88/system_design)
|
||||
* [mmcgrana/services-engineering](https://github.com/mmcgrana/services-engineering)
|
||||
* [System design cheat sheet](https://gist.github.com/vasanthk/485d1c25737e8e72759f)
|
||||
* [A distributed systems reading list](http://dancres.github.io/Pages/)
|
||||
* [Cracking the system design interview](http://www.puncsky.com/blog/2016-02-13-crack-the-system-design-interview)
|
||||
|
||||
## İletişim
|
||||
|
||||
Bu makaleyle ilgili eksiklikleri, soruları veya yorumlarınızı tartışmak için benimle iletişime geçmekten çekinmeyin.
|
||||
|
||||
İletişim bilgilerimi [GitHub ana sayfamda](https://github.com/donnemartin) bulabilirsiniz.
|
||||
|
||||
## Lisans
|
||||
|
||||
*Bu repodaki kodları ve kaynakları sizlere açık kaynak lisansı altında sağlıyorum. Burası benim kişisel arşivim olduğu için, koduma ve kaynaklarıma ilişkin aldığınız lisans, işverenimden (Facebook) değil; benim tarafımdan sağlanmaktadır.*
|
||||
|
||||
> Copyright 2017 Donne Martin
|
||||
>
|
||||
> Creative Commons Attribution 4.0 International License (CC BY 4.0)
|
||||
>
|
||||
> http://creativecommons.org/licenses/by/4.0/
|
||||
Loading…
Reference in New Issue