Tafsiri ya kifungu hicho ilitayarishwa usiku wa kuamkia kozi hiyo .
Mambo muhimu:
- Ni muhimu sana kuunda schema ingawa ni hiari katika MongoDB.
- Vivyo hivyo, faharisi lazima zilingane na mpangilio wako na mifumo ya ufikiaji.
- Epuka kutumia vitu vikubwa na safu kubwa.
- Kuwa mwangalifu na mipangilio ya MongoDB, haswa linapokuja suala la usalama na kuegemea.
- MongoDB haina kiboresha hoja, kwa hivyo ni lazima uwe mwangalifu unapotekeleza utendakazi wa hoja.
Nimekuwa nikifanya kazi na hifadhidata kwa muda mrefu sana, lakini hivi karibuni tu niligundua MongoDB. Kuna mambo machache ambayo natamani kujua kabla sijaanza kuyafanyia kazi. Wakati mtu tayari ana uzoefu katika uwanja fulani, wana mawazo ya awali kuhusu hifadhidata ni nini na wanafanya nini. Kwa matumaini ya kufanya iwe rahisi kwa wengine kuelewa, ninawasilisha orodha ya makosa ya kawaida.
Kuunda seva ya MongoDB bila uthibitishaji
Kwa bahati mbaya, MongoDB imewekwa bila uthibitishaji kwa chaguo-msingi. Kwa kituo cha kazi kinachopatikana ndani ya nchi, mazoezi haya ni ya kawaida. Lakini kwa kuwa MongoDB ni mfumo wa watumiaji wengi ambao unapenda kutumia kumbukumbu nyingi, itakuwa bora ikiwa utaiweka kwenye seva iliyo na RAM nyingi iwezekanavyo, hata ikiwa utaitumia tu kwa maendeleo. Kusakinisha kwenye seva kupitia bandari chaguo-msingi kunaweza kuwa tatizo, hasa ikiwa msimbo wowote wa javascript unaweza kutekelezwa katika ombi (kwa mfano, $where kama wazo kwa ).
Kuna njia kadhaa za uthibitishaji, lakini rahisi zaidi ni kuweka kitambulisho cha mtumiaji/nenosiri. Tumia wazo hili unapofikiria juu ya uthibitishaji dhahania kulingana na . Linapokuja suala la usalama, MongoDB inapaswa kusasishwa kila mara, na kumbukumbu zinapaswa kuangaliwa kila wakati kwa ufikiaji ambao haujaidhinishwa. Kwa mfano, napenda kuchagua bandari tofauti kama bandari chaguomsingi.
Usisahau kufunga eneo la shambulio kwa MongoDB
ina vidokezo vyema vya kupunguza hatari ya kuingilia mtandao na kuvuja kwa data. Ni rahisi kuiondoa na kusema kwamba seva ya ukuzaji haihitaji kiwango cha juu cha usalama. Walakini, sio rahisi na hii inatumika kwa seva zote za MongoDB. Hasa, ikiwa hakuna sababu ya kulazimisha ya kutumia , au , unahitaji kulemaza utumiaji wa nambari ya kiholela katika JavaScript kwa kuandika kwenye faili ya usanidi. . Kwa kuwa faili za data hazijasimbwa kwa njia fiche katika MongoDB ya kawaida, inaeleweka kuendesha MongoDB nayo , ambayo ina ufikiaji kamili wa faili, na ufikiaji mdogo kwake tu na uwezo wa kutumia vidhibiti vya ufikiaji wa faili vya mfumo wa uendeshaji.
Hitilafu wakati wa kuendeleza mzunguko
MongoDB haitumii schema. Lakini hii haina maana kwamba mpango hauhitajiki. Ikiwa unataka tu kuhifadhi hati bila muundo wowote thabiti, kuzihifadhi kunaweza kuwa haraka na rahisi, lakini kuzirejesha baadaye kunaweza kuwa vigumu. .
Nakala ya zamani " Inafaa kusoma, na vipengele kama katika chombo cha tatu cha Studio 3T, inafaa kutumia kwa ukaguzi wa mara kwa mara wa mizunguko.
Usisahau mpangilio wa kupanga
Kusahau mpangilio wa kupanga kunaweza kusababisha kufadhaika zaidi na kupoteza muda zaidi kuliko usanidi mwingine wowote usio sahihi. Kwa chaguo-msingi MongoBD hutumia . Lakini hakuna uwezekano wa kuwa na manufaa kwa mtu yeyote. Aina ambazo hazijali kadhia, nyeti kwa lafudhi, na aina za binary zilizingatiwa kuwa anachronism za kudadisi pamoja na shanga, kafti na masharubu yaliyopinda katika miaka ya 80 ya karne iliyopita. Sasa matumizi yao hayawezi kusamehewa. Katika maisha halisi, "pikipiki" ni sawa na "Pikipiki". Na "Uingereza" na "Uingereza" ni sehemu moja. Herufi ndogo ni herufi kubwa tu inayolingana na herufi kubwa. Na usinifanye nianze kupanga vipaza sauti. Unapounda hifadhidata katika MongoDB, tumia mgongano usiojali lafudhi na , ambazo zinalingana na lugha na . Hii itafanya kutafuta kupitia data ya kamba rahisi zaidi.
Unda makusanyo na hati kubwa
MongoDB ina furaha kupangisha hati kubwa hadi 16MB katika makusanyo, na Imeundwa kwa hati kubwa zaidi ya 16 MB. Lakini kwa sababu hati kubwa zinaweza kuwekwa hapo, kuzihifadhi sio wazo nzuri. MongoDB itafanya kazi vyema zaidi ikiwa utahifadhi hati mahususi zenye ukubwa wa kilobaiti chache, ukizichukulia kama safu mlalo kwenye jedwali pana la SQL. Nyaraka kubwa zitakuwa chanzo cha matatizo na .
Kuunda hati na safu kubwa
Nyaraka zinaweza kuwa na safu. Ni bora ikiwa idadi ya vipengele katika safu ni mbali na nambari ya tarakimu nne. Ikiwa vipengele vitaongezwa kwenye safu mara kwa mara, itazidi hati iliyo nayo na itahitaji kuwa , ambayo ina maana itakuwa muhimu . Wakati wa kuorodhesha hati tena na safu kubwa, faharisi mara nyingi zitaandikwa tena, kwani kuna , ambayo huhifadhi index yake. Kuorodhesha upya huku pia hutokea wakati hati inapoingizwa au kufutwa.
MongoDB ina kitu kinachoitwa , ambayo inatoa nafasi kwa hati kukua ili kupunguza tatizo hili.
Unaweza kufikiria kuwa unaweza kufanya bila kuorodhesha safu. Kwa bahati mbaya, ukosefu wa faharisi unaweza kukusababishia matatizo mengine. Kwa kuwa hati huchanganuliwa kutoka mwanzo hadi mwisho, kutafuta vipengee mwishoni mwa safu kutachukua muda mrefu, na shughuli nyingi zinazohusiana na hati kama hiyo zitakuwa. .
Usisahau kwamba mpangilio wa hatua katika mkusanyiko ni muhimu
Katika mfumo wa hifadhidata ulio na kiboreshaji cha hoja, maswali unayoandika ni maelezo ya kile unachotaka kupata, sio jinsi ya kukipata. Utaratibu huu unafanya kazi kwa mlinganisho na kuagiza katika mgahawa: kwa kawaida unaagiza sahani tu, na usipe maagizo ya kina kwa mpishi.
Katika MongoDB, unaelekeza mpishi. Kwa mfano, unahitaji kuhakikisha kuwa data inapita reduce mapema iwezekanavyo katika bomba kwa kutumia $match ΠΈ $project, na kupanga hutokea baada tu reduce, na kwamba utafutaji unafanyika kwa mpangilio unaotaka. Kuwa na kiboreshaji hoja ambacho huondoa kazi isiyo ya lazima, kupanga hatua kikamilifu, na kuchagua aina za kujiunga kunaweza kukuharibia. Ukiwa na MongoDB, una udhibiti zaidi kwa gharama ya urahisi.
Zana kama itarahisisha ujenzi wa hoja za kujumlisha . Kipengele cha Kihariri cha Kujumlisha hukuruhusu kutumia taarifa za bomba hatua moja baada ya nyingine, na kukagua data ya ingizo na matokeo katika kila hatua kwa utatuzi rahisi.
Kutumia Kurekodi Haraka
Kamwe usiweke chaguo za uandishi wa MongoDB kuwa na kasi ya juu lakini kuegemea kidogo. Hali hii "faili-na-kusahau" inaonekana haraka kwa sababu amri inarudishwa kabla ya uandishi kutokea. Ikiwa mfumo utaacha kufanya kazi kabla ya data kuandikwa kwa diski, itapotea na kuishia katika hali isiyolingana. Kwa bahati nzuri, 64-bit MongoDB imewezesha kuingia.
Injini za uhifadhi za MMAPv1 na WiredTiger hutumia ukataji miti ili kuzuia hili, ingawa WiredTiger inaweza kupona hadi uthabiti wa mwisho. , ikiwa ukataji miti umezimwa.
Uandishi wa habari huhakikisha kuwa hifadhidata iko katika hali thabiti baada ya kurejesha na kuhifadhi data zote hadi imeandikwa kwenye kumbukumbu. Mzunguko wa rekodi husanidiwa kwa kutumia parameta .
Ili kuwa na uhakika wa maingizo, hakikisha kuingia kumewashwa kwenye faili ya usanidi ), na mzunguko wa rekodi unalingana na kiasi cha habari ambacho unaweza kumudu kupoteza.
Kupanga bila index
Wakati wa kutafuta na kujumlisha, mara nyingi kuna haja ya kupanga data. Hebu tumaini kwamba hii inafanywa katika moja ya hatua za mwisho, baada ya kuchuja matokeo ili kupunguza kiasi cha data iliyopangwa. Na hata katika kesi hii, kwa kuchagua utahitaji . Unaweza kutumia index moja au kiwanja.
Ikiwa hakuna faharisi inayofaa, MongoDB itafanya bila hiyo. Kuna kikomo cha kumbukumbu cha 32 MB kwa saizi ya jumla ya hati zote ndani , na ikiwa MongoDB itafikia kikomo hiki, basi itatupa makosa au itarudisha .
Tafuta bila usaidizi wa index
Hoja za utafutaji hufanya kazi sawa na operesheni ya JOIN katika SQL. Ili kufanya kazi vyema zaidi, wanahitaji faharasa ya thamani ya ufunguo unaotumika kama ufunguo wa kigeni. Hii sio dhahiri kwa sababu matumizi hayajaonyeshwa ndani explain(). Fahirisi kama hizo ni pamoja na faharasa iliyoandikwa explain(), ambayo kwa upande wake hutumiwa na waendeshaji wa bomba $match ΠΈ $sort, wanapokutana mwanzoni mwa bomba. Fahirisi sasa zinaweza kufunika hatua yoyote .
Kujiondoa kutumia masasisho mengi
Mbinu kutumika kubadilisha sehemu ya hati iliyopo au hati nzima, hadi uingizwaji kamili, kulingana na parameter unayotaja . Kile ambacho sio dhahiri sana ni kwamba haitashughulikia hati zote kwenye mkusanyiko isipokuwa utaweka chaguo kusasisha hati zote zinazokidhi vigezo vya ombi.
Usisahau umuhimu wa mpangilio wa funguo kwenye jedwali la hashi
Katika JSON, kitu kina mkusanyiko usiopangwa wa saizi ya sifuri au jozi zaidi za jina/thamani, ambapo jina ni mfuatano na thamani ni mfuatano, nambari, boolean, null, kitu, au mkusanyiko.
Kwa bahati mbaya, BSON huweka msisitizo mkubwa juu ya utaratibu wakati wa kutafuta. Katika MongoDB, mpangilio wa funguo ndani ya vitu vilivyojengwa , i.e. { firstname: "Phil", surname: "factor" } - hii sio sawa na { { surname: "factor", firstname: "Phil" }. Hiyo ni, lazima uhifadhi mpangilio wa jozi za majina/thamani katika hati zako ikiwa unataka kuwa na uhakika wa kuzipata.
Usichanganyikiwe "Null" ΠΈ "isiyoelezewa"
Thamani "isiyoelezewa" haikuwahi kutumika katika JSON, kulingana na JSON (ECMA-404 Sehemu ya 5), ββingawa inatumika katika JavaScript. Zaidi ya hayo, kwa BSON ni ya kizamani na inabadilishwa kuwa $null, ambayo sio suluhisho nzuri kila wakati. .
Matumizi ya $limit() bila $sort()
Mara nyingi unapokua katika MongoDB, ni muhimu kuona tu sampuli ya matokeo ambayo yatarejeshwa kutoka kwa hoja au mkusanyiko. Kwa kazi hii utahitaji $limit(), lakini haipaswi kamwe kuwa katika nambari ya mwisho isipokuwa uitumie hapo awali $sort. Mitambo hii ni muhimu kwa sababu vinginevyo huwezi kuthibitisha mpangilio wa matokeo, na hutaweza kutazama data kwa uaminifu. Juu ya matokeo utapata maingizo tofauti kulingana na upangaji. Ili kufanya kazi kwa uhakika, hoja na mijumuisho lazima iwe ya kuamua, yaani, kutoa matokeo sawa kila wakati inapotekelezwa. Kanuni ambayo ina $limit(), lakini hapana $sort, haitakuwa ya kuamua na inaweza kusababisha makosa ambayo itakuwa vigumu kufuatilia.
Hitimisho
Njia pekee ya kukatishwa tamaa na MongoDB ni kulinganisha moja kwa moja na aina nyingine ya hifadhidata, kama vile DBMS, au kuja kuitumia kulingana na matarajio fulani. Ni kama kulinganisha chungwa na uma. Mifumo ya hifadhidata hutumikia madhumuni maalum. Ni bora kuelewa na kuthamini tofauti hizi kwako mwenyewe. Itakuwa aibu kushinikiza watengenezaji wa MongoDB juu ya njia ambayo iliwalazimisha chini ya njia ya DBMS. Ninataka kuona njia mpya na za kuvutia za kutatua matatizo ya zamani, kama vile kuhakikisha uadilifu wa data na kuunda mifumo ya data ambayo inaweza kuhimili kushindwa na mashambulizi mabaya.
Utangulizi wa MongoDB wa shughuli za ACID katika toleo la 4.0 ni mfano mzuri wa kuleta maboresho muhimu kwa njia ya ubunifu. Shughuli za hati nyingi na taarifa nyingi sasa ni za atomiki. Pia inawezekana kurekebisha muda unaohitajika kupata kufuli na kukomesha shughuli zilizokwama, na pia kubadilisha kiwango cha kutengwa.
Soma zaidi:
Chanzo: mapenzi.com