Kumbuka. tafsiri.: Jaana Dogan ni mhandisi mwenye uzoefu katika Google ambaye kwa sasa anashughulikia uangalizi wa huduma za uzalishaji za kampuni zilizoandikwa katika Go. Katika makala hii, ambayo ilipata umaarufu mkubwa kati ya watazamaji wanaozungumza Kiingereza, alikusanya katika pointi 17 maelezo muhimu ya kiufundi kuhusu DBMSs (na wakati mwingine mifumo iliyosambazwa kwa ujumla) ambayo ni muhimu kuzingatia kwa watengenezaji wa maombi makubwa / yanayohitaji.
Idadi kubwa ya mifumo ya kompyuta hufuatilia hali yao na, ipasavyo, inahitaji aina fulani ya mfumo wa kuhifadhi data. Nilikusanya maarifa kuhusu hifadhidata kwa muda mrefu, nikifanya makosa ya muundo ambayo yalisababisha upotezaji wa data na kukatika. Katika mifumo inayochakata idadi kubwa ya habari, hifadhidata ziko kwenye moyo wa usanifu wa mfumo na hufanya kama kipengele muhimu katika kuchagua suluhisho mojawapo. Licha ya ukweli kwamba umakini wa karibu hulipwa kwa kazi ya hifadhidata, shida ambazo watengenezaji wa programu hujaribu kutarajia mara nyingi ni ncha ya barafu. Katika safu hii ya vifungu, ninashiriki maoni kadhaa ambayo yatakuwa muhimu kwa watengenezaji ambao sio maalum katika uwanja huu.
- Una bahati ikiwa 99,999% ya wakati mtandao hausababishi shida.
- ACID inamaanisha vitu vingi tofauti.
- Kila hifadhidata ina njia zake za kuhakikisha uthabiti na kutengwa.
- Kuzuia matumaini huja kuwaokoa wakati ni vigumu kudumisha kawaida.
- Kuna hitilafu zingine kando na usomaji chafu na upotezaji wa data.
- Hifadhidata na mtumiaji huwa hawakubaliani kila wakati juu ya hatua.
- Ugawaji wa kiwango cha programu unaweza kuhamishwa nje ya programu.
- Autoincrementing inaweza kuwa hatari.
- Data ya zamani inaweza kuwa muhimu na si haja ya kufungwa.
- Upotoshaji ni wa kawaida kwa vyanzo vya wakati wowote.
- Kuchelewa kuna maana nyingi.
- Mahitaji ya utendaji yanapaswa kutathminiwa kwa shughuli mahususi.
- Shughuli zilizowekwa zinaweza kuwa hatari.
- Shughuli hazipaswi kuunganishwa na hali ya maombi.
- Wapangaji hoja wanaweza kukuambia mengi kuhusu hifadhidata.
- Uhamiaji mkondoni ni ngumu, lakini inawezekana.
- Ongezeko kubwa la hifadhidata linajumuisha ongezeko la kutotabirika.
Ningependa kumshukuru Emmanuel Odeke, Rein Henrichs na wengine kwa maoni yao kuhusu toleo la awali la makala hii.
Una bahati ikiwa 99,999% ya wakati mtandao hausababishi shida.
Swali linabaki juu ya jinsi teknolojia za kisasa za mtandao zinavyoaminika na mara ngapi mifumo iko chini kwa sababu ya kushindwa kwa mtandao. Taarifa kuhusu suala hili ni chache na utafiti mara nyingi hutawaliwa na mashirika makubwa yenye mitandao maalumu, vifaa na wafanyakazi.
Kwa kiwango cha upatikanaji cha 99,999% kwa Spanner (database ya Google inayosambazwa duniani kote), Google inadai kuwa pekee matatizo yanahusiana na mtandao. Wakati huo huo, kampuni inaita mtandao wake maalumu "nguzo kuu" ya upatikanaji wa juu. Jifunze , iliyofanyika mwaka 2014, changamoto mojawapo ya “", ambayo Peter Deutsch aliiunda mnamo 1994. Je, mtandao unaaminika kweli?
Utafiti wa kina nje ya makampuni makubwa, uliofanywa kwa mtandao mpana, haupo. Pia hakuna data ya kutosha kutoka kwa wahusika wakuu kuhusu asilimia ngapi ya matatizo ya wateja wao yanahusiana na mtandao. Tunafahamu vyema kukatika kwa rundo la mtandao wa watoa huduma wakubwa wa wingu ambao wanaweza kupunguza sehemu nzima ya Mtandao kwa saa kadhaa kwa sababu tu ni matukio ya hali ya juu ambayo huathiri idadi kubwa ya watu na makampuni. Kukatika kwa mtandao kunaweza kusababisha matatizo katika matukio mengi zaidi, hata kama si matukio hayo yote ambayo yanaangaziwa. Wateja wa huduma za wingu pia hawajui chochote kuhusu sababu za matatizo. Ikiwa kuna kutofaulu, karibu haiwezekani kuihusisha na hitilafu ya mtandao kwa upande wa mtoa huduma. Kwao, huduma za mtu wa tatu ni masanduku nyeusi. Haiwezekani kutathmini athari bila kuwa mtoa huduma mkubwa.
Kwa kuzingatia kile ambacho wachezaji wakubwa wanaripoti kuhusu mifumo yao, ni salama kusema uko katika bahati ikiwa matatizo ya mtandao yanachangia asilimia ndogo tu ya matatizo yanayoweza kutokea wakati wa kukatika. Mawasiliano ya mtandao bado yanakabiliwa na mambo ya kawaida kama vile hitilafu za maunzi, mabadiliko ya topolojia, mabadiliko ya usanidi wa usimamizi na kukatika kwa umeme. Hivi karibuni, nilishangaa kujua kwamba orodha ya matatizo iwezekanavyo iliongezwa (ndio, umesikia sawa).
ACID inamaanisha vitu vingi tofauti
ACID inawakilisha Atomicity, Consistency, Isolation, Reliability. Tabia hizi za shughuli zinalenga kuhakikisha uhalali wao katika tukio la kushindwa, makosa, kushindwa kwa vifaa, nk. Bila ACID au mipango sawa, itakuwa vigumu kwa wasanidi programu kutofautisha kile wanachowajibikia na kile hifadhidata inawajibikia. Hifadhidata nyingi za shughuli za uhusiano hujaribu kufuata ACID, lakini mbinu mpya kama NoSQL zimetoa hifadhidata nyingi bila shughuli za ACID kwa sababu ni ghali kutekeleza.
Nilipoingia kwenye tasnia kwa mara ya kwanza, uongozi wetu wa kiufundi ulizungumza kuhusu jinsi dhana ya ACID ilivyofaa. Ili kuwa sawa, ACID inachukuliwa kuwa maelezo mafupi badala ya kiwango madhubuti cha utekelezaji. Leo naona ni muhimu sana kwa sababu inaibua aina fulani ya maswala (na kupendekeza anuwai ya suluhisho zinazowezekana).
Si kila DBMS inayotii ACID; Wakati huo huo, utekelezaji wa hifadhidata unaounga mkono ACID huelewa seti ya mahitaji kwa njia tofauti. Mojawapo ya sababu kwa nini utekelezwaji wa ACID ni dhaifu ni kutokana na mabadilishano mengi ambayo yanapaswa kufanywa ili kutekeleza mahitaji ya ACID. Watayarishi wanaweza kuwasilisha hifadhidata zao kama zinazotii ACID, lakini tafsiri ya matukio makali inaweza kutofautiana kwa kiasi kikubwa, kama vile utaratibu wa kushughulikia matukio "yasiyowezekana". Angalau, wasanidi programu wanaweza kupata uelewa wa hali ya juu wa ugumu wa utekelezaji wa msingi ili kupata uelewa sahihi wa tabia zao maalum na kubuni mabadilishano ya kibiashara.
Mjadala kuhusu iwapo MongoDB inatii mahitaji ya ACID unaendelea hata baada ya toleo la 4 kutolewa. MongoDB haijaauniwa kwa muda mrefu , ingawa kwa chaguo-msingi data iliwekwa kwenye diski si zaidi ya mara moja kila sekunde 60. Hebu fikiria hali ifuatayo: machapisho ya maombi mawili yanaandika (w1 na w2). MongoDB imefaulu kuhifadhi w1, lakini w2 inapotea kwa sababu ya hitilafu ya maunzi.
Mchoro unaoonyesha hali hiyo. MongoDB huacha kufanya kazi kabla ya kuandika data kwenye diski
Kujitolea kwa diski ni mchakato wa gharama kubwa. Kwa kuzuia ahadi za mara kwa mara, watengenezaji huboresha utendakazi wa kurekodi kwa gharama ya kutegemewa. MongoDB kwa sasa inasaidia ukataji miti, lakini maandishi machafu bado yanaweza kuathiri uadilifu wa data kwani kumbukumbu hunaswa kila milisekunde 100 kwa chaguo-msingi. Hiyo ni, hali kama hiyo bado inawezekana kwa kumbukumbu na mabadiliko yaliyowasilishwa ndani yao, ingawa hatari ni ndogo sana.
Kila hifadhidata ina uthabiti wake na mifumo ya kujitenga
Kati ya mahitaji ya ACID, uthabiti na kutengwa kunajivunia idadi kubwa zaidi ya utekelezwaji tofauti kwa sababu anuwai ya biashara ni pana. Ni lazima kusema kuwa uthabiti na kutengwa ni kazi ghali kabisa. Zinahitaji uratibu na kuongeza ushindani kwa uthabiti wa data. Utata wa tatizo huongezeka sana inapohitajika kuongeza hifadhidata kwa usawa katika vituo vingi vya data (hasa ikiwa ziko katika maeneo tofauti ya kijiografia). Kufikia kiwango cha juu cha uthabiti ni ngumu sana, kwani pia hupunguza upatikanaji na huongeza mgawanyiko wa mtandao. Kwa maelezo ya jumla zaidi ya jambo hili, nakushauri urejelee . Inafaa pia kuzingatia kuwa programu zinaweza kushughulikia viwango vidogo vya kutofautiana, na watayarishaji programu wanaweza kuelewa nuances ya tatizo vizuri vya kutosha kutekeleza mantiki ya ziada katika programu kushughulikia kutokwenda bila kutegemea sana hifadhidata kulishughulikia.
DBMS mara nyingi hutoa viwango tofauti vya kutengwa. Wasanidi programu wanaweza kuchagua moja yenye ufanisi zaidi kulingana na mapendekezo yao. Kutengwa kwa chini kunaruhusu kuongezeka kwa kasi, lakini pia huongeza hatari ya mbio za data. Insulation ya juu inapunguza uwezekano huu, lakini inapunguza kasi ya kazi na inaweza kusababisha ushindani, ambayo itasababisha breki vile katika msingi kwamba kushindwa kuanza.
Mapitio ya mifano iliyopo ya sarafu na mahusiano kati yao
Kiwango cha SQL kinafafanua viwango vinne tu vya kutengwa, ingawa katika nadharia na mazoezi kuna mengi zaidi. inatoa muhtasari bora wa mifano iliyopo ya sarafu. Kwa mfano, Google Spanner huhakikisha usakinishaji wa nje kwa ulandanishi wa saa, na ingawa hii ni safu kali zaidi ya kutengwa, haijafafanuliwa katika tabaka za kawaida za kutengwa.
Kiwango cha SQL kinataja viwango vifuatavyo vya kutengwa:
- Inaweza kuzidi (madhubuti zaidi na ghali): Utekelezaji unaoweza kutekelezwa una athari sawa na utekelezaji wa shughuli fulani mfuatano. Utekelezaji wa mfuatano unamaanisha kwamba kila shughuli inayofuata huanza tu baada ya ule uliopita kukamilika. Ikumbukwe kwamba ngazi Inaweza kuzidi mara nyingi hutekelezwa kama kinachojulikana kutengwa kwa snapshot (kwa mfano, katika Oracle) kwa sababu ya tofauti za tafsiri, ingawa utengaji wa picha yenyewe haujawakilishwa katika kiwango cha SQL.
- Usomaji unaorudiwa: Rekodi ambazo hazijawekwa katika muamala wa sasa zinapatikana kwa shughuli ya sasa, lakini mabadiliko yaliyofanywa na miamala mingine (kama vile safu mlalo mpya) .
- Kusoma kujitolea: Data ambayo haijatumwa haipatikani kwa miamala. Katika kesi hii, shughuli zinaweza tu kuona data iliyojitolea, na usomaji wa phantom unaweza kutokea. Ikiwa muamala utaingiza na kutekeleza safu mlalo mpya, muamala wa sasa utaweza kuziona utakapoulizwa.
- Soma bila kujitolea (angalau kiwango kali na cha gharama kubwa): Usomaji mchafu unaruhusiwa, miamala inaweza kuona mabadiliko ambayo hayajatekelezwa yanayofanywa na miamala mingine. Kwa mazoezi, kiwango hiki kinaweza kuwa muhimu kwa makadirio mabaya, kama vile maswali
COUNT(*)juu ya meza.
Kiwango Inaweza kuzidi hupunguza hatari ya mbio za data, huku zikiwa ghali zaidi kutekeleza na kusababisha mzigo wa juu zaidi wa ushindani kwenye mfumo. Viwango vingine vya kutengwa ni rahisi kutekeleza, lakini huongeza uwezekano wa mbio za data. Baadhi ya DBMS hukuruhusu kuweka kiwango maalum cha kutengwa, zingine zina mapendeleo thabiti na sio viwango vyote vinavyoauniwa.
Usaidizi wa viwango vya kutengwa mara nyingi hutangazwa katika DBMS fulani, lakini uchunguzi wa makini tu wa tabia yake unaweza kufunua kile kinachotokea.
Mapitio ya hitilafu za fedha katika viwango tofauti vya kutengwa kwa DBMS tofauti
Martin Kleppmann katika mradi wake Inalinganisha viwango tofauti vya kutengwa, huzungumza kuhusu hitilafu za upatanishi, na kama hifadhidata inaweza kuambatana na kiwango fulani cha kutengwa. Utafiti wa Kleppmann unaonyesha jinsi watengenezaji hifadhidata tofauti hufikiria juu ya viwango vya kutengwa.
Kuzuia matumaini huja kuwaokoa wakati ni vigumu kudumisha kawaida.
Kuzuia inaweza kuwa ghali sana, si tu kwa sababu inaongeza ushindani katika hifadhidata, lakini pia kwa sababu inahitaji seva za maombi kuunganishwa mara kwa mara kwenye hifadhidata. Ugawaji wa mtandao unaweza kuzidisha hali ya kipekee ya kufunga na kusababisha mikwaruzo ambayo ni vigumu kutambua na kutatua. Katika hali ambapo kufuli kwa kipekee hakufai, kufunga kwa matumaini husaidia.
ni njia ambayo wakati wa kusoma kamba, inazingatia toleo lake, checksum, au wakati wa marekebisho ya mwisho. Hii hukuruhusu kuhakikisha kuwa hakuna mabadiliko ya toleo la atomiki kabla ya kubadilisha ingizo:
UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1
Katika kesi hii, uppdatering meza products haitafanywa ikiwa operesheni nyingine ilifanya mabadiliko hapo awali kwenye safu mlalo hii. Ikiwa hakuna shughuli zingine zilizofanywa kwenye safu hii, mabadiliko ya safu moja yatatokea na tunaweza kusema kwamba sasisho lilifanikiwa.
Kuna hitilafu zingine kando na usomaji chafu na upotezaji wa data
Linapokuja suala la uwiano wa data, lengo ni juu ya uwezekano wa hali ya mbio ambayo inaweza kusababisha usomaji chafu na kupoteza data. Walakini, hitilafu za data haziishii hapo.
Mfano mmoja wa hitilafu kama hizo ni kurekodi upotoshaji (andika miiko). Upotoshaji ni ngumu kugundua kwa sababu hutafutwa kikamilifu. Hazitokani na usomaji mchafu au upotezaji wa data, lakini kwa ukiukaji wa vikwazo vya kimantiki vilivyowekwa kwenye data.
Kwa mfano, hebu tuzingatie programu ya ufuatiliaji ambayo inahitaji mwendeshaji mmoja awe anapiga simu kila wakati:
BEGIN tx1; BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0 SELECT COUNT(*)
FROM operators
WHERE oncall = TRUE;
0
UPDATE operators UPDATE operators
SET oncall = TRUE SET oncall = TRUE
WHERE userId = 4; WHERE userId = 2;
COMMIT tx1; COMMIT tx2;Katika hali iliyo hapo juu, uharibifu wa rekodi utatokea ikiwa shughuli zote mbili zitafanywa kwa ufanisi. Ingawa hapakuwa na usomaji mchafu au upotevu wa data, uadilifu wa data ulitatizwa: sasa watu wawili wanazingatiwa kwenye simu kwa wakati mmoja.
Utengaji unaoweza kutambulika, muundo wa schema, au vikwazo vya hifadhidata vinaweza kusaidia kuondoa ufisadi wa uandishi. Ni lazima wasanidi programu waweze kutambua hitilafu kama hizo wakati wa ukuzaji ili kuziepuka katika uzalishaji. Wakati huo huo, upotoshaji wa kurekodi ni ngumu sana kutafuta katika msingi wa nambari. Hasa katika mifumo mikubwa, wakati timu tofauti za maendeleo zina jukumu la kutekeleza kazi kulingana na majedwali sawa na hazikubaliani juu ya maalum ya ufikiaji wa data.
Hifadhidata na mtumiaji huwa hawakubaliani kila mara juu ya nini cha kufanya
Moja ya vipengele muhimu vya hifadhidata ni dhamana ya utaratibu wa utekelezaji, lakini utaratibu huu yenyewe hauwezi kuwa wazi kwa msanidi programu. Hifadhidata hutekeleza miamala kwa mpangilio unaopokelewa, si kwa mpangilio ambao watayarishaji programu wanakusudia. Mpangilio wa shughuli ni ngumu kutabiri, haswa katika mifumo inayolingana iliyopakiwa sana.
Wakati wa usanidi, haswa wakati wa kufanya kazi na maktaba zisizozuia, mtindo mbaya na usomaji wa chini unaweza kusababisha watumiaji kuamini kuwa miamala inatekelezwa kwa kufuatana, wakati kwa kweli wanaweza kufika kwenye hifadhidata kwa mpangilio wowote.
Kwa mtazamo wa kwanza, katika programu hapa chini, T1 na T2 huitwa sequentially, lakini ikiwa kazi hizi hazizuiliki na mara moja urudishe matokeo katika fomu. , basi mpangilio wa simu utaamuliwa na wakati walipoingia kwenye hifadhidata:
result1 = T1() // matokeo halisi ni ahadi
matokeo2 = T2()
Ikiwa atomiki inahitajika (hiyo ni, ama shughuli zote lazima zikamilishwe au kusitishwa) na mambo ya mlolongo, basi shughuli T1 na T2 lazima zifanyike ndani ya shughuli moja.
Ugawaji wa kiwango cha programu unaweza kuhamishwa nje ya programu
Sharding ni njia ya kugawanya hifadhidata kwa usawa. Baadhi ya hifadhidata zinaweza kugawanya data kiotomatiki kwa usawa, wakati zingine haziwezi, au sio nzuri sana. Wakati wasanifu/wasanidi wa data wanaweza kutabiri jinsi data itafikiwa, wanaweza kuunda sehemu za mlalo katika nafasi ya mtumiaji badala ya kukabidhi kazi hii kwenye hifadhidata. Utaratibu huu unaitwa "sharding ya kiwango cha maombi" (kugawanya kiwango cha maombi).
Kwa bahati mbaya, jina hili mara nyingi hujenga dhana potofu kwamba sharding maisha katika huduma za maombi. Kwa kweli, inaweza kutekelezwa kama safu tofauti mbele ya hifadhidata. Kulingana na ukuaji wa data na marudio ya schema, mahitaji ya kushiriki yanaweza kuwa magumu sana. Baadhi ya mikakati inaweza kufaidika kutokana na uwezo wa kurudia bila kulazimika kusambaza tena seva za programu.
Mfano wa usanifu ambao seva za programu zinatenganishwa na huduma ya sharding
Kuhamisha shard katika huduma tofauti huongeza uwezo wa kutumia mikakati tofauti ya kugawa bila hitaji la kusambaza programu upya. ni mfano wa mfumo wa sharding vile katika ngazi ya maombi. Vitess hutoa sharding mlalo kwa MySQL na inaruhusu wateja kuunganishwa nayo kupitia itifaki ya MySQL. Mfumo hugawanya data katika nodi tofauti za MySQL ambazo hazijui chochote kuhusu kila mmoja.
Autoincrementing inaweza kuwa hatari
AUTOINCREMENT ni njia ya kawaida ya kutengeneza funguo msingi. Mara nyingi kuna matukio wakati hifadhidata zinatumiwa kama jenereta za vitambulisho, na hifadhidata ina majedwali yaliyoundwa ili kutoa vitambulisho. Kuna sababu kadhaa kwa nini kutengeneza funguo za msingi kwa kutumia kuongeza kiotomatiki sio bora:
- Katika hifadhidata iliyosambazwa, kuongeza kiotomatiki ni shida kubwa. Ili kuunda kitambulisho, kufuli ya kimataifa inahitajika. Badala yake, unaweza kutoa UUID: hii haihitaji mwingiliano kati ya nodi tofauti za hifadhidata. Kuongeza kiotomatiki kwa kufuli kunaweza kusababisha ugomvi na kupunguza kwa kiasi kikubwa utendaji wa viingilio katika hali zilizosambazwa. Baadhi ya DBMS (kwa mfano, MySQL) zinaweza kuhitaji usanidi maalum na uangalizi wa makini zaidi ili kupanga urudufishaji mkuu. Na ni rahisi kufanya makosa wakati wa kusanidi, ambayo itasababisha kushindwa kwa kurekodi.
- Baadhi ya hifadhidata zina algorithms za kugawa kulingana na funguo za msingi. Vitambulisho vinavyofuatana vinaweza kusababisha sehemu moto zisizotabirika na kuongezeka kwa mzigo kwenye sehemu fulani huku zingine zikisalia bila kufanya kazi.
- Ufunguo wa msingi ni njia ya haraka zaidi ya kufikia safu katika hifadhidata. Kwa njia bora za kutambua rekodi, vitambulisho vya kufuatana vinaweza kugeuza safu wima muhimu zaidi katika majedwali kuwa safu wima isiyofaa iliyojaa thamani zisizo na maana. Kwa hivyo, inapowezekana, tafadhali chagua ufunguo msingi wa kipekee na asilia (km jina la mtumiaji).
Kabla ya kuamua mbinu, zingatia athari za vitambulisho na UUID zinazoongeza kiotomatiki kwenye kuorodhesha, kugawanya na kugawa.
Data ya zamani inaweza kuwa muhimu na haihitaji kufungwa
Multiversion Concurrency Control (MVCC) hutekeleza mahitaji mengi ya uthabiti ambayo yalijadiliwa kwa ufupi hapo juu. Baadhi ya hifadhidata (kwa mfano, Postgres, Spanner) hutumia MVCC "kulisha" miamala kwa vijipicha—matoleo ya zamani zaidi ya hifadhidata. Shughuli za muamala pia zinaweza kusasishwa ili kuhakikisha uthabiti. Wakati wa kusoma kutoka kwa muhtasari wa zamani, data iliyopitwa na wakati inasomwa.
Kusoma data ya zamani kunaweza kuwa na manufaa, kwa mfano, wakati wa kutengeneza uchanganuzi kutoka kwa data au kukokotoa takriban thamani zilizojumlishwa.
Faida ya kwanza ya kufanya kazi na data ya urithi ni muda mdogo wa kusubiri (hasa ikiwa hifadhidata inasambazwa katika jiografia tofauti). Ya pili ni kwamba shughuli za kusoma tu hazifungiwi. Hii ni faida kubwa kwa programu zinazosoma sana, mradi tu zinaweza kushughulikia data ya zamani.
Seva ya programu husoma data kutoka kwa nakala ya ndani ambayo imepitwa na wakati kwa sekunde 5, hata kama toleo jipya zaidi linapatikana upande wa pili wa Bahari ya Pasifiki.
DBMS husafisha matoleo ya zamani kiotomatiki na, katika hali zingine, hukuruhusu kufanya hivi kwa ombi. Kwa mfano, Postgres inaruhusu watumiaji kufanya VACUUM juu ya ombi, na pia mara kwa mara hufanya operesheni hii moja kwa moja. Spanner huendesha kikusanya takataka ili kuondoa vijipicha vya zaidi ya saa moja.
Vyanzo vya wakati wowote vinaweza kupotoshwa
Siri iliyohifadhiwa vizuri zaidi katika sayansi ya kompyuta ni kwamba API zote za saa hudanganya. Kwa kweli, mashine zetu hazijui wakati halisi wa sasa. Kompyuta zina fuwele za quartz zinazozalisha mitetemo ambayo hutumiwa kuweka wakati. Walakini, sio sahihi vya kutosha na zinaweza kuwa mbele / nyuma ya wakati halisi. Mabadiliko yanaweza kufikia sekunde 20 kwa siku. Kwa hivyo, wakati kwenye kompyuta zetu lazima upatanishwe mara kwa mara na mtandao.
Seva za NTP hutumiwa kwa ulandanishi, lakini mchakato wa ulandanishi wenyewe unategemea ucheleweshaji wa mtandao. Hata maingiliano na seva ya NTP katika kituo hicho cha data huchukua muda. Ni wazi kuwa kufanya kazi na seva ya NTP ya umma kunaweza kusababisha upotoshaji mkubwa zaidi.
Saa za atomiki na GPS zinazolingana nazo ni bora zaidi kwa kubainisha wakati wa sasa, lakini ni ghali na zinahitaji usanidi changamano, kwa hivyo haziwezi kusakinishwa kwenye kila gari. Kwa sababu hii, vituo vya data hutumia mbinu ya ngazi. Saa za atomiki na/au GPS huonyesha muda halisi, na kisha hutangazwa kwa mashine nyingine kupitia seva za upili. Hii ina maana kwamba kila mashine itapata urekebishaji fulani kutoka kwa wakati halisi.
Hali hiyo inazidishwa na ukweli kwamba programu na hifadhidata mara nyingi ziko kwenye mashine tofauti (ikiwa sio katika vituo tofauti vya data). Kwa hivyo, wakati utatofautiana sio tu kwenye nodi za DB zinazosambazwa kwenye mashine tofauti. Pia itakuwa tofauti kwenye seva ya programu.
Google TrueTime inachukua mbinu tofauti kabisa. Watu wengi wanaamini kuwa maendeleo ya Google katika mwelekeo huu yanaelezewa na mpito wa banal kwa saa za atomiki na GPS, lakini hii ni sehemu tu ya picha kubwa. Hivi ndivyo TrueTime inavyofanya kazi:
- TrueTime hutumia vyanzo viwili tofauti: GPS na saa za atomiki. Saa hizi zina hali za kutofaulu zisizohusiana. [tazama ukurasa wa 5 kwa maelezo zaidi - takriban. tafsiri.), hivyo matumizi yao ya pamoja huongeza kuegemea.
- TrueTime ina API isiyo ya kawaida. Inarudisha wakati kama muda na makosa ya kipimo na kutokuwa na uhakika kujengwa ndani yake. Wakati halisi kwa wakati ni mahali fulani kati ya mipaka ya juu na ya chini ya muda. Spanner, hifadhidata iliyosambazwa ya Google, husubiri tu hadi iwe salama kusema kwamba muda wa sasa umeisha. Njia hii inaleta latency katika mfumo, haswa ikiwa kutokuwa na uhakika kwa mabwana ni kubwa, lakini inahakikisha usahihi hata katika hali iliyosambazwa ulimwenguni.
Vipengee vya Spanner hutumia TrueTime, ambapo TT.now() hurejesha muda, kwa hivyo Spanner hulala tu hadi wakati ambapo inaweza kuwa na uhakika kwamba wakati wa sasa umepita hatua fulani.
Kupungua kwa usahihi katika kubainisha muda wa sasa kunamaanisha kuongezeka kwa muda wa shughuli za Spanner na kupungua kwa utendaji. Hii ndiyo sababu ni muhimu kudumisha usahihi wa hali ya juu zaidi ingawa haiwezekani kupata saa sahihi kabisa.
Kuchelewa kuna maana nyingi
Ukiuliza wataalam kadhaa kuhusu kuchelewa ni nini, labda utapata majibu tofauti. Katika latency ya DBMS mara nyingi huitwa "database latency" na ni tofauti na ile inayotambuliwa na mteja. Ukweli ni kwamba mteja anaona jumla ya ucheleweshaji wa mtandao na ucheleweshaji wa hifadhidata. Uwezo wa kutenga aina ya kusubiri ni muhimu wakati wa kutatua matatizo ya kukua. Wakati wa kukusanya na kuonyesha vipimo, kila wakati jaribu kuweka jicho kwenye aina zote mbili.
Mahitaji ya utendaji yanapaswa kutathminiwa kwa shughuli mahususi
Wakati mwingine sifa za utendaji wa DBMS na mapungufu yake hubainishwa katika suala la kuandika/kusoma matokeo na muda wa kusubiri. Hii inatoa muhtasari wa jumla wa vigezo muhimu vya mfumo, lakini wakati wa kutathmini utendakazi wa DBMS mpya, mbinu ya kina zaidi ni kutathmini shughuli muhimu kando (kwa kila hoja na/au shughuli). Mifano:
- Andika muda na muda wa kusubiri unapoingiza safu mlalo mpya kwenye jedwali X (yenye safu mlalo milioni 50) yenye vikwazo vilivyobainishwa na uwekaji safu mlalo katika jedwali zinazohusiana.
- Kuchelewa kwa kuonyesha marafiki wa marafiki wa mtumiaji fulani wakati wastani wa idadi ya marafiki ni 500.
- Ucheleweshaji wa kurejesha maingizo 100 bora kutoka kwa historia ya mtumiaji wakati mtumiaji anafuata watumiaji wengine 500 na maingizo X kwa saa.
Tathmini na majaribio yanaweza kujumuisha kesi kama hizo muhimu hadi uwe na uhakika kwamba hifadhidata inakidhi mahitaji ya utendaji. Kanuni sawa ya kidole gumba pia huzingatia uchanganuzi huu wakati wa kukusanya vipimo vya muda na kubainisha SLO.
Jihadharini na maadili ya juu wakati wa kukusanya vipimo kwa kila operesheni. Tumia kumbukumbu, mkusanyiko wa matukio, au ufuatiliaji uliosambazwa ili kupata data ya utatuzi wa nguvu ya juu. Katika makala "»unaweza kujifahamisha na mbinu za utatuzi wa kuchelewa.
Shughuli zilizowekwa zinaweza kuwa hatari
Sio kila DBMS inasaidia shughuli zilizowekwa, lakini zinapofanya hivyo, shughuli kama hizo zinaweza kusababisha makosa yasiyotarajiwa ambayo sio rahisi kugundua kila wakati (yaani, inapaswa kuwa wazi kuwa kuna aina fulani ya makosa).
Unaweza kuepuka kutumia miamala iliyopachikwa kwa kutumia maktaba za mteja zinazoweza kuzitambua na kuzipita. Iwapo shughuli zilizowekwa haziwezi kuachwa, chukua tahadhari maalum katika utekelezaji wake ili kuepuka hali zisizotarajiwa ambapo shughuli zilizokamilishwa husitishwa kimakosa kutokana na zile zilizowekwa kiota.
Kujumuisha miamala katika tabaka tofauti kunaweza kusababisha miamala isiyotarajiwa, na kwa mtazamo wa usomaji wa msimbo, inaweza kuifanya iwe ngumu kuelewa nia ya mwandishi. Angalia programu ifuatayo:
with newTransaction():
Accounts.create("609-543-222")
with newTransaction():
Accounts.create("775-988-322")
throw Rollback();Je, matokeo ya nambari iliyo hapo juu yatakuwa nini? Je, itarudisha nyuma shughuli zote mbili, au ile ya ndani tu? Ni nini hufanyika ikiwa tunategemea safu nyingi za maktaba ambazo zinajumuisha uundaji wa miamala kwa ajili yetu? Je, tutaweza kutambua na kuboresha kesi kama hizi?
Hebu fikiria safu ya data iliyo na shughuli nyingi (k.m. newAccount) tayari inatekelezwa katika shughuli zake yenyewe. Nini kitatokea ikiwa utaziendesha kama sehemu ya mantiki ya biashara ya kiwango cha juu ambayo inaendeshwa ndani ya shughuli zake yenyewe? Je, kutengwa na uthabiti katika kesi hii itakuwa nini?
function newAccount(id string) {
with newTransaction():
Accounts.create(id)
}Badala ya kutafuta majibu ya maswali kama haya yasiyo na mwisho, ni bora kuzuia shughuli zilizowekwa. Baada ya yote, safu yako ya data inaweza kufanya shughuli za kiwango cha juu kwa urahisi bila kuunda shughuli zake. Kwa kuongeza, mantiki ya biashara yenyewe ina uwezo wa kuanzisha shughuli, kufanya shughuli juu yake, kufanya au kukomesha shughuli.
function newAccount(id string) {
Accounts.create(id)
}
// In main application:
with newTransaction():
// Read some data from database for configuration.
// Generate an ID from the ID service.
Accounts.create(id)
Uploads.create(id) // create upload queue for the user.Shughuli hazipaswi kuunganishwa na hali ya maombi
Wakati mwingine inajaribu kutumia hali ya maombi katika shughuli kubadilisha maadili fulani au kurekebisha vigezo vya hoja. Nuance muhimu ya kuzingatia ni wigo sahihi wa maombi. Wateja mara nyingi huanza upya shughuli wakati kuna matatizo ya mtandao. Ikiwa shughuli basi inategemea hali ambayo inabadilishwa na mchakato mwingine, inaweza kuchagua thamani isiyo sahihi kulingana na uwezekano wa mbio za data. Ni lazima miamala izingatie hatari ya masharti ya mbio za data katika programu.
var seq int64
with newTransaction():
newSeq := atomic.Increment(&seq)
Entries.query(newSeq)
// Other operations...Muamala ulio hapo juu utaongeza nambari ya mfuatano kila wakati inapotekelezwa, bila kujali matokeo ya mwisho. Ikiwa ahadi itashindwa kwa sababu ya matatizo ya mtandao, ombi litatekelezwa kwa nambari tofauti ya mlolongo unapojaribu tena.
Wapangaji wa hoja wanaweza kukuambia mengi kuhusu hifadhidata
Wapangaji hoja huamua jinsi hoja itatekelezwa katika hifadhidata. Pia huchanganua maombi na kuyaboresha kabla ya kuyatuma. Wapangaji wanaweza tu kutoa makadirio yanayowezekana kulingana na ishara walizo nazo. Kwa mfano, ni ipi njia bora zaidi ya utafutaji kwa swali lifuatalo?
SELECT * FROM articles where author = "rakyll" order by title;Matokeo yanaweza kupatikana kwa njia mbili:
- Uchanganuzi kamili wa jedwali: Unaweza kuangalia kila ingizo kwenye jedwali na urudishe nakala zilizo na jina la mwandishi linalolingana, na kisha uziamuru.
- Uchanganuzi wa kielezo: Unaweza kutumia faharasa kupata vitambulisho vinavyolingana, pata safu mlalo hizo, kisha uziagize.
Kazi ya mpangaji swala ni kuamua mkakati gani ni bora. Inafaa kuzingatia kuwa wapangaji wa hoja wana uwezo mdogo wa kutabiri. Hii inaweza kusababisha maamuzi mabaya. DBA au wasanidi wanaweza kuzitumia kutambua na kurekebisha maswali yenye utendaji wa chini. Matoleo mapya ya DBMS yanaweza kusanidi vipangaji hoja, na kujitambua kunaweza kusaidia wakati wa kusasisha hifadhidata ikiwa toleo jipya litasababisha matatizo ya utendakazi. Kumbukumbu za hoja polepole, ripoti za tatizo la kusubiri, au takwimu za muda wa utekelezaji zinaweza kusaidia kutambua hoja zinazohitaji uboreshaji.
Baadhi ya vipimo vinavyowasilishwa na kipanga hoja vinaweza kuwa chini ya kelele (hasa wakati wa kukadiria muda wa kusubiri au wakati wa CPU). Nyongeza nzuri kwa wapanga ratiba ni zana za kufuatilia na kufuatilia njia ya utekelezaji. Wanakuruhusu kugundua shida kama hizo (ole, sio DBMS zote hutoa zana kama hizo).
Uhamiaji mtandaoni ni ngumu lakini inawezekana
Uhamiaji wa mtandaoni, uhamaji wa moja kwa moja, au uhamishaji wa wakati halisi unamaanisha kuhama kutoka hifadhidata moja hadi nyingine bila kuharibika kwa muda au uharibifu wa data. Uhamiaji wa moja kwa moja ni rahisi kutekeleza ikiwa mpito utatokea ndani ya DBMS/injini sawa. Hali inakuwa ngumu zaidi inapohitajika kuhamia DBMS mpya yenye mahitaji tofauti ya utendaji na schema.
Kuna mifano tofauti ya uhamiaji mtandaoni. Hapa kuna mmoja wao:
- Washa ingizo mara mbili katika hifadhidata zote mbili. Hifadhidata mpya katika hatua hii haina data yote, lakini inakubali data ya hivi punde tu. Ukiwa na uhakika wa hili, unaweza kuendelea na hatua inayofuata.
- Washa usomaji kutoka kwa hifadhidata zote mbili.
- Sanidi mfumo ili usomaji na uandishi ufanyike hasa kwenye hifadhidata mpya.
- Acha kuandika kwenye hifadhidata ya zamani huku ukiendelea kusoma data kutoka kwayo. Katika hatua hii, hifadhidata mpya bado haina data fulani. Zinapaswa kunakiliwa kutoka kwa hifadhidata ya zamani.
- Hifadhidata ya zamani ni ya kusoma tu. Nakili data inayokosekana kutoka kwa hifadhidata ya zamani hadi mpya. Baada ya uhamiaji kukamilika, badilisha njia kwenye hifadhidata mpya, na usimamishe ya zamani na uifute kutoka kwa mfumo.
Kwa maelezo ya ziada, napendekeza kuwasiliana , ambayo inaelezea mkakati wa uhamiaji wa Stripe kulingana na mtindo huu.
Ongezeko kubwa la hifadhidata linajumuisha ongezeko la kutotabirika
Ukuaji wa hifadhidata husababisha shida zisizotabirika zinazohusiana na kiwango chake. Kadiri tunavyojua zaidi kuhusu muundo wa ndani wa hifadhidata, ndivyo tunavyoweza kutabiri jinsi itakavyokua. Walakini, wakati fulani bado hauwezekani kutabiri.
Kadiri msingi unavyokua, mawazo na matarajio ya hapo awali kuhusu kiasi cha data na mahitaji ya kipimo data cha mtandao yanaweza kupitwa na wakati. Hapa ndipo swali linapotokea la urekebishaji mkubwa wa muundo, uboreshaji mkubwa wa utendakazi, kufikiria upya uwekaji, au uhamishaji hadi DBMS zingine ili kuepusha matatizo yanayoweza kutokea.
Lakini usifikiri kwamba ujuzi bora wa muundo wa ndani wa hifadhidata iliyopo ni jambo pekee ambalo ni muhimu. Mizani mpya italeta na haijulikani mpya. Pointi za maumivu zisizotabirika, usambazaji wa data usio na usawa, maswala ya bandwidth na vifaa visivyotarajiwa, trafiki inayoongezeka kila wakati na sehemu mpya za mtandao zitakulazimisha kufikiria upya mbinu yako ya hifadhidata, mfano wa data, mfano wa kupeleka, na saizi ya hifadhidata.
...
Wakati nilianza kufikiria kuchapisha nakala hii, tayari kulikuwa na vitu vitano zaidi kwenye orodha yangu ya asili. Kisha ikaja idadi kubwa kuhusu nini kingine kinaweza kufunikwa. Kwa hivyo, kifungu kinagusa shida zisizo wazi ambazo zinahitaji umakini wa hali ya juu. Walakini, hii haimaanishi kuwa mada imechoka na sitairudia tena katika nyenzo zangu za baadaye na sitafanya mabadiliko kwa ya sasa.
PS
Soma pia kwenye blogi yetu:
- «";
- «";
- «'.
Chanzo: mapenzi.com