Son zamanlar öyrəndim ki, (dəyişən lisenziya səbəbilə deyirlər). Bu, bir neçə ildir ki, MongoDB-nin nə qədər pis olduğuna dair çox sayda məqalə gördüyüm üçün düşünməyə vadar etdi və heç kimin onu istifadə etməməsi lazım olduğunu bildirdi. Ancaq bu müddət ərzində MongoDB daha yetkin bir məhsul halına gəldi. Nə baş verdi? Bütün bu nifrət, yeni DB-nin marketinqinin başlanğıcındakı səhvlərlə mi bağlıdır? Yoxsa insanlar MongoDB-ni lazım olmayan yerlərdə tətbiq edirlər?
Əgər sizdə MongoDB-ni müdafiə etdiyimi düşünürsənsə, xahiş edirəm, oxuyun məqalənin sonunda.
Yeni tendensiya
Mən proqram təminatı sənayesində tövsiyə etməyə layiq olduğu qədər illərdir çalışıram, amma buna baxmayaraq hələ də sənayemizə təsir edən yalnız az bir trend gördüm. 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… siyahı sonsuzdur. Hər il yeni tendensiyalar ortaya çıxır. Bəziləri tez keçir, bəziləri isə proqram inkişafını fundamental şəkildə dəyişir.
Hər yeni tendensiyanın ətrafında bir növ ümumi həyəcan yaranır: insanlar ya özləri gəmiyə atılmağa çalışırlar, ya da başqalarının yaratdığı səsi eşidirlər - və izdihama qoşulurlar. Bu proses Gartner şirkəti tərəfindən şəklində kodlaşdırılıb. Mübahisəli olsa da, bu qrafik, texnologiyaların sonunda istifadə üçün faydalı olana qədər baş verdiyini ümumi şəkildə təsvir edir.
Amma zaman-zaman yeni bir innovasiya meydana gəlir (ya da ikinci gəliş baş verir, bu halda olduğu kimi), yalnız bir konkret tətbiq tərəfindən idarə olunur. NoSQL hype isə MongoDB-nin meydana gəlməsi və sürətlə yüksəlməsi ilə sıx əlaqəlidir. Bu trendi MongoDB başlatmadı: əslində, iri internet şirkətləri böyük məlumatların işlənməsində çətinliklərlə qarşılaşdılar ki, bu da qeyri-relyasiyalı DB-lərə dönüşü gətirdi. Ümumi hərəkat, Google-dan Bigtable və Facebook-dan Cassandra kimi layihələrlə başladı, ancaq MongoDB, əksər inkişafçılar tərəfindən əlçatan olan ən tanınmış və geniş istifadə olunan NoSQL verilənlər bazası halına gəldi.
Qeyd: sən bunun içində sənədli DB-ləri, sütunlu DB-ləri, açar/dəyər anbarları və NoSQL-in ümumi tərifinə daxil olan digər sayıla biləcək bütün növ verilənlərin anbarlarını qarışdırdığımı düşünə bilərsən. Və haqlısan. Ancaq o dövrdə xaos hökm sürürdü. Həm hər kəs NoSQL-ə meyilli oldu, həm də bu, hamıya tamamilə müqəddəs oldu, amma bir çoxu müxtəlif texnologiyalar arasındakı fərqləri görmürdü. Bir çoxları üçün MongoDB NoSQL-in sino oldu.
İnkişaf etdiricilər ona hücum etdilər. Hər hansı bir problemi həll etmək üçün sehrli şəkildə miqyaslana bilən sxemasız verilənlər bazası ideyası olduqca cəlbedici görünürdü. 2014-cü ilə yaxın, əvvəllər MySQL, Postgres və ya SQL Server kimi mütləq əlaqəli verilənlər bazası istifadə olunan hər yerdə MongoDB verilənlər bazaları yerləşdirilməyə başlanmışdı. Niyə? Soruşduqda, siz "vebin miqyasıdır" qədər sadə bir cavabdan "mənim məlumatlarım zəif tənzimlənib və sxemasız verilənlər bazasına yaxşı oturur" qədər düşünülmüş bir cavaba qədər cavab ala bilərsiniz.
Unutmaq olmaz ki, MongoDB və sənəd verilənlər bazaları məhz ənənəvi əlaqəli verilənlər bazalarının bir sıra problemlərini həll edir:
- Sıx təsis: Əlaqəli verilənlər bazasında, əgər sizdə dinamik olaraq formalaşmış məlumatlar varsa, siz bir çox təsadüfi "müxtəlif" məlumat sütunları yaratmağa, bura blob məlumatları sıxmağa və ya konfiqurasiya istifadə etməyə məcbursunuz. … bunların hamısının ciddi çatışmazlıqları var.
- Miqyaslama çətinliyi: Əgər məlumatlar o qədər çoxdursa ki, bir serverə sığmır, MongoDB bir neçə maşında miqyaslamaq üçün mexanizmlər təklif etdi.
- Sxemanın mürəkkəb dəyişiklikləri: heç bir mühacirət! Əlaqəli verilənlər bazasında, DB strukturu dəyişdirmək böyük bir problem ola bilər (xüsusilə məlumatlar çox olduqda). MongoDB bunu əhəmiyyətli dərəcədə asanlaşdırdı. Və onu elə asan etdi ki, siz sadəcə olaraq sxemanı dərhal yeniləyə və çox sürətlə irəliləyə bilərsiniz.
- Yazma performansı: MongoDB performansı yaxşı idi, xüsusilə də düzgün tənzimləndikdə. Hətta tez-tez tənqid edilən out-of-the-box MongoDB konfiqurasiyası da bir neçə təsirli performans göstəriciləri nümayiş etdirirdi.
Bütün risklər sizin üzərinizdədir
MongoDB-nin potensial üstünlükləri, xüsusilə müəyyən problem sinifləri üçün son dərəcə böyük idi. Yuxarıdakı siyahıya kontekstdən və təcrübədən xəbəri olmayan bir kimsə baxsa, MongoDB-nin həqiqətən inqilabi bir DBMS olduğunu düşünə bilər. Yeganə problem ondan ibarətdir ki, yuxarıda sadalanan üstünlüklər bəzi şərtlərlə müşayiət olunur, bəziləri aşağıda göstərilmişdir.
Haqsızlıq olmamaq üçün, 10gen/MongoDB Inc.-də heç kim aşağıda adı çəkilənlərin yanıldığını deməyəcək, bunlar sadəcə kompromislərdir.
- Transaksiyaların itirilməsi: əməliyyatlar bir çox əlaqəli verilənlər bazasının əsas xüsusiyyətidir (hamısı olmasa, amma əksəriyyəti). Əməliyyatla bağlılıq, bir neçə əməliyyatı atomik şəkildə həyata keçirə biləcəyiniz və məlumatların uyğun qalmasını təmin edə biləcəyiniz deməkdir. Təbii ki, NoSQL verilənlər bazası ilə əməliyyatla bağlılıq bir sənəd çərçivəsində ola bilər və ya iki mərhələli təsdiqləmə istifadə edərək əməliyyatlarla bağlı məna əldə edə bilərsiniz. Ancaq bu funksionallığı özünüz həyata keçirməlisiniz... bu isə mürəkkəb və əmək tələb edən bir iş ola bilər. Çox vaxt siz problemin olduğunu anlamırsınız, ta ki, verilənlər bazasında məlumatların yolverilməz vəziyyətlərə düşdüyünü gördüyünüzə qədər, çünki əməliyyatların atomikliyini təmin etmək mümkün olmur. Qeyd: bir çoxu mənə bildirdi ki, keçən il MongoDB 4.0-da əməliyyatlar meydana gəlib, amma müəyyən məhdudiyyətlərlə. Məqalənin nəticəsi əvvəlki kimidir: texnologiyanın ehtiyaclarınıza uyğun olub-olmadığını qiymətləndirin.
- Əlaqə əlaqələrinin itirilməsi (xarici açarlar): əgər məlumatlarınızda əlaqələr varsa, onları tətbiqdə tətbiq etməlisiniz. Bu əlaqələrin saxlandığı bir verilənlər bazasının olması tətbiqdən tələb olunan işin əhəmiyyətli hissəsini azaldacaq, nəticədə proqramçılarınız üçün də asanlıq olacaq.
- Verilənlər strukturunu tətbiq etmə imkanı olmaması: sərt sxemlər bəzən böyük bir problemə çevrilir, amma düzgün istifadə edildikdə bu, məlumatları yaxşı strukturlaşdırmaq üçün güclü bir mexanizmdir. MongoDB kimi sənəd əsaslı verilənlər bazaları sxemada inanılmaz dərəcədə çeviklik təmin edir, lakin bu çeviklik məlumatların təmiz saxlanması məsuliyyətini götürmür. Əgər bunlara diqqət etməsəniz, nəticədə gözlədiyiniz formada saxlanmayan məlumatlar üçün tətbiqdə çox kod yazmalısınız. Bizim Simple Thread şirkətində tez-tez dediyimiz kimi… tətbiqi bir gün yenidən yazacaqlar, amma məlumatlar əbədi yaşayacaq. Qeyd: MongoDB sxemanın yoxlanmasını dəstəkləyir: bu faydalıdır, amma əlaqəli verilənlər bazasında olduğu kimi eyni zəmanətlər vermir. Ən əsası, sxemanın yoxlanmasını əlavə etmə və ya dəyişdirmə, kolleksiyadakı mövcud məlumatlara təsir etmir. Özünüzə əmin olun ki, yeni sxemaya uyğun olaraq məlumatları yeniləyirsiniz. Öz ehtiyaclarınıza uyğun olub-olmadığına özünüz qərar verin.
- Öz sorğu dili / alət ekosisteminin itirilməsi: SQL-nin ortaya çıxması tam bir inqilab oldu və o vaxtdan bəri heç nə dəyişməyib. Bu inanılmaz dərəcədə güclü bir dildir, amma bir o qədər də mürəkkəbdir. Yeni bir dil olan JSON-dan ibarət parçalarla verilənlər bazasına sorğular qurma ehtiyacı, SQL ilə təcrübəsi olan insanlar üçün böyük bir geri addım olaraq qiymətləndirilir. SQL verilənlər bazaları ilə qarşılıqlı əlaqə quran bir alətlər aləmi mövcuddur: IDE-lərdən hesabat alətlərinə qədər. SQL dəstəkləməyən bir verilənlər bazasına keçid, deməkdir ki, bu alətlərin əksərini istifadə edə bilmirsiniz və ya onları istifadə etmək üçün məlumatları SQL-ə çevirmək lazımdır, bu isə düşündüyünüzdən daha çətin ola bilər.
MongoDB-yə keçən bir çox inkişaf etdirici kompromisləri çox yaxşı başa düşmürdü və tez-tez onu əsas məlumat saxlanma yeri kimi qəbul edərək gözlərinə bağlı daldılar. Belə olduqdan sonra geriyə dönmək çox çətin oldu.
Başqa nə edə bilərdik?
Hər kəs başı ilə irəliləməyib və dərinliyə düşməyib. Ancaq çoxsaylı layihələr MongoDB-ni yerləşdirdikləri yerlərə sırf uyğun olmayan yerlərdə quraşdırdı - və hələ uzun illər onunla yaşamaq məcburiyyətində qalmışlar. Əgər bu təşkilatlar bir az vaxt sərf edib texnologiya seçimini sistematik düşünəcəkləri qədər çəkinməsələrdi, əksər hallarda fərqli seçim edərdilər.
Yaxşı texnologiya necə seçilir? Texnologiyaların dəyərləndirilməsi üçün sistematik bir çərçivə yaratmaq məqsədilə bir neçə cəhd edilmişdir, məsələn, və , amma mənim fikrimcə, bu yersiz mürəkkəbdir.
Bir çox texnologiyanı məntiqli bir şəkildə dəyərləndirmək mümkündür, yalnız iki əsas suala cavab verməklə. Məsələ, onlara cavab verə biləcək insanları tapmaqda, suallara cavab tapmaq zamanında haqsızlıq etmədən vaxt sərf etməkdir.
Əgər siz bir problem ilə qarşılaşmırsınızsa, yeni bir alətə ehtiyacınız yoxdur. Nöqtə.
Sual 1: Hansı problemləri həll etməyə çalışıram?
Əgər siz bir problem ilə qarşılaşmırsınızsa, yeni bir alətə ehtiyacınız yoxdur. Nöqtə. Həll axtarmaq lazım deyil, sonra isə problem uydurmaq lazım deyil. Əgər yeni texnologiyanın sizdə olan əvvəlki texnologiyadan əhəmiyyətli dərəcədə daha yaxşı bir şəkildə həll etdiyi bir problem ilə qarşılaşmırsınızsa, burada müzakirə edilməyə dəyər bir şey yoxdur. Bu texnologiyaya keçmək istəsəniz, çünki başqalarının onu necə istifadə etdiyini gördüysəniz, düşünün ki, onların hansı problemlərlə qarşılaşdığını başa düşün və sizdə belə problemlərin olub-olmadığını soruşun. Başqalarının istifadə etdiyi texnologiyanı asanlıqla qəbul etmək mümkün, amma eyni problemlərlə qarşılaşıb-qarşılaşmadığınızı anlamaq çətindir.
Sual 2: Nədən məhrum oluram?
Bu, şübhəsiz ki, daha çətin bir sualdır, çünki həm köhnə, həm də yeni texnologiyanı yaxşı başa düşmək üçün dərinləşmək lazım olacaq. Bəzən yeni texnologiyanı tam başa düşmək üçün onunla bir şey qurana qədər və ya belə bir təcrübəyə malik bir işçiniz olmayana qədər gözləməli olursunuz.
Heç birinə sahib olmasanız, bu alətin dəyərini müəyyən etmək üçün mümkün olan ən az investisiyaları düşünmək mənalıdır. Və əgər investisiya etsəniz, qərarı ləğv etmək nə qədər çətin olacaq?
İnsanlar hər şeyi məhv edir.
Bu suallara mümkün qədər obyektiv cavab verməyə çalışarkən, bir şeyi unutmayın: insan təbiəti ilə mübarizə aparmalısınız. Texnologiyanı səmərəli qiymətləndirmək üçün aşmalı olduğunuz bir sıra kognitiv yanılmalar var. Budur, yalnız bir neçəsi:
- — hər kəs bununla tanışdır, lakin bu ilə mübarizə aparmaq çətindir. Sadəcə olaraq, texnologiyanın gerçək ehtiyaclarınıza uyğun olduğuna əmin olun.
- — bir çox inkişaf etdirici uzun müddət işlədikləri texnologiyaları qiymətləndirməkdə azaldır və yeni texnologiyanın üstünlüklərini şişirdirlər. Yalnız proqramçılar deyil, hər kəs bu kognitiv yanılmaya məruz qalır.
- — biz gördüyümüzü görməyi sevirik və olmadığını gözardı edirik. Bu, yalnız yeni texnologiyanı şişirtmək deyil, həm də onun çatışmazlıqlarını gözardı etmək ilə birlikdə xaosa gətirib çıxara bilər..
Obyektiv qiymətləndirmək asan deyil, lakin əsas kognitiv yanılmaları anlamaq daha rasional qərarlar qəbul etməyə kömək edəcək.
Xülasə
Bir yenilik ortaya çıxdıqda, iki suala ehtiyatla cavab vermək lazımdır:
- Bu alət həqiqi bir problemi həll edirmi?
- Komproisləri yaxşı anlayırıqmı?
Bu iki suala əmin cavab verə bilmirsinizsə, bir neçə addım geriyə atın və düşünün.
MongoDB əslində düzgün seçim idimi? Şübhəsiz, bəli; əksər mühəndislik texnologiyalarında olduğu kimi, bu, bir çox amillərdən asılıdır. Bu iki suala cavab verənlərdən bir çoxu MongoDB-dən fayda götürüb və bu faydanı davam etdirirlər. Kim bundan faydalana bilmədisə, ümid edirəm ki, hype dövründə keçdiyi sərgi haqqında dəyərli və çox ağrılı olmayan bir dərs almışdır.
Xəbərdarlıq
Mongoda heç bir sevgi və ya nifrət hiss etmirəm. Bizim MongoDB-yə uyğun olan problemlərimiz olmayıb. Mən bilirəm ki, 10gen/MongoDB Inc. əvvəlcə təhlükəsiz olmayan standart dəyərlər təyin edərək və MongoDB-ni hər yerdə (xüsusilə hackatonlarda) hər növ məlumatlar üçün universal bir həll kimi irəliləyərək çox cəsarətli addım atdı. Yəqin ki, bu, pis bir qərar idi. Lakin bu, burada təsvir edilən yanaşmanı təsdiqləyir: bu problemləri texnologiyanı üzvi qiymətləndirmə ilə çox tez aşkar etmək mümkün idi.
Mənbə: habr.com
