Terjemahan artikel telah disediakan pada malam permulaan kursus .
Sorotan:
- Ia amat penting untuk membangunkan skema walaupun ia adalah pilihan dalam MongoDB.
- Begitu juga, indeks mesti sepadan dengan skema dan corak akses anda.
- Elakkan menggunakan objek besar dan tatasusunan besar.
- Berhati-hati dengan tetapan MongoDB, terutamanya apabila ia berkaitan dengan keselamatan dan kebolehpercayaan.
- MongoDB tidak mempunyai pengoptimum pertanyaan, jadi anda mesti berhati-hati apabila melakukan operasi pertanyaan.
Saya telah bekerja dengan pangkalan data untuk masa yang sangat lama, tetapi baru-baru ini menemui MongoDB. Terdapat beberapa perkara yang saya harap saya tahu sebelum saya mula bekerja dengannya. Apabila seseorang sudah mempunyai pengalaman dalam bidang tertentu, mereka mempunyai tanggapan prasangka tentang pangkalan data dan apa yang mereka lakukan. Dengan harapan untuk memudahkan orang lain memahami, saya membentangkan senarai kesilapan biasa.
Mencipta pelayan MongoDB tanpa pengesahan
Malangnya, MongoDB dipasang tanpa pengesahan secara lalai. Untuk stesen kerja yang diakses secara tempatan, amalan ini adalah perkara biasa. Tetapi memandangkan MongoDB ialah sistem berbilang pengguna yang suka menggunakan jumlah memori yang besar, adalah lebih baik jika anda meletakkannya pada pelayan dengan RAM sebanyak mungkin, walaupun anda hanya akan menggunakannya untuk pembangunan. Memasang pada pelayan melalui port lalai boleh menjadi masalah, terutamanya jika sebarang kod javascript boleh dilaksanakan dalam permintaan (contohnya, $where sebagai idea untuk ).
Terdapat beberapa kaedah pengesahan, tetapi yang paling mudah ialah menetapkan ID pengguna/kata laluan. Gunakan idea ini semasa anda memikirkan tentang pengesahan mewah berdasarkan . Apabila bercakap tentang keselamatan, MongoDB harus sentiasa dikemas kini dan log hendaklah sentiasa diperiksa untuk akses yang tidak dibenarkan. Sebagai contoh, saya suka memilih port yang berbeza sebagai port lalai.
Jangan lupa untuk mengikat permukaan serangan ke MongoDB
mengandungi petua yang baik untuk mengurangkan risiko pencerobohan rangkaian dan kebocoran data. Sangat mudah untuk menghapuskannya dan mengatakan bahawa pelayan pembangunan tidak memerlukan tahap keselamatan yang tinggi. Walau bagaimanapun, ia tidak semudah itu dan ini terpakai kepada semua pelayan MongoDB. Khususnya, jika tiada alasan yang kukuh untuk digunakan , atau , anda perlu melumpuhkan penggunaan kod arbitrari dalam JavaScript dengan menulis dalam fail konfigurasi . Memandangkan fail data tidak disulitkan dalam MongoDB standard, masuk akal untuk menjalankan MongoDB dengannya , yang mempunyai akses penuh kepada fail, dengan akses terhad sahaja kepadanya dan keupayaan untuk menggunakan kawalan akses fail sistem pengendalian itu sendiri.
Ralat semasa membangunkan litar
MongoDB tidak menggunakan skema. Tetapi ini tidak bermakna bahawa skim itu tidak diperlukan. Jika anda hanya mahu menyimpan dokumen tanpa sebarang corak yang konsisten, menyimpannya boleh menjadi cepat dan mudah, tetapi untuk mendapatkannya kemudian boleh menjadi sukar. .
Artikel klasik " Ia berbaloi untuk dibaca, dan ciri seperti dalam alat pihak ketiga Studio 3T, ia patut digunakan untuk pemeriksaan biasa litar.
Jangan lupa susunan isihan
Melupakan susunan isihan boleh menyebabkan lebih banyak kekecewaan dan membuang lebih banyak masa daripada konfigurasi lain yang salah. Secara lalai penggunaan MongoBD . Tetapi ia tidak mungkin berguna kepada sesiapa sahaja. Jenis sensitif huruf besar, sensitif aksen, perduaan dianggap sebagai anakronisme yang ingin tahu bersama-sama dengan manik, kaftan dan misai kerinting pada tahun 80-an abad yang lalu. Kini penggunaan mereka tidak boleh dimaafkan. Dalam kehidupan sebenar, "motosikal" adalah sama dengan "Motor". Dan "Britain" dan "Britain" adalah tempat yang sama. Huruf kecil hanyalah setara dengan huruf besar huruf besar. Dan jangan biarkan saya mula menyusun diakritik. Apabila mencipta pangkalan data dalam MongoDB, gunakan pengumpulan tidak sensitif aksen dan , yang sesuai dengan bahasa dan . Ini akan menjadikan carian melalui data rentetan lebih mudah.
Buat koleksi dengan dokumen besar
MongoDB berbesar hati untuk mengehoskan dokumen besar sehingga 16MB dalam koleksi, dan Direka untuk dokumen besar yang lebih besar daripada 16 MB. Tetapi hanya kerana dokumen besar boleh diletakkan di sana, menyimpannya di sana bukanlah idea yang baik. MongoDB akan berfungsi dengan baik jika anda menyimpan dokumen individu yang bersaiz beberapa kilobait, memperlakukannya lebih seperti baris dalam jadual SQL yang luas. Dokumen yang besar akan menjadi punca masalah .
Mencipta dokumen dengan tatasusunan yang besar
Dokumen boleh mengandungi tatasusunan. Adalah lebih baik jika bilangan elemen dalam tatasusunan jauh daripada nombor empat digit. Jika elemen ditambahkan pada tatasusunan dengan kerap, ia akan mengatasi dokumen yang mengandunginya dan perlu , yang bermaksud ia perlu . Apabila mengindeks semula dokumen dengan tatasusunan yang besar, indeks selalunya akan ditimpa, kerana terdapat , yang menyimpan indeksnya. Pengindeksan semula ini juga berlaku apabila dokumen dimasukkan atau dipadamkan.
MongoDB mempunyai sesuatu yang dipanggil , yang menyediakan ruang untuk dokumen berkembang untuk meminimumkan masalah ini.
Anda mungkin berfikir bahawa anda boleh melakukannya tanpa pengindeksan tatasusunan. Malangnya, kekurangan indeks boleh menyebabkan anda menghadapi masalah lain. Memandangkan dokumen diimbas dari awal hingga akhir, mencari elemen pada penghujung tatasusunan akan mengambil masa yang lebih lama dan kebanyakan operasi yang dikaitkan dengan dokumen sedemikian akan .
Jangan lupa bahawa susunan peringkat dalam pengagregatan adalah penting
Dalam sistem pangkalan data dengan pengoptimum pertanyaan, pertanyaan yang anda tulis adalah penjelasan tentang perkara yang anda ingin dapatkan, bukan cara mendapatkannya. Mekanisme ini berfungsi dengan analogi dengan memesan di restoran: biasanya anda hanya memesan hidangan, dan tidak memberikan arahan terperinci kepada tukang masak.
Dalam MongoDB, anda mengarahkan tukang masak. Sebagai contoh, anda perlu memastikan bahawa data melaluinya reduce seawal mungkin dalam saluran paip menggunakan $match ΠΈ $project, dan pengisihan berlaku hanya selepas reduce, dan bahawa carian berlaku dalam susunan yang anda mahukan. Mempunyai pengoptimum pertanyaan yang menghapuskan kerja yang tidak perlu, menyusun langkah secara optimum dan memilih jenis gabungan boleh merosakkan anda. Dengan MongoDB, anda mempunyai lebih kawalan pada kos kemudahan.
Alat seperti akan memudahkan pembinaan pertanyaan pengagregatan dalam . Ciri Editor Pengagregatan membolehkan anda menggunakan pernyataan saluran paip satu peringkat pada satu masa, dan memeriksa data input dan output pada setiap peringkat untuk penyahpepijatan yang lebih mudah.
Menggunakan Rakaman Pantas
Jangan sekali-kali menetapkan pilihan tulis MongoDB untuk mempunyai kelajuan tinggi tetapi kebolehpercayaan rendah. Mod ini "fail-dan-lupakan" kelihatan pantas kerana arahan dikembalikan sebelum penulisan berlaku. Jika sistem ranap sebelum data ditulis ke cakera, ia akan hilang dan berakhir dalam keadaan tidak konsisten. Nasib baik, MongoDB 64-bit telah didayakan pengelogan.
Enjin storan MMAPv1 dan WiredTiger menggunakan pembalakan untuk menghalang perkara ini, walaupun WiredTiger boleh pulih kepada konsisten terakhir , jika pengelogan dilumpuhkan.
Journaling memastikan bahawa pangkalan data berada dalam keadaan konsisten selepas pemulihan dan mengekalkan semua data sehingga ia ditulis ke jurnal. Kekerapan rakaman dikonfigurasikan menggunakan parameter .
Untuk memastikan entri, pastikan pengelogan didayakan dalam fail konfigurasi ), dan kekerapan rakaman sepadan dengan jumlah maklumat yang anda mampu kehilangan.
Isih tanpa indeks
Apabila mencari dan mengagregat, selalunya terdapat keperluan untuk mengisih data. Harap-harap ini dilakukan pada salah satu peringkat akhir, selepas menapis hasilnya untuk mengurangkan jumlah data yang diisih. Dan walaupun dalam kes ini, untuk menyusun anda akan perlukan . Anda boleh menggunakan indeks tunggal atau kompaun.
Jika tiada indeks yang sesuai, MongoDB akan melakukannya tanpanya. Terdapat had memori sebanyak 32 MB pada jumlah saiz semua dokumen dalam , dan jika MongoDB mencapai had ini, ia sama ada akan membuang ralat atau kembali .
Cari tanpa sokongan indeks
Pertanyaan carian melaksanakan fungsi yang serupa dengan operasi JOIN dalam SQL. Untuk berfungsi dengan baik, mereka memerlukan indeks nilai kunci yang digunakan sebagai kunci asing. Ini tidak jelas kerana penggunaannya tidak ditunjukkan dalam explain(). Indeks sedemikian adalah tambahan kepada indeks yang ditulis dalam explain(), yang seterusnya digunakan oleh pengendali saluran paip $match ΠΈ $sort, apabila mereka bertemu pada permulaan saluran paip. Indeks kini boleh meliputi mana-mana peringkat .
Menarik diri daripada menggunakan pelbagai kemas kini
Kaedah digunakan untuk menukar sebahagian daripada dokumen sedia ada atau keseluruhan dokumen, sehingga penggantian lengkap, bergantung pada parameter yang anda tentukan . Apa yang tidak begitu jelas ialah ia tidak akan memproses semua dokumen dalam koleksi melainkan anda menetapkan pilihan untuk mengemas kini semua dokumen yang memenuhi kriteria permintaan.
Jangan lupa kepentingan susunan kekunci dalam jadual cincang
Dalam JSON, objek terdiri daripada koleksi tidak tertib saiz sifar atau lebih pasangan nama/nilai, dengan nama ialah rentetan dan nilai ialah rentetan, nombor, boolean, nol, objek atau tatasusunan.
Malangnya, BSON memberi banyak penekanan pada pesanan semasa mencari. Dalam MongoDB, susunan kunci dalam objek terbina dalam , iaitu { firstname: "Phil", surname: "factor" } - ini tidak sama dengan { { surname: "factor", firstname: "Phil" }. Iaitu, anda mesti menyimpan susunan pasangan nama/nilai dalam dokumen anda jika anda ingin memastikan mereka menemuinya.
Jangan keliru "Batal" ΠΈ "tidak ditentukan"
Nilai "tidak ditentukan" tidak pernah sah dalam JSON, menurut JSON (ECMA-404 Bahagian 5), walaupun ia digunakan dalam JavaScript. Selain itu, untuk BSON ia sudah usang dan ditukar kepada $null, yang tidak selalu merupakan penyelesaian yang baik. .
Gunakan $limit() tanpa $sort()
Selalunya apabila anda membangun dalam MongoDB, adalah berguna untuk hanya melihat sampel hasil yang akan dikembalikan daripada pertanyaan atau pengagregatan. Untuk tugas ini anda perlukan $limit(), tetapi ia tidak sepatutnya berada dalam kod akhir melainkan anda menggunakannya sebelum ini $sort. Mekanik ini diperlukan kerana jika tidak, anda tidak dapat menjamin susunan keputusan, dan anda tidak akan dapat melihat data dengan pasti. Di bahagian atas hasil anda akan mendapat entri yang berbeza bergantung pada pengisihan. Untuk berfungsi dengan pasti, pertanyaan dan pengagregatan mestilah bersifat deterministik, iaitu, menghasilkan hasil yang sama setiap kali ia dilaksanakan. Kod yang mengandungi $limit(), tetapi tidak $sort, tidak akan bersifat deterministik dan seterusnya boleh menyebabkan ralat yang sukar untuk dikesan.
Kesimpulan
Satu-satunya cara untuk kecewa dengan MongoDB ialah membandingkannya terus dengan jenis pangkalan data lain, seperti DBMS, atau datang untuk menggunakannya berdasarkan jangkaan tertentu. Ia seperti membandingkan oren dengan garpu. Sistem pangkalan data berfungsi untuk tujuan tertentu. Adalah lebih baik untuk memahami dan menghargai perbezaan ini sendiri. Adalah memalukan untuk menekan pembangun MongoDB melalui laluan yang memaksa mereka ke laluan DBMS. Saya ingin melihat cara baharu dan menarik untuk menyelesaikan masalah lama, seperti memastikan integriti data dan mencipta sistem data yang berdaya tahan terhadap kegagalan dan serangan berniat jahat.
Pengenalan MongoDB tentang transaksialiti ACID dalam versi 4.0 adalah contoh yang baik untuk memperkenalkan penambahbaikan penting dengan cara yang inovatif. Transaksi berbilang dokumen dan berbilang penyata kini bersifat atom. Ia juga mungkin untuk melaraskan masa yang diperlukan untuk memperoleh kunci dan menamatkan transaksi yang tersekat, serta menukar tahap pengasingan.
Baca lebih lanjut:
Sumber: www.habr.com