Saya baru tahu itu Red Hat menghapus dukungan MongoDB dari Satelit (misalnya, karena perubahan lisensi). Itu membuat saya berpikir bahwa dalam beberapa tahun terakhir saya telah melihat banyak artikel tentang betapa buruknya MongoDB dan tidak seorang pun boleh menggunakannya. Namun selama ini, MongoDB telah menjadi produk yang jauh lebih matang. Apa yang telah terjadi? Apakah semua kebencian itu benar-benar karena kesalahan di awal pemasaran DBMS yang baru? Atau apakah orang hanya menggunakan MongoDB di tempat yang salah?

Jika Anda tiba-tiba merasa saya membela MongoDB, silakan baca penafian di akhir artikel.

Tren baru

Saya telah berkecimpung di industri perangkat lunak selama bertahun-tahun lebih dari yang bisa dikatakan, tetapi tetap saja saya hanya menjadi bagian dari tren yang melanda industri kami. Saya telah menyaksikan kebangkitan 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain… daftarnya tidak ada habisnya. Setiap tahun ada tren baru. Beberapa memudar dengan cepat, sementara yang lain secara mendasar mengubah cara perangkat lunak dikembangkan.

Di sekitar setiap tren baru, kegembiraan umum tertentu tercipta: orang-orang melompat ke perahu sendiri, atau melihat kebisingan yang dihasilkan oleh orang lain - dan mengikuti kerumunan. Proses ini telah dikodifikasi oleh Gartner di Siklus hype. Meskipun masih bisa diperdebatkan, grafik ini menggambarkan secara kasar apa yang terjadi pada teknologi sebelum akhirnya berguna untuk digunakan.

Tetapi dari waktu ke waktu ada (atau ada kedatangan kedua, seperti dalam kasus ini) sebuah inovasi baru, didorong oleh hanya satu implementasi spesifik darinya. Dalam kasus NoSQL, hype sangat didorong oleh kemunculan dan kebangkitan MongoDB yang meroket. MongoDB tidak memulai tren ini: pada kenyataannya, perusahaan Internet besar mulai mengalami masalah dalam memproses data dalam jumlah besar, yang menyebabkan kembalinya database non-relasional. Pergerakan umum dimulai dengan proyek-proyek seperti Google's Bigtable dan Facebook's Cassandra, tetapi MongoDB-lah yang menjadi implementasi database NoSQL yang paling terkenal dan dapat diakses yang dapat diakses oleh sebagian besar pengembang.

Catatan: Anda mungkin berpikir bahwa saya membingungkan database dokumen dengan database kolom, penyimpanan kunci/nilai, atau salah satu dari banyak jenis penyimpanan data lainnya yang termasuk dalam definisi umum NoSQL. Dan kamu benar. Tetapi pada saat itu, kekacauan merajalela. Semua orang terobsesi dengan NoSQL, itu telah menjadi segalanya tentu saja perlu, meskipun banyak yang tidak melihat perbedaan dalam teknologi yang berbeda. Bagi banyak orang, MongoDB telah menjadi sinonim dengan Tanpa SQL.

Dan para pengembang melompatinya. Gagasan tentang basis data tanpa skema yang secara ajaib diskalakan untuk menyelesaikan masalah apa pun cukup menggoda. Sekitar tahun 2014, tampaknya di mana-mana database relasional seperti MySQL, Postgres, atau SQL Server digunakan setahun yang lalu, database MongoDB digunakan. Ketika ditanya mengapa, Anda bisa mendapatkan jawaban dari yang dangkal "ini adalah skala web" hingga yang lebih bijaksana "data saya terstruktur sangat longgar dan cocok dengan basis data tanpa skema."

Penting untuk diingat bahwa MongoDB, dan database dokumen secara umum, menyelesaikan sejumlah masalah dengan database relasional tradisional:

• Skema ketat: dengan database relasional, jika Anda memiliki data yang dihasilkan secara dinamis, Anda dipaksa untuk membuat banyak kolom data "berbeda" acak, mendorong gumpalan data di sana, atau menggunakan konfigurasi ekstensi EAV… semua ini memiliki kekurangan yang signifikan.
• Kesulitan penskalaan: Jika ada begitu banyak data yang tidak muat di satu server, MongoDB menawarkan mekanisme untuk memungkinkannya diskalakan di beberapa mesin.
• Modifikasi sirkuit yang rumit: tidak ada migrasi! Dalam database relasional, mengubah struktur database bisa menjadi masalah besar (terutama bila ada banyak data). MongoDB telah mampu menyederhanakan prosesnya. Dan membuatnya sangat mudah sehingga Anda dapat memperbarui skema saat bepergian dan melanjutkan dengan sangat cepat.
• Menulis kinerja: Performa MongoDB bagus, terutama jika disetel dengan benar. Bahkan konfigurasi MongoDB yang out-of-the-box, yang sering dikritik, menunjukkan beberapa angka kinerja yang mengesankan.

Semua risiko ada pada Anda

Manfaat potensial MongoDB sangat besar, terutama untuk kelas masalah tertentu. Jika Anda membaca daftar di atas tanpa memahami konteksnya dan tidak memiliki pengalaman, Anda mungkin mendapat kesan bahwa MongoDB benar-benar DBMS yang revolusioner. Satu-satunya masalah adalah manfaat yang tercantum di atas datang dengan sejumlah peringatan, beberapa di antaranya tercantum di bawah ini.

Agar adil, tidak ada seorang pun di 10gen/MongoDB Inc. tidak akan mengatakan bahwa yang berikut ini tidak benar, ini hanya kompromi.

• Kerugian transaksiJ: Transaksi adalah fitur inti dari banyak database relasional (tidak semua, tetapi sebagian besar). Transaksional berarti Anda dapat melakukan banyak operasi secara atomik dan dapat memastikan bahwa data tetap konsisten. Tentu saja, dengan database NoSQL, transaksional dapat berada dalam satu dokumen, atau Anda dapat menggunakan komitmen dua fase untuk mendapatkan semantik transaksional. Tetapi Anda harus mengimplementasikan fungsi ini sendiri... yang bisa menjadi tugas yang sulit dan memakan waktu. Seringkali Anda tidak menyadari masalah sampai Anda melihat bahwa data dalam database masuk ke status tidak valid karena tidak mungkin untuk menjamin atomisitas operasi. Catatan: Saya telah diberitahu oleh banyak orang bahwa transaksi diperkenalkan di MongoDB 4.0 tahun lalu, tetapi dengan beberapa batasan. Kesimpulan dari artikel tersebut tetap sama: menilai bagaimana teknologi tersebut sesuai dengan kebutuhan Anda.
• Hilangnya integritas relasional (kunci asing): jika data Anda memiliki hubungan, maka Anda harus menerapkannya di aplikasi. Memiliki database yang menghormati hubungan ini akan membutuhkan banyak pekerjaan dari aplikasi dan oleh karena itu pada pemrogram Anda.
• Ketidakmampuan untuk menerapkan struktur data: Skema ketat kadang-kadang bisa menjadi masalah besar, tetapi mereka juga merupakan mekanisme yang kuat untuk penataan data yang baik jika digunakan dengan bijak. Database dokumen seperti MongoDB memberikan fleksibilitas skema yang luar biasa, tetapi fleksibilitas itu menghilangkan tanggung jawab untuk menjaga kebersihan data. Jika Anda tidak merawatnya, pada akhirnya Anda akan menulis banyak kode di aplikasi Anda untuk memperhitungkan data yang tidak disimpan dalam bentuk yang Anda harapkan. Seperti yang sering mereka katakan di Simple Thread perusahaan kami… aplikasi akan ditulis ulang suatu hari nanti, tetapi datanya akan hidup selamanya. Catatan: MongoDB mendukung validasi skema, yang berguna tetapi tidak memberikan jaminan yang sama seperti database relasional. Pertama-tama, menambah atau mengubah validasi skema tidak memengaruhi data yang ada dalam koleksi. Anda harus memastikan bahwa Anda memperbarui data sesuai dengan skema baru. Putuskan sendiri apakah ini cukup untuk kebutuhan Anda.
• Bahasa kueri sendiri / hilangnya ekosistem alat: Munculnya SQL adalah revolusi mutlak, dan tidak ada yang berubah sejak saat itu. Ini adalah bahasa yang sangat kuat, tetapi juga cukup kompleks. Kebutuhan untuk membuat kueri basis data dalam bahasa baru, yang terdiri dari fragmen JSON, dianggap sebagai langkah mundur yang besar oleh orang-orang yang berpengalaman dengan SQL. Ada banyak alat yang berinteraksi dengan database SQL, dari IDE hingga alat pelaporan. Pindah ke database yang tidak mendukung SQL berarti Anda tidak dapat menggunakan sebagian besar alat ini, atau Anda perlu mengonversi data ke SQL untuk menggunakannya, yang mungkin lebih sulit daripada yang Anda pikirkan.

Banyak pengembang yang beralih ke MongoDB tidak terlalu memahami trade-off, dan sering menyelam lebih dulu untuk menyiapkannya sebagai penyimpanan data utama mereka. Setelah itu, seringkali sangat sulit untuk kembali.

Apa yang bisa dilakukan secara berbeda?

Tidak semua orang melompat lebih dulu dan jatuh ke bawah. Tetapi banyak proyek telah menginstal basis MongoDB yang tidak sesuai - dan mereka harus menggunakannya selama bertahun-tahun. Jika organisasi-organisasi ini meluangkan waktu untuk mempertimbangkan pilihan teknologi mereka secara metodis, banyak yang akan membuat pilihan yang berbeda.

Bagaimana cara memilih teknologi yang tepat? Ada beberapa upaya untuk membuat kerangka sistematis untuk penilaian teknologi, seperti "Kerangka untuk penerapan teknologi dalam organisasi perangkat lunak" и "Framefork untuk mengevaluasi teknologi perangkat lunak", tetapi menurut saya ini adalah kerumitan yang tidak perlu.

Banyak teknologi dapat dinilai secara cerdas hanya dengan mengajukan dua pertanyaan dasar. Masalahnya terletak pada menemukan orang yang dapat menjawabnya secara bertanggung jawab, meluangkan waktu untuk menemukan jawaban dan tanpa bias.

Jika Anda tidak menghadapi masalah, Anda tidak memerlukan alat baru. Dot.

Pertanyaan 1: Masalah apa yang saya coba selesaikan?

Jika Anda tidak menghadapi masalah, Anda tidak memerlukan alat baru. Dot. Tidak perlu mencari solusi lalu muncul masalah. Kecuali jika Anda menghadapi masalah bahwa teknologi baru tidak dapat menyelesaikannya secara signifikan lebih baik daripada teknologi Anda saat ini, maka tidak ada yang perlu didiskusikan di sini. Jika Anda mempertimbangkan untuk menggunakan teknologi ini karena Anda telah melihat orang lain menggunakannya, pikirkan tentang masalah yang mereka hadapi dan tanyakan apakah Anda mengalami masalah tersebut. Sangat mudah untuk merangkul teknologi karena orang lain menggunakannya, kesulitannya adalah mengetahui apakah Anda menghadapi masalah yang sama.

Pertanyaan 2: Apa yang saya lewatkan?

Ini tentu pertanyaan yang lebih sulit, karena Anda harus menggali dan memahami teknologi lama dan baru dengan baik. Kadang-kadang Anda tidak dapat benar-benar memahami yang baru sampai Anda membangun sesuatu dengannya atau memiliki rekan kerja dengan pengalaman itu.

Jika Anda tidak memiliki keduanya, masuk akal untuk memikirkan investasi seminimal mungkin untuk menentukan nilai instrumen ini. Dan jika Anda melakukan investasi, seberapa sulitkah untuk membalikkan keputusan?

Orang-orang selalu merusak segalanya

Dalam mencoba menjawab pertanyaan-pertanyaan ini dengan tidak memihak, ingat satu hal: Anda harus melawan sifat manusia. Ada sejumlah bias kognitif yang harus diatasi untuk mengevaluasi teknologi secara efektif. Berikut beberapa di antaranya:

• Efek bergabung dengan mayoritas Semua orang tahu tentang dia, tapi masih sulit untuk melawannya. Pastikan saja teknologinya benar-benar sesuai dengan kebutuhan Anda yang sebenarnya.
• efek kebaruan Banyak pengembang cenderung meremehkan teknologi yang telah mereka gunakan sejak lama dan melebih-lebihkan manfaat dari teknologi baru. Tidak hanya programmer, semua orang tunduk pada bias kognitif ini.
• Efek Atribut Positif Kita cenderung melihat apa yang ada dan melupakan apa yang tidak. Hal ini dapat menyebabkan kekacauan, dikombinasikan dengan efek kebaruan, karena Anda tidak hanya menilai terlalu tinggi teknologi baru, tetapi juga mengabaikan kekurangannya..

Penilaian objektif tidaklah mudah, tetapi memahami bias kognitif yang mendasarinya akan membantu Anda membuat keputusan yang lebih rasional.

Ringkasan

Ketika sebuah inovasi muncul, dua pertanyaan perlu dijawab dengan sangat hati-hati:

• Apakah alat ini memecahkan masalah nyata?
• Apakah kita pandai memahami pertukaran?

Jika Anda tidak dapat menjawab dua pertanyaan ini dengan percaya diri, mundurlah beberapa langkah dan pikirkan.

Jadi, apakah la MongoDB secara umum merupakan pilihan yang tepat? Tentu saja ya; seperti kebanyakan teknologi rekayasa, itu tergantung pada banyak faktor. Di antara mereka yang menjawab dua pertanyaan ini, banyak yang mendapat manfaat dari MongoDB dan terus melakukannya. Bagi Anda yang belum, saya harap Anda telah mempelajari pelajaran yang berharga dan tidak terlalu menyakitkan tentang melewati siklus hype.

еймер

Saya ingin mengklarifikasi bahwa saya tidak menyukai atau membenci MongoDB. Kami hanya tidak memiliki jenis masalah yang paling cocok untuk diselesaikan oleh MongoDB. Saya tahu 10gen/MongoDB Inc. bertindak sangat berani pada awalnya, menyetel default yang tidak aman dan mempromosikan MongoDB di mana-mana (terutama di hackathon) sebagai solusi satu atap untuk bekerja dengan data apa pun. Itu mungkin keputusan yang buruk. Tapi itu menegaskan pendekatan yang dijelaskan di sini: masalah ini dapat dideteksi dengan sangat cepat bahkan dengan penilaian teknologi yang dangkal.

Sumber: www.habr.com