Bir sonraki HighLoad++ konferansı 6 ve 7 Nisan 2020'de St. Petersburg'da gerçekleştirilecek.
Ayrıntılar ve biletler . HighLoad++ Sibirya 2019. Salon "Krasnoyarsk". 25 Haziran 12:00. Tezler ve .
Ticari bir ürün için önemli olan hususların dikkate alınmadığı durumlarda, pratik gerekliliklerin teoriyle çeliştiği görülür. Bu konuşma, ticari bir ürünün gereksinimlerine dayanan akademik araştırmaya dayalı Nedensel tutarlılık bileşenleri oluşturmaya yönelik farklı yaklaşımların seçilmesi ve birleştirilmesi için bir süreç sunmaktadır. Dinleyiciler mantıksal saatlere, bağımlılık takibine, sistem güvenliğine, saat senkronizasyonuna yönelik mevcut teorik yaklaşımları ve MongoDB'nin neden belirli çözümlere karar verdiğini öğrenecekler.
Mikhail Tyulenev (bundan sonra MT olarak anılacaktır): – Nedensel tutarlılıktan bahsedeceğim – bu MongoDB'de üzerinde çalıştığımız bir özellik. Bir grup dağıtılmış sistemde çalışıyorum, bunu yaklaşık iki yıl önce yaptık.
Bu süreçte pek çok akademik araştırmaya alışmam gerekti çünkü bu özellik oldukça iyi çalışıldı. Muhtemelen herhangi bir üretim uygulamasında mevcut olan çok özel gereksinimler nedeniyle, tek bir makalenin bir üretim veritabanında gerekli olanlara uymadığı ortaya çıktı.
Akademik Araştırma tüketicileri olarak bundan nasıl bir şeyler hazırladığımızı, daha sonra kullanıcılarımıza kullanımı kolay ve güvenli bir hazır yemek olarak sunabileceğimizi anlatacağım.
Nedensel tutarlılık. Kavramları tanımlayalım
Başlangıç olarak nedensel tutarlılığın ne olduğunu genel hatlarıyla söylemek istiyorum. İki karakter var - Leonard ve Penny ("The Big Bang Theory" dizisi):
Diyelim ki Penny Avrupa'da ve Leonard ona sürpriz bir parti düzenlemek istiyor. Ve onu arkadaş listesinden atıp tüm arkadaşlarına bir güncelleme göndermekten daha iyi bir şey düşünemiyor: "Hadi Penny'yi mutlu edelim!" (Avrupa'da, uyurken tüm bunları görmüyor ve göremiyor çünkü orada değil). Sonunda bu gönderiyi siler, Akıştan siler ve hiçbir şeyi fark etmemesi ve skandal olmaması için erişimi geri yükler.
Bunların hepsi iyi hoş ama sistemin dağıtık olduğunu ve işlerin biraz ters gittiğini varsayalım. Örneğin, eğer olaylar sebep-sonuç ilişkisine sahip değilse, Penny'nin erişim kısıtlaması bu gönderi ortaya çıktıktan sonra meydana gelmiş olabilir. Aslında bu, bir iş fonksiyonunu gerçekleştirmek için Nedensel tutarlılığın gerekli olduğu duruma bir örnektir (bu durumda).
Aslında bunlar veritabanının oldukça önemsiz özellikleridir - çok az kişi bunları destekler. Modellere geçelim.
Tutarlılık Modelleri
Veritabanlarında tutarlılık modeli tam olarak nedir? Bunlar, dağıtılmış bir sistemin, müşterinin hangi verileri hangi sırayla alabileceği konusunda verdiği garantilerden bazılarıdır.
Prensip olarak tüm tutarlılık modelleri, dağıtılmış bir sistemin, örneğin bir dizüstü bilgisayardaki bir düğümde çalışan bir sisteme ne kadar benzediğine dayanır. Ve coğrafi olarak dağıtılmış binlerce "Düğüm" üzerinde çalışan bir sistem, prensipte tüm bu özelliklerin otomatik olarak gerçekleştirildiği bir dizüstü bilgisayara ne kadar benzer.
Bu nedenle tutarlılık modelleri yalnızca dağıtık sistemlere uygulanır. Daha önce var olan ve aynı dikey ölçeklendirmede çalışan sistemlerin hiçbirinde bu tür sorunlar yaşanmadı. Bir adet Ara Bellek Önbelleği vardı ve her şey her zaman ondan okunuyordu.
Güçlü Model
Aslında ilk model Güçlü'dür (veya sıklıkla adlandırıldığı gibi yükselme yeteneği çizgisi). Bu, gerçekleştiği onaylandıktan sonra her değişikliğin sistemin tüm kullanıcıları tarafından görülebilmesini sağlayan bir tutarlılık modelidir.
Bu, veritabanındaki tüm olayların küresel bir sırasını oluşturur. Bu çok güçlü bir tutarlılık özelliğidir ve genellikle çok pahalıdır. Ancak çok iyi destekleniyor. Çok pahalı ve yavaştır; nadiren kullanılır. Buna yükselme yeteneği denir.
Spanner'da desteklenen, Dış Tutarlılık adı verilen daha güçlü bir özellik daha vardır. Bunun hakkında biraz sonra konuşacağız.
Nedensel
Sıradaki nedensellik, tam da bahsettiğim şey bu. Güçlü ve Nedensel arasında bahsetmeyeceğim birkaç alt düzey daha var, ancak bunların hepsi Nedensel'e indirgeniyor. Bu önemli bir modeldir çünkü tüm modeller arasında en güçlüsüdür, bir ağın veya bölümlerin varlığında en güçlü tutarlılıktır.
Nedensellik aslında olayların neden-sonuç ilişkisiyle birbirine bağlandığı bir durumdur. Çoğunlukla müşterinin bakış açısından haklarınızı okuyun olarak algılanırlar. Müşteri bazı değerleri gözlemlemişse geçmişteki değerleri göremez. Zaten ön ek okumalarını görmeye başlıyor. Hepsi aynı şeye varıyor.
Tutarlılık modeli olarak nedensellik, tüm istemcilerden gelen olayların aynı sırayla gözlemlendiği, sunucudaki olayların kısmi bir sıralamasıdır. Bu durumda Leonard ve Penny.
nihai
Üçüncü model Nihai Tutarlılıktır. Bu kesinlikle tüm dağıtılmış sistemlerin desteklediği şeydir, en mantıklısı olan minimal model. Bunun anlamı şudur: Verilerde bazı değişiklikler yaptığımızda, bir noktada bunlar tutarlı hale gelir.
Böyle bir anda hiçbir şey söylemiyor, aksi takdirde Dış Tutarlılığa dönüşürdü - tamamen farklı bir hikaye olurdu. Bununla birlikte, bu çok popüler bir modeldir ve en yaygın olanıdır. Varsayılan olarak, dağıtılmış sistemlerin tüm kullanıcıları Nihai Tutarlılığı kullanır.
Karşılaştırmalı birkaç örnek vermek istiyorum:
Bu oklar ne anlama geliyor?
- gecikme. Tutarlılık gücü arttıkça, bariz nedenlerden dolayı büyür: Daha fazla kayıt yapmanız, kümeye katılan tüm ana bilgisayarlardan ve düğümlerden verilerin zaten orada olduğuna dair onay almanız gerekir. Buna göre Nihai Tutarlılık en hızlı cevaba sahiptir, çünkü orada kural olarak bunu hafızaya bile kaydedebilirsiniz ve bu prensipte yeterli olacaktır.
- Kullanılabilirlik. Bunu sistemin ağ kesintileri, bölünmeler veya bir tür arıza durumunda yanıt verme yeteneği olarak anlarsak, tutarlılık modeli azaldıkça hata toleransı artar, çünkü bir ana bilgisayarın aynı anda yaşaması bizim için yeterlidir. zaman bazı veriler üretir. Nihai Tutarlılık verilerle ilgili hiçbir şeyi garanti etmez; her şey olabilir.
- Anomaliler. Aynı zamanda elbette anormalliklerin sayısı da artıyor. Güçlü Tutarlılıkta bunların neredeyse hiç var olmaması gerekir, ancak Nihai Tutarlılıkta her şey olabilirler. Şu soru ortaya çıkıyor: Eğer anormallikler içeriyorsa insanlar neden Nihai Tutarlılığı seçiyor? Cevap, Nihai Tutarlılık modellerinin uygulanabilir olduğu ve anormalliklerin örneğin kısa bir süre içinde ortaya çıktığıdır; tutarlı verileri okumak ve az çok okumak için sihirbazı kullanmak mümkündür; Güçlü tutarlılık modellerini kullanmak çoğu zaman mümkündür. Pratikte bu işe yarar ve çoğu zaman anormalliklerin sayısı zamanla sınırlıdır.
CAP teoremi
Tutarlılık, kullanılabilirlik kelimelerini gördüğünüzde aklınıza ne geliyor? Bu doğru - CAP teoremi! Şimdi bu efsaneyi ortadan kaldırmak istiyorum... Sorunu ben değilim, harika bir makale, harika bir kitap yazan Martin Kleppmann'ım.
CAP teoremi 2000'li yıllarda Tutarlılık, Kullanılabilirlik, Bölümler: herhangi ikisini alırsanız üçünü seçemezsiniz şeklinde formüle edilmiş bir prensiptir. Bu belli bir prensipti. Birkaç yıl sonra Gilbert ve Lynch tarafından bir teorem olarak kanıtlandı. Daha sonra bu bir mantra olarak kullanılmaya başlandı - sistemler CA, CP, AP vb. şeklinde bölünmeye başlandı.
Bu teorem aslında aşağıdaki durumlar için kanıtlanmıştır... Öncelikle, Erişilebilirlik sıfırdan yüze kadar sürekli bir değer olarak kabul edilmiyordu (0 - sistem “ölüdür”, 100 - hızlı yanıt verir; biz bunu böyle düşünmeye alışkınız) , ancak algoritmanın bir özelliği olarak, tüm yürütmeleri için veri döndürmesini garanti eder.
Tepki süresiyle ilgili tek bir kelime bile yok! 100 yıl sonra veri döndüren bir algoritma var; CAP teoreminin bir parçası olan kesinlikle harika bir algoritma.
İkincisi: Teorem, bu değişikliklerin yeniden boyutlandırılabilir olmasına rağmen aynı anahtarın değerlerindeki değişiklikler için kanıtlandı. Bu, gerçekte pratikte kullanılmadıkları anlamına gelir, çünkü modeller farklıdır Nihai Tutarlılık, Güçlü Tutarlılık (belki).
Bütün bunlar ne için? Dahası, CAP teoremi tam olarak kanıtlandığı haliyle pratikte uygulanamaz ve nadiren kullanılır. Teorik olarak her şeyi bir şekilde sınırlandırıyor. Sezgisel olarak doğru olan ancak genel olarak kanıtlanmamış belirli bir ilke ortaya çıkıyor.
Nedensel tutarlılık en güçlü modeldir
Şu anda olan şu ki, üç şeyin hepsini elde edebilirsiniz: Bölümleri kullanarak Tutarlılık, Kullanılabilirlik. Özellikle Nedensel tutarlılık, Bölümlerin (ağdaki kesintilerin) varlığında hala çalışan en güçlü tutarlılık modelidir. Bu nedenle bu kadar ilgi gördü ve bu yüzden bu konuyu ele aldık.
Öncelikle uygulama geliştiricilerin işini kolaylaştırır. Özellikle sunucudan büyük destek alınması: Bir istemcide meydana gelen tüm kayıtların başka bir istemciye aynı sırayla ulaşmasının garanti edilmesi. İkincisi, bölmelere dayanıklıdır.
MongoDB Dahili Mutfak
Öğle yemeği olduğunu hatırlayarak mutfağa geçiyoruz. Böyle bir veritabanını ilk kez duyanlar için size sistem modelini yani MongoDB'nin ne olduğunu anlatacağım.
MongoDB (bundan sonra "MongoDB" olarak anılacaktır), yatay ölçeklendirmeyi yani parçalamayı destekleyen dağıtılmış bir sistemdir; ve her bir parçanın içinde veri yedekliliğini, yani çoğaltmayı da destekler.
MongoDB'deki parçalama (ilişkisel bir veritabanı değil) otomatik dengeleme gerçekleştirir, yani her belge koleksiyonu (veya ilişkisel veriler açısından "tablo") parçalara bölünür ve sunucu bunları otomatik olarak parçalar arasında taşır.
Bir istemci için istekleri dağıtan Sorgu Yönlendiricisi, üzerinden çalıştığı bir istemcidir. Nerede ve hangi verinin bulunduğunu zaten biliyor ve tüm istekleri doğru parçaya yönlendiriyor.
Bir diğer önemli nokta: MongoDB tek master’dır. Bir Birincil vardır; içerdiği anahtarları destekleyen kayıtları alabilir. Çoklu ana kopya yazma işlemi yapamazsınız.
4.2 sürümünü yayınladık - orada yeni ilginç şeyler ortaya çıktı. Özellikle, Lucene - arama - yani çalıştırılabilir java'yı doğrudan Mongo'ya eklediler ve orada, Elastica'da olduğu gibi Lucene üzerinden arama yapmak mümkün hale geldi.
Ve yeni bir ürün yaptılar - Charts, bu ürün aynı zamanda Atlas'ta da mevcut (Mongo'nun kendi Cloud'u). Ücretsiz Seviyeleri var; bununla oynayabilirsiniz. Grafikleri gerçekten beğendim - veri görselleştirme, çok sezgisel.
Malzemeler Nedensel tutarlılık
Leslie Lampert'in bu konuda yayınlanmış yaklaşık 230 makalesini saydım. Şimdi hafızamdan size bu materyallerden bazı kısımları aktaracağım.
Her şey Leslie Lampert'in 1970'lerde yazdığı bir makaleyle başladı. Gördüğünüz gibi bu konuyla ilgili bazı araştırmalar halen devam ediyor. Şimdi nedensel tutarlılık, dağıtılmış sistemlerin geliştirilmesiyle bağlantılı olarak ilgi görüyor.
Kısıtlamalar
Hangi kısıtlamalar var? Bu aslında temel noktalardan biri çünkü bir üretim sisteminin getirdiği kısıtlamalar, akademik makalelerdeki kısıtlamalardan çok farklı. Genellikle oldukça yapaydırlar.
- Öncelikle "MongoDB" daha önce de söylediğim gibi tek bir master'dır (bu büyük ölçüde basitleştirir).
- Sistemin yaklaşık 10 bin parçayı desteklemesi gerektiğine inanıyoruz. Bu değeri açıkça sınırlayacak mimari kararlar alamayız.
- Bir bulutumuz var, ancak bir kişinin ikili dosyayı indirdiğinde, onu dizüstü bilgisayarında çalıştırdığında ve her şeyin harika çalıştığında hala fırsata sahip olması gerektiğini varsayıyoruz.
- Araştırmanın nadiren varsaydığı bir şeyi varsayıyoruz: dış müşteriler ne isterlerse yapabilirler. MongoDB açık kaynaktır. Buna göre müşteriler o kadar akıllı ve öfkeli olabilirler ki her şeyi kırmak isteyebilirler. Bizans Feilor'larının ortaya çıkabileceğini düşünüyoruz.
- Çevre dışındaki harici istemciler için önemli bir sınırlama vardır: Bu özellik devre dışı bırakılırsa performansta herhangi bir düşüş gözlemlenmemelidir.
- Diğer bir nokta ise genel olarak akademik karşıtıdır: önceki versiyonlarla gelecek versiyonların uyumluluğu. Eski sürücüler yeni güncellemeleri desteklemeli ve veritabanı da eski sürücüleri desteklemelidir.
Genel olarak tüm bunlar kısıtlamalar getirir.
Nedensel tutarlılık bileşenleri
Şimdi bazı bileşenlerden bahsedeceğim. Genel olarak nedensel tutarlılığı düşünürsek blokları seçebiliriz. Belli bir bloğa ait işlerden seçtik: Bağımlılık Takibi, saat seçimi, bu saatlerin birbiriyle nasıl senkronize edilebileceği ve güvenliği nasıl sağladığımız - kısaca bahsedeceklerimin özeti bu:
Tam Bağımlılık Takibi
Neden gerekli? Böylece veri kopyalandığında her kayıt, her veri değişikliğinin hangi değişikliklere bağlı olduğu hakkında bilgi içerir. İlk ve saf değişiklik, bir kayıt içeren her mesajın önceki mesajlarla ilgili bilgileri içermesidir:
Bu örnekte süslü parantez içindeki sayı kayıt numaralarıdır. Hatta bazen değerleri olan bu kayıtlar bütünüyle aktarılır, bazen de bazı versiyonları aktarılır. Sonuç olarak, her değişiklik bir öncekiyle ilgili bilgileri içerir (tabii ki tüm bunları kendi içinde taşır).
Neden bu yaklaşımı (tam izleme) kullanmamaya karar verdik? Açıkçası, çünkü bu yaklaşım pratik değildir: Bir sosyal ağda yapılacak herhangi bir değişiklik, söz konusu sosyal ağda yapılan önceki tüm değişikliklere, örneğin her güncellemede Facebook veya VKontakte'nin aktarılmasına bağlıdır. Bununla birlikte, Tam Bağımlılık Takibi konusunda çok sayıda araştırma var; bunlar sosyal öncesi ağlar; bazı durumlarda gerçekten işe yarıyor.
Açık Bağımlılık Takibi
Bir sonraki daha sınırlıdır. Bilgi aktarımı da burada dikkate alınır, ancak yalnızca açıkça bağımlı olan bilgiler. Kural olarak Uygulama tarafından neyin belirlendiğine bağlıdır. Veriler çoğaltıldığında, sorgu yalnızca önceki bağımlılıklar karşılandığında, yani gösterildiğinde yanıtları döndürür. Nedensel tutarlılığın işleyişinin özü budur.
5 numaralı kaydın 1, 2, 3, 4 numaralı kayıtlara bağlı olduğunu görüyor ve buna göre, önceki tüm değişiklikler zaten veritabanından geçmişken, Penny'nin erişim kararıyla yapılan değişikliklere müşterinin erişmesini bekliyor.
Bu da bize yakışmıyor çünkü hâlâ çok fazla bilgi var ve bu da işleri yavaşlatacak. Başka bir yaklaşım daha var...
Lamport Saati
Onlar çok yaşlılar. Lamport Clock, bu bağımlılıkların Lamport Clock adı verilen skaler bir fonksiyona katlandığı anlamına gelir.
Skaler fonksiyon soyut bir sayıdır. Buna genellikle mantıksal zaman denir. Her etkinlikte bu sayaç artar. Şu anda proses tarafından bilinen sayaç her mesajı gönderir. Süreçlerin senkronizasyonunun bozulabileceği, tamamen farklı zamanlara sahip olabileceği açıktır. Ancak sistem bir şekilde saati bu tür mesajlaşmalarla dengeliyor. Bu durumda ne olur?
Bunu açıklığa kavuşturmak için bu büyük parçayı ikiye böldüm: Arkadaşlar, koleksiyonun bir parçasını içeren bir düğümde yaşayabilir ve Feed, bu koleksiyonun bir parçasını içeren başka bir düğümde yaşayabilir. Çizginin dışına nasıl çıkabilecekleri açık mı? İlk Akış şunu söyleyecektir: "Kopyalandı" ve ardından Arkadaşlar. Sistem, Friends koleksiyonundaki Friends bağımlılıkları da teslim edilene kadar Feed'in gösterilmeyeceğine dair bir tür garanti sağlamıyorsa, o zaman tam olarak bahsettiğim durumu yaşayacağız.
Feed'deki sayaç süresinin mantıksal olarak nasıl arttığını görüyorsunuz:
Yani bu Lamport Saati ve Nedensel tutarlılığın (Lamport Saati aracılığıyla açıklanan) ana özelliği şudur: Eğer Olay A ve B'ye sahipsek ve Olay B, Olay A*'ya bağlıysa, bu durumda A Olayının Mantıksal Zamanının şundan küçük olduğu sonucu çıkar: Olay B'den LogicalTime.
* Bazen A'nın B'den önce gerçekleştiğini, yani A'nın B'den önce gerçekleştiğini de söylerler - bu, genel olarak meydana gelen olayların tamamını kısmen düzenleyen belirli bir ilişkidir.
Bunun tersi yanlıştır. Bu aslında Lamport Clock'un ana dezavantajlarından biri - kısmi düzen. Eşzamanlı olaylarla ilgili bir kavram var, yani ne (A, B'den önce olmuş) ne de (A, B'den önce olmuş) olaylar. Bunun bir örneği, Leonard'ın paralel olarak başka birini arkadaş olarak eklemesidir (örneğin Leonard bile değil, Sheldon).
Bu, Lamport saatleriyle çalışırken sıklıkla kullanılan özelliktir: özellikle fonksiyona bakarlar ve bundan bu olayların belki de bağımlı olduğu sonucuna varırlar. Çünkü bir yol doğrudur: MantıksalZaman A, MantıksalZaman B'den küçükse, o zaman B, A'dan önce olamaz; ve daha fazlası varsa, o zaman belki.
vektör saati
Lamport saatinin mantıksal gelişimi Vektör Saatidir. Buradaki her düğümün kendi ayrı saatini içermesi ve bir vektör olarak iletilmesi bakımından farklılık gösterirler.
Bu durumda, vektörün sıfırıncı indeksinin Feed'den sorumlu olduğunu ve vektörün ilk indeksinin Arkadaşlar (bu düğümlerin her biri) için olduğunu görürsünüz. Ve şimdi artacaklar: “Feed” in sıfır indeksi yazarken artıyor – 1, 2, 3:
Vector Clock neden daha iyi? Çünkü hangi olayların eşzamanlı olduğunu ve farklı düğümlerde ne zaman meydana geldiğini anlamanıza olanak tanırlar. MongoDB gibi bir parçalama sistemi için bu çok önemlidir. Ancak harika bir şey olmasına, harika çalışmasına ve muhtemelen bize yakışmasına rağmen bunu biz seçmedik...
10 bin parçamız varsa, sıkıştırsak veya başka bir şey bulsak bile 10 bin bileşeni aktaramayız - yük yine de tüm bu vektörün hacminden birkaç kat daha küçük olacaktır. Bu nedenle kalbimizi ve dişlerimizi gıcırdatarak bu yaklaşımdan vazgeçip başka bir yaklaşıma geçtik.
Spanner TrueTime. Atomik saat
Spanner'la ilgili bir hikaye olacağını söylemiştim. Bu, XNUMX. yüzyıldan kalma harika bir şey: atom saatleri, GPS senkronizasyonu.
Fikir nedir? "Spanner", yakın zamanda insanların kullanımına bile sunulan bir Google sistemidir (buna SQL eklediler). Oradaki her işlemin bir zaman damgası vardır. Zaman senkronize olduğundan*, her olaya belirli bir zaman atanabilir; atom saatlerinin bir bekleme süresi vardır ve sonrasında farklı bir zamanın "olması" garanti edilir.
Böylece sadece veri tabanına yazıp belli bir süre bekleyerek olayın Serileştirilebilirliği otomatik olarak garanti altına alınır. Prensipte hayal edilebilecek en güçlü Tutarlılık modeline sahipler - bu Dış Tutarlılıktır.
* Lampart saatlerinin temel sorunu budur; dağıtılmış sistemlerde asla senkronize olmazlar. Farklılaşabilirler; NTP ile bile hala pek iyi çalışmıyorlar. "Spanner"ın bir atom saati var ve senkronizasyon mikrosaniye gibi görünüyor.
Neden seçmedik? Kullanıcılarımızın yerleşik bir atom saatine sahip olduğunu varsaymıyoruz. Ortaya çıktıklarında, her dizüstü bilgisayarda yerleşik olarak bir tür süper harika GPS senkronizasyonu olacak - o zaman evet... Ama şimdilik mümkün olan en iyisi Amazon, Baz İstasyonları - fanatikler için... Bu yüzden başka saatler kullandık .
Hibrit Saat
Bu aslında MongoDB'de Nedensel tutarlılığı sağlarken işaretlenen şeydir. Nasıl hibritler? Hibrit skaler bir değerdir ancak iki bileşeni vardır:
- Birincisi Unix çağıdır (“bilgisayar dünyasının başlangıcından bu yana kaç saniye geçti”).
- İkincisi bir miktar artıştır, ayrıca 32 bitlik imzasız bir int'dir.
Aslında hepsi bu. Şöyle bir yaklaşım var: Zamandan sorumlu olan kısım sürekli saatle senkronize oluyor; Her güncelleme gerçekleştiğinde, bu kısım saatle senkronize edilir ve zamanın her zaman aşağı yukarı doğru olduğu ortaya çıkar ve artış, aynı anda meydana gelen olaylar arasında ayrım yapmanızı sağlar.
Bu MongoDB için neden önemli? Çünkü belirli bir zamanda bir çeşit yedek restoran yapmanıza olanak tanıyor, yani olay zamana göre indeksleniyor. Belirli olaylara ihtiyaç duyulduğunda bu önemlidir; Bir veritabanı için olaylar, zaman içinde belirli aralıklarla veritabanında meydana gelen değişikliklerdir.
En önemli sebebi sadece sana anlatacağım (lütfen kimseye söyleme)! Bunu yaptık çünkü organize, indekslenmiş veriler MongoDB OpLog'da böyle görünüyor. OpLog, veritabanındaki kesinlikle tüm değişiklikleri içeren bir veri yapısıdır: önce OpLog'a giderler ve ardından çoğaltılmış bir tarih veya parça olması durumunda Depolamanın kendisine uygulanırlar.
Ana sebep buydu. Yine de, bir veritabanı geliştirmenin pratik gereksinimleri de vardır; bu, veritabanının basit olması gerektiği anlamına gelir; az kodlu, mümkün olduğunca az sayıda bozuk şeyin yeniden yazılması ve test edilmesi gerekir. Oploglarımızın hibrit saatler tarafından indekslenmesi bize çok yardımcı oldu ve doğru seçimi yapmamızı sağladı. Gerçekten işe yaradı ve ilk prototip üzerinde bir şekilde sihirli bir şekilde çalıştı. Çok havalıydı!
Saat senkronizasyonu
Bilimsel literatürde açıklanan çeşitli senkronizasyon yöntemleri vardır. İki farklı parçamız olduğunda senkronizasyondan bahsediyorum. Tek bir kopya kümesi varsa herhangi bir senkronizasyona gerek yoktur: bu “tek ana bilgisayardır”; tüm değişikliklerin içine düştüğü bir OpLog'umuz var - bu durumda, her şey zaten "Oplog" un kendisinde sırayla sıralanmıştır. Ancak iki farklı parçamız varsa burada zaman senkronizasyonu önemlidir. Burası vektör saatinin daha çok yardımcı olduğu yer! Ama bizde bunlara sahip değiliz.
İkincisi uygundur - bu "Kalp Atışı". Her zaman biriminde oluşan bazı sinyallerin değişimi mümkündür. Ancak Kalp atışları çok yavaş, müşterimize gecikme sağlayamıyoruz.
Gerçek zaman elbette harika bir şeydir. Ama yine de, bu muhtemelen gelecek... Her ne kadar Atlas'ta zaten yapılabiliyor olsa da, zaten hızlı "Amazon" zaman senkronize edicileri var. Ancak herkesin kullanımına açık olmayacak.
Dedikodu yapmak, tüm mesajların zaman içermesidir. Yaklaşık olarak bizim kullandığımız bu kadar. Düğümler arasındaki her mesaj, bir sürücü, bir veri düğümü yönlendiricisi, MongoDB için kesinlikle her şey bir tür öğedir, çalışan bir saati içeren bir veritabanı bileşenidir. Her yerde melez zaman anlamı taşıyorlar, aktarılıyor. 64 bit mi? Bu izin verir, bu mümkündür.
Hepsi birlikte nasıl çalışıyor?
Burada işi biraz kolaylaştırmak için bir kopya setine bakıyorum. Birincil ve İkincil vardır. İkincil çoğaltma yapar ve her zaman Birincil ile tamamen senkronize edilmez.
Belirli bir zaman değeri ile “Primery”ye ekleme gerçekleşir. Bu ek, maksimum sayı ise dahili sayımı 11 artırır. Veya saat değerlerini kontrol edip saat değerleri büyükse saate senkronizasyon yapacaktır. Bu, zamana göre düzenlemenizi sağlar.
Kaydı yaptıktan sonra önemli bir an yaşanır. Saat "MongoDB"dedir ve yalnızca "Oplog"a yazılması durumunda artırılır. Bu, sistemin durumunu değiştiren olaydır. Kesinlikle tüm klasik makalelerde, bir mesajın bir düğüme çarpması bir olay olarak kabul edilir: mesaj geldi, bu da sistemin durumunu değiştirdiği anlamına gelir.
Bunun nedeni, araştırma sırasında bu mesajın nasıl yorumlanacağının tam olarak belli olmamasıdır. “Oplog”a yansıtılmadığı takdirde hiçbir şekilde yorumlanmayacağını ve sistemin durumundaki bir değişikliğin sadece “Oplog”a bir giriş olduğunu kesin olarak biliyoruz. Bu bizim için her şeyi basitleştirir: Model onu basitleştirir ve onu tek bir kopya seti içinde düzenlememize ve diğer birçok yararlı şeye olanak tanır.
"Oplog"a zaten yazılmış olan değer döndürülür - "Oplog"un zaten bu değeri içerdiğini ve zamanının 12 olduğunu biliyoruz. Şimdi, diyelim ki, okuma başka bir düğümden (İkincil) başlıyor ve ClusterTime'ın kendisinden sonra iletiliyor İleti. Şöyle diyor: "En azından saat 12'den sonra veya on iki sırasında olan her şeye ihtiyacım var" (yukarıdaki resme bakın).
Buna Nedensel tutarlılık (CAT) denir. Teoride öyle bir kavram var ki bu kendi içinde tutarlı olan bir zaman dilimi. Bu durumda sistemin 12. anda gözlemlenen halinin bu olduğunu söyleyebiliriz.
Şimdi burada henüz hiçbir şey yok, çünkü bu tür, Birincil'den veri kopyalamak için İkincil'e ihtiyaç duyduğunuz durumu simüle eder. Bekliyor... Ve şimdi veriler geldi - bu değerleri geri veriyor.
Hemen hemen her şey bu şekilde çalışıyor. Neredeyse.
"Neredeyse" ne anlama geliyor? Diyelim ki bu işin nasıl yürüdüğünü okuyup anlayan birileri var. ClusterTime'ın her oluştuğunda dahili mantıksal saati güncellediğini ve ardından bir sonraki girişin birer birer arttığını fark ettim. Bu fonksiyon 20 satır alır. Diyelim ki bu kişi 64 bitlik en büyük sayıyı (eksi bir) iletiyor.
Neden "eksi bir"? Bu değere dahili saat yerleştirileceği için (açıkçası, bu mümkün olan en büyük ve mevcut saatten daha büyüktür), o zaman "Oplog" da bir giriş meydana gelecek ve saat başka bir birim tarafından arttırılacak - ve zaten orada olacak maksimum değer olsun (basitçe tüm birimler var, gidecek başka yer yok), aziz olmayan int'ler).
Bundan sonra sistemin hiçbir şey için kesinlikle erişilemez hale geleceği açıktır. Yalnızca boşaltılıp temizlenebilir - çok fazla manuel çalışma. Tam kullanılabilirlik:
Üstelik bu durum başka bir yerde tekrarlanırsa tüm küme çöker. Herkesin çok hızlı ve kolay bir şekilde organize edebileceği, kesinlikle kabul edilemez bir durum! Bu nedenle bu anı en önemli anlardan biri olarak değerlendirdik. Nasıl önlenir?
Bizim yolumuz ClusterTime'ı imzalamak
Mesajda bu şekilde iletilir (mavi metinden önce). Ancak aynı zamanda bir imza (mavi metin) oluşturmaya da başladık:
İmza, veritabanında güvenli bir çevrede saklanan bir anahtar tarafından oluşturulur; kendisi oluşturulur ve güncellenir (kullanıcılar bu konuda hiçbir şey görmez). Bir karma oluşturulur ve her mesaj oluşturulduğunda imzalanır ve alındığında doğrulanır.
Muhtemelen insanların aklına şu soru geliyor: “Bu, işleri ne kadar yavaşlatıyor?” Özellikle bu özelliğin olmadığı durumlarda hızlı çalışması gerektiğini söylemiştim.
Bu durumda Nedensel tutarlılığı kullanmak ne anlama gelir? Bu afterClusterTime parametresini göstermek içindir. Bu olmadan, yine de değerleri iletecektir. Dedikodu yapmak, sürüm 3.6'dan itibaren her zaman işe yarar.
Sürekli imza üretimini bırakırsak, yaklaşımlarımıza ve gereksinimlerimize uymayan bir özelliğin yokluğunda bile sistemi yavaşlatacaktır. Peki ne yaptık?
Çabucak yap!
Oldukça basit bir şey ama püf noktası ilginç; paylaşacağım, belki birileri ilgilenir.
İmzalı verileri saklayan bir karmamız var. Tüm veriler önbellekten geçer. Önbellek belirli bir zamanı değil, Aralığı imzalar. Bir değer geldiğinde bir Aralık oluştururuz, son 16 biti maskeleriz ve bu değeri imzalarız:
Böyle bir imza alarak sistemi (nispeten) 65 bin kat hızlandırıyoruz. Harika çalışıyor: Deneyler yaptığımızda, sıralı güncelleme yaptığımızda aslında süre 10 bin kat azaldı. Anlaşmazlığa düştüklerinde bunun işe yaramayacağı açıktır. Ancak çoğu pratik durumda işe yarar. Range imzasının imzayla birleşimi güvenlik sorununu çözdü.
Ne öğrendik?
Bundan çıkardığımız dersler:
- Materyalleri, hikayeleri, makaleleri okumalıyız çünkü pek çok ilginç şeyimiz var. Bazı özellikler üzerinde çalışırken (özellikle şimdi, işlem yaptığımızda vb.) okuyup anlamamız gerekiyor. Zaman alır ama aslında çok faydalıdır çünkü nerede olduğumuzu açıkça ortaya koyar. Yeni bir şey bulamadık; sadece malzemeleri aldık.
Genel olarak, akademik bir konferans olduğunda (örneğin Sigmon) düşünmede belirli bir farklılık vardır - herkes yeni fikirlere odaklanır. Algoritmamızdaki yenilikler neler? Burada özellikle yeni bir şey yok. Yenilik daha ziyade mevcut yaklaşımları bir araya getirme şeklimizde yatıyor. Bu nedenle ilk iş Lampart'tan başlayarak klasikleri okumaktır.
- Üretimde gereksinimler tamamen farklıdır. Eminim ki birçoğunuz soyut bir boşluktaki "küresel" veritabanlarıyla değil, kullanılabilirlik, gecikme ve hata toleransı sorunları olan normal, gerçek şeylerle karşı karşıyasınız.
- Son olarak, farklı fikirlere bakmamız ve tamamen farklı birkaç makaleyi tek bir yaklaşımda birleştirmemiz gerekti. Örneğin imzalama fikri genellikle, Bizanslı olmayan Başarısızlar için yetkilendirme protokolünün içinde olan, Bizanslılar için ise yetkilendirme protokolünün dışında olan Paxos protokolünü dikkate alan bir makaleden geldi... Genel olarak, biz de tam olarak bunu yapıyoruz. yaparak sona erdi.
Burada kesinlikle yeni bir şey yok! Ama hepsini karıştırır karıştırmaz... Olivier salatası tarifinin saçmalık olduğunu söylemekle aynı şey, çünkü yumurta, mayonez ve salatalık zaten icat edildi... Aynı hikaye.
Bununla bitireceğim. Teşekkür ederim!
sorular
Dinleyicilerden gelen soru (bundan sonra B olarak anılacaktır): – Rapor için teşekkürler Mikhail! Zaman konusu ilginç. Dedikodu yapıyorsunuz. Herkesin kendi saati var, herkes kendi yerel saatini biliyor dediler. Anladığım kadarıyla, bir sürücümüz var - sürücüleri, sorgu planlayıcıları ve parçaları olan çok sayıda müşteri olabilir... Ve aniden bir tutarsızlıkla karşılaşırsak sistem ne hale gelir: Birisi bunun bir amaç için olduğuna karar verirse bir dakika önde, biri bir dakika geride mi? Sonumuz nereye varacak?
MT: – Gerçekten harika bir soru! Sadece kırıklardan bahsetmek istedim. Soruyu doğru anladıysam şöyle bir durumla karşı karşıyayız: 1. parça ve 2. parça var, bu iki parçadan okuma yapılıyor - tutarsızlıkları var, birbirleriyle etkileşime girmiyorlar çünkü bildikleri zaman farklı. özellikle oploglarda var oldukları zaman.
Diyelim ki 1. parça bir milyon kayıt yaptı, 2. parça hiçbir şey yapmadı ve istek iki parçaya geldi. Ve ilkinin afterClusterTime'ı bir milyonun üzerinde. Böyle bir durumda, açıkladığım gibi, 2. parça asla yanıt vermeyecektir.
In: – Nasıl senkronize olduklarını ve tek bir mantıksal zamanı seçtiklerini bilmek istedim.
MT: - Senkronize edilmesi çok kolay. Shard, ClusterTime'dan sonra kendisine geldiğinde ve "Oplog" da zaman bulamayınca, onaylanmayan bir işlem başlatır. Yani elleriyle zamanını bu değere yükseltir. Bu, bu istekle eşleşen hiçbir etkinliğin olmadığı anlamına gelir. Bu olayı yapay olarak yaratır ve böylece Nedensel Tutarlı hale gelir.
In: – Peki ya bundan sonra ağın bir yerinde kaybolan başka olaylar aklına gelirse?
MT: – Shard tek master olduğundan bir daha gelmeyecek şekilde tasarlanmıştır. Zaten kaydolmuşsa gelmeyecekler, daha sonra gelecekler. Bir yere bir şeyin takılması, sonra yazmaması, sonra bu olayların gelmesi ve nedensel tutarlılığın bozulması olamaz. Yazmayınca hepsi gelmeli (onları bekleyecek).
In: – Kuyruklarla ilgili birkaç sorum var. Nedensel tutarlılık, gerçekleştirilmesi gereken belirli bir eylem sırasının olduğunu varsayar. Paketlerimizden biri kaybolursa ne olur? İşte 10'u, 11'i geliyor... 12'si ortadan kayboldu ve herkes onun gerçekleşmesini bekliyor. Ve birden arabamız bozuldu, hiçbir şey yapamıyoruz. Yürütülmeden önce biriken kuyruğun maksimum uzunluğu var mı? Herhangi bir durum kaybolduğunda hangi ölümcül başarısızlık meydana gelir? Üstelik daha önceki bir durumun olduğunu yazarsak, o zaman bir şekilde ondan mı başlamalıyız? Ama onu uzaklaştırmadılar!
MT: – Ayrıca harika bir soru! Biz ne yapıyoruz? MongoDB'nin çekirdek yazma, çekirdek okuma kavramı vardır. Hangi durumlarda bir mesaj kaybolabilir? Bir yazma yeter sayısı olmadığında veya bir okuma yeter sayısı olmadığında (bir tür çöp de yapışabilir).
Nedensel tutarlılığa ilişkin olarak büyük bir deneysel test gerçekleştirildi; bunun sonucu, yazma ve okumaların çoğunlukta olmaması durumunda Nedensel tutarlılık ihlallerinin meydana gelmesiydi. Aynen öyle diyorsun!
Tavsiyemiz: Nedensel tutarlılığı kullanırken en azından çoğunluk okumasını kullanın. Bu durumda çekirdek kaydı kaybolsa bile hiçbir şey kaybolmaz... Bu ortogonal bir durumdur: Kullanıcı verinin kaybolmasını istemiyorsa çekirdek kaydı kullanması gerekir. Nedensel tutarlılık kalıcılığı garanti etmez. Dayanıklılık, çoğaltma ve çoğaltmayla ilişkili makinelerle garanti edilir.
In: – Bizim için parçalama gerçekleştiren bir örnek oluşturduğumuzda (sırasıyla ana değil, köle), kendi makinesinin Unix zamanına veya “ana”nın zamanına güvenir; İlk kez mi yoksa periyodik olarak mı senkronize ediliyor?
MT: – Şimdi açıklayacağım. Parça (yani yatay bölüm) – orada her zaman bir Birincil vardır. Ve bir parçanın bir "ana"sı olabilir ve kopyaları olabilir. Ancak parça her zaman kaydı destekler çünkü bazı etki alanlarını desteklemesi gerekir (parçanın Birincil alanı vardır).
In: – Yani her şey tamamen “ustaya” mı bağlı? Master zamanı her zaman kullanılıyor mu?
MT: - Evet. Mecazi olarak şunu söyleyebilirsiniz: “ana” ya, “Oplog”a bir giriş gerçekleştiğinde saat işliyor.
In: – Bağlanan ve zaman hakkında hiçbir şey bilmesine gerek olmayan bir müşterimiz var mı?
MT: – Hiçbir şey bilmenize gerek yok! Danışanda nasıl çalıştığından bahsedecek olursak: Danışan Nedensel tutarlılığı kullanmak istediğinde seans açması gerekir. Artık her şey ortada: oturumdaki işlemler ve hakların alınması... Oturum, istemcide meydana gelen mantıksal olayların sıralanmasıdır.
Bu oturumu açarsa ve orada Nedensel tutarlılık istediğini söylerse (eğer oturum varsayılan olarak Nedensel tutarlılığı destekliyorsa), her şey otomatik olarak çalışır. Sürücü bu süreyi hatırlar ve yeni bir mesaj aldığında bu süreyi artırır. Bir öncekinin, verileri döndüren sunucudan hangi yanıtı döndürdüğünü hatırlar. Bir sonraki istek afterCluster("bundan daha büyük zaman") ifadesini içerecektir.
Müşterinin kesinlikle hiçbir şey bilmesine gerek yok! Bu onun için tamamen anlaşılmaz bir durum. İnsanlar bu özellikleri kullanırsa ne yapabilirler? İlk olarak, ikincilleri güvenle okuyabilirsiniz: Birincil'e yazabilir ve coğrafi olarak çoğaltılmış ikincillerden okuyabilir ve çalıştığından emin olabilirsiniz. Aynı zamanda Birincil'de kaydedilen oturumlar İkincil'e bile aktarılabilir, yani bir değil birden fazla oturum kullanabilirsiniz.
In: – Bilgi işlem biliminin yeni bir katmanı olan CRDT (Çakışmasız Çoğaltılan Veri Türleri) veri türleri, Nihai tutarlılık konusuyla güçlü bir şekilde ilişkilidir. Bu tür verileri veri tabanına entegre etmeyi düşündünüz mü ve bu konuda neler söyleyebilirsiniz?
MT: - İyi soru! CRDT, yazma çakışmaları için anlamlıdır: MongoDB'de tek yönetici.
In: – Devoplardan bir sorum var. Gerçek dünyada, Bizans Başarısızlığının meydana geldiği ve korunan çevre içindeki kötü insanların protokole girmeye, özel bir şekilde zanaat paketleri göndermeye başladığı Cizvit durumları var mı?
MT: – Çevrenin içindeki kötü insanlar Truva atı gibidir! Çevre içindeki kötü insanlar pek çok kötü şey yapabilirler.
In: – Kabaca söylemek gerekirse, sunucuda bir fil hayvanat bahçesini yerleştirebileceğiniz ve tüm kümeyi sonsuza kadar çökertebileceğiniz bir delik bırakmanın açık olduğu açık... Manuel kurtarma zaman alacak... Bu, en hafif tabirle söylemek gerekirse, yanlış. Öte yandan ilginç: Gerçek hayatta, pratikte doğal olarak benzer iç saldırıların meydana geldiği durumlar var mı?
MT: – Gerçek hayatta güvenlik ihlalleriyle nadiren karşılaştığım için olup olmadığını söyleyemem. Ama kalkınma felsefesinden bahsedecek olursak şöyle düşünüyoruz: Güvenliği sağlayan adamlara güvenlik sağlayan bir çevremiz var; bu bir kale, bir duvar; ve çevrenin içinde ne istersen yapabilirsin. Sadece görüntüleme yeteneğine sahip kullanıcıların olduğu gibi, dizini silme yeteneğine sahip kullanıcıların da olduğu açıktır.
Haklara bağlı olarak kullanıcıların verebileceği zarar bir fare olabileceği gibi bir fil de olabilir. Tam haklara sahip bir kullanıcının her şeyi yapabileceği açıktır. Sınırlı haklara sahip bir kullanıcı önemli ölçüde daha az zarara neden olabilir. Özellikle sistemi bozamaz.
In: – Korunan çevrede birisi, sunucuyu ve eğer şanslıysanız tüm kümeyi tamamen yok etmek için sunucu için beklenmedik protokoller oluşturmaya çalıştı... Hiç bu kadar "iyi" olur mu?
MT: "Hiç böyle şeyler duymadım." Bir sunucuyu bu şekilde çökertebileceğiniz gerçeği bir sır değil. İçeride başarısız olmak, protokolden olmak, mesaja böyle bir şey yazabilecek yetkili kullanıcı olmak... Aslında imkansız çünkü yine de doğrulanacak. İstemeyen kullanıcılar için bu kimlik doğrulamayı devre dışı bırakmak mümkündür - o zaman bu onların sorunudur; kabaca söylersek, duvarları kendileri yıktılar ve oraya bir fili itebilirsin, bu da ezecek... Ama genel olarak bir tamirci gibi giyinebilirsin, gelip onu çıkarabilirsin!
In: – Rapor için teşekkürler. Sergey (Yandex). Mong'da Replica Set'te oy kullanan üye sayısını sınırlayan bir sabit vardır ve bu sabit 7 (yedi)'dir. Bu neden bir sabit? Bu neden bir tür parametre değil?
MT: – 40 düğümlü Replika Setlerimiz var. Her zaman çoğunluk vardır. Hangi versiyon olduğunu bilmiyorum...
In: – Replica Set'te oy kullanmayan üyeleri çalıştırabilirsiniz ancak en fazla 7 oy veren üye vardır.Replica Setimiz 3 veri merkezine yayılmışsa bu durumda kapanmadan nasıl kurtulabiliriz? Bir veri merkezi kolayca kapanabilir ve başka bir makine düşebilir.
MT: – Bu zaten raporun kapsamını biraz aşıyor. Bu genel bir sorudur. Belki sana daha sonra anlatabilirim.
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com