Bunu bu yaxınlarda bildim Red Hat, MongoDB dəstəyini Peykdən çıxarır (lisenziya dəyişikliyinə görə deyirlər). Bu məni düşündürdü, çünki son bir neçə ildə MongoDB-nin nə qədər dəhşətli olduğu və heç kimin ondan necə istifadə etməməsi haqqında bir çox məqalə görmüşəm. Lakin bu müddət ərzində MongoDB daha yetkin bir məhsula çevrildi. Nə olub? Bütün nifrət həqiqətən yeni DBMS-nin erkən marketinqindəki səhvlərdən qaynaqlanır? Yoxsa insanlar MongoDB-ni yanlış yerlərdə istifadə edirlər?

MongoDB-ni müdafiə etdiyimi hiss edirsinizsə, oxuyun imtina məqalənin sonunda.

Yeni trend

Mən proqram sənayesində deyə biləcəyimdən daha çox illərdir işləyirəm, lakin hələ də sənayemizə təsir edən tendensiyaların yalnız kiçik bir hissəsinə məruz qalmışam. 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain-in yüksəlişinin şahidi oldum... siyahı sonsuzdur. Hər il yeni tendensiyalar ortaya çıxır. Bəziləri tez bir zamanda yox olur, digərləri isə proqram təminatının işlənib hazırlanma qaydasını kökündən dəyişir.

Hər bir yeni tendensiya ümumi həyəcan yaradır: insanlar ya gəmiyə tullanır, ya da başqalarının yaratdığı səs-küyü görüb izdihamı izləyirlər. Bu proses Gartner tərəfindən kodlaşdırılmışdır şırınga dövrü. Mübahisəli olsa da, bu zaman qrafiki texnologiyaların faydalı hala gəlməzdən əvvəl nə baş verdiyini təxminən təsvir edir.

Ancaq vaxtaşırı yeni bir yenilik meydana çıxır (yaxud bu vəziyyətdə olduğu kimi ikincisi də var) yalnız bir xüsusi tətbiqetmə ilə idarə olunur. NoSQL vəziyyətində, şırınga MongoDB-nin meydana çıxması və meteorik yüksəlişi ilə güclü şəkildə idarə olundu. MongoDB bu tendensiyaya başlamadı: əslində, böyük internet şirkətləri böyük həcmdə məlumatların işlənməsi ilə bağlı problemlər yaşamağa başladılar və bu, əlaqəsi olmayan verilənlər bazalarının geri qaytarılmasına səbəb oldu. Ümumi hərəkət Google-un Bigtable və Facebook-un Cassandra kimi layihələri ilə başladı, lakin əksər tərtibatçıların daxil olduğu ən məşhur və əlçatan NoSQL verilənlər bazası tətbiqinə çevrilən MongoDB idi.

Qeyd: Siz hesab edə bilərsiniz ki, mən sənəd verilənlər bazalarını sütunlu verilənlər bazası, açar/dəyər anbarları və ya ümumi NoSQL tərifinə daxil olan çoxsaylı digər məlumat anbarları ilə qarışdırıram. Və haqlısan. Lakin o zaman xaos hökm sürürdü. Hər kəs NoSQL ilə məşğuldur, hamıya çevrilib tamamilə zəruridir, baxmayaraq ki, bir çoxları fərqli texnologiyalardakı fərqləri görmədilər. Çoxları üçün MongoDB oldu ilə sinonimdir NoSQL.

Və tərtibatçılar bunun üzərinə atıldı. İstənilən problemi həll etmək üçün sehrli şəkildə miqyas alan sxemsiz verilənlər bazası ideyası olduqca cəlbedici idi. Təxminən 2014-cü ildə belə görünürdü ki, bir il əvvəl MySQL, Postgres və ya SQL Server kimi əlaqəli verilənlər bazasından istifadə edilən hər yerdə MongoDB verilənlər bazası yerləşdirilməyə başladı. Səbəbini soruşduqda, "bu, internetin miqyasıdır" cavabından daha düşünülmüş "məlumatlarım çox sərbəst qurulub və sxemsiz verilənlər bazasına yaxşı uyğun gəlir" cavabını ala bilərsiniz.

MongoDB və ümumiyyətlə sənəd verilənlər bazalarının ənənəvi əlaqəli verilənlər bazaları ilə bir sıra problemləri həll etdiyini xatırlamaq vacibdir:

• Ciddi sxem: Əlaqəli verilənlər bazası ilə, dinamik şəkildə yaradılan məlumatlarınız varsa, ya bir dəstə təsadüfi "müxtəlif" məlumat sütunları yaratmalı, ora məlumat bloklarını itələməli və ya konfiqurasiyadan istifadə etməlisiniz. EAV...bütün bunların əhəmiyyətli çatışmazlıqları var.
• Çətinlik miqyası: Bir serverə sığmayan o qədər çox məlumat varsa, MongoDB onun birdən çox maşın arasında miqyasına imkan verən mexanizmlər təklif etdi.
• Kompleks dövrə dəyişiklikləri: miqrasiya yoxdur! Əlaqəli verilənlər bazasında verilənlər bazası strukturunun dəyişdirilməsi böyük problem ola bilər (xüsusilə çoxlu məlumat olduqda). MongoDB prosesi xeyli sadələşdirə bildi. Və bunu o qədər asanlaşdırdı ki, siz getdiyiniz zaman dövrəni yeniləyə və çox sürətlə davam edə bilərsiniz.
• Səsyazma performansı: MongoDB performansı yaxşı idi, xüsusilə düzgün konfiqurasiya edildikdə. Hətta MongoDB-nin tez-tez tənqid olunduğu qutudan kənar konfiqurasiyası bəzi təsirli performans rəqəmlərini göstərdi.

Bütün risklər sizin üzərinizdədir

MongoDB-nin potensial faydaları, xüsusən də müəyyən problemlər sinifləri üçün çox böyük idi. Yuxarıdakı siyahını konteksti başa düşmədən və təcrübəniz olmadan oxusanız, MongoDB-nin həqiqətən inqilabi DBMS olduğu təəssüratı yarana bilər. Yeganə problem o idi ki, yuxarıda sadalanan faydalar bir sıra xəbərdarlıqlarla gəlirdi, onlardan bəziləri aşağıda verilmişdir.

Ədalətli olmaq üçün, 10gen/MongoDB Inc-də heç kim. Aşağıdakıların doğru olmadığını deməyəcək, bunlar sadəcə kompromislərdir.

• İtirilmiş əməliyyatlar: Əməliyyatlar bir çox əlaqəli verilənlər bazalarının (hamısı deyil, əksəriyyəti) əsas xüsusiyyətidir. Tranzaksiya o deməkdir ki, siz atomik olaraq çoxlu əməliyyatlar həyata keçirə bilərsiniz və məlumatların ardıcıl qalmasını təmin edə bilərsiniz. Əlbəttə ki, NoSQL verilənlər bazası ilə tranzaksiya bir sənəd daxilində ola bilər və ya tranzaksiya semantikasını əldə etmək üçün iki fazalı öhdəliklərdən istifadə edə bilərsiniz. Amma siz bu funksiyanı özünüz həyata keçirməli olacaqsınız... çətin və vaxt aparan iş ola bilər. Çox vaxt siz verilənlər bazasındakı məlumatların etibarsız vəziyyətə düşdüyünü görənə qədər problemin olduğunu dərk etmirsiniz, çünki əməliyyatların atomikliyinə zəmanət verilmir. Qeyd: Bir çox insanlar mənə MongoDB 4.0-ın keçən il əməliyyatlar təqdim etdiyini, lakin bəzi məhdudiyyətlərlə olduğunu söylədi. Məqalədən götürülmüş fikir dəyişməz olaraq qalır: texnologiyanın ehtiyaclarınıza nə dərəcədə cavab verdiyini qiymətləndirin.
• Münasibətlərin bütövlüyünün itirilməsi (xarici açarlar): Əgər məlumatlarınızın əlaqələri varsa, onda siz onları tətbiqdə tətbiq etməli olacaqsınız. Bu əlaqələrə hörmət edən verilənlər bazasına sahib olmaq, tətbiqin və buna görə də proqramçıların çox işini aparacaq.
• Məlumat strukturunu tətbiq etmək bacarığının olmaması: Ciddi sxemlər bəzən böyük problem ola bilər, lakin onlar həm də ağıllı şəkildə istifadə edildiyi təqdirdə məlumatların yaxşı strukturlaşdırılması üçün güclü mexanizmdir. MongoDB kimi sənəd verilənlər bazaları inanılmaz sxem çevikliyini təmin edir, lakin bu çeviklik məlumatların təmiz saxlanması məsuliyyətini aradan qaldırır. Əgər onlara diqqət yetirməsəniz, gözlədiyiniz formada saxlanmayan məlumatları nəzərə almaq üçün tətbiqinizdə çoxlu kod yazmaqla nəticələnəcəksiniz. Simple Thread şirkətimizdə tez-tez dediyimiz kimi... proqram nə vaxtsa yenidən yazılacaq, lakin məlumatlar əbədi olaraq yaşayacaq. Qeyd: MongoDB sxem yoxlamasını dəstəkləyir: faydalıdır, lakin əlaqəli verilənlər bazasında olduğu kimi eyni zəmanətləri vermir. Əvvəla, sxem yoxlamasının əlavə edilməsi və ya dəyişdirilməsi kolleksiyadakı mövcud məlumatlara təsir göstərmir. Məlumatları yeni sxemə uyğun olaraq yeniləməyinizə əmin olmaq sizə bağlıdır. Bunun ehtiyaclarınız üçün kifayət olub-olmadığına özünüz qərar verin.
• Doğma sorğu dili / alət ekosisteminin itirilməsi: SQL-in yaranması mütləq bir inqilab idi və o vaxtdan bəri heç nə dəyişmədi. Bu, inanılmaz dərəcədə güclü, eyni zamanda olduqca mürəkkəb bir dildir. JSON fraqmentlərindən ibarət yeni dildə verilənlər bazası sorğularının qurulması ehtiyacı SQL ilə işləmək təcrübəsi olan insanlar tərəfindən geriyə doğru böyük bir addım kimi qiymətləndirilir. IDE-lərdən hesabat alətlərinə qədər SQL verilənlər bazası ilə qarşılıqlı əlaqədə olan bütün alətlər kainatı mövcuddur. SQL-i dəstəkləməyən verilənlər bazasına keçmək o deməkdir ki, siz bu alətlərin əksəriyyətindən istifadə edə bilməyəcəksiniz və ya onlardan istifadə etmək üçün məlumatları SQL-ə çevirməlisiniz ki, bu da düşündüyünüzdən daha çətin ola bilər.

MongoDB-yə müraciət edən bir çox tərtibatçılar, həqiqətən də, güzəştləri başa düşmürdülər və tez-tez onu ilkin məlumat anbarı kimi quraşdırmaq fikrinə düşərdilər. Bundan sonra geri qayıtmaq çox vaxt inanılmaz dərəcədə çətin olurdu.

Başqa cür nə etmək olardı?

Heç də hamı başını aşağı atıb dibinə vurmadı. Ancaq bir çox layihələr MongoDB-ni sadəcə uyğun gəlmədiyi yerlərdə quraşdırdı - və onlar uzun illər onunla yaşamalı olacaqlar. Əgər bu təşkilatlar bir az vaxt sərf etsəydi və texnologiya seçimlərini metodik olaraq düşünsəydilər, çoxları fərqli seçimlər edərdi.

Doğru texnologiyanı necə seçmək olar? kimi texnologiyanın qiymətləndirilməsi üçün sistematik çərçivə yaratmaq üçün bir neçə cəhdlər edilmişdir "Proqram təşkilatlarına texnologiyaların tətbiqi üçün çərçivə" и "Proqram texnologiyalarının qiymətləndirilməsi üçün çərçivə", amma mənə elə gəlir ki, bu, lazımsız mürəkkəblikdir.

Bir çox texnologiyaları yalnız iki əsas sual verməklə ağıllı şəkildə qiymətləndirmək olar. Problem onlara məsuliyyətlə cavab verə bilən, cavabları tapmaq üçün vaxt ayıran və qərəzsiz insanlar tapmaqdır.

Əgər hər hansı bir problemlə qarşılaşmırsınızsa, yeni alətə ehtiyacınız yoxdur. Nöqtə.

Sual 1: Hansı problemləri həll etməyə çalışıram?

Əgər hər hansı bir problemlə qarşılaşmırsınızsa, yeni alətə ehtiyacınız yoxdur. Nöqtə. Çözüm axtarıb sonra problem uydurmağa ehtiyac yoxdur. Yeni texnologiyanın mövcud texnologiyanızdan əhəmiyyətli dərəcədə yaxşı həll etdiyi problemlə qarşılaşmasanız, burada müzakirə ediləcək heç nə yoxdur. Əgər başqalarının istifadə etdiyini gördüyünüzə görə bu texnologiyadan istifadə etməyi düşünürsünüzsə, onların hansı problemlərlə üzləşdiyini düşünün və sizdə bu problemlərin olub olmadığını soruşun. Bir texnologiyanı qəbul etmək asandır, çünki başqaları ondan istifadə edir, problem eyni problemlərlə üzləşib-qarşılaşmadığınızı anlamaqdır.

Sual 2: Mən nəyi əskik edirəm?

Bu, şübhəsiz ki, daha çətin sualdır, çünki siz həm köhnə, həm də yeni texnologiyanı dərindən öyrənməli və yaxşı başa düşməlisiniz. Bəzən onunla bir şey qurana qədər və ya bu təcrübəyə sahib olan biri olana qədər yenisini həqiqətən başa düşə bilməzsən.

Əgər sizdə heç biri yoxdursa, bu alətin dəyərini müəyyən etmək üçün mümkün olan minimum investisiya haqqında düşünməyin mənası var. Və sərmayə qoyduqdan sonra qərarı geri qaytarmaq nə qədər çətin olacaq?

İnsanlar həmişə hər şeyi məhv edirlər

Bu suallara mümkün qədər qərəzsiz cavab verməyə çalışarkən bir şeyi xatırlayın: insan təbiəti ilə mübarizə aparmalı olacaqsınız. Texnologiyanı effektiv qiymətləndirmək üçün aradan qaldırılmalı olan bir sıra koqnitiv qərəzlər var. Budur yalnız bir neçəsi:

• Çoxluğa qoşulmağın təsiri - hamı onun haqqında bilir, amma onunla mübarizə aparmaq hələ də çətindir. Sadəcə texnologiyanın faktiki ehtiyaclarınıza uyğun olduğundan əmin olun.
• Yenilik effekti — Bir çox tərtibatçılar uzun müddət işlədikləri texnologiyaları düzgün qiymətləndirmir və yeni texnologiyanın faydalarını həddən artıq qiymətləndirirlər. Bu, təkcə proqramçılar deyil, hər kəs bu idrak qərəzinə həssasdır.
• Müsbət xüsusiyyətlərin təsiri - Biz orda olanı görməyə və çatışmayanı gözdən itirməyə meylliyik. Bu, yenilik effekti ilə birləşdirildikdə xaosa səbəb ola bilər, çünki siz nəinki yeni texnologiyaya yüksək qiymət verirsiniz, həm də onun çatışmazlıqlarına məhəl qoymursunuz..

Obyektiv qiymətləndirmə asan deyil, lakin əsas koqnitiv qərəzləri başa düşmək sizə daha rasional qərarlar qəbul etməyə kömək edəcək.

Xülasə

Hər dəfə bir yenilik ortaya çıxanda iki suala çox diqqətlə cavab vermək lazımdır:

• Bu alət real problemi həll edirmi?
• Mübadilələri yaxşı başa düşürükmü?

Bu iki suala inamla cavab verə bilmirsinizsə, bir neçə addım geri çəkin və düşünün.

Beləliklə, MongoDB düzgün seçim idimi? Əlbəttə bəli; Əksər mühəndislik texnologiyalarında olduğu kimi, bu da bir çox amillərdən asılıdır. Bu iki suala cavab verənlər arasında bir çoxları MongoDB-dən faydalanıb və faydalanmağa davam edir. Bunu etməyənlər üçün ümid edirəm ki, siz şırınga dövründən keçmək haqqında dəyərli və çox ağrılı olmayan bir dərs öyrəndiniz.

İmtina

Aydınlaşdırmaq istəyirəm ki, mənim MongoDB ilə nə sevgi, nə də nifrət münasibətim var. Sadəcə olaraq, MongoDB-nin həll etmək üçün ən uyğun olduğu kimi problemlərimiz olmayıb. Mən bilirəm ki, 10gen/MongoDB Inc. əvvəlcə çox cəsarətli idi, etibarlı olmayan defoltları təyin etdi və MongoDB-ni hər yerdə (xüsusilə hackathonlarda) hər hansı bir məlumatla işləmək üçün universal bir həll kimi təbliğ etdi. Yəqin ki, pis qərar idi. Lakin bu, burada təsvir edilən yanaşmanı təsdiqləyir: texnologiyanın səthi qiymətləndirilməsi ilə belə bu problemlər çox tez aşkar edilə bilər.

Mənbə: www.habr.com