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

Jika Anda tiba-tiba merasa seperti saya melindungi MongoDB, harap baca penafian di akhir artikel.

Tren baru

Saya telah bekerja di industri perangkat lunak selama lebih dari bertahun-tahun untuk berbicara dengan sopan, tetapi semua sama, hanya sebagian kecil dari tren yang melanda industri kami yang menyumbang saya. Saya telah menyaksikan pertumbuhan 4GL, AOP, Agile, SOA, Web 2.0, AJAX, blockchain ... daftarnya tidak ada habisnya. Setiap tahun tren baru muncul. Beberapa dengan cepat menghilang, sementara yang lain secara mendasar mengubah cara perangkat lunak dikembangkan.

Sekitar setiap tren baru, kegembiraan umum dibuat: orang-orang baik melompat ke perahu, atau melihat suara yang dihasilkan oleh orang lain - dan mengikuti kerumunan. Proses ini dikodifikasikan oleh Gartner dalam siklus sensasi . Meskipun kontroversial, grafik ini secara kasar menggambarkan apa yang terjadi pada teknologi sebelum akhirnya dapat digunakan.

Tetapi dari waktu ke waktu, sebuah inovasi baru muncul (atau terjadi kedatangan kedua, seperti dalam kasus ini), didorong oleh hanya satu implementasi spesifik. Dalam kasus NoSQL, hype sangat didorong oleh munculnya dan peningkatan cepat MongoDB. MongoDB tidak meluncurkan 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 Bigtable dari Google dan Cassandra dari Facebook, tetapi MongoDB-lah yang menjadi implementasi paling terkenal dan terjangkau dari basis data NoSQL, yang dapat diakses oleh sebagian besar pengembang.

Catatan: Anda mungkin berpikir bahwa saya mencampur basis data dokumen dengan basis data 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 memerintah. Semua orang terobsesi dengan NoSQL, semua orang benar - benar membutuhkannya, walaupun banyak yang tidak melihat perbedaan dalam teknologi yang berbeda. Bagi banyak orang, MongoDB telah menjadi identik dengan NoSQL.

Dan para pengembang menyerangnya. Itu ide yang cukup menggoda untuk memiliki database tanpa skema yang secara ajaib berskala untuk menyelesaikan masalah apa pun. Sekitar 2014, tampaknya di mana-mana di mana database relasional digunakan setahun yang lalu, seperti MySQL, Postgres atau SQL Server, database MongoDB mulai digunakan. Untuk pertanyaan mengapa, Anda bisa mendapatkan jawaban dari dangkal "ini adalah skala web" ke yang lebih bijaksana "data saya sangat terstruktur dan sangat cocok ke dalam database tanpa skema".

Penting untuk diingat bahwa database MongoDB dan dokumen pada umumnya memecahkan sejumlah masalah dengan database relasional tradisional:

Skema ketat : dengan basis data relasional, jika Anda memiliki data yang dihasilkan secara dinamis, Anda terpaksa membuat sekelompok kolom data "berbeda" acak, mendorong gumpalan data di sana atau menggunakan konfigurasi EAV ... semua ini memiliki kelemahan yang signifikan.
Kesulitan penskalaan : jika ada begitu banyak data yang tidak sesuai pada satu server, MongoDB telah mengusulkan mekanisme untuk menskalakannya pada beberapa mesin.
Modifikasi sirkuit canggih : tidak ada migrasi! Dalam database relasional, mengubah struktur database bisa menjadi masalah besar (terutama ketika ada banyak data). MongoDB dapat sangat menyederhanakan proses. Dan itu membuatnya sangat mudah sehingga Anda hanya dapat memperbarui sirkuit saat bepergian dan bergerak sangat cepat.
Merekam kinerja: Kinerja MongoDB baik, terutama dengan penyetelan yang tepat. Bahkan konfigurasi MongoDB di luar kotak, yang sering dikritik, menunjukkan beberapa metrik kinerja yang mengesankan.

Semua risiko ada pada Anda.

Potensi manfaat 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 revolusioner. Satu-satunya masalah adalah bahwa keuntungan di atas disertai dengan sejumlah pemesanan, beberapa di antaranya tercantum di bawah ini.

Dalam keadilan, tidak ada seorang pun di 10gen / MongoDB Inc. dia tidak akan mengatakan bahwa yang berikut ini tidak benar, itu hanya kompromi.

Kehilangan transaksi : Transaksi adalah fitur utama dari banyak basis data relasional (tidak semua, tetapi sebagian besar). Transaksional berarti Anda dapat melakukan beberapa operasi secara atom dan dapat menjamin bahwa data akan tetap konsisten. Tentu saja, dengan database NoSQL, transaksionalitas dapat berada dalam dokumen yang sama, atau Anda dapat menggunakan komitmen dua fase untuk mendapatkan semantik transaksional. Tetapi Anda harus mengimplementasikan fungsi ini sendiri ... yang dapat menjadi tugas yang kompleks dan memakan waktu. Seringkali Anda tidak menyadari masalah sampai Anda melihat bahwa data dalam database jatuh ke keadaan yang tidak dapat diterima, karena tidak mungkin untuk menjamin keaslian operasi. Catatan: banyak yang memberi tahu saya bahwa transaksi muncul di MongoDB 4.0 tahun lalu, tetapi dengan sejumlah keterbatasan. Kesimpulan dari artikel tetap sama: mengevaluasi bagaimana teknologi memenuhi kebutuhan Anda.
Kehilangan integritas relasional (kunci asing) : jika ada hubungan dalam data Anda, maka Anda harus menerapkannya dalam aplikasi. Memiliki basis data yang sesuai dengan hubungan ini akan menghapus sebagian besar pekerjaan dari aplikasi dan, oleh karena itu, dari programmer Anda.
Kurangnya kemampuan untuk menerapkan struktur data : skema ketat terkadang menjadi masalah besar, tetapi juga merupakan mekanisme yang kuat untuk penataan data yang baik, jika digunakan dengan benar. Database dokumen seperti MongoDB memberikan fleksibilitas skema yang luar biasa, tetapi fleksibilitas ini menghilangkan tanggung jawab menjaga data tetap bersih. Jika Anda tidak merawatnya, maka pada akhirnya Anda harus menulis banyak kode dalam aplikasi untuk menghitung data yang tidak disimpan dalam bentuk yang Anda harapkan. Seperti yang sering dikatakan perusahaan kami Thread Sederhana ... suatu hari aplikasi akan ditulis ulang, dan datanya akan hidup selamanya. Catatan: MongoDB mendukung validasi skema: ini berguna, tetapi tidak memberikan jaminan yang sama seperti dalam database relasional. Pertama-tama, menambahkan atau memodifikasi pemeriksaan skema tidak memengaruhi data yang ada dalam koleksi. Anda sendiri harus memastikan bahwa Anda memperbarui data sesuai dengan skema baru. Putuskan sendiri apakah ini cukup untuk kebutuhan Anda.
Bahasa query asli / hilangnya ekosistem alat : munculnya SQL telah menjadi revolusi absolut, dan tidak ada yang berubah sejak saat itu. Ini adalah bahasa yang sangat kuat, tetapi juga sangat kompleks. Kebutuhan untuk merancang kueri basis data dalam bahasa baru yang terdiri dari fragmen JSON dianggap sebagai langkah besar ke belakang oleh orang-orang yang memiliki pengalaman dengan SQL. Ada seluruh semesta alat yang berinteraksi dengan database SQL: dari IDE ke alat pelaporan. Pergi ke database yang tidak mendukung SQL berarti bahwa Anda tidak dapat menggunakan sebagian besar alat ini atau Anda perlu mengkonversi data ke SQL untuk menggunakannya, dan ini bisa lebih sulit daripada yang Anda pikirkan.

Banyak pengembang yang beralih ke MongoDB tidak benar-benar memahami pertukaran, dan sering menukik, mengaturnya sebagai penyimpanan data primer. Setelah ini, seringkali sangat sulit untuk kembali.

Apa yang bisa dilakukan secara berbeda?

Tidak semua orang melompat duluan dan mencapai bagian bawah. Tetapi banyak proyek menginstal pangkalan MongoDB di mana itu tidak cocok - dan mereka harus hidup dengannya selama bertahun-tahun. Jika organisasi-organisasi ini menghabiskan waktu dan secara metodis mempertimbangkan pilihan teknologi, banyak yang akan membuat pilihan yang berbeda.

Bagaimana cara memilih teknologi yang tepat? Ada beberapa upaya untuk membuat kerangka kerja sistematis untuk mengevaluasi teknologi, seperti "Kerangka untuk memperkenalkan teknologi ke dalam organisasi perangkat lunak" dan "Kerangka untuk mengevaluasi teknologi perangkat lunak" , tetapi bagi saya tampaknya ini adalah kompleksitas yang tidak perlu.

Banyak teknologi dapat dievaluasi secara wajar dengan hanya mengajukan dua pertanyaan dasar. Masalahnya adalah menemukan orang yang dapat merespons secara bertanggung jawab terhadap mereka, menghabiskan waktu mencari jawaban dan tanpa bias.

Jika Anda tidak menemukan masalah, Anda tidak perlu alat baru. Intinya.

Pertanyaan 1: Masalah apa yang saya coba selesaikan?

Jika Anda tidak menemukan masalah, Anda tidak perlu alat baru. Intinya. Tidak perlu mencari solusi dan kemudian muncul masalah. Jika Anda belum mengalami masalah bahwa teknologi baru tidak menyelesaikan jauh lebih baik daripada teknologi yang ada, maka tidak ada yang perlu didiskusikan. Jika Anda mempertimbangkan untuk menggunakan teknologi ini karena Anda melihat bagaimana orang lain menggunakannya, maka pertimbangkan masalah apa yang mereka hadapi dan tanyakan apakah Anda memiliki masalah seperti itu. Sangat mudah untuk menerima teknologi karena orang lain menggunakannya, kesulitannya adalah dalam memahami apakah Anda menghadapi masalah yang sama.

Pertanyaan 2: Apa yang hilang dari saya?

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

Jika Anda tidak memiliki satu atau yang lain, maka masuk akal untuk berpikir tentang investasi minimum yang mungkin untuk menentukan nilai alat ini. Dan jika Anda berinvestasi, seberapa sulitkah membalikkan keputusan?

Orang selalu merusak segalanya

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

Efek bergabung dengan mayoritas - semua orang tahu tentang hal itu, tetapi masih sulit untuk bertarung dengannya. Pastikan saja teknologi tersebut benar-benar sesuai dengan kebutuhan Anda yang sebenarnya.
Efek kebaruan - banyak pengembang cenderung meremehkan teknologi yang telah mereka kerjakan untuk waktu yang lama dan melebih-lebihkan keuntungan dari teknologi baru. Bukan hanya programmer, setiap orang tunduk pada bias kognitif ini.
Efek dari karakteristik positif - kita cenderung melihat apa yang ada, dan kehilangan pandangan tentang apa yang hilang. Ini dapat menyebabkan kekacauan dalam kombinasi dengan efek kebaruan, karena Anda tidak hanya melebih-lebihkan teknologi baru, tetapi juga mengabaikan kekurangannya .

Penilaian objektif tidak mudah, tetapi memahami bias kognitif dasar akan membantu membuat keputusan yang lebih rasional.

Ringkasan

Ketika inovasi tertentu muncul, dua pertanyaan harus dijawab dengan sangat hati-hati:

Apakah alat ini memecahkan masalah nyata?
Apakah kita memahami kompromi dengan baik?

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

Jadi, apakah MongoDB umumnya pilihan yang tepat? Tentu saja ya; seperti kebanyakan teknologi rekayasa, ini tergantung pada banyak faktor. Di antara mereka yang menjawab dua pertanyaan ini, banyak yang mendapat manfaat dari MongoDB dan terus mendapat manfaat darinya. Siapa pun yang tidak melakukan ini, saya harap mereka menerima pelajaran yang berharga dan tidak terlalu menyakitkan tentang gerakan sepanjang siklus hype.

Penafian

Saya ingin mengklarifikasi bahwa saya tidak memiliki cinta atau kebencian untuk MongoDB. Hanya saja kami tidak memiliki masalah yang paling cocok dengan MongoDB. Saya tahu bahwa 10gen / MongoDB Inc. Pada awalnya, dia bertindak sangat berani, menetapkan nilai default yang tidak aman dan mempromosikan MongoDB di mana-mana (terutama pada hackathon) sebagai solusi universal untuk bekerja dengan data apa pun. Ini mungkin keputusan yang buruk. Tapi itu menegaskan pendekatan yang dijelaskan di sini: masalah ini dapat dideteksi dengan sangat cepat bahkan dengan evaluasi teknologi yang dangkal.

Apakah MongoDB pilihan yang tepat?