Növbəti HighLoad++ konfransı 2020-ci il aprel ayının 6 və 7-də Sankt-Peterburqda keçiriləcək.
Təfərrüatlar və biletlər . HighLoad++ Siberia 2019. "Krasnoyarsk" zalı. 25 iyun, 12:00. Tözislər və .
Bəzən praktiki tələblər nəzəriyyə ilə çəkişmə ərsəyə gətirir, burada isə ticarət məhsulu üçün vacib olan aspektlər nəzərə alınmır. Bu təqdimatda, bir komersiya məhsulunun tələblərinə əsaslanaraq, Causal consistency komponentlərinin yaradılması üçün müxtəlif yanaşmaların seçilməsi və kombinasiyası prosesini təqdim edəcəyik. Dinləyicilər logical clocks, dependency tracking, system security, clock synchronization mövzularında mövcud nəzəri yanaşmalar haqqında bilgilənəcəklər və MongoDB-nin hansı qərarları necə verdiyinə dair məlumat alacaqlar.
Mixail Tyulenyev (bundan sonra – MT): – Mən Causal consistency haqqında danışacağam – bu, MongoDB-də işlədiyimiz bir xüsusiyyətdir. Mən paylanmış sistemlər qrupunda işləyirəm, bu xüsusiyyəti təxminən iki il əvvəl yaratdıq.
Proses zamanı bir çox akademik araşdırmalarla tanış olmalı olduq, çünki bu xüsusiyyət kifayət qədər yaxşı öyrənilib. Aydın oldu ki, heç bir məqalə istehsal üçün tələb olunanları tam olaraq qarşılamır, databazanın öz spesifik tələblərinə görə, nəhayət, hansısa istehsal tətbiqetmələrində.
Mən, akademik araşdırmalara istinadan, biz hazırladığımız şeylərin necə olduğunu, sonra bunu istifadəçilərimizə rahat, etibarlı şəkildə təqdim edəcəyimizi danışacağam.
Causal consistency. Terminləri müəyyənləşdirmək.
Əvvəlcə, Causal consistency-nin nə olduğunu qısaca izah etmək istəyirəm. İki xarakter var – leonard və Penny ("Böyük partlayış teorisi" serialı):
Gəlin düşünək ki, Penny Avropadadır, Leonard isə ona sürpriz etməyə çalışır, onun üçün bir tədbir təşkil etmək istəyir. Və o, daha yaxşı bir şey düşünmür, onun dostlarından hər kəsə "Penny-ni sevindirək!" (o Avropadadır, yatdığı zaman, bunların heç birini görmür) deyərək bir post yollayır. Nəticədə bu postu silir, "Fid"-dən silir və Penny-nin heç bir şey görməməsi üçün access-i bərpa edir.
Bunlar gözəl, lakin gəlin düşünək ki, sistem paylanmışdır və hadisələr bir az fərqli gedir. Mümkün ki, Penny-nin access məhdudiyyəti bu postdan sonra baş verib, əgər hadisələr bir-birinə səbəb-nəticə münasibətində deyilsə. Əslində, bu – biznes funksiyasını yerinə yetirmək üçün Causal consistency-nin tələb olunduğu bir nümunədir (bu halda).
Əslində bu, database-in kifayət qədər qəliz xüsusiyyətləridir – bu cür xüsusiyyətləri çox az adam dəstəkləyir. Gəlin modellərə keçək.
Uyğunlaşma modelləri (Consistency Models)
Ümumiyyətlə, verilənlər bazalarında konsistensiya modeli nədir? Bu, paylanmış sistemin müştərilərə hansı məlumatların və hansı ardıcıllıqla təqdim ediləcəyinə dair verdiyi müəyyən zəmanətlərdir.
Əslində, bütün konsistensiya modelləri, paylanmış sistemin nəyə qədər bir nodda, məsələn, bir noutbukun üzərində işləyən sistemə bənzədiyi ilə bağlıdır. Və sistemin, minlərlə coğrafi bölgələrdə olan "Nod" üzərində işlədiyi zaman, bunların özündə bütün bu xüsusiyyətlərin avtomatik şəkildə yerinə yetirilib-yetirilmədiyinə baxılır.
Bu səbəbdən konsistensiya modelləri yalnız paylanmış sistemlərə aiddir. Əvvəlki dövrlərdə bir vertikal miqyasda çalışan bütün sistemlər belə problemlərlə qarşılaşmırdı. Orada yalnız bir Buffer Cache var idi və bütün məlumatlar həmişə oradan oxunurdu.
Strong modeli
Əslində, ilk model – Strong (ya da onu tez-tez Rise Ability adlandırır). Bu konsistensiya modeli, hər bir dəyişiklik, onun baş verdiyi təsdiqi alınan kimi, sistemin bütün istifadəçilərinə görünməsini təmin edir.
Bu, verilənlər bazasında bütün hadisələrin qlobal ardıcıllığını yaradır. Bu, konsistensiyanın çox güclü bir xüsusiyyətidir və həqiqətən də, çox bahalıdır. Buna baxmayaraq, bu çox yaxşı dəstəklənir. Sadəcə olaraq, bu çox bahalı və yavaşdır – ona görə də nadir hallarda istifadə olunur. Buna Rise Ability deyilir.
Həmçinin, "Spanner"də dəstəklənən daha güclü bir xüsusiyyət var – buna Xarici Konsistensiya deyilir. Bunun haqqında bir az sonra danışacağıq.
Causal
Növbəti model Causal'dır, bu da məhz sadıq olduğum şeydir. Strong və Causal arasında daha bir neçə alt səviyyə var, amma bunların hamısı Causal-a aiddir. Bu, vacib bir modeldir, çünki bu, bütün modellər arasında ən güclüsüdür, şəbəkə və ya parçalanmalar olduğu zaman ən güclü konsistensiyadır.
Causals, faktiki olaraq, hadisələrin səbəb-nəticə əlaqəsi ilə bağlı olduğu vəziyyətdir. Çox vaxt müştəri nöqteyi-nəzərindən bunu "Read your own rights" kimi başa düşürlər. Əgər müştəri bəzi dəyərləri müşahidə edibsə, o, keçmişdə olan dəyərləri görə bilmir. O artıq prefiks oxumalarını görməyə başlayır. Bunların hamısı bir-birinə bənzəyir.
Causals, konsistensiya modeli olaraq, serverdə hadisələrin müəyyən ardıcıllıqda qismən sıralanmasıdır; bu zaman bütün müştərilərdən gələn hadisələr eyni ardıcıllıqla müşahidə olunur. Bu halda – Leonard və Penny.
Eventual
Üçüncü model – Eventual Consistency'dir. Bu, tamamilə bütün paylanmış sistemlər tərəfindən dəstəklənən, məna kəsb edən minimal modeldir. Bu, o deməkdir ki, verilənlərdə müəyyən dəyişikliklər baş verdikdə, bir zaman içində onlar konsistent olur.
Bu anlarda o heç nə demir, əks halda External Consistency-yə çevrilərdi - tamamilə fərqli bir hekayə olardı. Lakin bu, çox populyar bir modeldir, ən yaygın olanıdır. Default olaraq, bütün paylanmış sistem istifadəçiləri məhz Eventual Consistency-dən istifadə edirlər.
Bəzi müqayisəli nümunələr gətirmək istəyirəm:
Bu oxlar nə deməkdir?
- Gecikme. Konsistensiya gücü artdıqca, anlayışlı səbəblərdən daha çox olur: daha çox yazı etmək, klasterdə iştirak edən bütün hostlardan və nodlardan təsdiq almaq lazım gəlir ki, məlumat orada artıq var. Buna görə də Eventual Consistency-də ən sürətli cavabdır, çünki orada adətən hər şey, hətta yaddaşda da qeydə alına və bununla kifayətlənilə bilər.
- Mövcudluq. Bunu sistemin şəbəkə kəsintiləri, partitions və ya digər nasazlıqlarla cavab vermə imkanı kimi anladıqda - konsistensiya modelinin azaldılması ilə mövcudluq artar, çünki bizim yalnız bir hostun çalışması və bu məlumatları verməsi kifayətdir. Eventual Consistency məlumatlarla bağlı heç bir zəmanət vermir - bu, istənilən şey ola bilər.
- Anomaliyalar. Bu halda, əlbətdə, anomaliyaların sayı artır. Güclü Konsistensiya üçün demək olar ki, heç bir anomaliya olmamalıdır, lakin Eventual Consistency-də hər cür anomaliya ola bilər. Suallara səbəb olur: niyə insanlar Eventual Consistency-ni seçirlər, əgər orada anomaliyalar varsa? Cavab budur ki, Eventual Consistency modelləri istifadə oluna bilər, anomaliyalarsa, məsələn, qısa bir zaman müddətində mövcuddur; oxumaq üçün master istifadə etmək imkanı var və nisbətən konsistent məlumatlar oxumaq mümkündür; tez-tez güclü konsistensiya modellərindən istifadə etmə imkanı var. Praktikası budur ki, çox vaxt anomaliyanın sayı zamanla məhduddur.
CAP Teoreması
Consistency, availability sözlərini gördükdə, ağlınıza nə gəlir? Düzdür - CAP teoreması! Mən indi bir mifin üstündən keçmək istəyirəm... Bu mən deyiləm - Martin Kleppmann, mükəmməl bir məqalə, mükəmməl bir kitab yazmışdır.
CAP teoreması – 2000-ci illərdə formalaşmış bir prinsipdir ki, Consistency, Availability, Partitions: hər hansı iki seçin, üçüncüsünü seçə bilməzsiniz. Bu, müəyyən bir prinsip idi. Bir neçə ildən sonra teorema olaraq sübut edildi, bunu Gilbert və Lynch etdilər. Sonra bu, şüar kimi istifadə olunmağa başladı - sistemlər CA, CP, AP və s. olaraq təsnifləşməyə başladı.
Bu teorema əslində hansı hallarda sübut olundu... Birincisi, Mövcudluq, sıfırdan yüzə qədər davamlı bir dəyər kimi (0 - sistem "ölüdür", 100 - tez cavab verir; biz onu belə düşünməyə öyrəşmişik) deyil, icra atılamalarının bütün müddətində məlumat qayıtmağı təmin edən bir alqoritm xüsusiyyəti kimi nəzərdən keçirilib.
Cavab müddəti haqqında heç bir söz yoxdur! Məlumatları 100 ildən sonra qaytaran bir alqoritm var - tamamilə gözəl available-alqoritm, CAP teoremasının bir hissəsidir.
İkincisi: teorema eyni açar dəyərinin dəyişikliklərinə görə sübut edilmişdir, bu dəyişikliklərin isə resizable xətti olmasıdır. Bu, deməkdir ki, faktiki olaraq, bunlar az istifadə olunur, çünki digər Eventual Consistency, Strong Consistency modelləri var.
Bütün bunlar nəyə görədir? CAP teoreması o formada, hansı ki, sübut edilib, praktik olaraq tətbiq edilə bilmir, nadir istifadə olunur. Teorik formada bir şəkildə hər şeyi məhdudlaşdırır. Nəticədə, bir prinsip yaranır ki, bu da intuitiv olaraq doğrudur, lakin ümumiyyətlə sübut edilmir.
Kausallıq konsistentliyi – ən güclü modeldir.
Hazırda baş verənlər – üç şeyi əldə etmək mümkündür: Consistency, Availability, Partitions vasitəsilə əldə edilir. Xüsusilə, Kausallıq konsistentliyi – Partitions (şəbəkə kəsintiləri) olduqda belə işləyən ən güclü konsistentlik modelidir. Buna görə də, bu böyük maraq doğurur və biz bu ilə məşğuluq.
Bu, birincisi, tətbiq inkişaf etdiricilərinin işini asanlaşdırır. Xüsusilə, server tərəfindən böyük dəstək olmağı: bütün qeydlərin, hansı ki, bir müştəri daxilində baş verir, digər müştəri üstündə müəyyən bir ardıcıllıqla gəlməsi zəmanətidir. İkincisi, o, partitions-ə dözə bilir.
MongoDB-nin daxili mətbəxi.
Nahar vaxtını unutmadan, mətbəxə keçirirk. Mən sistem modelindən danışacağam, yəni MongoDB-nin nə olduğunu, bununla ilk dəfə eşidənlər üçün.
MongoDB (bundan sonra «MongoDB») – şaquli miqyaslanma dəstəkləyən, yəni şarding, paylanmış sistemdir; və hər bir sharda o, məlumatların artıq olduğu, yəni replikasiyonu da dəstəkləyir.
MongoDB-də (müraciət etməyən DB) şarding avtomatik olaraq balanslaşdırma həyata keçirir, yəni, hər bir sənəd kolleksiyası (yəni, riyazi məlumatların terminologiyasında «cədvəl») hissələrə ayrılır, və server avtomatik olaraq onları sharlara köçürür.
Sorğu Router, müştəri üçün bir müştəri olaraq işləyir, onun vasitəsilə işləyir. Artıq harada və hansı məlumatların olduğunu bilir, bütün sorğuları düzgün sharda yönləndirir.
Başqa bir vacib məsələ: MongoDB - tək ustadır. Bir Primary var - o, özündə saxladığı açarları dəstəkləyən qeydləri götürə bilər. Multi-master yazmaq mümkün deyil.
Biz 4.2 versiyasını buraxdıq - burada yeni maraqlı şeylər ortaya çıxdı. Xüsusilə, Lucene – axtarış – tam olaraq «Mongo»-da executable java daxil edildi və burada Lucene ilə, «Elastic»-də olduğu kimi axtarış aparmaq mümkün oldu.
Yeni bir ürün geliştirdik - Charts, aynı zamanda "Atlas"ta (kendi Cloud "Mongo") mevcut. Ücretsiz katmanları var - bununla deneme yapabilirsiniz. Charts'ı çok beğendim - veri görselleştirmesi, oldukça sezgisel.
Causal consistency bileşenleri
Bu konuyla ilgili yaklaşık 230 makale saydım - Leslie Lampert'tan. Şu anda aklımdan bazı bölümlerini sizinle paylaşacağım.
Her şey Leslie Lampert'ın 1970'lerde yazdığı makaleyle başladı. Gördüğünüz gibi, bu konuyla ilgili hâlâ bazı araştırmalar devam ediyor. Şu anda Causal consistency, dağıtık sistemlerin gelişimiyle ilgili olarak ilgi görüyor.
Məhdudiyyətlər
Hangi kısıtlamalar var? Bu aslında en önemli konulardan biri, çünkü üretim sistemlerinin koyduğu kısıtlamalar, akademik makalelerdeki kısıtlamalardan oldukça farklı. Genellikle, bu kısıtlamalar hayli yapay.
- Öncelikle, "MongoDB" tek anahtara sahiptir, daha önce de söylediğim gibi (bu durumu oldukça basit hale getirir).
- Sistemin yaklaşık 10.000 shard desteklemesi gerektiğini düşünüyoruz. Bu değeri açıkça sınırlayan herhangi bir mimari karar alamayız.
- Bir bulutumuz var, ancak kullanıcıların binary dosyayı indirdiğinde, dizüstü bilgisayarında çalışmasını sağlaması gerektiğini düşünüyoruz.
- Araştırmada nadiren kullanılan bir durum öngörüyoruz: dış müşteriler her şeyi yapabilir. "MongoDB" açık kaynaklıdır. Dolayısıyla, müşteriler oldukça zeki veya kötü niyetli olabilir - her şeyi kırmaya çalışabilirler. Biz, Bizans Hatalarının ortaya çıkabileceğini öngörüyoruz.
- Dış müşteriler için, perimetrin dışındaki önemli bir kısıtlama vardır: bu özellik kapatıldığında, herhangi bir performans düşüşü gözlemlenmemelidir.
- Bir başka önemli nokta - tamamen akademik olmayan: önceki sürümler ile gelecekteki sürümlerin uyumluluğu. Eski sürücüler, yeni güncellemeleri desteklemeli ve veritabanı eski sürücüleri desteklemelidir.
Genel olarak, tüm bunlar kısıtlamalar getiriyor.
Causal consistency bileşenleri
Şimdi bazı bileşenleri anlatacağım. Causal consistency genel olarak değerlendirildiğinde, bloklar halinde ayırabiliriz. Biz, belirli bir bloğa ait çalışmalardan seçtik: Dependency Tracking, saatlerin seçimleri, bu saatlerin nasıl senkronize edileceği ve güvenliği nasıl sağladığımız - bunlar, konuşacağım konuların genel çerçevesi.
Tam bağımlılık takibi (Full Dependency Tracking)
Neden gereklidir? Veriler tekrarlandığında - her kayıt, her veri değişikliği, hangi değişikliklere bağlı olduğunu içeren bilgiyi taşımaları için. En basit ve ilkel değişiklik, her mesajın, içerdiği kaydı geçmiş mesajlar hakkında bilgi taşıyacak şekilde tasarlanmasıdır:
Bu nümunədə süslü mötərizələrdəki nömrə qeydlərin nömrələridir. Bəzən bu qeydlər tam şəkildə dəyərlərlə birgə ötürülür, bəzən isə nə isə versiyalar göndərilir. Məzmun belədir ki, hər dəyişiklik əvvəlki haqqında məlumatı ehtiva edir (bu, açıq şəkildə içərisində daşınır).
Niyə bu yanaşmadan istifadə etməməyə qərar verdik (tam izləmə)? Aydın olan odur ki, bu yanaşma praktik deyil: hər sosial şəbəkədəki dəyişiklik əvvəlki bütün dəyişikliklərdən asılıdır və bu, hər yeniləmədə "Facebook" və ya "VKontakte"-ni ötürür. Buna baxmayaraq, tam asılılıq izləməsi ilə bağlı çoxlu tədqiqatlar var – bu, sosial şəbəkələrdən əvvəlki bir şeydir; bəzi hallarda bu, həqiqətən də işləyir.
Aydin Asılılıq İzləmə (Explicit Dependency Tracking)
Növbəti yanaşma daha məhdudlaşdırılmışdır. Burada da yalnız açıq asılı olan məlumatların ötürülməsi nəzərdən keçirilir. Nələrin nədən asılı olduğunu, adətən, Tətbiq müəyyən edir. Məlumatlar replikasiya edildikdə, sorğu zamanı yalnız əvvəlki asılılıqlar təmin olunduğu zaman cavablar təqdim olunur, yəni göstərilmişdir. Bu, Causal consistency-nin necə işlədiyinin əsasını təşkil edir.
O, 5-ci qeydin 1, 2, 3, 4 qeydlərindən asılı olduğunu görür – buna görə də, müştəri, Penny-nin icra etdiyi dəyişikliklərə çıxış əldə etməzdən əvvəl bütün əvvəlki dəyişikliklərin verilənlər bazasında keçdiyinə əmin olur.
Bu da bizi qane etmir, çünki hələ də məlumat çoxdur və bu, yavaşladacaq. Digər bir yanaşma var…
Lamport Saatı (Lamport Clock)
Onlar çox köhnədir. Lamport Saatı bu asılılıqların bir skalar funksiya halına gətirildiyini nəzərdə tutur ki, bu da Lamport Saatı adlanır.
Skalar funksiya müəyyən bir abstrakt ədəddir. Çox vaxt onu məntiqi zaman adlandırırlar. Hər hadisədə bu sayğac artır. Hal-hazırda proses tərəfindən bilinən sayğac hər mesajı göndərir. Aydındır ki, proseslər senkronizə edilməmiş ola bilər, onlarda tamamilə fərqli zaman ola bilər. Buna baxmayaraq, bu cür mesaj mübadiləsi sistemi bir şəkildə saatların balanslaşdırılmasına kömək edir. Bu halda nə baş verir?
Mən o böyük shard-ı iki hissəyə bölmüşəm ki, aydın olsun: Friends bir nodda qala bilər, orada bir kolleksiyanın hissəsi saxlanılır, Feed isə tamamilə fərqli bir nodda ola bilər ki, orada bu kolleksiyanın bir hissəsi mövcuddur. Aydındır ki, onlar necə sırada olmasınlar? Əvvəlcə Feed deyəcək: "Replika edildi", sonra isə – Friends. Əgər sistem, Friends kolleksiyasındakı asılılıqlar təmin olunmadan Feed-in göstərilməməsinə zəmanət vermirsə, o zaman mənim bəhs etdiyim vəziyyət yarana bilər.
Siz Feed-də sayğacın məntiqi zamanının necə artdığını görə bilirsiniz:
Bununla birlikte, bu Lamport Saati ve Sebep uyumluluğunun (Lamport Saati üzerinden açıklanan) temel özelliği şudur: A ve B olaylarımız varsa ve B olayı A olayına bağımlıysa *, o halde Event A'nın LogicalTime'ı, Event B'nin LogicalTime'ından daha azdır.
* Bazen A'nın B'den önce gerçekleştiği, yani A'nın B'den önce olduğu söylenir - bu, gerçekleşmiş tüm olaylar kümesini kısmen sıralayan bir ilişkidir.
Tam tersi yanlıştır. Bu aslında Lamport Saati'nin temel dezavantajlarından biri - kısmi sıralama. Eşzamanlı olaylar kavramı vardır, yani ne (A B'den önce oldu) ne de (A B'den önce oldu) diyebiliriz. Örneğin, Leonard'ın başka birini arkadaş olarak eklemesi (şimdilik Leonard değil de Sheldon örneğin) bir örnek olabilir.
İşte bu, Lamport saatleri ile çalışırken sıklıkla kullanılan bir özelliktir: tam olarak işe bakarız ve bununla sonuç çıkarırız - bu olayların bağımlı olup olmadıkları. Çünkü bir yönde bu doğrudur: Eğer LogicalTime A, LogicalTime B'den küçükse, o zaman B, A'dan önce olamaz; ama eğer büyükse, olabilir.
Vektör saatleri (Vector Clock)
Lamport saatlerinin mantıksal geliştirmesi Vektör saatleridir. Bunlar, burada bulunan her düğümün kendi ayrı saatini içerdiği ve bunların bir vektör olarak iletildiği şekilde farklıdır.
Bu durumda, vektörün sıfır indeksinin Feed'e, birinci indeksinin ise Friends'e (bu düğümlerin her biri) karşılık geldiğini görebilirsiniz. Ve şimdi artacaklar: sıfır indeks 'Feed' kaydedilirken - 1, 2, 3:
Vektör saatleri neden daha iyidir? Çünkü hangi olayların eşzamanlı olduğunu ve bunların farklı düğümlerde ne zaman gerçekleştiğini anlamaya olanak tanır. Bu, shardlama sistemleri için çok önemlidir, örneğin 'MongoDB'. Ancak biz bunu seçmedik, oysa ki bu harika bir şey ve mükemmel çalışıyor, belki bize de uygun olabilirdi...
Eğer 10 bin shardımız varsa, 10 bin bileşeni iletemeyiz, her ne kadar sıkıştırsak veya başka bir şey denesek bile - yine de faydalı yük, bu vektörün tüm hacminden kat kat daha az olacaktır. Bu yüzden, kalbimizi ve dişlerimizi sıkarak bu yaklaşımdan vazgeçtik ve başka birine geçtik.
Spanner TrueTime. Atom saatleri
‘Spanner’dan bahsedeceğim. Bu harika bir şey, tam XXI. yüzyıl: atom saatleri, GPS senkronizasyonu.
Fikir nedir? ‘Spanner’ - bu Google'ın sistemi, yakın zamanda insanlar için erişilebilir hale geldi (onun üstüne SQL eklediler). Her işlem orada belirli bir zaman damgasına sahiptir. Zaman senkronize olduğu için*, her olaya belirli bir zaman atanabilir - atom saatlerinin bir bekleme zamanı vardır, bu süre dolduktan sonra garantili olarak başka bir zaman gerçekleşir.
Beləliklə, sadəcə DB-yə yazaraq və müəyyən bir müddət gözləyərək hadisələrin Serializability-ni avtomatik təmin etmək mümkündür. Onların ən güclü Consistency modeli var ki, bu da əsasən təqdim edilə biləcək – bu, External Consistency-dir.
* Bu, Lemparta saatlarının əsas problemlərindən biridir – onlar heç vaxt paylanmış sistemlərdə sinkronlaşdırılmır. NTP olsa da, hələ də yaxşı işləmir. "Spanner" atom saatları və sinkronlaşdırmağa malikdir, mikrosaniyələrə qədər.
Niyə biz seçmədik? Biz sizin istifadəçilərinizin daxil edilmiş atom saatlarına sahib olduğunu düşünmürük. Onlar hər laptopa daxil edildikdə, super mükəmməl GPS sinkronizasiyası olacaq – o zaman bəli... Ancaq indiyə qədər mümkün olan ən yaxşı şey "Amazon", Base Stations – fanatlar üçün... Buna görə biz başqa saatlar istifadə etdik.
Hibrid saatlar (Hybrid Clock)
Bu, faktiki olaraq, Causal consistency-ni təmin edən "MongoDB"də tık-tık edən şeydir. Onlar hibrid nədir? Hibrid bir skalar dəyərdir, amma iki komponentdən ibarətdir:
- Birincisi – Unix dövrü ("kompüter dünyasının başlanğıcından bəri neçə saniyə keçmişdir").
- İkincisi – 32-bit unsigned int olan bir inkrement.
Bu, əslində, budur. Belə bir yanaşma var: vaxtla əlaqəli hissə hər zaman saatlarla sinkronlaşdırılır; hər dəfə yeniləmə baş verdikdə, bu hissə saatlarla sinkronlaşır və beləliklə vaxt hər zaman az-çox düzgün olur, inkrement isə eyni anda baş vermiş hadisələri fərqləndirməyə imkan verir.
Bu, "MongoDB" üçün niyə vacibdir? Çünki müəyyən bir zamana bərpa-updatelər etməyə imkan verir, yəni hadisə vaxtla indeksləşdirilir. Bu, müəyyən hadisələri tələb etdiyində vacibdir; məlumat bazası üçün hadisələr – müəyyən zaman intervallarında baş vermiş dəyişikliklərdir.
Ən vacib səbəbi yalnız sizə deyəcəyəm (xahiş edirəm, yalnız heç kimə deməyin)! Biz bunu etdik, çünki "MongoDB" OpLog-da sıralanmış, indeksləşdirilmiş məlumatlar belə görünür. OpLog – bu məlumat bazasında baş vermiş bütün dəyişiklikləri saxlayan bir məlumat strukturu: əvvəlcə onlar OpLog-a daxil olur, sonra isə replikasiya olunmuş məlumat və ya shard olaylarında Storage-a tətbiq olunur.
Bu, əsas səbəb idi. Yenə də məlumat bazasının inkişafına praktik tələblər var, bu da deməkdir ki, sadə olmalıdır – az kod, mümkün qədər az pozulmuş şeylər olmalı, bunları yenidən yazmaq və sınaqdan keçirmək lazımdır. Bizim oploqların hibrid saatlarla indeksləşdirilməsi çox kömək etdi və düzgün seçimi etmək imkanı verdi. Bu, həqiqətən özünü doğrultdu və bir növ sehrli şəkildə işlədi, birinci prototipdə. Çox gözəl idi!
Saatların sinkronizasiyası
Elmi ədəbiyyatda təsvir olunan bir neçə sinxronizasiya üsulu vardır. Mən iki fərqli shard olduqda sinxronizasyadan danışıram. Əgər bir replikasiya seti varsa, burada heç bir sinxronizasiyaya ehtiyac yoxdur: bu ‘tək-master’dir; bütün dəyişikliklərin daxil olduğu OpLog adlı bir sistemimiz var - bu halda hər şey artıq ‘OpLog’ içində ardıcıl olaraq sıralanmışdır. Lakin iki fərqli shardımız varsa, burada zaman sinxronizasiyası vacibdir. Burada vektor saatları daha yaxşı kömək edir! Amma bizdə yoxdur.
İkinci üsul ‘Hearthbeats’dir. Zaman vahidində baş verən bəzi siqnalları mübadilə edə bilərsiniz. Lakin ‘Hearthbeats’ çox yavaşdır, müştərimiz üçün latency təmin edə bilmirik.
Doğru zaman - əlbəttə ki, əla bir şeydir. Amma, yenə də, bu, ehtimal ki, gələcəkdir… Lakin ‘Atlas’da artıq bunu edə bilərsiniz, artıq sürətli ‘Amazon’ sinxronizatorları var. Amma bu, hamı üçün əlçatan olmayacaq.
Gossiping - bu, bütün mesajların zaman məlumatını ehtiva etməsidir. Bu, təxminən istifadə etdiyimiz şeydir. Nodalardan, sürücü, marşrutlaşdırıcı data nodları arasında hər bir mesaj - tam ‘MongoDB’-də olan bu cür elementlər, verilənlər bazasının komponentləri var ki, içində axan saatlar var. Hər yerdə hibrid zamanda bir dəyəri mövcuddur, bu, ötürülür. 64 bit? Bu mümkündür, bu yararlıdır.
Bütün bunlar bir yerdə necə işləyir?
Burada bir replikasiya setini daha sadə başa düşmək üçün nəzərdən keçirirəm. Burada Primary və Secondary var. Secondary replikasiyanı həyata keçirir və həmişə tam olaraq Primary ilə sinxron olmur.
‘Primary’də müəyyən bir zaman dəyəri ilə bir insert olur. Bu insert daxili sayğacı 11 artırır, əgər bu maksimumdursa. Yoxsa, saat dəyərlərini yoxlayacaq və əgər saat dəyərləri daha çoxdursa, saatlarla sinxronlaşacaq. Bu isə zamanla sıralamağa imkan tanıyır.
O yazdıqdan sonra vacib bir an baş verir. ‘MongoDB’ dəki saatlar yalnız ‘OpLog’-da yazı olduğu halda artırılır. Bu sistemin vəziyyətini dəyişən hadisədir. Bütün klassik məqalələrdə hadisə, mesajın nod-a daxil olmasıdır: mesaj gəldi - deməli, sistem vəziyyətini dəyişdi.
Bu, araşdırma zamanı həmin mesajın necə şərh ediləcəyini tam başa düşməyin çətin olması ilə bağlıdır. Biz tamamilə bilirik ki, əgər o ‘OpLog’-da əks olunmayıbsa, o, heç bir şəkildə şərh edilməyəcək və sistemin vəziyyətini dəyişən yeganə şey ‘OpLog’-a yazıdır. Bu, hər şeyi asanlaşdırır: həm modelin sadələşməsini, həm də bir replikasiya seti çərçivəsində ardıcıllığı təmin etməyə imkan verir və bir çox digər faydalı şeyləri mümkün edir.
Dəyər, artıq «Oplog»da yazılıb – biz bilirik ki, «Oplog»da bu dəyər var, və onun vaxtı – 12. İndi, deyək ki, oxuma başqa bir noddan (İkincil) başlayır, və o artıq mesajda afterClusterTime-i ötürür. O deyir: «Mənə lazımdır, baş vermiş bütün hadisələr ən azı 12-dən sonra və ya on iki zamanı» (yuxarıdakı şəkilə baxın).
Buna Causal a consistent (CAT) deyilir. Teoriyada belə bir anlayış var ki, bu, öz-özünə konsistent olan bir zaman kəsiyidir. Bu halda, sistemin vəziyyəti, 12 vaxtında müşahidə olunan bir hal kimi ifadə oluna bilər.
İndiyə qədər burada heç nə yoxdur, çünki bu, İkincil-in Primary-dən məlumatları replikasiya etməsi lazım olan vəziyyəti simulyasiya edir. O gözləyir... və işte məlumatlar gəldi – o bu dəyərləri geri qaytarır.
Böyle işləyir. Demək olar ki.
«Demək olar ki» nə deməkdir? Gəlin fərz edək ki, tutaq ki, bir insan var, o, bunun necə işlədiyini oxuyub anladı. Anladı ki, hər dəfə ClusterTime olur, daxili lojiq saatları yeniləyir, və sonra növbəti yazı bir vahid artırır. Bu funksiyanın 20 sətiri var. Fərz edək ki, bu insan maksimum 64 bit-lik ədəd, bir vahid azdır.
Niyə «bir vahid azdır»? Çünki daxili saatlar bu dəyərə qoyulacaq (aşkar ki, bu indiki vaxtdan daha böyük ola bilər), sonra «Oplog»a yazılacaq, və saat bir vahid daha artırılacaq – və artıq maksimum dəyər olacaq (orada sadəcə bütün 1-lər var, daha irəliləyiş yoxdur, unsaint int-lar).
Aydındır ki, bundan sonra sistem tamamilə erişilməz olur. Onu yalnız yükləmək, təmizləmək olur – çoxlu əl işləri. Tam əlçatanlıq:
Həmçinin, əgər bu hara da replikasiya edilirsə, bütün klaster düşəcək. Tamamilə qəbul edilə bilməz bir vəziyyət, ki, hər kəs bunu çox sürətlə və asanlıqla təşkil edə bilər! Buna görə biz bu məsələyə ən vaciblərdən biri olaraq baxdıq. Bunu necə önləmək olar?
Bizim yolumuz – clusterTime-i imzalamaqdır.
Beləcə, bu mesajda ötürülür (mavi mətnə qədər). Ancaq biz eləcə də imza yaratmağa başladıq (mavi mətndə):
İmza, verilənlər bazasında, qorunan perimetrin içində saxlanılan açarla yaradılır; özü yaradılır, yenilənir (istifadəçilər bunun heç birini görmür). Hash yaradılır, və hər mesaj yaradılarkən imzalanır, alındıqda isə təsdiqlənir.
İnsanlarda sual yaranır: «Bu nə dərəcədə yavaşladır?» Deyirdim ki, bu xüsusiyyət olmadan xüsusilə sürətli işləməlidir.
Bu halda Causal consistency istifadə etmək nə deməkdir? Bu, afterClusterTime parametrini nümayiş etdirməkdir. Bunu etmədən, o, bütün hallarda dəyərləri ötürəcək. Gossiping, 3.6 versiyasından etibarən, həmişə işləyir.
Əgər biz daimi imza yaradılmasını saxlayarsaq, bu, sistemi yavaşladacaq, hətta xüsusiyyət olmadıqda belə; bu, bizim yanaşmalarımıza və tələblərimizə uyğun deyil. Bəs biz nə etdik?
Bunu tez et!
Əslində, olduqca sadə bir şey, amma maraqlı bir fənd - paylaşacağam, bəlkə kiminsə işinə yarayar.
Bizim imzalanmış məlumatları saxlayan bir həş var. Bütün məlumatlar kəşdən keçir. Kəş konkret zamana imza atmır, əksinə, aralığa imza atır. Müəyyən bir dəyər gəldikdə, biz aralığı yaradırıq, son 16 biti gizlədirik və bu dəyəri imzalayırıq:
Belə bir imza alaraq sistemi (şəxsən) 65 min dəfə sürətləndiririk. Bu, mükəmməl işləyir: eksperimentləri qoyanda – həqiqətən də 10 min dəfə ardıcıl yeniləmə zamanı azaldı. Aydındır ki, onlar bir-birinə qarışanda, bu, alınmır. Amma əksər praktik hallarda bu işləyir. Aralığın imzası ilə birgə imza təhlükəsizlik problemini həll etməyə kömək etdi.
Nə öyrəndik?
Bundan çıxardığımız dərslər:
- Fikirlər, hekayələr, məqalələr oxumaq lazımdır, çünki çox maraqlı şeylərimiz var. Biz müəyyən bir xüsusiyyət üzərində işləyərkən (xüsusilə indi, tranzaksiyalar etdiyimiz zaman və s.), oxumaq və başa düşmək lazımdır. Bu vaxt aparır, amma əslində çox faydalıdır, çünki yerləşdiyimiz yer aydın olur. Biz əslində yeni bir şey icad etməmişik - sadəcə inqrediyentləri götürmüşük.
Ümumiyyətlə, akademik konfrans olduğunda düşüncə sistemində müəyyən fərq olur (məsələn, «Sigmon»)- orada hamı yeni fikirlərə fokuslanır. Bizim algoritmimizin yeniliyi nədir? Burada xüsusi bir yenilik yoxdur. Yenilik daha çox məvcud yanaşmaları necə birləşdirdiyimizdədir. Buna görə birincisi - klassikləri, Ləmpartdan başlamaqla oxumaq lazımdır.
- İstehsalda tamamilə fərqli tələblər var. Mən əminəm ki, bir çoxunuz «sfarişedici» verilənlər bazaları ilə deyil, real, normal əşyalarla üzləşirsiniz, onların availability, latency və etibarsızlıq problemləri var.
- Sonuncusu - müxtəlif fikirlər üzərində düşünmək və ümumiyyətlə fərqli bir neçə məqaləni bir yanaşmada birləşdirmək məcburiyyətində qaldıq. İmza qoyma fikri, məsələn, Paxos protokolunu əhatə edən bir məqalədən gəldi, bu,.authorization protocolu içində olmayan qeyri-vizantiya Failorları üçün, vizantiya üçün isə – authorization xəttindən kənarda... Ümumiyyətlə, biz nə ilə nəticələnmişik.
Burada tamamilə yeni bir şey yoxdur! Amma biz bunları bir yerə qarışdırdıqdan sonra... Salat Olivier reseptinin sadəcə, yumurta, mayonez və xiyarların artıq icad olunduğu olduğu kimi, bunun mənası yoxdur deməsi kimidir... Bu, demək olar ki, eyni hekayədir.
Burada dayanacağam. Təşəkkür edirəm!
Suallar
İştirakçıdan sual (davamedir – V): – Təşəkkür edirəm, Mixail, təqdimat üçün! Zamanla bağlı mövzu maraqlıdır. Siz Gossiping istifadə edirsiniz. Dediniz ki, hər kəsin öz zamanını var, hamı öz yerli zamanını bilir. Mən belə anladım ki, bizdə sürücü var - müştərilərin sürücü ilə çox ola bilər, query-planner’lar da, shard-lar da çoxdur... Bəs sistem hansı vəziyyətə düşür, əgər bir anda bizdə uyğunsuzluq yaranarsa: kiminsə fikri var ki, o bir dəqiqə irəlidədir, kiminsə isə bir dəqiqə geridə? Biz harada olacağıq?
MT: – Əslində, əla sualdır! Mən də shard-lar haqqında danışmaq istəyirdim. Əgər sualı düzgün başa düşsəm, bizdə belə bir vəziyyət var: shard 1 və shard 2 var, oxuma bu iki shard-dan baş verir - onların arasında uyğunsuzluq var, çünki onların bildiyi zaman fərqlidir, xüsusən də onların log-larında mövcud olan zaman.
Götürək ki, shard 1 bir milyon qeydlər edib, shard 2 isə heç nə etməyib, amma sorğu iki shard-a gəlib. Birincisinin afterClusterTime dəyəri bir milyondan çoxdur. Belə bir vəziyyətdə, izah etdiyim kimi, shard 2 heç vaxt cavab verməyəcək.
A: – Mən bilmək istəyirdim, onlar necə senkronizə olunur və bir məntiqi zaman seçirlər?
MT: – Onlar çox asanlıqla senkronizə olurlar. Shard, afterClusterTime gəldiyi zaman, və o 'Optolog'da zaman tapmadığı zaman - no approved-i işə salır. Yəni özü öz zamanını bu dəyərə qaldırır. Bu, onun bu sorğuya uyğun hadisələrinin olmadığı deməkdir. O, bu hadisəni süni şəkildə yaradır və beləliklə Causal Consistent olur.
A: – Bəs, buna sonra şəbəkədə itən hadisələr gəlsə, nə olar?
MT: – Shard-lar belə yerləşir ki, artıq bu hadisələr gələ bilməz, çünki bu single master-dir. Əgər o, artıq qeyd edibsə, o, artıq gəlməmiş olacaq, yalnız sonrakılar olacaq. Belə ola bilməz ki, haradasa nəsə ilişib qalsın, sonra o, no write etsin, və bu hadisələr gəlsin - və Causal consistency pozulsun. O, no write etdikdə, hamısı gəlməlidir (o, onları gözləyəcək).
A: – Mənim bir neçə sualım var sıra ilə bağlı. Causal consistency müəyyən bir hərəkətlər sırasını nəzərdə tutur ki, bunlar icra olunmalıdır. Əgər bizim bir paketi itirsək, nə baş verəcək? 10-cu, 11-ci... 12-ci itdi, digərləri isə onun icrasını gözləyir. Və birdən bizim maşın sönür, heç nə edə bilmirik. İcra edilmədən əvvəl maksimum hansı uzunluqda sıra olmalıdır? Hər hansı bir vəziyyəti itirməkdə hansı fatal failure baş verir? Həm də, əgər biz yazırıqsa ki, əvvəlki bir vəziyyət var, deməli, biz buna əsaslanmalıyıq? Amma ondan əsaslanmamışıq!
MT: – Bu da gözəl sualdır! Bəs nə edirik? MongoDB-də kvorum qeydləri, kvorum oxuma anlayışı var. Hansi hallarda mesaj itə bilər? Qeydim qeyri-kvorumlu olduqda və ya oxuma qeyri-kvorumlu olduqda (həmçinin hansısa zibil də ola bilər).
Causal consistency ilə bağlı geniş bir eksperiment aparılmışdır ki, bunun nəticəsi göstərir ki, qeydlər və oxuma qeyri-kvorum olduqda, Causal consistency pozulmaları baş verir. Tam olaraq dediyiniz kimi!
Məsləhətimiz: Causal consistency istifadə edərkən, ən azı kvorum oxumaqdan istifadə edin. Bu halda, heç bir şey itəcək, hətta kvorum yazma itəcək... Bu ortogonal bir vəziyyətdir: istifadəçi məlumatların itməsini istəmirsə, kvorum yazmağı istifadə etməlidir. Causal consistency davamlılıq zəmanəti vermir. Davamlılıq zəmanətini replication və replication ilə bağlı mexanizm verir.
A: – Biz instance yaradırıq, hansı ki, şardinqi (master deyil, müvafiq olaraq slave) yerinə yetirir, o, öz qurğusunun unix vaxtına və ya 'master'ın vaxtına əsaslanır; ilk dəfə yoxsa mütəmadi olaraq sinkronizasiya edilir?
MT: – İndi açıqlayacam. Shard (yəni, horizontal partisiya) – burada həmişə Primary var. Və shard-da 'master' ola bilər və replika ola bilər. Lakin shard həmişə yazmağı dəstəkləyir, çünki o, müəyyən bir domeni dəstəkləməlidir (shard-da Primary yerləşir).
A: – Yəni, hər şey tamamilə 'master' dan asılıdır? Həmişə 'master' vaxtı istifadə olunur?
MT: – Bəli. İfada etmək üçün desək: saatlar tıqıltı edir, 'master'a yazma baş verdikdə, 'Opolog' da.
A: – Bizdə müştəri var, o qoşulur və onun vaxt haqqında heç bir şey bilməsinə ehtiyac yoxdur?
MT: – Ümumiyyətlə heç bir şey bilməsinə ehtiyac yoxdur! Müştəri necə işlədiyini desək: müştəri, Causal consistency istifadə etmək istədikdə, sessiya açmalıdır. İndi orada hər şey var: sessiyada tranzaksiyalar və hüquqları geri alma... Sessiya, müştəri ilə baş verən məntiqi hadisələrin sıralanmasıdır.
Əgər o, bu sessiyanı açır və orada Causal consistency istədiyini deyirsə (əgər sessiya standart olaraq Causal consistency dəstəkləyirsə), hər şey avtomatik işləyir. Driver bu zamanı yadda saxlayır və yeni mesaj alanda onu artırır. O, serverdən geri dönən əvvəlki cavabın nə olduğunu yadda saxlayır. Növbəti sorğu afterCluster ('bu vaxtdan daha çox') ehtiva edəcək.
Müştəridən tamamilə heç bir şey bilməsi tələb olunmur! Bu, onun üçün tamamilə şüşədir. Əgər insanlar bu funksiyaları istifadə edərsə, nə etməyə imkan verir? Birincisi, ikinci planda etibarlı oxumaq mümkündür: Primary-yə yazmaq mümkündür, geolokasiyalı replika edilmiş secondaries-dən oxumaq mümkündür və bunun işlədiyinə əmin olmaq mümkündür. Eyni zamanda, Primary-də yazılmış sessiyalar hələ də Secondary-yə ötürülə bilər, yəni sadəcə bir sessiya deyil, bir neçə sessiya istifadə etmək olar.
A: – Eventual consistency mövzusu yeni Compute science qatına - CRDT (Conflict-free Replicated Data Types) tipli məlumatlara çox bağlıdır. Siz bu məlumat tiplərinin verilənlər bazasına inteqrasiya edilməsi məsələsini müzakirə etmisinizmi və bunun haqqında nə deyə bilərsiniz?
MT: – Yaxşı sualdır! CRDT yazma münaqişələri üçün məna kəsb edir: MongoDB-də – single master.
A: – Mənim devopslardan bir sualım var. Müasir dünyada belə jezuityan vəziyyətlər olur ki, Bizans tipi bir uğursuzluq baş verir və qorunan perimetrin içinə düşmüş pis insanlar protokol ilə məşğul olmağa başlayıb, xüsusi şəkildə hazırlanmış paketlər göndərə bilirlərmi?
MT: – Qorunan perimetrin içindəki pis insanlar – Troya atı ilə eynidir! Qorunan perimetrin içindəki pis insanlar bir çox pis işlər görə bilərlər.
A: – Aydındır ki, serverdə sadəcə bir deşik qoymaq, bestizlik məqsədilə bütün bir fillər zooparkını ötürməyə və bütün klasteri daimi olaraq aşırmağa imkan vermək… Bərpa müddəti tələb edəcək… Sadəcə olaraq, bu, düz deyil. Digər tərəfdən, maraqlı bir sual var: Gerçək həyatda, təcrübədə belə daxili hücumların baş verdiyi vəziyyətlər olurmu?
MT: – Real həyatda security breach hallarına az rast gəldiyim üçün bunu demək çətindir – ola bilsin, açılır. Lakin inkişaf fəlsəfəsinə gəldikdə, biz belə düşünürük: bizim bir perimetrimiz var ki, bu da təhlükəsizlik işini görən uşaqları təmin edən bir qapı, divardır; və perimetrin daxilində istədiyimiz hər şeyi edə bilərik. Aydındır ki, baxış imkanı olan istifadəçilər var, bir də kataloqu silmək imkanı olan istifadəçilər var.
İstifadəçilərin hüquqlarından asılı olaraq, ziyanı, bəlkə də, siçan ola bilər, bəlkə də, fillə. Aydındır ki, tam hüquqlara malik istifadəçi istədiyini edə bilər. İstifadəçi məhdud hüquqlara sahib olduqda ziyan daha az ola bilər. Xüsusilə, o sistemi məhv edə bilmir.
A: – Qorunan perimetrdə kiminsə server üçün gözlənilməz protokollar formalaşdırmasına cəhd etməsi, serveri sarsıtmaq və şanslı olduqda bütün klasteri sarsıtmağa çalışması… Belə hallarda "çox yaxşı" olurmu?
MT: – Belə şeylər eşitməmişəm. Serveri belə yıxmağın sirri yoxdur. Protokoldan içəri girib, bir nəfərin özünü tanıtmış istifadəçi kimi, mesajda bir şey yazması ilə içəridən yıxmağı bacarması… Əslində mümkün deyil, çünki o, mütləq təsdiqlənəcək. İstəməyən istifadəçilər üçün bu təsdiqi dayandırma seçimi var – bu, onların problemləri; onlar, sadəcə olaraq, divarları öz əlləri ilə dağıtdılar və ora bir fillin daxil olmasına icazə verdilər… Ümumiyyətlə, bəlkə də, ustalar kimi geyinib gəlib onu çəkib çıxarmaq olar!
A: – Təşəkkür edirəm, hesabat üçün. Sergey ("Yandex"). "Mongo"da, Replica Set-də səs verən üzvlərin sayını məhdudlaşdıran bir sabit var və bu sabit 7-yə bərabərdir. Niyə bu sabitdir? Niyə bu, bir parametr deyil?
MT: – Bizim Replica Set-də 40 nod da olur. Həmişə əksəriyyət tələb olunur. Hansı versiya olduğunu bilmirəm…
A: – Replica Set-də səsverməyən üzvləri işə salmaq mümkündür, lakin səs verənlərin sayı maksimum 7 olmalıdır. Belə bir halda, əgər bizim Replica Set 3 məlumat mərkəzinə yayılıbsa, çıxış etməyi necə idarə edəcəyik? Bir məlumat mərkəzi asanlıqla bağlana bilər və başqa bir maşın da çıxış edə bilər.
MT: – Bu artıq hesabatın bir az xaricindədir. Bu ümumi bir sualdır. Bəlkə, sonra bunu izah edə bilərəm.
Bir az reklam 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Bizim məqalələrimizi bəyənirsiniz? Daha maraqlı materiallar görmək istəyirsiniz? Bizi dəstəkləyin, sifariş verərək və ya tanışlarınıza tövsiyə edərək. , Sizin üçün icad etdiyimiz bənzərsiz entry-level serverlərin analoqu: (RAID1 və RAID10 ilə variantlar, 24 nüvəyə qədər və 40GB DDR4-a qədər mövcuddur).
Dell R730xd, Amsterdamdakı Equinix Tier IV data mərkəzində iki dəfə ucuz? Yalnız bizdə Niderlandda! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — 99 $-dan! Bunun haqqında oxuyun
Mənbə: habr.com
