Kwa kutarajia kuanza kwa uandikishaji mpya kwa kozi hiyo tunaendelea kuchapisha mfululizo wa makala kuhusu usimbaji fiche katika MySQL.
Katika makala iliyotangulia katika mfululizo huu () Tulizungumza kuhusu maduka muhimu. Katika makala hii, tutaangalia jinsi ufunguo mkuu unavyotumiwa na kujadili faida na hasara za usimbaji wa bahasha.
Wazo la usimbaji fiche wa bahasha ni kwamba funguo zinazotumiwa kwa usimbaji fiche (funguo za nafasi ya meza) zimesimbwa kwa ufunguo mwingine (ufunguo mkuu). Vifunguo vya nafasi ya meza hutumika kusimba data kwa njia fiche. Kielelezo, hii inaweza kuwakilishwa kama ifuatavyo:
Ufunguo mkuu upo kwenye ufunguo, na funguo za nafasi ya meza ziko kwenye vichwa vya meza vilivyosimbwa (kwenye ukurasa wa 0 wa nafasi ya meza).
Katika picha hapo juu:
Jedwali A limesimbwa kwa njia fiche kwa Ufunguo 1. Ufunguo wa 1 umesimbwa kwa njia fiche kwa ufunguo mkuu na kuhifadhiwa kwa njia iliyosimbwa katika kichwa cha jedwali A.
Jedwali B limesimbwa kwa njia fiche kwa Ufunguo wa 2. Ufunguo wa 2 umesimbwa kwa njia fiche kwa ufunguo mkuu (ufunguo wa masker) na kuhifadhiwa kwa njia iliyosimbwa katika kichwa cha jedwali B.
Na kadhalika.
Seva inapohitaji kusimbua jedwali A, hurejesha ufunguo mkuu kutoka kwenye hifadhi, husoma kitufe cha 1 kilichosimbwa kwa njia fiche kutoka kwenye kichwa cha jedwali A, na kusimbua kitufe cha 1. Kitufe cha 1 kilichosimbwa huwekwa kwenye kumbukumbu ya seva na hutumika kusimbua jedwali A.
InnoDB
Katika InnoDB, usimbaji fiche halisi na usimbuaji hufanywa katika kiwango cha I/O. Hii ina maana kwamba ukurasa umesimbwa kwa njia fiche mara moja kabla haujatolewa hadi kwenye diski na kusimbwa mara tu baada ya kusomwa kutoka kwenye diski.
Katika InnoDB, usimbaji fiche hufanya kazi tu katika kiwango cha nafasi ya meza. Na kwa msingi, meza zote huundwa katika nafasi tofauti za meza () Kwa maneno mengine, nafasi ya meza imeundwa ambayo inaweza kuwa na meza moja tu. Ingawa unaweza pia kuunda meza kwenye nafasi ya msingi ya meza () Lakini kwa hali yoyote, meza iko kila wakati kwenye nafasi fulani ya meza. Na kwa kuwa usimbaji fiche hutokea katika kiwango cha nafasi ya meza, huenda umesimbwa kikamilifu au la. Hii inamaanisha kuwa haiwezekani kusimba sehemu tu ya jedwali kwenye nafasi kuu ya meza.
Ikiwa kwa sababu fulani umezimwa faili-per-meza, basi meza zote zinaundwa ndani ya nafasi ya meza ya mfumo. Unaweza kusimba kwa njia fiche nafasi ya meza ya mfumo kwa kutumia utofauti wa innodbsysnafasi ya mezakusimba kwa njia fiche au kutumia nyuzi za usimbaji, lakini hii bado ni kipengele cha majaribio. MySQL haina.
Kabla ya kuendelea, tunahitaji kuangalia muundo wa kitambulisho kikuu cha ufunguo (MKID). Inajumuisha UUID, KEYKitambulisho na kiambishi awali cha "INNODBKey". Inaonekana kama hii: INNODBKey-UUID-KEYKitambulisho
UUID ni uuid ya seva iliyo na KEY ya nafasi ya meza iliyosimbwaKitambulisho ni thamani inayoongezeka kila mara. Wakati ufunguo mkuu umeundwa hapo awali, KEYKitambulisho ni 1. Wakati wa kuzungusha ufunguo, wakati ufunguo mkuu mpya unapoundwa, KEYID = 2, na kadhalika. Tutajadili mzunguko mkuu wa ufunguo kwa undani zaidi katika makala zijazo katika mfululizo huu.
Sasa kwa kuwa tunajua jinsi kitambulishi kikuu cha ufunguo kinaonekana, hebu tuangalie kichwa cha nafasi ya meza iliyosimbwa kwa njia fiche. Wakati nafasi ya meza imesimbwa kwa njia fiche, maelezo ya usimbaji fiche huongezwa kwenye kichwa. Inaonekana kama hii:
KITAMBULISHO CHA UFUNGUO ni UFUNGUOKitambulisho kinatoka kwa kitambulishi kikuu cha ufunguo, ambacho tayari tumekijadili. UUID ni UUID ya seva, ambayo inatumika pia katika kitambulisho kikuu cha ufunguo. TABLESPACE KEY ni kitufe cha nafasi ya meza, ambacho kina biti 256 zinazozalishwa bila mpangilio na seva. Vekta ya uanzishaji (IV) pia ina biti 256 zinazozalishwa bila mpangilio (ingawa inapaswa kuwa biti 128). IV inatumika kuanzisha usimbaji fiche na usimbuaji wa AES (biti 128 pekee kati ya 256 ndizo zinazotumika). Mwishoni, kuna cheki ya CRC32 ya TABLESPACE KEY na IV.
Nimekuwa nimerahisisha mambo kupita kiasi wakati huu, nikisema kwamba kichwa kina kitufe cha nafasi ya meza iliyosimbwa kwa njia fiche. Kwa kweli, ufunguo wa nafasi ya meza na IV huhifadhiwa na kusimbwa kwa njia fiche kwa kutumia ufunguo mkuu. Kumbuka kwamba kabla ya kusimba ufunguo wa nafasi ya meza na IV, CRC32 huhesabiwa kwao.
Kwa nini tunahitaji CRC32?
Kwa kifupi, ni kuhakikisha uhalali wa ufunguo mkuu. Baada ya kusimbua ufunguo wa nafasi ya meza na vekta ya kuanzisha, hundi hukokotolewa na kulinganishwa na CRC32 iliyohifadhiwa kwenye kichwa. Ikiwa cheki zinalingana, tuna ufunguo mkuu halali na ufunguo wa nafasi ya meza. Vinginevyo, nafasi ya meza imetiwa alama kuwa haipo (hatutaweza kuisimbua hata hivyo).
Unaweza kuuliza: ni wakati gani funguo zinathibitishwa? Jibu liko kwenye uanzishaji wa seva. Seva iliyo na jedwali/nafasi za meza zilizosimbwa kwa njia fiche husoma UUID na KEY inapoanzisha.Kitambulisho kutoka kwa kichwa hutoa kitambulisho kikuu cha ufunguo. Kisha hurejesha ufunguo mkuu unaohitajika kutoka kwa ufunguo, huondoa ufunguo wa nafasi ya meza, na kuthibitisha hesabu. Kwa mara nyingine tena, ikiwa checksum inalingana, kila kitu ni sawa; ikiwa sivyo, nafasi ya meza imewekwa alama kama haipo.
Ikiwa ulisoma nakala iliyotangulia katika safu hii (), unaweza kukumbuka kuwa unapotumia duka la vitufe la msingi wa seva, seva hupokea tu orodha ya vitambulishi muhimu wakati wa kuanza, au kwa usahihi zaidi, kitambulisho cha ufunguo na kitambulisho cha mtumiaji, kwa kuwa jozi hii hutambulisha ufunguo kwa njia ya kipekee. Sasa ninasema kwamba seva inapokea funguo zote zinazohitaji ili kuthibitisha uwezo wa kusimbua vitufe vya nafasi ya meza wakati wa kuanza. Kwa hivyo kwa nini funguo pekee hupakiwa wakati wa uanzishaji katika kesi ya ufunguo wa msingi wa seva?kitambulisho na mtumiajiid, na sio funguo zote? Kwa sababu huenda usihitaji funguo zote. Hii ni kwa sababu ya mzunguko mkuu wa ufunguo. Wakati ufunguo mkuu unapozungushwa, ufunguo mkuu mpya huundwa kwenye duka la vitufe, lakini funguo za zamani hazijafutwa. Kwa hivyo, unaweza kuwa na funguo nyingi kwenye duka la vitufe vya seva yako ambazo hazihitajiki na seva na kwa hivyo hazijarejeshwa wakati wa kuanzisha seva.
Ni wakati wa kujadili kwa ufupi faida na hasara za usimbaji wa ufunguo mkuu. Faida kubwa ni kwamba unahitaji ufunguo mmoja tu wa usimbaji fiche (ufunguo mkuu), ambao umehifadhiwa kando na data yako iliyosimbwa. Hii hufanya seva kuwasha haraka na nafasi ya kuhifadhi kuwa ndogo, na kuifanya iwe rahisi kudhibiti. Ufunguo wa bwana mmoja pia ni rahisi kutengeneza upya.
Hata hivyo, usimbaji fiche wa ufunguo mkuu una tatizo moja kuu: mara tu nafasi ya mezani imesimbwa kwa njia fiche kwa tablespace_key, daima inasalia imesimbwa kwa ufunguo sawa. Kuzungusha funguo kuu haisaidii hapa. Kwa nini hii ni drawback? Tunajua kwamba MySQL ina hitilafu ambazo zinaweza kusababisha ajali ya ghafla na kuunda faili ya msingi. Kwa kuwa faili ya msingi ina utupaji wa kumbukumbu ya seva, kuna uwezekano kwamba utupaji huo utakuwa na kitufe cha nafasi ya meza iliyosimbwa. Mbaya zaidi, funguo za nafasi ya meza zilizosimbwa huhifadhiwa kwenye kumbukumbu, ambayo inaweza kubadilishwa kuwa diski. Unaweza kusema hii sio shida kwa sababu unahitaji haki za mizizi kufikia faili hizi na kizigeu cha kubadilishana. Ndiyo. Lakini mizizi inahitajika kwa muda tu. Mara mtu anapopata ufikiaji wa ufunguo wa nafasi ya meza uliosimbwa, anaweza kuendelea kuutumia kusimbua data, hata bila upendeleo wa mizizi. Zaidi ya hayo, diski inaweza kuibiwa, na kizigeu/faili za msingi za kubadilishana zinaweza kusomwa kwa kutumia zana za wahusika wengine. Madhumuni ya TDE ni kuifanya isisomeke hata ikiwa diski imeibiwa. Inawezekana kusimba tena nafasi ya meza kwa njia fiche kwa kutumia vitufe vipya. Kipengele hiki kinaitwa nyuzi za usimbaji fiche na bado ni cha majaribio wakati wa kuandika.
Soma zaidi:
Chanzo: mapenzi.com
