Saya baru-baru ini mengetahuinya Red Hat mengalih keluar sokongan MongoDB daripada Satelit (mereka mengatakan kerana perubahan lesen). Ini membuatkan saya berfikir kerana dalam beberapa tahun kebelakangan ini saya telah melihat satu tan artikel tentang betapa dahsyatnya MongoDB dan bagaimana sesiapa pun tidak boleh menggunakannya. Tetapi pada masa ini, MongoDB telah menjadi produk yang lebih matang. Apa yang berlaku? Adakah semua kebencian itu benar-benar disebabkan oleh kesilapan dalam pemasaran awal DBMS baharu? Atau adakah orang hanya menggunakan MongoDB di tempat yang salah?

Jika anda rasa saya mempertahankan MongoDB, sila baca penafian pada akhir artikel.

Trend baru

Saya telah bekerja dalam industri perisian selama lebih tahun daripada yang saya boleh katakan, tetapi saya masih hanya terdedah kepada sebahagian kecil daripada trend yang telah melanda industri kami. Saya telah menyaksikan kebangkitan 4GL, AOP, Agile, SOA, Web 2.0, AJAX, Blockchain... senarainya tidak berkesudahan. Setiap tahun trend baru muncul. Ada yang cepat pudar, sementara yang lain secara asasnya mengubah cara perisian dibangunkan.

Setiap aliran baharu mencipta keseronokan umum: orang sama ada melompat ke atas kapal, atau melihat bunyi yang dijana oleh orang lain dan mengikuti orang ramai. Proses ini dikodkan oleh Gartner dalam kitaran gembar-gembur. Walaupun kontroversi, garis masa ini secara kasar menerangkan perkara yang berlaku kepada teknologi sebelum akhirnya menjadi berguna.

Tetapi dari semasa ke semasa inovasi baru muncul (atau mempunyai kedatangan kedua, seperti dalam kes ini) didorong oleh hanya satu pelaksanaan tertentu. Dalam kes NoSQL, gembar-gembur sangat didorong oleh kemunculan dan peningkatan mendadak MongoDB. MongoDB tidak memulakan trend ini: sebenarnya, syarikat Internet yang besar mula menghadapi masalah memproses sejumlah besar data, yang membawa kepada pemulangan pangkalan data bukan perhubungan. Pergerakan keseluruhan bermula dengan projek seperti Google's Bigtable dan Facebook's Cassandra, tetapi MongoDBlah yang menjadi pelaksanaan pangkalan data NoSQL yang paling terkenal dan boleh diakses yang boleh diakses oleh kebanyakan pembangun.

Nota: Anda mungkin berfikir bahawa saya mengelirukan pangkalan data dokumen dengan pangkalan data kolumnar, stor kunci/nilai atau mana-mana jenis stor data lain yang berada di bawah definisi NoSQL umum. Dan awak betul. Tetapi pada masa itu huru-hara berlaku. Semua orang taksub dengan NoSQL, ia telah menjadi semua orang betul-betul perlu, walaupun ramai yang tidak melihat perbezaan dalam teknologi yang berbeza. Bagi kebanyakan orang, MongoDB telah menjadi sinonim dengan NoSQL.

Dan pemaju menerkamnya. Idea pangkalan data tanpa skema yang secara ajaib berskala untuk menyelesaikan sebarang masalah agak menggoda. Sekitar tahun 2014, nampaknya di mana-mana setahun yang lalu menggunakan pangkalan data hubungan seperti MySQL, Postgres atau SQL Server mula menggunakan pangkalan data MongoDB. Apabila ditanya mengapa, anda boleh mendapatkan jawapan daripada "ini ialah skala web" kepada yang lebih bijak "data saya berstruktur sangat longgar dan sesuai dengan pangkalan data tanpa skema."

Adalah penting untuk diingat bahawa MongoDB, dan pangkalan data dokumen secara umum, menyelesaikan beberapa masalah dengan pangkalan data hubungan tradisional:

• Skim yang ketat: Dengan pangkalan data hubungan, jika anda telah menjana data secara dinamik, anda terpaksa sama ada membuat sekumpulan lajur rawak "pelbagai" data, memasukkan gumpalan data ke dalamnya atau menggunakan konfigurasi EAV...semua ini mempunyai kelemahan yang ketara.
• Kesukaran menskala: Jika terdapat terlalu banyak data sehingga ia tidak muat pada satu pelayan, MongoDB menawarkan mekanisme untuk membolehkannya menskala merentas berbilang mesin.
• Pengubahsuaian litar kompleks: tiada migrasi! Dalam pangkalan data hubungan, menukar struktur pangkalan data boleh menjadi masalah besar (terutama apabila terdapat banyak data). MongoDB dapat memudahkan proses ini. Dan ia menjadikannya begitu mudah sehingga anda hanya boleh mengemas kini litar sambil anda pergi dan bergerak dengan cepat.
• Prestasi rakaman: Prestasi MongoDB adalah baik, terutamanya apabila dikonfigurasikan dengan betul. Malah konfigurasi MongoDB yang luar biasa, yang sering dikritik, menunjukkan beberapa angka prestasi yang mengagumkan.

Semua risiko terletak pada anda

Faedah berpotensi MongoDB sangat besar, terutamanya untuk kelas masalah tertentu. Jika anda membaca senarai di atas tanpa memahami konteks dan tanpa pengalaman, anda mungkin mendapat tanggapan bahawa MongoDB adalah benar-benar DBMS revolusioner. Satu-satunya masalah ialah faedah yang disenaraikan di atas datang dengan beberapa kaveat, beberapa daripadanya disenaraikan di bawah.

Untuk berlaku adil, tiada sesiapa di 10gen/MongoDB Inc. tidak akan mengatakan bahawa perkara berikut tidak benar, ini hanyalah kompromi.

• Urus niaga yang hilang: Transaksi ialah ciri teras bagi banyak pangkalan data hubungan (bukan semua, tetapi kebanyakannya). Transaksional bermakna anda boleh melakukan berbilang operasi secara atom dan boleh memastikan data kekal konsisten. Sudah tentu, dengan pangkalan data NoSQL, transaksi boleh berada dalam satu dokumen, atau anda boleh menggunakan komitmen dua fasa untuk mendapatkan semantik transaksi. Tetapi anda perlu melaksanakan sendiri fungsi ini... yang boleh menjadi tugas yang sukar dan memakan masa. Selalunya anda tidak menyedari terdapat masalah sehingga anda melihat data dalam pangkalan data berakhir dalam keadaan tidak sah kerana atomicity operasi tidak dapat dijamin. Nota: Ramai orang memberitahu saya bahawa MongoDB 4.0 telah memperkenalkan transaksi tahun lepas, tetapi dengan beberapa batasan. Pengambilan daripada artikel itu tetap sama: nilai sejauh mana teknologi memenuhi keperluan anda.
• Kehilangan integriti hubungan (kunci asing): Jika data anda mempunyai hubungan, maka anda perlu menggunakannya dalam aplikasi. Mempunyai pangkalan data yang menghormati hubungan ini akan mengambil banyak kerja daripada aplikasi dan oleh itu pengaturcara anda.
• Kurang keupayaan untuk menggunakan struktur data: Skema yang ketat kadangkala boleh menjadi masalah besar, tetapi ia juga merupakan mekanisme yang berkuasa untuk penstrukturan data yang baik jika digunakan dengan bijak. Pangkalan data dokumen seperti MongoDB menyediakan fleksibiliti skema yang luar biasa, tetapi fleksibiliti ini menghilangkan tanggungjawab untuk memastikan data bersih. Jika anda tidak menjaganya, anda akhirnya akan menulis banyak kod dalam aplikasi anda untuk mengambil kira data yang tidak disimpan dalam bentuk yang anda harapkan. Seperti yang sering kami katakan di syarikat kami Simple Thread... aplikasi itu suatu hari nanti akan ditulis semula, tetapi data akan kekal selama-lamanya. Nota: MongoDB menyokong semakan skema: ia berguna, tetapi tidak memberikan jaminan yang sama seperti dalam pangkalan data hubungan. Pertama sekali, menambah atau menukar semakan skema tidak menjejaskan data sedia ada dalam koleksi. Terpulang kepada anda untuk memastikan anda mengemas kini data mengikut skema baharu. Tentukan sendiri sama ada ini mencukupi untuk keperluan anda.
• Bahasa pertanyaan asli / kehilangan ekosistem alat: Kemunculan SQL adalah revolusi mutlak dan tiada apa yang berubah sejak itu. Ia adalah bahasa yang sangat berkuasa, tetapi juga agak kompleks. Keperluan untuk membina pertanyaan pangkalan data dalam bahasa baharu yang terdiri daripada serpihan JSON dianggap sebagai langkah besar ke belakang oleh orang yang mempunyai pengalaman bekerja dengan SQL. Terdapat seluruh alam alat yang berinteraksi dengan pangkalan data SQL, daripada IDE kepada alat pelaporan. Beralih ke pangkalan data yang tidak menyokong SQL bermakna anda tidak boleh menggunakan kebanyakan alat ini atau anda perlu menterjemah data ke dalam SQL untuk menggunakannya, yang mungkin lebih sukar daripada yang anda fikirkan.

Ramai pembangun yang beralih kepada MongoDB tidak benar-benar memahami pertukaran, dan sering menyelam terlebih dahulu untuk memasangnya sebagai stor data utama mereka. Selepas ini ia selalunya amat sukar untuk kembali.

Apa yang boleh dilakukan secara berbeza?

Tidak semua orang melompat lebih awal dan memukul bahagian bawah. Tetapi banyak projek telah memasang MongoDB di tempat yang ia tidak sesuai - dan mereka perlu hidup dengannya selama bertahun-tahun akan datang. Jika organisasi ini telah meluangkan sedikit masa dan memikirkan secara teratur pilihan teknologi mereka, ramai yang akan membuat pilihan yang berbeza.

Bagaimana untuk memilih teknologi yang betul? Terdapat beberapa percubaan untuk mencipta rangka kerja yang sistematik untuk penilaian teknologi, seperti "Kerangka untuk memperkenalkan teknologi ke dalam organisasi perisian" и "Kerangka untuk menilai teknologi perisian", tetapi nampaknya saya ini adalah kerumitan yang tidak perlu.

Banyak teknologi boleh dinilai secara bijak dengan bertanya hanya dua soalan asas. Masalahnya ialah mencari orang yang boleh menjawabnya dengan penuh tanggungjawab, meluangkan masa untuk mencari jawapan dan tanpa berat sebelah.

Jika anda tidak menghadapi sebarang masalah, anda tidak memerlukan alat baharu. titik.

Soalan 1: Apakah masalah yang saya cuba selesaikan?

Jika anda tidak menghadapi sebarang masalah, anda tidak memerlukan alat baharu. titik. Tidak perlu mencari penyelesaian dan kemudian mencipta masalah. Melainkan anda menghadapi masalah yang diselesaikan oleh teknologi baharu dengan ketara lebih baik daripada teknologi sedia ada anda, tiada apa yang perlu dibincangkan di sini. Jika anda mempertimbangkan untuk menggunakan teknologi ini kerana anda telah melihat orang lain menggunakannya, fikirkan masalah yang mereka hadapi dan tanya jika anda mengalami masalah tersebut. Mudah untuk menerima teknologi kerana orang lain menggunakannya, cabarannya ialah memahami sama ada anda menghadapi masalah yang sama.

Soalan 2: Apa yang saya hilang?

Ini sememangnya soalan yang lebih sukar kerana anda perlu menggali dan memahami dengan baik kedua-dua teknologi lama dan baharu. Kadang-kadang anda tidak boleh benar-benar memahami yang baharu sehingga anda telah membina sesuatu dengannya atau mempunyai seseorang yang mempunyai pengalaman itu.

Jika anda tidak mempunyai kedua-duanya, maka masuk akal untuk memikirkan pelaburan minimum yang mungkin untuk menentukan nilai instrumen ini. Dan sebaik sahaja anda membuat pelaburan, betapa sukarnya untuk membalikkan keputusan itu?

Orang sentiasa merosakkan segala-galanya

Semasa anda cuba menjawab soalan-soalan ini dengan saksama yang mungkin, ingat satu perkara: anda perlu melawan sifat manusia. Terdapat beberapa bias kognitif yang mesti diatasi untuk menilai teknologi dengan berkesan. Berikut adalah beberapa sahaja:

• Kesan menyertai majoriti - semua orang tahu tentang dia, tetapi masih sukar untuk melawannya. Hanya pastikan teknologi benar-benar sepadan dengan keperluan sebenar anda.
• kesan kebaharuan — Ramai pembangun cenderung untuk memandang rendah teknologi yang telah mereka kerjakan untuk masa yang lama dan melebih-lebihkan faedah teknologi baharu. Ia bukan hanya pengaturcara, semua orang terdedah kepada kecenderungan kognitif ini.
• Kesan ciri-ciri positif - Kita cenderung untuk melihat apa yang ada dan melupakan apa yang hilang. Ini boleh membawa kepada huru-hara apabila digabungkan dengan kesan kebaharuan, kerana anda bukan sahaja terlalu menghargai teknologi baharu, tetapi juga mengabaikan kelemahannya.

Penilaian objektif bukanlah mudah, tetapi memahami kecenderungan kognitif yang mendasari akan membantu anda membuat keputusan yang lebih rasional.

Ringkasan

Setiap kali inovasi muncul, dua soalan mesti dijawab dengan berhati-hati:

• Adakah alat ini menyelesaikan masalah sebenar?
• Adakah kita memahami pertukaran dengan baik?

Jika anda tidak dapat menjawab dua soalan ini dengan yakin, ambil beberapa langkah ke belakang dan fikirkan.

Jadi adakah MongoDB adalah pilihan yang tepat? Sudah tentu YA; Seperti kebanyakan teknologi kejuruteraan, ini bergantung kepada banyak faktor. Di antara mereka yang menjawab dua soalan ini, ramai yang telah mendapat manfaat daripada MongoDB dan terus berbuat demikian. Bagi mereka yang tidak melakukannya, saya harap anda mempelajari pelajaran yang berharga dan tidak terlalu menyakitkan tentang bergerak melalui kitaran gembar-gembur.

Penafian

Saya ingin menjelaskan bahawa saya tidak mempunyai hubungan cinta mahupun benci dengan MongoDB. Kami tidak mempunyai jenis masalah yang paling sesuai untuk diselesaikan oleh MongoDB. Saya tahu bahawa 10gen/MongoDB Inc. pada mulanya sangat berani, menetapkan lalai yang tidak selamat dan mempromosikan MongoDB di mana-mana (terutamanya di hackathon) sebagai penyelesaian universal untuk bekerja dengan sebarang data. Ia mungkin keputusan yang buruk. Tetapi ia mengesahkan pendekatan yang diterangkan di sini: masalah ini boleh dikesan dengan cepat walaupun dengan penilaian cetek teknologi.

Sumber: www.habr.com