Aku bubar ngerti sing Red Hat mbusak dhukungan MongoDB saka Satelit (padha ngomong amarga owah-owahan lisensi). Iki nggawe aku mikir amarga ing sawetara taun kepungkur aku wis ndeleng akeh artikel babagan carane MongoDB ala lan ora ana sing kudu nggunakake. Nanging sajrone wektu iki, MongoDB wis dadi produk sing luwih diwasa. Ana apa? Apa kabeh gething tenan amarga kesalahan ing marketing awal DBMS anyar? Utawa wong mung nggunakake MongoDB ing panggonan sing salah?

Yen sampeyan rumangsa yen aku mbela MongoDB, waca wewaler ing pungkasan artikel.

Tren anyar

Aku wis makarya ing industri software kanggo taun luwih saka aku bisa ngomong, nanging aku isih mung wis kapapar bagean cilik saka tren sing wis kenek industri kita. Aku wis nyekseni munggah 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain ... dhaftar punika telas. Saben taun tren anyar katon. Sawetara cepet ilang, dene liyane ngganti cara piranti lunak dikembangake.

Saben gaya anyar nggawe kasenengan umum: wong mlumpat ing papan, utawa ndeleng swara sing diasilake wong liya lan ngetutake wong akeh. Proses iki dikodifikasi dening Gartner ing siklus hype. Sanajan kontroversial, garis wektu iki kira-kira nggambarake apa sing kedadeyan karo teknologi sadurunge dadi migunani.

Nanging saka wektu kanggo wektu inovasi anyar katon (utawa wis teka kapindho, kaya ing kasus iki) mimpin dening mung siji implementasine tartamtu. Ing kasus NoSQL, hype banget didorong dening muncule lan mundhak meteorik MongoDB. MongoDB ora miwiti tren iki: nyatane, perusahaan Internet gedhe wiwit duwe masalah ngolah data sing akeh, sing nyebabake bali database non-relasional. Gerakan sakabèhé diwiwiti kanthi proyèk kaya Google Bigtable lan Facebook Cassandra, nanging MongoDB sing dadi implementasi database NoSQL sing paling kondhang lan bisa diakses sing umume pangembang bisa ngakses.

Cathetan: Sampeyan bisa uga mikir yen aku mbingungake database dokumen karo database kolom, toko kunci/nilai, utawa sawetara jinis toko data liyane sing ana ing definisi NoSQL umum. Lan sampeyan bener. Nanging ing wektu iku kekacauan mrentah. Kabeh wong kepengin banget karo NoSQL, wis dadi kabeh wong pancen tenan perlu, sanajan akeh sing ora weruh beda ing teknologi beda. Kanggo akeh, MongoDB wis dadi sinonim karo NoSQL.

Lan pangembang pounced ing. Gagasan babagan basis data tanpa skema sing skala ajaib kanggo ngatasi masalah apa wae cukup nggodho. Kira-kira taun 2014, kayane ing endi wae setaun kepungkur nggunakake basis data relasional kayata MySQL, Postgres utawa SQL Server wiwit nyebarake basis data MongoDB. Yen ditakoni kenapa, sampeyan bisa njaluk jawaban saka "iki ukuran web" menyang sing luwih wicaksana "dataku disusun banget lan pas karo database tanpa skema."

Penting kanggo elinga yen MongoDB, lan database dokumen umume, ngrampungake sawetara masalah karo database relasional tradisional:

• Skema sing ketat: Kanthi basis data relasional, yen sampeyan wis nggawe data kanthi dinamis, sampeyan kepeksa nggawe pirang-pirang kolom data "macem-macem" acak, nyopir gumpalan data ing kana, utawa nggunakake konfigurasi. EAV... kabeh iki nduweni kekurangan sing signifikan.
• Kesulitan scaling: Yen ana akeh data sing ora pas ing siji server, MongoDB nawakake mekanisme kanggo ngidini ukuran ing sawetara mesin.
• modifikasi sirkuit Komplek: ora migrasi! Ing basis data relasional, ngganti struktur basis data bisa dadi masalah gedhe (utamane yen ana akeh data). MongoDB bisa nyederhanakake proses kasebut. Lan digawe iku supaya gampang sing mung bisa nganyari sirkuit nalika sampeyan pindhah lan nerusake banget cepet.
• Kinerja ngrekam: Kinerja MongoDB apik, utamane yen dikonfigurasi kanthi bener. Malah konfigurasi out-of-the-box MongoDB, sing asring dikritik, nuduhake sawetara nomer kinerja sing apik banget.

Kabeh risiko ana ing sampeyan

Mupangat potensial MongoDB gedhe banget, utamane kanggo masalah kelas tartamtu. Yen sampeyan maca dhaptar ing ndhuwur tanpa mangerteni konteks lan tanpa pengalaman, sampeyan bisa entuk kesan yen MongoDB pancen minangka DBMS revolusioner. Masalah mung yaiku keuntungan sing kasebut ing ndhuwur teka karo sawetara caveat, sawetara sing kapacak ing ngisor iki.

Supaya adil, ora ana wong ing 10gen/MongoDB Inc. ora bakal ngomong yen ing ngisor iki ora bener, iki mung kompromi.

• Transaksi sing ilang: Transaksi minangka fitur inti saka akeh database hubungan (ora kabeh, nanging paling). Transactional tegese sampeyan bisa nindakake macem-macem operasi atom lan bisa mesthekake yen data tetep konsisten. Mesthine, kanthi basis data NoSQL, transaksi bisa ana ing siji dokumen, utawa sampeyan bisa nggunakake komitmen rong fase kanggo entuk semantik transaksional. Nanging sampeyan kudu ngetrapake fungsi kasebut dhewe ... sing bisa dadi tugas sing angel lan butuh wektu. Asring sampeyan ora ngerti yen ana masalah nganti sampeyan ndeleng data ing database rampung ing negara sing ora bener amarga atomicity operasi ora bisa dijamin. Cathetan: Akeh wong sing ngandhani yen MongoDB 4.0 ngenalake transaksi taun kepungkur, nanging kanthi sawetara watesan. Takeaway saka artikel tetep padha: evaluasi carane uga teknologi meets kabutuhan.
• Mundhut integritas relasional (kunci asing): Yen data sampeyan duwe hubungan, sampeyan kudu ngetrapake ing aplikasi kasebut. Duwe database sing ngormati hubungan kasebut bakal mbutuhake akeh karya saka aplikasi lan mulane programer sampeyan.
• Kurang kemampuan kanggo ngetrapake struktur data: Skema ketat kadhangkala bisa dadi masalah gedhe, nanging uga mekanisme kuat kanggo struktur data sing apik yen digunakake kanthi wicaksana. Basis data dokumen kaya MongoDB nyedhiyakake keluwesan skema sing luar biasa, nanging keluwesan iki ngilangi tanggung jawab kanggo njaga data sing resik. Yen sampeyan ora njupuk care saka wong-wong mau, sampeyan bakal mungkasi munggah nulis akèh kode ing aplikasi kanggo akun data sing ora disimpen ing wangun sing dikarepake. Kaya sing asring kita ucapake ing perusahaan Simple Thread ... aplikasi kasebut bakal ditulis maneh, nanging data kasebut bakal urip ing salawas-lawase. Cathetan: MongoDB ndhukung pamriksan skema: migunani, nanging ora menehi jaminan sing padha karo database relasional. Kaping pisanan, nambah utawa ngganti mriksa skema ora mengaruhi data sing ana ing koleksi. Sampeyan kudu mesthekake yen sampeyan nganyari data miturut skema anyar. Temtokake dhewe apa iki cukup kanggo kabutuhan sampeyan.
• Basa pitakon asli / ilang ekosistem alat: Tekane SQL minangka revolusi mutlak lan ora ana owah-owahan wiwit iku. Iku basa sing luar biasa kuat, nanging uga cukup rumit. Kebutuhan kanggo mbangun pitakon basis data ing basa anyar sing kalebu fragmen JSON dianggep minangka langkah gedhe mundur dening wong sing duwe pengalaman nggarap SQL. Ana kabeh alat sing sesambungan karo database SQL, saka IDE nganti alat nglaporake. Pindhah menyang database sing ora ndhukung SQL tegese sampeyan ora bisa nggunakake paling alat iki utawa sampeyan kudu nerjemahake data menyang SQL kanggo nggunakake, kang bisa dadi luwih angel saka sampeyan mikir.

Akeh pangembang sing nguripake MongoDB ora ngerti babagan trade-off, lan asring nyilem dhisik kanggo nginstal minangka nyimpen data utama. Sawise iki asring banget angel bali.

Apa sing bisa ditindakake kanthi cara sing beda?

Ora saben wong mlumpat luwih dhisik lan kenek ngisor. Nanging akeh proyek sing wis nginstal MongoDB ing papan sing ora cocog - lan kudu urip nganti pirang-pirang taun. Yen organisasi kasebut wis ngenteni sawetara wektu lan mikir kanthi metodhe babagan pilihan teknologi, akeh sing bakal nggawe pilihan sing beda.

Carane milih teknologi tengen? Ana sawetara upaya kanggo nggawe kerangka sistematis kanggo penilaian teknologi, kayata "Kerangka kanggo ngenalake teknologi menyang organisasi piranti lunak" и "Kerangka kanggo ngevaluasi teknologi piranti lunak", nanging misale jek kula sing iki kerumitan rasah.

Akeh teknologi bisa ditaksir kanthi cerdas kanthi takon mung rong pitakonan dhasar. Masalahe yaiku nemokake wong sing bisa mangsuli kanthi tanggung jawab, njupuk wektu kanggo nemokake jawaban lan tanpa bias.

Yen sampeyan ora nemoni masalah, sampeyan ora butuh alat anyar. Titik.

Pitakonan 1: Masalah apa sing arep dakrampungake?

Yen sampeyan ora nemoni masalah, sampeyan ora butuh alat anyar. Titik. Ora perlu golek solusi banjur nyipta masalah. Kajaba yen sampeyan nemoni masalah sing bisa diatasi dening teknologi anyar sing luwih apik tinimbang teknologi sing wis ana, ora ana sing kudu dirembug ing kene. Yen sampeyan mikir nggunakake teknologi iki amarga sampeyan wis ndeleng wong liya nggunakake, pikirake masalah apa sing diadhepi lan takon apa sampeyan duwe masalah kasebut. Gampang nampa teknologi amarga wong liya nggunakake, tantangane ngerti apa sampeyan ngadhepi masalah sing padha.

Pitakonan 2: Apa aku ilang?

Iki mesthi dadi pitakonan sing luwih angel amarga sampeyan kudu digali lan ngerti babagan teknologi lawas lan anyar. Kadhangkala sampeyan ora bisa ngerti sing anyar nganti sampeyan wis nggawe utawa duwe wong sing duwe pengalaman kasebut.

Yen sampeyan ora duwe, iku ndadekake pangertèn kanggo mikir bab investasi minimal bisa kanggo nemtokake Nilai saka instrument iki. Lan yen sampeyan nggawe investasi, kepiye angel mbalikke keputusan kasebut?

Wong tansah ngrusak kabeh

Nalika sampeyan nyoba mangsuli pitakon kasebut kanthi adil, elinga siji perkara: sampeyan kudu nglawan sifat manungsa. Ana sawetara bias kognitif sing kudu diatasi kanggo ngevaluasi teknologi kanthi efektif. Ing ngisor iki mung sawetara:

• Efek gabung karo mayoritas - kabeh wong ngerti babagan dheweke, nanging isih angel nglawan dheweke. Priksa manawa teknologi kasebut cocog karo kabutuhan nyata sampeyan.
• Efek anyar - Akeh pangembang cenderung ngremehake teknologi sing wis digarap nganti suwe lan ngira-ngira keuntungan teknologi anyar. Ora mung programer, kabeh wong rentan kanggo bias kognitif iki.
• Efek saka ciri positif - Kita cenderung ndeleng apa sing ana lan kelangan apa sing ilang. Iki bisa nyebabake kekacauan nalika digabungake karo efek anyar, amarga sampeyan ora mung overvalue teknologi anyar, nanging uga nglirwakake kekurangane..

Evaluasi objektif ora gampang, nanging ngerteni bias kognitif sing ndasari bakal mbantu sampeyan nggawe keputusan sing luwih rasional.

Ringkesan

Nalika inovasi katon, rong pitakonan kudu dijawab kanthi ati-ati:

• Apa alat iki ngatasi masalah nyata?
• Apa kita ngerti trade-off kanthi apik?

Yen sampeyan ora bisa mangsuli pitakon loro iki kanthi yakin, mundur sawetara langkah lan pikirake.

Dadi MongoDB malah dadi pilihan sing tepat? Mesthi ya; Kaya akeh teknologi teknik, iki gumantung ing pirang-pirang faktor. Ing antarane sing mangsuli pitakon loro kasebut, akeh sing entuk manfaat saka MongoDB lan terus nindakake. Kanggo sing ora, muga-muga sampeyan sinau pelajaran sing migunani lan ora nglarani babagan obah liwat siklus hype.

Penafian

Aku pengin njlentrehake yen aku ora duwe hubungan katresnan utawa sengit karo MongoDB. Kita mung durung nemoni masalah sing paling cocog karo MongoDB. Aku ngerti yen 10gen/MongoDB Inc. banget kandel ing wiwitan, nyetel standar sing ora aman lan promosi MongoDB ing endi wae (utamane ing hackathon) minangka solusi universal kanggo nggarap data apa wae. Iku mbokmenawa kaputusan ala. Nanging negesake pendekatan sing diterangake ing kene: masalah kasebut bisa dideteksi kanthi cepet sanajan kanthi penilaian teknologi sing entheng.

Source: www.habr.com