Növbəti HighLoad++ konfransı 6 və 7 aprel 2020-ci il tarixlərində Sankt-Peterburqda baş tutacaq.
Təfərrüatlar və biletlər . HighLoad++ Sibir 2019. Krasnoyarsk Zalı. 25 iyun, saat 12:00. Abstraktlar və .
Belə olur ki, praktiki tələblər nəzəriyyə ilə ziddiyyət təşkil edir, burada kommersiya məhsulu üçün vacib olan cəhətlər nəzərə alınmır. Bu məqalə kommersiya məhsulunun tələblərinə əsaslanan akademik tədqiqat əsasında Səbəb ardıcıllığı komponentlərinin yaradılması üçün müxtəlif yanaşmaların seçilməsi və birləşdirilməsi prosesini təqdim edir. Tələbələr məntiqi saatlara mövcud nəzəri yanaşmalar, asılılığın izlənilməsi, sistem təhlükəsizliyi, saat sinxronizasiyası və niyə MongoDB-nin müəyyən həllər üzərində qərar tutduğunu öyrənəcəklər.
Mixail Tyulenev (bundan sonra - MT): - Mən Səbəb ardıcıllığı 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, biz bunu təxminən iki il əvvəl etmişik.
Prosesdə mən çoxlu akademik Tədqiqatla tanış olmalı oldum, çünki bu xüsusiyyət yaxşı öyrənilib. Məlum oldu ki, heç bir məqalə istehsalda tələb olunana, çox güman ki, hər hansı bir istehsal proqramında olan çox xüsusi tələblər baxımından verilənlər bazasına uyğun gəlmir.
Akademik Tədqiqatın istehlakçısı olaraq ondan nəyisə necə hazırladığımızdan danışacağam ki, sonra istifadəçilərimizə rahat və istifadəsi təhlükəsiz olan hazır yemək kimi təqdim edə bilərik.
Səbəb ardıcıllığı. Gəlin anlayışları müəyyənləşdirək
Başlamaq üçün mən ümumi şəkildə Səbəb ardıcıllığının nə olduğunu demək istəyirəm. İki personaj var - Leonard və Penny ("The Big Bang Theory" serialı):
Deyək ki, Penni Avropadadır və Leonard onun üçün sürpriz qonaqlıq etmək istəyir. Və onu dost siyahısından atmaqdan, lentdəki bütün dostlarına yeniləmə göndərməkdən daha yaxşı bir şey düşünmür: "Gəlin Pennini xoşbəxt edək!" (Avropadadır, yatarkən bütün bunları görmür və görə bilmir, çünki orada yoxdur). Son anda o, bu yazını silir, “Lent”dən silir və girişi bərpa edir ki, heç nə görməsin və qalmaqal olmasın.
Hər şey yaxşıdır, amma tutaq ki, sistem paylanıb və işlər bir az da pis getməyib. Məsələn, hadisələr səbəb-nəticə əlaqəsi olmadan Penny-nin giriş məhdudiyyəti bu yazı göründükdən sonra baş verə bilər. Əslində, bu, bir iş funksiyasını yerinə yetirmək üçün Səbəb ardıcıllığının tələb olunduğu bir nümunədir (bu halda).
Əslində, bunlar verilənlər bazasının qeyri-trivial xüsusiyyətləridir - çox az adam onları dəstəkləyir. Gəlin modellərə keçək.
Ardıcıllıq Modelləri
Verilənlər bazalarında ardıcıllıq modeli nədir? Bu, paylanmış sistemin müştərinin hansı məlumatları və hansı ardıcıllıqla ala biləcəyinə dair verdiyi zəmanətlərdən bəziləridir.
Prinsipcə, bütün ardıcıllıq modelləri, paylanmış sistemin, məsələn, noutbukda bir qovşaqda işləyən sistemə nə qədər bənzədiyinə bağlıdır. Minlərlə geo-paylanmış "qovşaqlar" üzərində işləyən sistem, bütün bu xüsusiyyətlərin prinsipcə avtomatik olaraq yerinə yetirildiyi noutbuka bənzəyir.
Buna görə də, ardıcıllıq modelləri yalnız paylanmış sistemlərə aiddir. Əvvəllər mövcud olan və eyni şaquli miqyasda işləyən bütün sistemlər belə problemlərlə üzləşmirdi. Bir Bufer Keşi var idi və hər şey həmişə ondan çıxarılırdı.
Güclü model
Əslində, ilk model Güclüdür (yaxud tez-tez adlandırıldığı kimi yüksəliş qabiliyyəti xətti). Bu, baş verdiyi təsdiqləndikdən sonra hər dəyişikliyin sistemin bütün istifadəçilərinə görünməsini təmin edən ardıcıllıq modelidir.
Bu, verilənlər bazasındakı bütün hadisələr üçün qlobal sifariş yaradır. Bu, çox güclü bir tutarlılıq xüsusiyyətidir və ümumiyyətlə çox bahalıdır. Bununla belə, çox yaxşı dəstəklənir. Bu, sadəcə olaraq, çox bahalı və yavaşdır - yalnız nadir hallarda istifadə olunur. Buna yüksəlmə qabiliyyəti deyilir.
Spanner-də dəstəklənən başqa, daha güclü xüsusiyyət var - buna Xarici Ardıcıllıq deyilir. Bu barədə bir az sonra danışacağıq.
Səbəb
Növbəti səbəb Səbəbdir, məhz bu barədə danışırdım. Güclü və Səbəb arasında bir neçə başqa alt səviyyələr var ki, onlar haqqında danışmayacağam, lakin onların hamısı Səbəb səviyyəsinə qədər qaynayır. Bu, vacib bir modeldir, çünki bütün modellərin ən güclüsü, şəbəkə və ya arakəsmələrin mövcudluğunda ən güclü ardıcıllıqdır.
Səbəblər əslində hadisələrin səbəb əlaqəsi ilə bağlandığı bir vəziyyətdir. Çox vaxt onlar müştəri nöqteyi-nəzərindən hüquqlarınızı oxuyun kimi qəbul edilir. Müştəri bəzi dəyərləri müşahidə edərsə, keçmişdə olan dəyərləri görə bilməz. Artıq prefiks oxunuşlarını görməyə başlayır. Hamısı eyni şeyə gəlir.
Ardıcıllıq modeli kimi səbəblər serverdə hadisələrin qismən sıralanmasıdır, burada bütün müştərilərdən gələn hadisələr eyni ardıcıllıqla müşahidə olunur. Bu vəziyyətdə, Leonard və Penny.
Sonda
Üçüncü model son ardıcıllıqdır. Bu, tamamilə bütün paylanmış sistemlərin dəstəklədiyi şeydir, ümumiyyətlə məna kəsb edən minimal modeldir. Bu, aşağıdakıları ifadə edir: məlumatlarda bəzi dəyişikliklər olduqda, müəyyən bir nöqtədə onlar ardıcıl olur.
Belə bir anda o, heç nə demir, əks halda Xarici Ardıcıllığa çevriləcək - bu, tamamilə fərqli bir hekayə olardı. Buna baxmayaraq, bu çox məşhur bir modeldir, ən çox yayılmışdır. Varsayılan olaraq, paylanmış sistemlərin bütün istifadəçiləri Eventual Consistency-dən istifadə edirlər.
Bir neçə müqayisəli misal çəkmək istəyirəm:
Bu oxlar nə deməkdir?
- Gecikmə. Ardıcıllığın gücü artdıqca, o, aşkar səbəblərə görə böyüyür: daha çox giriş etməli, klasterdə iştirak edən bütün hostlar və qovşaqlardan məlumatların artıq orada olduğuna dair təsdiq almalısan. Müvafiq olaraq, Son Ardıcıllıq ən sürətli cavabdır, çünki orada, bir qayda olaraq, hətta yaddaşa köçürə bilərsiniz və bu, prinsipcə kifayət edəcəkdir.
- Mövcudluq. Bu, sistemin şəbəkə fasilələri, arakəsmələr və ya hər hansı bir nasazlıq olduqda cavab vermək qabiliyyəti kimi başa düşülürsə, ardıcıllıq modelinin azalması ilə səhvlərə dözümlülük artır, çünki bir hostun yaşaması bizim üçün kifayətdir. eyni zamanda bəzi məlumatlar verir. Son Davamlılıq məlumatlarla bağlı heç nəyə zəmanət vermir - hər şey ola bilər.
- anomaliyalar. Bu da təbii ki, anomaliyaların sayını artırır. Güclü Ardıcıllıqda onlar demək olar ki, heç vaxt mövcud olmamalıdırlar və Son Davamlılıqda onlar hər şey ola bilər. Sual yaranır: insanlar anomaliyaları ehtiva edirsə, Niyə Konsistensiyanı seçirlər? Cavab ondan ibarətdir ki, Son Davamlılıq modelləri tətbiq oluna bilər və anomaliyalar, məsələn, qısa müddət ərzində mövcuddur; oxumaq və daha çox və ya daha az oxumaq üçün ardıcıl məlumat üçün master istifadə etmək mümkündür; güclü ardıcıllıq modellərindən istifadə etmək çox vaxt mümkündür. Praktikada bu işləyir və tez-tez anomaliyaların sayı zamanla məhdudlaşır.
C.A.P teoremi
Ardıcıllıq, əlçatanlıq sözlərini görəndə ağlınıza nə gəlir? Düzdür - CAP teoremi! İndi mən mifi dağıtmaq istəyirəm... Mən deyiləm - gözəl məqalə, gözəl kitab yazan Martin Kleppman var.
CAP teoremi 2000-ci illərdə tərtib edilmiş prinsipdir ki, Ardıcıllıq, Əlçatımlılıq, Bölmələr: hər ikisini götürün və üçü seçmək mümkün deyil. Bu bir prinsip idi. Bir neçə il sonra Gilbert və Linch tərəfindən teorem kimi sübut edildi. Sonra mantra kimi istifadə olunmağa başladı - sistemlər CA, CP, AP və s. bölünməyə başladı.
Bu teorem əslində aşağıdakı hallar üçün sübut edilmişdir ... Birincisi, Əlçatımlılıq sıfırdan yüzlərə qədər davamlı dəyər kimi qəbul edilməmişdir (0 - sistem "ölüdür", 100 - tez cavab verir; biz bunu nəzərə almağa öyrəşmişik), lakin alqoritmin bir xüsusiyyəti olaraq, bütün icraları üçün məlumatları qaytarmasına zəmanət verir.
Cavab müddəti haqqında ümumiyyətlə bir söz yoxdur! 100 ildən sonra məlumatları qaytaran bir alqoritm var - mükəmməl incə mövcud alqoritm, CAP teoreminin bir hissəsidir.
İkincisi: bu dəyişikliklərin ölçüsü dəyişdirilə bilən xətt olmasına baxmayaraq, eyni açarın dəyərlərində dəyişikliklər üçün bir teorem sübut edilmişdir. Bu o deməkdir ki, əslində onlar praktiki olaraq istifadə edilmir, çünki modellər fərqlidir Son Konsistensiya, Güclü Davamlılıq (bəlkə də).
Niyə hamısı? CAP teoreminin sübut olunduğu formada praktiki olaraq tətbiq olunmamasına görə ondan nadir hallarda istifadə olunur. Nəzəri formada hər şeyi müəyyən mənada məhdudlaşdırır. İntuitiv olaraq doğru olan, lakin ümumiyyətlə, heç bir şəkildə sübut edilməmiş müəyyən bir prinsip ortaya çıxır.
Səbəb ardıcıllığı ən güclü modeldir
İndi baş verən budur ki, siz hər üç şeyi əldə edə bilərsiniz: Ardıcıllıq, Mövcudluq arakəsmələrdən istifadə etməklə. Xüsusilə, Causal tutarlılığı ən güclü ardıcıllıq modelidir, arakəsmələrin mövcudluğunda (şəbəkədə fasilələr) hələ də işləyir. Ona görə də bu, çox böyük maraq doğurur, ona görə də biz onu götürdük.
Birincisi, proqram tərtibatçılarının işini asanlaşdırır. Xüsusilə, serverdən böyük dəstəyin olması: bir müştərinin daxilində baş verən bütün qeydlərin başqa bir müştəriyə belə bir ardıcıllıqla gəlməsinə zəmanət verildikdə. İkincisi, arakəsmələri saxlayır.
MongoDB-nin daxili mətbəxi
Həmin naharı xatırlayıb mətbəxə keçirik. Mən sistem modeli haqqında danışacağam, yəni belə bir verilənlər bazası haqqında ilk dəfə eşidənlər üçün MongoDB nədir.
MongoDB (bundan sonra "MongoDB" adlandırılacaq) üfüqi miqyaslaşdırmanı, yəni parçalanmanı dəstəkləyən paylanmış sistemdir; və hər bir parçanın içərisində o, həmçinin məlumat ehtiyatını, yəni replikasiyanı dəstəkləyir.
"MongoDB"-də (relational verilənlər bazası deyil) parçalanma avtomatik balanslaşdırmanı həyata keçirir, yəni sənədlərin hər bir kolleksiyasını (və ya əlaqə məlumatları baxımından "cədvəl") parçalara ayırır və server onları avtomatik olaraq qəliblər arasında köçürür.
Müştəri üçün sorğuları paylayan Sorğu Router onun işlədiyi bəzi müştəridir. O, artıq harada və hansı məlumatların yerləşdiyini bilir, bütün sorğuları düzgün parçaya yönəldir.
Başqa bir vacib məqam: MongoDB tək master-dir. Bir Primary var - o, ehtiva etdiyi açarları dəstəkləyən qeydləri götürə bilər. Siz Multi-master yaza bilməzsiniz.
4.2 buraxılışını etdik - orada yeni maraqlı şeylər meydana çıxdı. Xüsusilə, onlar Lucene -search - dəqiq icra edilə bilən java-nı birbaşa Monqo-ya daxil etdilər və orada Elastica-da olduğu kimi Lucene vasitəsilə axtarış etmək mümkün oldu.
Və onlar yeni məhsul yaratdılar - Diaqramlar, o, Atlasda da mövcuddur (Monqonun öz bulududur). Onların Pulsuz Tier var - bununla oynaya bilərsiniz. Diaqramları çox bəyəndim - məlumatların vizuallaşdırılması, çox intuitiv.
Səbəb tutarlılığı olan maddələr
Bu mövzuda dərc edilmiş 230-a yaxın məqaləni saydım - Leslie Lampertdən. İndi yaddaşımdan bu materialların bəzi hissələrini sizə çatdıracağam.
Hər şey Lesli Lampertin 1970-ci illərdə yazdığı məqaləsi ilə başladı. Gördüyünüz kimi, bu mövzuda bəzi araşdırmalar hələ də davam edir. İndi Causal ardıcıllığı paylanmış sistemlərin inkişafı ilə əlaqədar maraq yaşayır.
Məhdudiyyətlər
Məhdudiyyətlər hansılardır? Bu, əslində əsas məqamlardan biridir, çünki istehsal sisteminin tətbiq etdiyi məhdudiyyətlər akademik məqalələrdə mövcud olan məhdudiyyətlərdən çox fərqlidir. Çox vaxt onlar olduqca süni olurlar.
- Birincisi, "MongoDB" əvvəllər dediyim kimi tək bir ustadır (bu, çox asanlaşdırır).
- Hesab edirik ki, sistem təxminən 10 min parçanı dəstəkləməlidir. Bu dəyəri açıq şəkildə məhdudlaşdıracaq heç bir memarlıq qərarı verə bilmərik.
- Bizdə bir bulud var, amma güman edirik ki, insan binar faylı yükləyəndə, onu laptopunda işlədəndə hələ də fürsətə malik olmalıdır və hər şey yaxşı işləyir.
- Tədqiqatda nadir hallarda istifadə olunan bir şeyi güman edirik: xarici müştərilər hər şeyi edə bilər. MongoDB açıq mənbədir. Müvafiq olaraq, müştərilər çox ağıllı, qəzəbli ola bilərlər - hər şeyi pozmaq istəyə bilərlər. Bizans fərziyyələrinin baş verə biləcəyini fərz edirik.
- Perimetrdən kənarda olan xarici müştərilər üçün bu, vacib bir məhdudiyyətdir: bu xüsusiyyət söndürülübsə, performansın azalması müşahidə edilməməlidir.
- Başqa bir məqam ümumiyyətlə antiakademikdir: əvvəlki versiyaların və gələcək versiyaların uyğunluğu. Köhnə sürücülər yeni yeniləmələri dəstəkləməlidir və verilənlər bazası köhnə sürücüləri dəstəkləməlidir.
Ümumiyyətlə, bütün bunlar məhdudiyyətlər qoyur.
Səbəb tutarlılığının komponentləri
İndi bəzi komponentlər haqqında danışacağam. Ümumiyyətlə Səbəb ardıcıllığını nəzərə alsaq, blokları seçə bilərik. Biz hansısa bloka aid olan işlərdən seçdik: Asılılığın İzlənməsi, saatların seçimi, bu saatların bir-biri ilə necə sinxronlaşdırıla biləcəyi və təhlükəsizliyi necə təmin etdiyimiz - bu, danışacağım şeylərin təxmini planıdır:
Tam Asılılığın İzlənməsi
Niyə lazımdır? Beləliklə, verilənlər təkrarlandıqda, hər bir qeyd, hər bir məlumat dəyişikliyi hansı dəyişikliklərdən asılı olduğu haqqında məlumat ehtiva edir. İlk və sadəlövh dəyişiklik, girişi olan hər bir mesajın əvvəlki mesajlar haqqında məlumatı ehtiva etməsidir:
Bu nümunədə qıvrımlı mötərizədə olan rəqəm rekord rəqəmlərdir. Bəzən dəyərləri olan bu qeydlər hətta bütünlüklə ötürülür, bəzən bəzi versiyalar köçürülür. Nəticə odur ki, hər bir dəyişiklik əvvəlki haqqında məlumat ehtiva edir (açıqcası, hamısını özündə daşıyır).
Nə üçün bu yanaşmadan (tam izləmə) istifadə etməməyə qərar verdik? Aydındır ki, bu yanaşma praktiki olmadığı üçün: sosial şəbəkədəki hər hansı dəyişiklik bu sosial şəbəkədəki bütün əvvəlki dəyişikliklərdən asılıdır, məsələn, hər yeniləmədə "Facebook" və ya "Vkontakte". Buna baxmayaraq, Tam Asılılığın İzlənməsi ilə bağlı çoxlu araşdırmalar var - bunlar sosial şəbəkələrdən əvvəldir, bəzi hallarda həqiqətən işləyir.
Açıq Asılılığın İzlənməsi
Növbəti daha məhduddur. Burada da məlumatın ötürülməsi nəzərdə tutulur, lakin yalnız açıq şəkildə asılı olan. Nədən asılıdır, bir qayda olaraq, artıq Tətbiq tərəfindən müəyyən edilir. Verilənlər təkrarlandıqda, sorğu yalnız əvvəlki asılılıqlar təmin edildikdə, yəni göstərildikdə cavabları qaytaracaq. Səbəb ardıcıllığının necə işlədiyinin mahiyyəti budur.
O, görür ki, 5-ci qeyd 1, 2, 3, 4 qeydlərindən asılıdır - müvafiq olaraq o, müştərinin Penny-nin giriş qaydası ilə edilən dəyişikliklərə daxil olmasını gözləyir, bütün əvvəlki dəyişikliklər verilənlər bazasında artıq keçib.
Bu da bizə uyğun gəlmir, çünki hələ çox məlumat var və bu, yavaşlayacaq. Başqa bir yanaşma var ...
Lamport saatı
Onlar çox qocalıblar. Lamport Saatı bu asılılıqların Lamport Saatı adlanan skalyar funksiyaya qatlanması deməkdir.
Skayar funksiya bəzi mücərrəd ədəddir. Buna çox vaxt məntiqi vaxt deyilir. Hər hadisə ilə bu sayğac artır. Hazırda prosesə məlum olan Sayğac hər mesajı göndərir. Aydındır ki, proseslər sinxronizasiya oluna bilər, onların tamam başqa vaxtları ola bilər. Buna baxmayaraq, belə bir mesaj mübadiləsi ilə sistem birtəhər saatı tarazlaşdırır. Bu halda nə baş verir?
Aydın olmaq üçün o böyük parçanı ikiyə böldüm: Dostlar kolleksiyanın bir hissəsini ehtiva edən bir qovşaqda yaşaya bilər və Lent bu kolleksiyanın bir hissəsini ehtiva edən başqa qovşaqda yaşaya bilər. Görürəm, onlar xəttdən necə çıxa bilirlər? Lent əvvəlcə "Təkrarlandı", sonra isə Dostlar deyəcək. Sistem Dostlar kolleksiyasındakı Dostlardan asılılıqlar da çatdırılmayana qədər Lentin göstərilməyəcəyinə dair müəyyən zəmanət vermirsə, o zaman qeyd etdiyim vəziyyətə tam olaraq sahib olacağıq.
Lentdə əks vaxtın məntiqi olaraq necə artdığını görə bilərsiniz:
Beləliklə, bu Lamport Saatının və Səbəb ardıcıllığının əsas xüsusiyyəti (Lamport Saatı vasitəsilə izah olunur) belədir: əgər bizdə A və B hadisələri varsa və B hadisəsi A* hadisəsindən asılıdırsa, onda A hadisəsinin Məntiqi Zamanı ondan azdır. Hadisə B-dən LogicalTime.
* Bəzən də deyirlər ki, A B-dən əvvəl olub, yəni A B-dən əvvəl olub - bu, ümumiyyətlə baş verən bütün hadisələr toplusunu qismən sifariş edən bir növ münasibətdir.
Bunun əksi səhvdir. Bu, əslində Lamport Clock-un əsas çatışmazlıqlarından biridir - qismən sifariş. Sinxron hadisələr anlayışı var, yəni nə (A B-dən əvvəl olub), nə də (A B-dən əvvəl baş verib). Buna misal olaraq Leonardın başqasının dostu kimi əlavə edilməsini göstərmək olar (hətta Leonard yox, məsələn, Sheldon).
Bu, Lamport saatları ilə işləyərkən tez-tez istifadə olunan xüsusiyyətdir: onlar funksiyaya baxır və bundan bir nəticə çıxarırlar - bəlkə də bu hadisələr asılıdır. Çünki bunun bir yolu doğrudur: Əgər LogicalTime A LogicalTime B-dən azdırsa, B A-dan əvvəl baş verə bilməz; və əgər daha çoxsa, bəlkə də.
Vektor saatı
Lamport saatının məntiqi inkişafı vektor saatıdır. Onlar bir-birindən fərqlənir ki, burada olan hər bir node özünəməxsus, ayrıca saatı ehtiva edir və onlar vektor kimi ötürülür.
Bu halda, vektorun sıfır indeksinin Feed üçün cavabdeh olduğunu və vektorun ilk indeksinin Dostlar (bu qovşaqların hər biri) üçün olduğunu görə bilərsiniz. İndi onlar artacaq: sıfır indeksi "Fida" yazarkən artır - 1, 2, 3:
Vector Clock niyə daha yaxşıdır? Hansı hadisələrin eyni vaxtda olduğunu və müxtəlif qovşaqlarda nə vaxt baş verdiyini anlamağa imkan verənlər. Bu, MongoDB kimi bir parçalanma sistemi üçün çox vacibdir. Ancaq biz bunu seçmədik, baxmayaraq ki, bu gözəl bir şeydir və əla işləyir və yəqin ki, bizə yaraşar ...
10 min parçamız varsa, 10 min komponenti köçürə bilmərik, hətta sıxsaq, başqa bir şeylə qarşılaşırıq - eyni zamanda faydalı yük bütün bu vektorun həcmindən dəfələrlə az olacaq. Ona görə də ürəyimizi və dişlərimizi sıxaraq bu yanaşmadan əl çəkib başqasına keçdik.
True Time açarı. atom saatı
Dedim ki, Spanner haqqında hekayə olacaq. Bu, XNUMX-ci əsrdə gözəl bir şeydir: atom saatları, GPS sinxronizasiyası.
Fikir nədir? "Spanner" hətta bu yaxınlarda insanlar üçün əlçatan olan bir Google sistemidir (onlar SQL-i ona əlavə etdilər). Orada hər bir əməliyyatın müəyyən vaxt möhürü var. Vaxt sinxronlaşdırıldığından *, hər bir hadisəyə müəyyən vaxt təyin edilə bilər - atom saatlarının gözləmə müddəti var, bundan sonra başqa vaxtın "baş verəcəyi" təmin edilir.
Beləliklə, sadəcə olaraq verilənlər bazasına yazılmaqla və bir müddət gözləməklə, hadisənin Serializasiyasına avtomatik zəmanət verilir. Onlar prinsipcə təsəvvür edilə bilən ən güclü Ardıcıllıq modelinə malikdirlər - bu, Xarici Ardıcıllıqdır.
* Bu, Lampart saatlarının əsas problemidir - onlar paylanmış sistemlərdə heç vaxt sinxron olmurlar. Onlar ayrıla bilər, hətta NTP ilə də hələ də çox yaxşı işləmirlər. "Spanner" atom saatına malikdir və zamanlama mikrosaniyə kimi görünür.
Niyə seçmədik? İstifadəçilərimizin daxili atom saatlarına sahib olduğunu düşünmürük. Onlar çıxdıqda, hər bir noutbukda quraşdırılmış, super sərin GPS sinxronizasiyası olacaq - sonra bəli ... Bu arada, mümkün olan ən yaxşı şey Amazon, Baza Stansiyalarıdır - fanatiklər üçün ... Ona görə də biz başqa saatlardan istifadə etdik.
Hibrid Saat
Səbəb ardıcıllığını təmin edərkən "MongoDB"-də qeyd olunan budur. Onlar hibrid nədir? Hibrid skalyar dəyərdir, lakin onun iki komponenti var:
- Birincisi unix dövrüdür (“kompüter dünyasının başlanğıcından” neçə saniyə keçib).
- İkincisi bəzi artımdır, həmçinin 32 bitlik imzasız int.
Bu, əslində, hamısıdır. Belə bir yanaşma var: vaxta cavabdeh olan hissə hər zaman saatla sinxronlaşdırılır; hər dəfə yeniləmə baş verəndə bu hissə saatla sinxronlaşdırılır və məlum olur ki, vaxt həmişə az və ya çox düzgündür və artım eyni vaxtda baş verən hadisələri ayırd etməyə imkan verir.
Bu MongoDB üçün niyə vacibdir? Çünki bu, müəyyən bir vaxtda bir növ ehtiyat nüsxəsini bərpa etməyə imkan verir, yəni hadisə zamana görə indeksləşdirilir. Bəzi tədbirlərə ehtiyac olduqda bu vacibdir; verilənlər bazası üçün hadisələr verilənlər bazasında müəyyən zaman aralığında baş verən dəyişikliklərdir.
Yalnız sənə deyəcəyimin ən böyük səbəbi (zəhmət olmasa heç kimə demə)! Biz bunu etdik, çünki sifarişli, indeksləşdirilmiş məlumat MongoDB OpLog-da belə görünür. OpLog verilənlər bazasında tamamilə bütün dəyişiklikləri ehtiva edən məlumat strukturudur: onlar əvvəlcə OpLog-a gedirlər, sonra isə təkrarlanan tarix və ya parça olduğu halda onlar artıq Yaddaşın özünə tətbiq edilir.
Əsas səbəb bu idi. Yenə də bazanın inkişafı üçün praktiki tələblər də var, bu o deməkdir ki, sadə olmalıdır - kiçik kod, yenidən yazılmalı və sınaqdan keçirilməli olan mümkün qədər az qırıq şey. Oploqlarımızın hibrid saatlar tərəfindən indeksləşdirilməsi çox kömək etdi və düzgün seçim etməyimizə imkan verdi. Bu, həqiqətən özünü doğrultdu və ilk prototipdə bir növ sehrli şəkildə qazandı. Çox gözəl idi!
Saat sinxronizasiyası
Elmi ədəbiyyatda təsvir edilən bir neçə sinxronizasiya metodu var. İki fərqli parçamız olduqda sinxronizasiyadan danışıram. Bir replika dəstdirsə, orada heç bir sinxronizasiya tələb olunmur: bu, “tək ustadır”; bizdə bütün dəyişikliklərin düşdüyü bir OpLog var - bu halda, hər şey artıq Oplogun özündə ardıcıl olaraq sıralanır. Ancaq iki fərqli parçamız varsa, burada zaman sinxronizasiyası vacibdir. Burada vektor saatı daha çox kömək etdi! Amma bizdə bunlar yoxdur.
İkincisi Ürək döyüntüsüdür. Hər zaman vahidində baş verən bəzi siqnalları mübadilə etmək mümkündür. Ancaq "Ürək döyüntüləri" çox yavaşdır, biz müştərimizə gecikmə təmin edə bilmirik.
Həqiqi vaxt, əlbəttə ki, gözəl bir şeydir. Ancaq yenə də bu, yəqin ki, gələcəkdir... Bunu Atlasda artıq etmək mümkün olsa da, artıq sürətli “Amazon” vaxt sinxronizatorları mövcuddur. Ancaq hər kəs üçün əlçatan olmayacaq.
Qeybət, bütün mesajların vaxt ehtiva etməsidir. Təxminən istifadə etdiyimiz budur. Qovşaqlar arasındakı hər mesaj, bir sürücü, məlumat node yönləndiricisi, MongoDB üçün tamamilə hər şey bir növ elementdir, axan saatları ehtiva edən verilənlər bazası komponentləridir. Onların hər yerdə hibrid zaman dəyəri var, ötürülür. 64 bit? İmkan verir, mümkündür.
Hamısı birlikdə necə işləyir?
Burada bir az asanlaşdırmaq üçün bir replika dəstini nəzərdən keçirirəm. İbtidai və Orta var. İkinci dərəcəli replikasiya edir və həmişə İbtidai ilə tam sinxronlaşdırılmır.
"İlkin"də müəyyən vaxt dəyəri olan əlavə (insert) var. Bu əlavə, maksimumdursa, daxili sayğacı 11 artırır. Və ya saat dəyərlərini yoxlayacaq və saat dəyərləri böyükdürsə, saatla sinxronizasiya edəcəkdir. Bu, vaxta görə sıralamağa imkan verir.
O qeyd etdikdən sonra mühüm an baş verir. Saat "MongoDB"-dədir və yalnız "Oploq"a yazıldıqda artırılır. Bu, sistemin vəziyyətini dəyişən hadisədir. Mütləq bütün klassik məqalələrdə hadisə qovşağına dəyən bir mesaj hesab olunur: mesaj gəldi, bu o deməkdir ki, sistem öz vəziyyətini dəyişib.
Bunun səbəbi, araşdırma zamanı bu mesajın necə şərh ediləcəyini anlamaq tamamilə mümkün deyil. Biz dəqiq bilirik ki, əgər o, “Oploq”da əksini tapmasa, o zaman heç bir şəkildə şərh olunmayacaq və sistemin vəziyyətindəki dəyişiklik “Oploq”da sadəcə bir girişdir. Bu, bizim üçün hər şeyi sadələşdirir: həm model sadələşdirir, həm də tək replika dəsti daxilində sifariş verməyə imkan verir, həm də bir çox başqa faydalı şeylər.
Artıq “Oploq”a yazılan dəyər qaytarılır – biz bilirik ki, bu dəyər artıq “Oploq”dadır və onun vaxtı 12-dir. İndi deyək ki, oxu başqa qovşaqdan (İkinci dərəcəli) başlayır və o, artıq mesajda sonra ClusterTime keçir. O deyir: "Mən ən azı 12-dən sonra və ya on iki ərzində baş verən hər şeyi istəyirəm" (yuxarıdakı şəkilə baxın).
Buna Causal a ardıcıl (CAT) deyilir. Nəzəriyyədə belə bir anlayış var ki, bu, özlüyündə ardıcıl olan bir zaman dilimidir. Bu halda deyə bilərik ki, bu, 12-ci anda müşahidə edilən sistemin vəziyyətidir.
Hal-hazırda burada hələ heç nə yoxdur, çünki bu növ İkinciliyin İlkin məlumatı təkrarlamasını istədiyiniz vəziyyəti təqlid edir. Gözləyir... İndi məlumatlar gəldi - bu dəyərləri geri qaytarır.
Demək olar ki, hamısı belə işləyir. Təxminən.
"Demək olar ki," nə deməkdir? Tutaq ki, hər şeyin necə işlədiyini oxuyan və başa düşən bir adam var. Başa düşdüm ki, hər dəfə ClusterTime baş verəndə o, daxili məntiqi saatı yeniləyir, sonra isə növbəti rekord bir dəfə artır. Bu funksiya 20 sətir çəkir. Tutaq ki, bu şəxs mümkün olan ən böyük 64 bitlik ədədi, mənfi bir rəqəmi ötürür.
Niyə "mənfi bir"? Daxili saat bu dəyərlə əvəzlənəcəyi üçün (aydındır ki, bu, mümkün olan ən böyük və indiki vaxtdan daha çoxdur), sonra "Oplog" da bir giriş baş verəcək və saat daha bir artacaq - və artıq olacaq ümumi olaraq maksimum dəyər olmalıdır (yalnız bütün vahidlər var, daha heç bir yerdə yoxdur, müqəddəs ints).
Aydındır ki, bundan sonra sistem heç bir şey üçün tamamilə əlçatmaz olur. Yalnız boşaltmaq, təmizləmək olar - bir çox əl işi. Tam mövcudluq:
Üstəlik, başqa yerdə təkrarlanırsa, bütün klaster sadəcə olaraq aşağı düşür. Hər kəsin çox tez və asanlıqla təşkil edə biləcəyi tamamilə qəbuledilməz bir vəziyyət! Ona görə də biz bu anı ən vacib məqamlardan biri hesab etdik. Bunun qarşısını necə almaq olar?
Bizim yolumuz clusterTime imzalamaqdır
Mesajda (mavi mətndən əvvəl) belə ötürülür. Ancaq biz də imza yaratmağa başladıq (mavi mətn):
İmza verilənlər bazasında, təhlükəsiz perimetr daxilində saxlanılan açar tərəfindən yaradılır; özü yaradılır, yenilənir (istifadəçilər bunu görmür). Hash yaradılır və yaradılan zaman hər bir mesaj imzalanır və qəbul edildikdə təsdiqlənir.
Yəqin ki, insanların bir sualı var: "Bu, işləri nə qədər ləngidir?" Mən sizə dedim ki, bu, xüsusən də bu xüsusiyyət olmadıqda tez işləməlidir.
Bu halda Səbəb ardıcıllığından istifadə etmək nə deməkdir? Bu, afterClusterTime parametrini göstərmək üçündür. Və onsuz, hər halda dəyərləri keçəcək. Qeybət, 3.6 versiyasından bəri həmişə işləyir.
İmzaların daimi nəslini tərk etsək, bu, yanaşmalarımıza və tələblərimizə uyğun gəlməyən bir xüsusiyyət olmadıqda belə sistemi yavaşlatacaq. Bəs biz nə etmişik?
Tez edin!
Kifayət qədər sadə bir şey, amma maraqlı bir hiylə - paylaşacam, bəlkə kimsə maraqlanacaq.
İmzalanmış məlumatları saxlayan bir hashımız var. Bütün məlumatlar keşdən keçir. Keş xüsusi olaraq vaxtı deyil, Aralığı işarələyir. Bəzi dəyər daxil olduqda, biz Aralıq yaradır, son 16 biti maskalayırıq və bu dəyəri imzalayırıq:
Belə bir imza əldə etməklə sistemi (şərti olaraq) 65 dəfə sürətləndiririk. Əla işləyir: təcrübələr qurulanda, ardıcıl yeniləməyə malik olduğumuz zaman əslində vaxt 10 min dəfə azaldı. Aydın məsələdir ki, onlar ixtilafda olanda bu işə yaramır. Ancaq əksər praktik hallarda işləyir. Range imzasının imza ilə birləşməsi təhlükəsizlik problemini həll etdi.
Biz nə öyrəndik?
Bundan öyrəndiyimiz dərslər:
- Materialları, hekayələri, məqalələri oxumalıyıq, çünki çox maraqlı şeylərimiz var. Biz hansısa funksiya üzərində işləyərkən (xüsusilə indi, əməliyyatlar etdikdə və s.) oxumaq, anlamaq lazımdır. Bu, vaxt tələb edir, amma əslində çox faydalıdır, çünki harada olduğumuzu aydınlaşdırır. Yeni bir şey tapmadıq, sadəcə inqrediyentləri götürdük.
Ümumiyyətlə, akademik konfrans olanda (məsələn, Siqmon) təfəkkürdə müəyyən fərq olur - hamı yeni ideyalara köklənir. Alqoritmimizin yeniliyi nədir? Burada xüsusi bir şey yoxdur. Əksinə, yenilik mövcud yanaşmaları necə birləşdirdiyimizdədir. Ona görə də ilk iş Lampartdan başlayaraq klassikləri oxumaqdır.
- İstehsalda tələblər tamamilə fərqlidir. Əminəm ki, bir çoxunuz mücərrəd vakuumda "sferik" verilənlər bazaları ilə deyil, mövcudluq, gecikmə və nasazlığa dözümlülük problemləri olan normal, real şeylərlə məşğul olursunuz.
- Ən son odur ki, biz müxtəlif ideyaları nəzərdən keçirməli və bir neçə tamamilə fərqli məqaləni bir yanaşmada, birlikdə birləşdirməli olduq. Məsələn, imzalanma ideyası ümumiyyətlə Paxos protokolunu nəzərdən keçirən məqalədən qaynaqlanır ki, bu protokol qeyri-Bizanslılar üçün icazə protokolunun daxilində, Bizanslılar üçün isə icazə protokolundan kənardır... Ümumiyyətlə, biz məhz budur. etməklə sona çatdı.
Burada tamamilə yeni heç nə yoxdur! Amma hamısını qarışdıran kimi... Olivier salatının reseptinin cəfəngiyyat olduğunu söyləmək kimi bir şeydir, çünki yumurta, mayonez və xiyar artıq icad edilib... Söhbət eyni hekayədən gedir.
Bununla bitirəcəm. Çox sağ ol!
Suallar
Tamaşaçıların sualı (bundan sonra - B): Hesabat üçün Michaela təşəkkür edirik! Zaman mövzusu maraqlıdır. Qeybətdən istifadə edirsən. Dedilər ki, hər kəsin öz vaxtı var, hər kəs yerli vaxtını bilir. Başa düşürəm ki, bizdə bir sürücü var - sürücüləri olan çoxlu müştəri ola bilər, sorğu-planlayıcılar da, çoxlu qırıntılar da ola bilər... Və birdən-birə uyğunsuzluq yaranarsa, sistem nəyə sürüşür: kimsə qərar verir ki, o bir dəqiqə qabaqda, kimsə - bir dəqiqə geridə? Biz harada olacağıq?
MT: - Əla sualdır! Mən sadəcə qırıntılar haqqında demək istədim. Əgər sualı düzgün başa düşdümsə, bizdə belə bir vəziyyət yaranıb: 1-ci və 2-ci qəlpə var, oxumaq bu iki qəlpədən baş verir - uyğunsuzluq var, bir-biri ilə əlaqə saxlamırlar, çünki bildikləri zaman fərqlidir, Xüsusilə onlar oploglarda mövcuddurlar.
Deyək ki, shard 1 milyon qeyd etdi, shard 2 heç bir şey etmədi və sorğu iki parçaya gəldi. Birincisində isə bir milyondan çox AfterClusterTime var. Belə bir vəziyyətdə, izah etdiyim kimi, shard 2 heç vaxt cavab verməyəcək.
IN: - Bilmək istərdim ki, onlar necə sinxronlaşır və bir məntiqi vaxt seçirlər?
MT: - Sinxronizasiya etmək çox asandır. Bir parça, afterClusterTime ona gəldikdə və Oploqda vaxt tapmayanda, təsdiqlənmir. Yəni vaxtını əli ilə bu dəyərə qaldırır. Bu o deməkdir ki, onun bu sorğuya uyğun hadisəsi yoxdur. O, bu hadisəni süni şəkildə yaradır və beləliklə, Causal Consistent olur.
IN: - Bəs bundan sonra onun başına şəbəkədə hardasa itmiş hadisələr gəlsə?
MT: - Shard tək usta olduğu üçün gəlməyəcək şəkildə düzülüb. Əgər o, artıq yazıbsa, o zaman artıq gəlməyəcəklər, ancaq sonra olacaqlar. Ola bilməz ki, nəsə bir yerdə ilişib qalıb, sonra yazılmayacaq, sonra bu hadisələr gəldi - və Səbəb ardıcıllığı pozuldu. O, heç bir şey yazmadıqda, hamısı gələcək (onları gözləyəcək).
IN: – Növbələrlə bağlı bir neçə sualım var. Səbəb ardıcıllığı, yerinə yetirilməli olan hərəkətlərin müəyyən növbəsinin olmasını nəzərdə tutur. Bir paketi itirsək nə olar? Budur, 10-cu gəlir, 11-ci... 12-si getdi, hamı onun gerçəkləşməsini gözləyir. Və birdən maşınımız öldü, əlimizdən heç nə gəlmir. İcra edilməzdən əvvəl yığılan maksimum növbə uzunluğu varmı? Hər hansı bir dövlət itirildikdə hansı ölümcül uğursuzluq baş verir? Üstəlik, bir növ əvvəlki vəziyyətin olduğunu yazsaq, onda birtəhər ondan başlamalıyıq? Və onu itələməyiblər!
MT: - Bu da əla sualdır! Biz nə edirik? MongoDB kvorum yazır, kvorum oxuyur anlayışına malikdir. Hansı hallarda mesaj yox ola bilər? Yazma kvorum olmadıqda və ya oxuma kvorum olmadıqda (bir növ zibil də yapışa bilər).
Səbəb ardıcıllığına gəlincə, böyük bir eksperimental yoxlama aparıldı, nəticədə yazma və oxuma kvorum olmadığı halda Səbəb ardıcıllığının pozulması baş verir. Tam dediyiniz şey!
Məsləhətimiz Səbəb ardıcıllığından istifadə edərkən ən azı oxunan kvorumdan istifadə etməkdir. Bu halda, kvorum qeydi itirilsə belə, heç nə itirilməyəcək... Bu ortoqonal vəziyyətdir: əgər istifadəçi məlumatların itirilməsini istəmirsə, kvorum qeydindən istifadə edilməlidir. Səbəb ardıcıllığı davamlılığa zəmanət vermir. Davamlılığa replikasiya və təkrarlama ilə əlaqəli mexanizm zəmanət verilir.
IN: - Sharding-in bizim üçün yerinə yetirdiyi bir nümunə yaratdıqda (müvafiq olaraq master deyil, quldur), o, öz maşınının unix vaxtına və ya "master" vaxtına əsaslanır; İlk dəfə və ya vaxtaşırı sinxronizasiya edilir?
MT: - İndi dəqiqləşdirərəm. Shard (yəni üfüqi bölmə) - orada həmişə İlkin var. Bir parçada "usta" ola bilər və replikalar ola bilər. Lakin parça hər zaman yazıla bilər, çünki o, hansısa domeni dəstəkləməlidir (kölgənin Əsas var).
IN: - Yəni hər şey sırf “usta”dan asılıdır? “Master” vaxtı həmişə istifadə olunurmu?
MT: - Bəli. Obrazlı demək olar: “master”də, “Oploq”da rekord vurulanda saat tıqqıldadır.
IN: - Bizi birləşdirən müştərimiz var və onun vaxt haqqında heç nə bilməsinə ehtiyac yoxdur?
MT: “Həqiqətən heç nə bilməyə ehtiyac yoxdur! Müştəri üzərində necə işlədiyindən danışsaq: müştəri Causal ardıcıllığından istifadə etmək istədikdə, sessiya açmalıdır. İndi hər şey var: həm seansda əməliyyatlar, həm də hüquqları əldə etmək ... Sessiya müştəri ilə baş verən məntiqi hadisələrin sıralanmasıdır.
Əgər o, bu sessiyanı açıb orada desə ki, Səbəb ardıcıllığı istəyir (əgər sessiya defolt olaraq Səbəb ardıcıllığını dəstəkləyirsə), hər şey avtomatik işləyir. Sürücü bu vaxtı xatırlayır və yeni mesaj aldıqda onu artırır. Məlumatı qaytaran serverdən əvvəlkinin hansı cavabı qaytardığını xatırlayır. Növbəti sorğuda afterCluster ("zaman bundan böyükdür") olacaq.
Müştərinin mütləq heç nə bilməsi lazım deyil! Onun üçün tamamilə qeyri-şəffafdır. İnsanlar bu xüsusiyyətlərdən istifadə edirlərsə, bu, onlara nə etməyə imkan verir? Birincisi, siz ikinci dərəcəliləri etibarlı şəkildə oxuya bilərsiniz: siz Primary-ə yaza və coğrafi olaraq təkrarlanan ikinci proqramlardan oxuya və onun işlədiyinə əmin ola bilərsiniz. Eyni zamanda, Primary-də qeydə alınan seanslar hətta İkinciliyə köçürülə bilər, yəni bir deyil, bir neçə seansdan istifadə edə bilərsiniz.
IN: - Hesablama elminin yeni təbəqəsi Son ardıcıllıq - CRDT (Conflict-free Replicated Data Types) məlumat növləri mövzusu ilə sıx bağlıdır. Bu məlumat növlərini verilənlər bazasına inteqrasiya etməyi düşünmüsünüzmü və bu barədə nə deyə bilərsiniz?
MT: - Yaxşı sual! CRDT yazı konfliktləri üçün məna kəsb edir: MongoDB-nin tək master var.
IN: – Mənim devoplardan bir sualım var. Real dünyada, Bizans Uğursuzluğu baş verdikdə və qorunan perimetrdəki pis insanlar protokola yapışmağa, sənətkarlıq paketlərini xüsusi bir şəkildə göndərməyə başlayanda belə Cizvit vəziyyətləri var?
MT: "Perimetr daxilindəki pis insanlar Troya atı kimidir!" Perimetr daxilində pis insanlar çox pis şeylər edə bilərlər.
IN: – Aydındır ki, serverdə, kobud desək, fillərin zooparkını yapışdıra və bütün klasteri əbədi olaraq çökdürə biləcəyiniz bir boşluq buraxmaq ... Əllə bərpa etmək üçün vaxt lazımdır ... Bu, yumşaq desək, belədir. səhv. Digər tərəfdən, aşağıdakılar maraqlıdır: real həyatda, praktikada təbii olaraq oxşar daxili hücumların baş verdiyi vəziyyətlər varmı?
MT: – Real həyatda təhlükəsizlik pozuntuları ilə nadir hallarda rastlaşdığım üçün onların baş verib-vermədiyini deyə bilmərəm. Ancaq inkişaf fəlsəfəsindən danışsaq, onda belə düşünürük: təhlükəsizliyi təmin edən oğlanları təmin edən perimetrimiz var - bu qala, divardır; və perimetr daxilində istədiyinizi edə bilərsiniz. Aydındır ki, yalnız baxmaq imkanı olan istifadəçilər var, kataloqu silmək imkanı olan istifadəçilər də var.
Hüquqlardan asılı olaraq, istifadəçilərin edə biləcəyi zərər siçan və ya fil ola bilər. Aydındır ki, tam hüquqlu bir istifadəçi ümumiyyətlə hər şeyi edə bilər. Məhdud hüquqları olan istifadəçi daha az zərər verə bilər. Xüsusilə sistemi poza bilməz.
IN: - Qorunan perimetrdə kimsə serveri xərçəngə salmaq üçün server üçün gözlənilməz protokollar yaratmağa dırmaşdı və şanslısınızsa, onda bütün klaster ... Bu qədər "yaxşı" ola bilərmi?
MT: “Mən heç vaxt belə şeylər eşitməmişəm. Bu yolla serveri doldura biləcəyiniz sirr deyil. İçəri doldurmaq, protokoldan olmaq, mesaja belə bir şey yaza bilən səlahiyyətli istifadəçi olmaq... Əslində bu mümkün deyil, çünki hələ də yoxlanılacaq. İstəməyən istifadəçilər üçün bu autentifikasiyanı söndürmək mümkündür - bu, onların problemidir; Kobud desək, divarları özləri dağıdıblar və ora fili soxmaq olar, o da onu əzəcək... Ümumiyyətlə, təmirçi geyinib, gəlib çıxartmaq olar!
IN: - Hesabat üçün təşəkkür edirik. Sergey (Yandex). Monqanın Replika Setində səs verən üzvlərin sayını məhdudlaşdıran sabiti var və bu sabit 7 (yeddi) təşkil edir. Niyə daimidir? Niyə bu bir növ parametr deyil?
MT: – Bizdə 40 qovşaqdan ibarət Replika dəstləri də var. Çoxluq həmişə var. Hansı versiya olduğunu bilmirəm...
IN: - Replica Set-də siz səsvermə hüququna malik olmayan üzvləri işlədə bilərsiniz, lakin səsvermə hüququ olan üzvləri - maksimum 7. Bu halda, 3 məlumat mərkəzinə çəkilmiş Replika Dəstimiz varsa, bağlanmadan necə sağ çıxa bilərik? Bir məlumat mərkəzi asanlıqla bağlana bilər və digər maşın sıradan çıxa bilər.
MT: – Bu, artıq hesabatın əhatə dairəsindən bir qədər kənardadır. Bu ümumi sualdır. Bəlkə sonra deyə bilərəm.
Bəzi reklamlar 🙂
Bizimlə qaldığınız üçün təşəkkür edirik. Məqalələrimiz xoşunuza gəlirmi? Daha maraqlı məzmun görmək istəyirsiniz? Sifariş verməklə və ya dostlarınıza tövsiyə etməklə bizə dəstək olun, , Sizin üçün bizim tərəfimizdən icad edilmiş giriş səviyyəli serverlərin unikal analoqu: (RAID1 və RAID10, 24 nüvəyə qədər və 40 GB DDR4 ilə mövcuddur).
Dell R730xd Amsterdamdakı Equinix Tier IV məlumat mərkəzində 2 dəfə ucuzdur? Yalnız burada Hollandiyada! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 dollardan! haqqında oxuyun
Mənbə: www.habr.com