Ang pagsasalin ng artikulo ay inihanda sa bisperas ng pagsisimula ng kurso .
Highlight:
- Napakahalaga na bumuo ng isang schema kahit na ito ay opsyonal sa MongoDB.
- Gayundin, dapat tumugma ang mga index sa iyong schema at mga pattern ng pag-access.
- Iwasang gumamit ng malalaking bagay at malalaking array.
- Mag-ingat sa mga setting ng MongoDB, lalo na pagdating sa seguridad at pagiging maaasahan.
- Walang query optimizer ang MongoDB, kaya dapat kang mag-ingat kapag nagsasagawa ng mga operasyon ng query.
Ako ay nagtatrabaho sa mga database sa napakatagal na panahon, ngunit kamakailan lamang ay natuklasan ang MongoDB. Mayroong ilang mga bagay na nais kong malaman bago ako nagsimulang magtrabaho dito. Kapag ang isang tao ay mayroon nang karanasan sa isang partikular na larangan, mayroon silang mga naisip tungkol sa kung ano ang mga database at kung ano ang kanilang ginagawa. Sa pag-asang gawing mas madaling maunawaan ng iba, nagpapakita ako ng listahan ng mga karaniwang pagkakamali.
Paglikha ng isang MongoDB server nang walang pagpapatunay
Sa kasamaang palad, ang MongoDB ay naka-install nang walang pagpapatunay bilang default. Para sa isang workstation na na-access nang lokal, ang pagsasanay na ito ay normal. Ngunit dahil ang MongoDB ay isang multi-user system na gustong gumamit ng malaking halaga ng memorya, mas mabuti kung ilalagay mo ito sa isang server na may pinakamaraming RAM hangga't maaari, kahit na gagamitin mo lamang ito para sa pag-unlad. Ang pag-install sa server sa pamamagitan ng default na port ay maaaring maging problema, lalo na kung anumang javascript code ang maaaring isagawa sa kahilingan (halimbawa, $where bilang isang ideya para sa ).
Mayroong ilang mga paraan ng pagpapatunay, ngunit ang pinakamadali ay magtakda ng user ID/password. Gamitin ang ideyang ito habang iniisip mo ang tungkol sa magarbong pagpapatotoo batay sa . Pagdating sa seguridad, ang MongoDB ay dapat na palaging na-update, at ang mga log ay dapat palaging suriin para sa hindi awtorisadong pag-access. Halimbawa, gusto kong pumili ng ibang port bilang default na port.
Huwag kalimutang itali ang ibabaw ng pag-atake sa MongoDB
naglalaman ng magagandang tip para mabawasan ang panganib ng panghihimasok sa network at pagtagas ng data. Madaling alisin ito at sabihin na ang isang development server ay hindi nangangailangan ng mataas na antas ng seguridad. Gayunpaman, hindi ganoon kadali at nalalapat ito sa lahat ng mga server ng MongoDB. Sa partikular, kung walang matibay na dahilan para gamitin , o , kailangan mong i-disable ang paggamit ng arbitrary code sa JavaScript sa pamamagitan ng pagsusulat sa configuration file . Dahil ang mga file ng data ay hindi naka-encrypt sa karaniwang MongoDB, makatuwirang patakbuhin ang MongoDB gamit ang , na may ganap na access sa mga file, na may limitadong access lamang dito at ang kakayahang gamitin ang sariling mga kontrol sa pag-access ng file ng operating system.
Error habang binubuo ang circuit
Ang MongoDB ay hindi gumagamit ng schema. Ngunit hindi ito nangangahulugan na ang pamamaraan ay hindi kinakailangan. Kung gusto mo lang mag-imbak ng mga dokumento nang walang anumang pare-parehong pattern, ang pag-iimbak ng mga ito ay maaaring maging mabilis at madali, ngunit ang pagkuha ng mga ito sa ibang pagkakataon ay maaaring maging mahirap. .
Klasikong artikulo " Ito ay nagkakahalaga ng pagbabasa, at mga tampok tulad ng sa third-party na tool na Studio 3T, sulit itong gamitin para sa mga regular na pagsusuri ng mga circuit.
Huwag kalimutan ang pagkakasunud-sunod ng pag-uuri
Ang paglimot sa pagkakasunud-sunod ng pag-uuri ay maaaring magdulot ng higit na pagkabigo at pag-aaksaya ng mas maraming oras kaysa sa anumang iba pang maling configuration. Bilang default, ginagamit ng MongoBD . Ngunit ito ay malamang na hindi kapaki-pakinabang sa sinuman. Ang case-sensitive, accent-sensitive, binary sort ay itinuturing na mga kakaibang anachronism kasama ng mga kuwintas, caftan at kulot na bigote noong dekada 80 ng huling siglo. Ngayon ang kanilang paggamit ay hindi mapapatawad. Sa totoong buhay, ang "motorsiklo" ay kapareho ng "Motorsiklo". At ang "Britain" at "Britain" ay iisang lugar. Ang maliit na titik ay ang malaking titik na katumbas ng malaking titik. At huwag mo akong simulan sa pag-uuri ng mga diacritics. Kapag gumagawa ng database sa MongoDB, gumamit ng accent-insensitive collation at , na tumutugma sa wika at . Gagawin nitong mas madali ang paghahanap sa pamamagitan ng string data.
Gumawa ng mga koleksyon na may malalaking dokumento
Masaya ang MongoDB na mag-host ng malalaking dokumento hanggang 16MB sa mga koleksyon, at Idinisenyo para sa malalaking dokumento na mas malaki sa 16 MB. Ngunit dahil lamang sa maaaring ilagay doon ang malalaking dokumento, hindi magandang ideya ang pag-iimbak ng mga ito doon. Pinakamahusay na gagana ang MongoDB kung mag-iimbak ka ng mga indibidwal na dokumento na ilang kilobytes ang laki, na tinatrato ang mga ito na parang mga hilera sa isang malawak na talahanayan ng SQL. Ang malalaking dokumento ay pagmulan ng mga problema .
Paglikha ng mga dokumento na may malalaking array
Ang mga dokumento ay maaaring maglaman ng mga array. Pinakamainam kung ang bilang ng mga elemento sa array ay malayo sa isang apat na digit na numero. Kung ang mga elemento ay madalas na idinagdag sa isang array, lalampas nito ang dokumentong naglalaman nito at kakailanganing maging , na nangangahulugang kakailanganin ito . Kapag muling ini-index ang isang dokumento na may malaking array, ang mga index ay madalas na ma-overwrite, dahil mayroong , na nag-iimbak ng index nito. Ang muling pag-index na ito ay nangyayari din kapag ang isang dokumento ay ipinasok o tinanggal.
May tinatawag ang MongoDB , na nagbibigay ng puwang para sa mga dokumento na lumago upang mabawasan ang problemang ito.
Maaari mong isipin na magagawa mo nang walang array indexing. Sa kasamaang palad, ang kakulangan ng mga index ay maaaring magdulot sa iyo ng iba pang mga problema. Dahil ang mga dokumento ay ini-scan mula simula hanggang matapos, ang paghahanap ng mga elemento sa dulo ng array ay mas magtatagal, at karamihan sa mga operasyong nauugnay sa naturang dokumento ay magiging .
Huwag kalimutan na ang pagkakasunud-sunod ng mga yugto sa isang pagsasama-sama ay mahalaga
Sa isang database system na may query optimizer, ang mga query na isinusulat mo ay mga paliwanag kung ano ang gusto mong makuha, hindi kung paano ito makukuha. Ang mekanismong ito ay gumagana sa pamamagitan ng pagkakatulad sa pag-order sa isang restaurant: kadalasan ay nag-order ka lang ng isang ulam, at hindi nagbibigay ng mga detalyadong tagubilin sa nagluluto.
Sa MongoDB, tinuturuan mo ang lutuin. Halimbawa, kailangan mong tiyakin na dumadaan ang data reduce nang maaga hangga't maaari sa pipeline gamit $match ΠΈ $project, at ang pag-uuri ay nangyayari lamang pagkatapos reduce, at ang paghahanap ay nangyayari sa eksaktong pagkakasunud-sunod na gusto mo. Maaaring masira ka ng pagkakaroon ng query optimizer na nag-aalis ng hindi kinakailangang gawain, mahusay na nagsusunod-sunod ng mga hakbang, at pumili ng mga uri ng pagsali. Sa MongoDB, mayroon kang higit na kontrol sa halaga ng kaginhawahan.
Mga tool tulad ng ay pasimplehin ang pagbuo ng mga pagsasama-sama ng mga query sa . Binibigyang-daan ka ng feature na Aggregation Editor na maglapat ng mga pipeline statement nang paisa-isa, at suriin ang input at output data sa bawat yugto para sa mas madaling pag-debug.
Gamit ang Mabilis na Pagre-record
Huwag kailanman itakda ang mga pagpipilian sa pagsulat ng MongoDB upang magkaroon ng mataas na bilis ngunit mababang pagiging maaasahan. Ang mode na ito "file-and-forget" tila mabilis dahil ibinalik ang utos bago mangyari ang pagsulat. Kung ang system ay nag-crash bago ang data ay naisulat sa disk, ito ay mawawala at mapupunta sa isang hindi pantay na estado. Sa kabutihang palad, ang 64-bit na MongoDB ay pinagana ang pag-log.
Ang MMAPv1 at WiredTiger storage engine ay gumagamit ng pag-log upang maiwasan ito, bagama't ang WiredTiger ay maaaring makabawi hanggang sa huling pare-pareho. , kung hindi pinagana ang pag-log.
Tinitiyak ng journaling na ang database ay nasa pare-parehong estado pagkatapos ng pagbawi at pinapanatili ang lahat ng data hanggang sa maisulat ito sa log. Ang dalas ng mga pag-record ay na-configure gamit ang parameter .
Para makasigurado sa mga entry, siguraduhing naka-enable ang pag-log sa configuration file ), at ang dalas ng mga pag-record ay tumutugma sa dami ng impormasyon na maaari mong mawala.
Pag-uuri nang walang index
Kapag naghahanap at nagsasama-sama, madalas na kailangang ayusin ang data. Umaasa tayo na ito ay gagawin sa isa sa mga huling yugto, pagkatapos i-filter ang resulta upang mabawasan ang dami ng data na pinagbubukod-bukod. At kahit na sa kasong ito, para sa pag-uuri kakailanganin mo . Maaari kang gumamit ng isang solong o tambalang index.
Kung walang angkop na index, gagawin ng MongoDB nang wala ito. Mayroong limitasyon sa memorya na 32 MB sa kabuuang sukat ng lahat ng mga dokumento , at kung maabot ng MongoDB ang limitasyong ito, ito ay maaaring magtapon ng error o babalik .
Maghanap nang walang suporta sa index
Ang mga query sa paghahanap ay gumaganap ng isang function na katulad ng JOIN operation sa SQL. Para gumana nang husto, kailangan nila ang index ng halaga ng key na ginamit bilang foreign key. Ito ay hindi halata dahil ang paggamit ay hindi makikita sa explain(). Ang mga naturang indeks ay karagdagan sa index na nakasulat sa explain(), na ginagamit naman ng mga operator ng pipeline $match ΠΈ $sort, kapag nagkita sila sa simula ng pipeline. Ang mga index ay maaari na ngayong sumaklaw sa anumang yugto .
Pag-opt out sa paggamit ng maraming update
pamamaraan ginagamit upang baguhin ang bahagi ng isang umiiral na dokumento o ang buong dokumento, hanggang sa kumpletong kapalit, depende sa parameter na iyong tinukoy . Ang hindi masyadong halata ay hindi nito ipoproseso ang lahat ng mga dokumento sa koleksyon maliban kung itatakda mo ang opsyon upang i-update ang lahat ng mga dokumentong nakakatugon sa pamantayan ng kahilingan.
Huwag kalimutan ang kahalagahan ng pagkakasunud-sunod ng mga susi sa isang hash table
Sa JSON, ang isang object ay binubuo ng isang hindi nakaayos na koleksyon ng laki na zero o higit pang mga pares ng pangalan/halaga, kung saan ang pangalan ay isang string at ang value ay isang string, numero, boolean, null, object, o array.
Sa kasamaang palad, binibigyang diin ng BSON ang order kapag naghahanap. Sa MongoDB, ang pagkakasunud-sunod ng mga susi sa loob ng mga built-in na bagay Ie { firstname: "Phil", surname: "factor" } - ito ay hindi katulad ng { { surname: "factor", firstname: "Phil" }. Ibig sabihin, dapat mong iimbak ang pagkakasunud-sunod ng mga pares ng pangalan/halaga sa iyong mga dokumento kung gusto mong makasigurado na mahahanap mo sila.
Huwag malito "Wala" ΠΈ "hindi natukoy"
Halaga "hindi natukoy" ay hindi kailanman wasto sa JSON, ayon sa JSON (ECMA-404 Section 5), kahit na ginagamit ito sa JavaScript. Bukod dito, para sa BSON ito ay hindi na ginagamit at na-convert sa $null, na hindi palaging isang magandang solusyon. .
Gamitin $limit() wala $sort()
Kadalasan kapag nagde-develop ka sa MongoDB, kapaki-pakinabang na makita lang ang isang sample ng resulta na ibabalik mula sa isang query o pagsasama-sama. Para sa gawaing ito kakailanganin mo $limit(), ngunit hindi ito dapat nasa huling code maliban kung ginamit mo ito dati $sort. Ang mekaniko na ito ay kinakailangan dahil kung hindi, hindi mo magagarantiya ang pagkakasunud-sunod ng resulta, at hindi mo mapagkakatiwalaang tingnan ang data. Sa tuktok ng resulta makakakuha ka ng iba't ibang mga entry depende sa pag-uuri. Upang gumana nang mapagkakatiwalaan, ang mga query at pagsasama-sama ay dapat na deterministiko, ibig sabihin, magdulot ng parehong mga resulta sa tuwing isasagawa ang mga ito. Code na naglalaman ng $limit(), pero hindi $sort, ay hindi magiging deterministiko at maaaring magdulot ng mga error na magiging mahirap subaybayan.
Konklusyon
Ang tanging paraan upang mabigo sa MongoDB ay direktang ihambing ito sa isa pang uri ng database, tulad ng isang DBMS, o gamitin ito batay sa ilang mga inaasahan. Ito ay tulad ng paghahambing ng isang orange sa isang tinidor. Ang mga sistema ng database ay nagsisilbi sa mga tiyak na layunin. Pinakamainam na maunawaan at pahalagahan ang mga pagkakaibang ito para sa iyong sarili. Ito ay isang kahihiyan na ipilit ang mga developer ng MongoDB sa isang landas na pinilit silang pababain ang landas ng DBMS. Gusto kong makakita ng mga bago at kawili-wiling paraan upang malutas ang mga lumang problema, tulad ng pagtiyak ng integridad ng data at paglikha ng mga data system na nababanat sa kabiguan at malisyosong pag-atake.
Ang pagpapakilala ng MongoDB ng ACID transactionality sa bersyon 4.0 ay isang magandang halimbawa ng pagpapakilala ng mahahalagang pagpapabuti sa isang makabagong paraan. Ang mga multi-document at multi-statement na transaksyon ay atomic na ngayon. Posible ring ayusin ang oras na kinakailangan upang makakuha ng mga kandado at wakasan ang mga natigil na transaksyon, pati na rin baguhin ang antas ng paghihiwalay.
Magbasa pa:
Pinagmulan: www.habr.com