Usimbaji fiche katika MySQL: Kutumia Ufunguo Mkuu

Kwa kutarajia kuanza kwa uandikishaji mpya kwa kozi hiyo "database" tunaendelea kuchapisha mfululizo wa makala kuhusu usimbaji fiche katika MySQL.

Katika makala iliyotangulia katika mfululizo huu (Usimbaji fiche katika MySQL: Keystore) tulizungumza juu ya vitufe. 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 uko kwenye duka la vitufe, na vitufe vya nafasi ya meza viko kwenye vichwa vya nafasi za meza zilizosimbwa (kwenye ukurasa wa 0 wa nafasi ya meza). 

Katika picha hapo juu:

• Jedwali A limesimbwa kwa njia fiche kwa ufunguo 1 (Ufunguo 1). Ufunguo wa 1 umesimbwa kwa njia fiche kwa kutumia kitufe kikuu na kuhifadhiwa kwa njia fiche kwenye kichwa cha jedwali A.

• Jedwali B limesimbwa kwa ufunguo 2 (Ufunguo 2). Ufunguo wa 2 umesimbwa kwa njia fiche kwa kutumia kitufe cha masker na kuhifadhiwa kwa njia fiche kwenye kichwa cha jedwali B.

• Na kadhalika.

Seva inapohitaji kusimbua jedwali A, hupata ufunguo mkuu kutoka kwa duka, husoma ufunguo uliosimbwa 1 kutoka kichwa cha jedwali A, na kusimbua ufunguo 1. Ufunguo uliosimbwa wa 1 umehifadhiwa kwenye kumbukumbu ya seva na hutumika kusimbua jedwali A. .

InnoDB

Katika InnoDB, usimbaji fiche na usimbuaji halisi unafanywa katika kiwango cha I/O. Hiyo ni, ukurasa umesimbwa kwa njia fiche kabla tu ya kusambazwa hadi kwenye diski na kusimbwa mara moja baada ya kusomwa kutoka kwenye diski.

Katika InnoDB, usimbaji fiche hufanya kazi tu katika kiwango cha nafasi ya meza. Na kwa chaguo-msingi meza zote huundwa katika nafasi tofauti za meza (nafasi ya meza ya faili kwa kila jedwali) Kwa maneno mengine, nafasi ya meza imeundwa ambayo inaweza kuwa na meza moja tu. Ingawa unaweza kuunda meza kwenye nafasi kuu ya meza pia (meza ya jumla) Lakini kwa hali yoyote, meza iko kila wakati kwenye nafasi ya meza. Na kwa kuwa usimbaji fiche unafanywa katika kiwango cha nafasi ya meza, labda umesimbwa kikamilifu au la. Hiyo ni, huwezi kusimba sehemu tu ya jedwali kwenye nafasi kuu ya jedwali. 

Ikiwa kwa sababu fulani umezimwa faili-per-meza, basi meza zote zinaundwa ndani ya nafasi ya meza ya mfumo. KATIKA Seva ya Percona ya MySQL 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 hii.

Kabla ya kuendelea, tunahitaji kuzingatia muundo wa kitambulisho kikuu cha ufunguo. Inajumuisha UUID, KEYKitambulisho na kiambishi awali "INNODBKey". Inaonekana kama hii: INNODBKey-UUID-KEYKitambulisho

UUID ni uuid ya seva iliyo na nafasi ya meza iliyosimbwa kwa njia fiche. ufunguoKitambulisho ni thamani inayoongezeka kila mara. Unapounda kwanza ufunguo mkuuKitambulisho ni 1. Wakati wa kuzungusha ufunguo, wakati ufunguo mkuu mpya unapoundwa, KEYID = 2 na kadhalika. Tutazungumza zaidi juu ya kuzunguka kwa ufunguo mkuu katika nakala za baadaye katika safu hii.

Sasa kwa kuwa tunajua jinsi kitambulisho kikuu cha ufunguo kinaonekana, hebu tuangalie kichwa cha nafasi ya meza iliyosimbwa kwa njia fiche. Wakati nafasi ya meza imesimbwa kwa njia fiche, habari ya usimbaji fiche huongezwa kwenye kichwa. Inaonekana kama hii:

KEYID ni KEYKitambulisho kutoka kwa ufunguo mkuu ambao tumejadili tayari. UUID ni uuid ya seva na inatumika pia katika kitambulisho kikuu cha ufunguo. TABLESPACE KEY - ufunguo wa nafasi ya meza, ambayo ina bits 256, iliyotolewa kwa nasibu na seva. Vekta ya uanzishaji (IV, vekta ya uanzishaji) pia ina biti 256 zinazozalishwa bila mpangilio (ingawa inapaswa kuwa biti 128). IV inatumika kuanzisha usimbaji fiche wa AES na usimbuaji (kati ya biti 256, 128 pekee ndizo zinazotumika). Mwishoni kuna cheki ya CRC32 ya TABLESPACE KEY na IV.

Wakati huu wote nimekuwa nimerahisisha kidogo kwa kusema kwamba kuna kitufe cha nafasi ya meza iliyosimbwa kwenye kichwa. Kwa kweli, ufunguo wa nafasi ya meza na vekta ya uanzishaji huhifadhiwa na kusimbwa kwa njia fiche pamoja kwa kutumia ufunguo mkuu. Kumbuka kwamba kabla ya ufunguo wa nafasi ya meza na vekta ya uanzishaji kusimbwa kwa njia fiche, CRC32 huhesabiwa kwa ajili yao.

Kwa nini CRC32 inahitajika?

Kwa kifupi, ili kuhakikisha ufunguo kuu ni halali. Baada ya kusimbua ufunguo wa nafasi ya meza na vekta ya kuanzisha, hundi hukokotolewa na kulinganishwa na CRC32 iliyohifadhiwa kwenye kichwa. Ikiwa cheki zinalingana, basi tunayo ufunguo sahihi mkuu na ufunguo wa nafasi ya meza. Vinginevyo, nafasi ya meza imetiwa alama kuwa haipo (bado hatuwezi kuichambua).

Unaweza kuuliza: ni wakati gani uthibitishaji wa funguo unafanywa? Jibu ni wakati seva inapoanza. Seva iliyo na jedwali / nafasi za meza zilizosimbwa kwa njia fiche husoma UUID, KEY wakati wa kuanzaKitambulisho kutoka kwa kichwa na hutoa kitambulisho kikuu cha ufunguo. Kisha hupata ufunguo mkuu unaohitajika kutoka kwa ufunguo, huondoa ufunguo wa nafasi ya meza, na kuthibitisha hesabu. Kwa mara nyingine tena, ikiwa cheki inalingana, basi kila kitu kiko sawa, hapana - nafasi ya meza imewekwa alama kuwa haipo.

Ukisoma nakala ya mwisho katika safu hii (Usimbaji fiche katika MySQL: Keystore), basi labda kumbuka kwamba unapotumia hifadhi ya ufunguo wa seva, seva hupokea tu orodha ya vitambulisho muhimu wakati wa kuanza, kwa usahihi zaidi, kitambulisho cha ufunguo na kitambulisho cha mtumiaji, kwa kuwa jozi hizi hutambulisha ufunguo kwa njia ya kipekee. Ninachosema sasa ni kwamba seva, inapoanzisha, inapata funguo zote zinazohitaji ili kuangalia kuwa funguo za nafasi ya meza zinaweza kusimbwa. Kwa hivyo kwa nini, wakati wa kuanzisha, katika kesi ya uhifadhi wa seva, ufunguo pekee hupakiwakitambulisho na mtumiajiid na si funguo zote? Kwa sababu huenda usihitaji funguo zote. Hii ni hasa kutokana na mzunguko wa ufunguo mkuu. Wakati ufunguo mkuu unapozungushwa kwenye vault, ufunguo mkuu mpya huundwa, lakini funguo za zamani hazijafutwa. Kwa hivyo, unaweza kuwa na funguo nyingi kwenye duka la vitufe za seva ambazo hazihitajiki na seva na kwa hivyo hazijarejeshwa wakati seva inapoanza.

Ni wakati wa kuzungumza kidogo juu ya faida na hasara za usimbuaji kwa kutumia ufunguo mkuu. Faida kubwa ni kwamba unahitaji ufunguo mmoja tu wa usimbaji fiche (ufunguo mkuu), ambao utawekwa tofauti na data yako iliyosimbwa. Hii hufanya uanzishaji wa seva haraka na uhifadhi kuwa mdogo, na kuifanya iwe rahisi kudhibiti. Na pia ufunguo pekee wa bwana ni rahisi kuzaliwa upya.

Walakini, usimbaji fiche wa ufunguo mkuu una shida moja kubwa: mara tu nafasi ya mezani imesimbwa kwa njia fiche kwa tablespace_key, daima inasalia imesimbwa kwa ufunguo sawa. Mzunguko mkuu wa ufunguo hausaidii hapa. Kwa nini hii ni hasara? Tunajua kwamba MySQL ina hitilafu ambazo zinaweza kusababisha kuanguka na kuunda faili ya msingi. Kwa kuwa faili ya msingi ina utupaji wa kumbukumbu ya seva, inaweza kutokea kwamba utupaji huo una kitufe cha nafasi ya meza iliyosimbwa. Mbaya zaidi, funguo za nafasi ya meza iliyosimbwa huhifadhiwa kwenye kumbukumbu, ambayo inaweza kubadilishwa kuwa diski. Unaweza kusema kuwa hii sio shida kwani unahitaji ruhusa za mizizi kufikia faili hizi na kizigeu cha kubadilishana. Ndiyo. Lakini mizizi inahitajika kwa muda tu. Mara tu mtu atakapopata ufunguo wa nafasi ya meza uliosimbwa, anaweza kuendelea kuutumia kusimbua data, hata bila ufikiaji wa mizizi. Kwa kuongeza, disk inaweza kuibiwa, na faili za kubadilishana / msingi zinaweza kusomwa kwa kutumia zana za tatu. Kusudi la TDE ni kuifanya isisomeke hata ikiwa diski imeibiwa. KATIKA Seva ya Percona ya MySQL inawezekana kusimba upya nafasi ya meza kwa kutumia vitufe vipya vilivyotengenezwa. Kipengele hiki kinaitwa nyuzi za usimbaji fiche na bado ni cha majaribio wakati wa uandishi huu.

Jifunze zaidi kuhusu kozi

Soma zaidi:

• Usimbaji fiche katika MySQL: Keystore

Chanzo: mapenzi.com