Ders 02 / 15
Merkezî ve Dağıtık Modeller
Tarihçenin tek sunucuda ya da her kopyada tutulmasının tasarım sonuçları; sürüm kimliğinin artan sayı yerine içerik karmasıyla üretilmesinin gerekçesi.
İçindekiler
Önceki ders tarihçeyi bir yönlü çevrimsiz çizge olarak tanımladı ama bu çizgenin nerede durduğunu söylemedi. Tek bir sunucuda mı tutulur, yoksa her katılımcının makinesinde eksiksiz bir kopyası mı bulunur? Bu soru bir uygulama ayrıntısı değildir: yanıt, sistemin hangi işlemleri ağ bağlantısı olmadan yapabileceğini, sürüm kimliklerinin nasıl üretileceğini ve bir arıza anında neyin kaybolacağını belirler.
Merkezî Model
Merkezî sürüm kontrolünde (centralized version control) tarihçenin tek bir yetkili kopyası vardır ve bir sunucuda durur. Katılımcıların makinesinde yalnızca çalışma kopyası bulunur: dosyaların belirli bir sürümdeki hâli, artı hangi sürümden alındığını söyleyen küçük bir kayıt. Tarihçenin kendisi yerelde yoktur.
Bu düzende her işlem sunucuya gider:
- Yeni bir işleme yazmak sunucuya bağlanmayı gerektirir.
- Geçmiş bir sürümü görmek için sunucudan istenir.
- İki sürüm arasındaki fark sunucuda hesaplanır ya da eksik veri sunucudan çekilir.
Karşılığında elde edilen şey basit bir doğruluk kaynağıdır. “Projenin şu anki hâli” sorusunun tek bir yanıtı vardır ve o yanıt sunucudadır. Erişim denetimi de tek noktada uygulanır: belirli dizinlere yazma yetkisi sunucu tarafından sınırlanabilir.
Dağıtık Model
Dağıtık sürüm kontrolünde (distributed version control) her kopya eksiksizdir. Bir depo alındığında yalnızca son sürüm değil, tarihçenin tamamı — tüm işlemeler, tüm anlık görüntüler — yerel makineye yazılır. Katılımcının elinde çalışma kopyası değil, tam bir depo (repository) vardır.
Sonuç, işlem kümesinin ikiye ayrılmasıdır:
| İşlem | Merkezî | Dağıtık |
|---|---|---|
| İşleme yazmak | Sunucu gerekir | Yerelde yapılır |
| Tarihçeyi listelemek | Sunucu gerekir | Yerelde yapılır |
| İki sürümün farkını almak | Sunucu gerekir | Yerelde yapılır |
| Geçmiş bir sürüme dönmek | Sunucu gerekir | Yerelde yapılır |
| Başkasının işini almak | Sunucu gerekir | Ağ gerekir |
| Kendi işini paylaşmak | Sunucu gerekir | Ağ gerekir |
Ağ yalnızca son iki satırda gereklidir. Bu ayrım, bu kursun bütün derslerinin ağ bağlantısı olmadan yapılabilmesinin nedenidir: kurs boyunca kurulacak depo yerelde kalacak ve tek başına işlevsel olacaktır. Uzak depo (remote) kavramı Dallanma ve İşbirliği kursunun konusudur.
Kimlik Sorunu
İki modelin en öğretici farkı, bir sürümün nasıl adlandırıldığındadır.
Merkezî modelde sunucu tek yetkilidir; sürümleri artan bir sayıyla numaralandırabilir. Sürüm 7’den sonra sürüm 8 gelir ve bu sayıyı kimin vereceği tartışmasızdır. Sayı hem kimlik hem de sıra bilgisi taşır: 8, 7’den sonradır.
Dağıtık modelde böyle bir yetkili yoktur. İki kişi birbirinden habersiz olarak aynı öncülün üzerine birer işleme yazarsa, ikisi de “sıradaki sayı” olarak aynı değeri seçerdi. Sonuçta aynı kimliği taşıyan iki farklı işleme oluşur ve tarihçe tutarsızlaşır. Artan sayı, merkezî bir sayaç gerektirir.
Çözüm, kimliği dış bir sayaçtan değil, içeriğin kendisinden türetmektir. Bir işlemenin kimliği, işlemenin bütün bileşenleri — anlık görüntüsü, öncülünün kimliği, yazarı, zamanı, mesajı — üzerinden hesaplanan bir karma değeridir. Bu seçimin üç sonucu vardır:
- Kimlik üretimi eşgüdüm gerektirmez. Herkes kendi işlemesinin kimliğini yerelde hesaplar; çakışma olasılığı karma fonksiyonunun çakışma direncine indirgenir.
- Kimlik, içeriğin bütünlük denetimidir. Bir işlemenin herhangi bir baytı değişirse kimliği de değişir. Depodaki bir bozulma sessiz kalmaz.
- Kimlik sıra bilgisi taşımaz. Bir karma değeri, başka bir karma değerinden “sonra” değildir. Sıra yalnızca öncül bağlarından, yani çizgenin kendisinden okunur.
Üçüncü sonuç, önceki dersteki topolojik sıra tartışmasını gerekli kılan şeydir: tarihçeyi sıralamak, kimlikleri karşılaştırmakla değil, çizgeyi gezerek yapılır.
Kimliğin içerikten türetilmesi bir noktayı daha kesinleştirir: öncülün kimliği hesaba girdiğine göre, geçmişteki bir işlemenin değiştirilmesi ondan sonraki bütün işlemelerin kimliğini değiştirir. Tarihçe, ucundan geriye doğru birbirine mühürlenmiştir. Üçüncü konudaki “işlemeyi değiştirme” ve “sıfırlama” derslerinde bu mühürlemenin sonuçları görülecektir.
Karma Fonksiyonundan Beklenen
Kimliğin içerikten türetilmesi, kullanılan karma fonksiyonuna belirli bir yük bindirir. Veri Yapıları kursunda karma fonksiyonları sözlük yapılarının dağılım aracı olarak incelenmişti; orada çakışma bir başarım sorunuydu, çözümü de zincirleme ya da açık adreslemeydi. Burada çakışmanın çözümü yoktur: iki farklı içerik aynı kimliği üretirse depo, birini diğerinin yerine koyabilir.
Bu nedenle beklenen özellik dağılım değil, çakışma direncidir: farklı iki içerik bulup aynı kimliği üretmenin hesaplama açısından yapılabilir olmaması. Sıradan sağlama toplamları bu özelliği taşımaz; kriptografik karma fonksiyonları taşımak üzere tasarlanır.
Özelliğin zamana bağlı olduğuna dikkat edilmelidir: bir karma fonksiyonuna karşı çakışma üretme yöntemi bulunduğunda, o fonksiyona dayanan depoların daha güçlü bir fonksiyona geçirilmesi gerekir. Depo biçiminin sürüm alanı taşıması ve nesne kimliği uzunluğunun biçime bağlı olması, tam olarak bu geçişi mümkün kılmak içindir. Bu kursta gösterilen kimlikler kırk onaltılık karakterden oluşur; başka bir karma fonksiyonu kullanan bir depoda uzunluk farklıdır, model aynıdır.
Yedeklilik ve Arıza
Merkezî modelde sunucu tek hata noktasıdır. Sunucu erişilemezse yazma işlemleri durur; sunucudaki veri kaybolursa ve yedeği yoksa tarihçe kaybolur. Çalışma kopyalarında yalnızca son sürüm bulunduğu için geçmiş geri getirilemez.
Dağıtık modelde her kopya tam bir yedektir. Merkezî bir sunucu kullanılıyor olsa bile — ki uygulamada çoğunlukla kullanılır — o sunucu bir eşgüdüm noktasıdır, tek nüsha değildir. Tarihçenin kaybolması için bütün kopyaların kaybolması gerekir.
Buna karşılık dağıtık model iki bedel getirir:
- Depolama. Her katılımcı tarihçenin tamamını tutar. Uzun ömürlü ve büyük dosyalar içeren projelerde bu maliyet belirginleşir; tarihçeye giren büyük bir ikili dosya, sonradan silinse bile bütün kopyalarda kalır.
- Erişim denetimi. Tarihçenin tamamı her kopyada bulunduğuna göre, “bu dizini yalnızca belirli kişiler görsün” kısıtı depo düzeyinde uygulanamaz. Denetim, paylaşımın yapıldığı noktaya taşınır.
İkinci maddenin pratik sonucu, gizli bilgilerin bir depoya hiçbir zaman girmemesi gerektiğidir. Bir parola işlendikten sonra silinse bile tarihçede durmaya devam eder ve deponun her kopyasına yayılmıştır. Yoksayma kuralları dersi bu konuyu yeniden ele alacaktır.
Model Seçimi Neyi Belirler
İki model arasındaki seçim, aracın hangi işlemleri ucuz kıldığını belirler. Dağıtık modelde işleme yazmak ağ gerektirmediği için ucuzdur; ucuz olduğu için sık yapılır; sık yapıldığı için her işleme küçük ve tek amaçlı olabilir. Bir sonraki konuda anlatılacak “atomik işleme” alışkanlığı, doğrudan bu maliyet yapısının sonucudur.
Aynı biçimde, tarihçenin tamamı yerelde bulunduğu için geçmişi sorgulamak ucuzdur. Bir satırın hangi işlemede değiştiğini bulmak ağ gecikmesi içermez; bu da geçmişe bakmayı sıradan bir okuma alışkanlığı hâline getirir.
Özet
- Merkezî modelde tarihçe tek sunucuda tutulur; katılımcıların elinde yalnızca çalışma kopyası bulunur.
- Dağıtık modelde her kopya tarihçenin tamamını içerir; ağ yalnızca paylaşım için gereklidir.
- Merkezî model artan sayıyla sürüm numarası verebilir; dağıtık modelde bunun için merkezî bir sayaç yoktur.
- Bu nedenle dağıtık sistemler kimliği içerikten türetir; kimlik aynı zamanda bütünlük denetimi sağlar ama sıra bilgisi taşımaz.
- Dağıtık modelin bedelleri depolama ve depo düzeyinde erişim denetiminin uygulanamamasıdır.
Sonraki Adım
Modelin sözcük dağarcığı tamamlandı. Sıradaki adım, bu modelin somut karşılığını kurmaktır:
boş bir dizini depoya dönüştürmek, oluşan .git dizininin içinde ne bulunduğunu görmek ve
yazarın kimliğini hangi yapılandırma katmanının belirlediğini anlamak. Sonraki ders kursun
örnek deposunu sıfırdan oluşturacak.
İlerlemeni kaydetmek ve not almak için Giriş yap
Notlarım
Not almak için giriş yapmalısın.