Wanasema kwamba kila kitu maishani kinafaa kujaribu angalau mara moja. Na ikiwa umezoea kufanya kazi na DBMS za uhusiano, basi inafaa kufahamiana na NoSQL katika mazoezi, kwanza kabisa, angalau kwa maendeleo ya jumla. Sasa, kutokana na maendeleo ya haraka ya teknolojia hii, kuna maoni mengi yanayopingana na mijadala mikali juu ya mada hii, ambayo huchochea maslahi.
Ukichunguza kiini cha mabishano haya yote, unaweza kuona kwamba yanatokea kwa sababu ya njia mbaya. Wale wanaotumia hifadhidata za NoSQL haswa mahali wanapohitajika wanaridhika na kupokea faida zote kutoka kwa suluhisho hili. Na wajaribio ambao wanategemea teknolojia hii kama tiba ambapo haitumiki hata kidogo wamekatishwa tamaa, kwa kuwa wamepoteza uwezo wa hifadhidata za uhusiano bila kupata manufaa makubwa.
Nitakuambia kuhusu uzoefu wetu katika kutekeleza suluhisho kulingana na Cassandra DBMS: kile tulichopaswa kukabiliana nacho, jinsi tulivyotoka katika hali ngumu, ikiwa tuliweza kufaidika kwa kutumia NoSQL na ambapo tulipaswa kuwekeza juhudi / fedha za ziada. .
Kazi ya awali ni kujenga mfumo unaorekodi simu katika aina fulani ya hifadhi.
Kanuni ya uendeshaji wa mfumo ni kama ifuatavyo. Ingizo ni pamoja na faili zilizo na muundo maalum unaoelezea muundo wa simu. Kisha programu inahakikisha kwamba muundo huu umehifadhiwa katika safu wima zinazofaa. Katika siku zijazo, simu zilizohifadhiwa hutumiwa kuonyesha habari juu ya matumizi ya trafiki kwa watumiaji (malipo, simu, historia ya usawa).
Ni wazi kabisa kwa nini walimchagua Cassandra - anaandika kama bunduki ya mashine, ni hatari kwa urahisi, na huvumilia makosa.
Kwa hivyo, hii ndio uzoefu ulitupa
Ndio, nodi iliyoshindwa sio janga. Hiki ndicho kiini cha ustahimilivu wa makosa wa Cassandra. Lakini node inaweza kuwa hai na wakati huo huo kuanza kuteseka katika utendaji. Kama ilivyotokea, hii inathiri mara moja utendaji wa nguzo nzima.
Cassandra haitakulinda ambapo Oracle ilikuokoa na vikwazo vyake. Na ikiwa mwandishi wa maombi hakuelewa hili mapema, basi mara mbili ambayo ilifika kwa Cassandra sio mbaya zaidi kuliko ya awali. Ikifika, tutaiweka.
IB hakupendezwa sana na Cassandra asiye na malipo nje ya boksi: Hakuna ukataji wa vitendo vya mtumiaji, hakuna utofautishaji wa haki. Taarifa kuhusu simu inachukuliwa kuwa data ya kibinafsi, ambayo ina maana kwamba majaribio yote ya kuomba / kubadilisha kwa njia yoyote lazima yameingia na uwezekano wa ukaguzi unaofuata. Pia, unahitaji kufahamu haja ya kutenganisha haki katika viwango tofauti kwa watumiaji tofauti. Mhandisi wa uendeshaji rahisi na msimamizi mkuu ambaye anaweza kufuta kwa uhuru nafasi nzima ya vitufe ni majukumu tofauti, majukumu tofauti na umahiri. Bila utofauti huo wa haki za ufikiaji, thamani na uadilifu wa data utatiliwa shaka mara moja kwa kasi zaidi kuliko kiwango CHOCHOTE cha uthabiti.
Hatukuzingatia kwamba simu zinahitaji uchanganuzi wa kina na sampuli za mara kwa mara kwa hali mbalimbali. Kwa kuwa rekodi zilizochaguliwa basi zinapaswa kufutwa na kuandikwa upya (kama sehemu ya kazi, lazima tuunge mkono mchakato wa kusasisha data wakati data iliingia kitanzi chetu kimakosa), Cassandra sio rafiki yetu hapa. Cassandra ni kama benki ya nguruwe - ni rahisi kuweka vitu ndani, lakini huwezi kuhesabu ndani yake.
Tumekumbana na tatizo la kuhamisha data kwenye maeneo ya majaribio (Nodi 5 kwenye jaribio dhidi ya 20 kwenye prom). Katika kesi hii, dampo haiwezi kutumika.
Tatizo la kusasisha schema ya data ya kuandika maombi kwa Cassandra. Kurudisha nyuma kutazalisha mawe mengi ya kaburi, ambayo yanaweza kusababisha hasara ya tija kwa njia zisizotabirika.. Cassandra imeboreshwa kwa ajili ya kurekodi, na hafikirii sana kabla ya kuandika. Operesheni yoyote iliyo na data iliyopo ndani yake pia ni rekodi. Hiyo ni, kwa kufuta yasiyo ya lazima, tutatoa rekodi zaidi zaidi, na ni baadhi tu yao yatakuwa na alama za makaburi.
Muda umeisha wakati wa kuingiza. Cassandra ni mzuri katika kurekodi, lakini wakati mwingine mtiririko unaoingia unaweza kumsumbua sana. Hii hutokea wakati programu inapoanza kuzunguka rekodi kadhaa ambazo haziwezi kuingizwa kwa sababu fulani. Na tutahitaji DBA halisi ambaye atafuatilia kumbukumbu za gc.log, mfumo na utatuzi kwa hoja za polepole, vipimo vya ubanaji vinasubiri.
Vituo kadhaa vya data katika kundi moja. Wapi kusoma kutoka na wapi kuandika?
Labda imegawanywa katika kusoma na kuandika? Na ikiwa ni hivyo, je, kuwe na DC karibu na maombi ya kuandika au kusoma? Na je, hatutaishia na ubongo wa mgawanyiko wa kweli ikiwa tutachagua kiwango kibaya cha uthabiti? Kuna maswali mengi, mipangilio mingi isiyojulikana, uwezekano ambao ungependa kufikiria.
Jinsi tulivyoamua
Ili kuzuia nodi kuzama, SWAP ilizimwa. Na sasa, ikiwa kuna ukosefu wa kumbukumbu, node inapaswa kwenda chini na si kuunda pause kubwa za gc.
Kwa hivyo, hatutegemei tena mantiki kwenye hifadhidata. Wasanidi programu wanajizoeza upya na wanaanza kuchukua tahadhari kikamilifu katika misimbo yao wenyewe. Utenganisho bora wa uhifadhi na usindikaji wa data.
Tulinunua usaidizi kutoka kwa DataStax. Ukuzaji wa Cassandra aliye na sanduku tayari imekoma (ahadi ya mwisho ilikuwa mnamo Februari 2018). Wakati huo huo, Datastax inatoa huduma bora na idadi kubwa ya ufumbuzi uliobadilishwa na uliobadilishwa kwa ufumbuzi uliopo wa IP.
Pia nataka kutambua kuwa Cassandra sio rahisi sana kwa maswali ya uteuzi. Bila shaka, CQL ni hatua kubwa mbele kwa watumiaji (ikilinganishwa na Trift). Lakini ikiwa una idara nzima ambazo zimezoea uunganisho rahisi kama huu, kuchuja bure kwa uwanja wowote na uwezo wa uboreshaji wa hoja, na idara hizi zinafanya kazi kusuluhisha malalamiko na ajali, basi suluhisho la Cassandra linaonekana kuwa chuki na kijinga kwao. Na tulianza kuamua jinsi wenzetu wanapaswa kufanya sampuli.
Tulizingatia chaguo mbili Katika chaguo la kwanza, tunaandika simu sio tu katika C *, lakini pia katika hifadhidata ya Oracle iliyohifadhiwa. Tofauti na C* pekee, hifadhidata hii huita kwa mwezi wa sasa pekee (kina cha kutosha cha hifadhi ya simu kwa kesi za kuchaji tena). Hapa tuliona mara moja shida ifuatayo: ikiwa tunaandika kwa usawa, basi tunapoteza faida zote za C * zinazohusiana na kuingizwa kwa haraka; ikiwa tunaandika kwa usawa, hakuna hakikisho kwamba simu zote muhimu ziliingia kwenye Oracle hata kidogo. Kulikuwa na jumlisha moja, lakini kubwa zaidi: kwa utendakazi, Msanidi Programu sawa wa PL/SQL inasalia, yaani, tunatekeleza kivitendo muundo wa "Facade". Chaguo mbadala. Tunatumia utaratibu wa kupakua simu kutoka kwa C*, huchota data fulani kwa ajili ya uboreshaji kutoka kwa jedwali zinazolingana katika Oracle, kuunganisha sampuli zinazotokana na kutupa matokeo, ambayo sisi kwa namna fulani tunatumia (rudi nyuma, kurudia, kuchambua, kuvutiwa). Cons: mchakato ni wa hatua nyingi, na kwa kuongeza, hakuna interface ya wafanyikazi wa operesheni.
Mwishowe, tulikaa kwenye chaguo la pili. Apache Spark ilitumiwa sampuli kutoka kwa mitungi tofauti. Kiini cha utaratibu kimepunguzwa kwa nambari ya Java, ambayo, kwa kutumia funguo maalum (msajili, wakati wa simu - funguo za sehemu), huchota data kutoka kwa C *, pamoja na data muhimu ya kuimarisha kutoka kwa hifadhidata nyingine yoyote. Baada ya hapo inawaunganisha kwenye kumbukumbu yake na kuonyesha matokeo kwenye jedwali linalosababisha. Tulichora uso wa wavuti juu ya cheche na ikawa inatumika kabisa.
Wakati wa kutatua tatizo la uppdatering data ya mtihani wa viwanda, tulizingatia tena ufumbuzi kadhaa. Uhamishaji wote kupitia Ssloader na chaguo la kugawanya nguzo katika eneo la majaribio katika sehemu mbili, ambazo kila moja ni ya kundi moja na lile la utangazaji, hivyo basi inaendeshwa nayo. Wakati wa kusasisha jaribio, ilipangwa kuwabadilisha: sehemu iliyofanya kazi kwenye jaribio imefutwa na kuingizwa katika uzalishaji, na nyingine huanza kufanya kazi na data tofauti. Hata hivyo, baada ya kufikiria tena, tulikagua kwa busara data ambayo ilistahili kuhamishwa, na tukagundua kuwa simu zenyewe ni huluki isiyolingana kwa majaribio, inayotolewa haraka ikiwa ni lazima, na ni seti ya data ya utangazaji ambayo haina thamani ya kuhamishiwa kwenye mtihani. Kuna vitu kadhaa vya kuhifadhi ambavyo vinafaa kusonga, lakini hizi ni meza kadhaa, na sio nzito sana. Kwa hiyo sisi kama suluhisho, Spark tena alikuja kuwaokoa, kwa msaada ambao tuliandika na kuanza kutumia kikamilifu hati ya kuhamisha data kati ya jedwali, mtihani wa prom.
Sera yetu ya sasa ya uwekaji huturuhusu kufanya kazi bila kurudi nyuma. Kabla ya promo, kuna mtihani wa lazima wa kukimbia, ambapo kosa sio ghali sana. Katika kesi ya kutofaulu, unaweza kuacha nafasi ya kesi kila wakati na kusongesha mpango mzima tangu mwanzo.
Ili kuhakikisha upatikanaji endelevu wa Cassandra, unahitaji dba na sio yeye tu. Kila mtu anayefanya kazi na maombi lazima aelewe wapi na jinsi ya kuangalia hali ya sasa na jinsi ya kutambua matatizo kwa wakati. Ili kufanya hivyo, tunatumia kikamilifu DataStax OpsCenter (Utawala na ufuatiliaji wa mzigo wa kazi), vipimo vya mfumo wa Cassandra Driver (idadi ya muda wa kuisha kwa kuandika kwa C*, idadi ya muda wa kusoma kutoka C*, kiwango cha juu cha latency, nk), kufuatilia uendeshaji. ya programu yenyewe, ikifanya kazi na Cassandra.
Tulipofikiria juu ya swali lililotangulia, tuligundua ni wapi hatari yetu kuu inaweza kuwa. Hizi ni fomu za kuonyesha data zinazoonyesha data kutoka kwa maswali kadhaa huru hadi hifadhi. Kwa njia hii tunaweza kupata habari zisizo sawa kabisa. Lakini tatizo hili lingekuwa muhimu kama tungefanya kazi na kituo kimoja tu cha data. Kwa hiyo jambo la busara zaidi hapa ni, bila shaka, kuunda kazi ya kundi kwa kusoma data kwenye programu ya tatu, ambayo itahakikisha kwamba data inapokelewa kwa muda mmoja. Kuhusu mgawanyiko wa kusoma na kuandika kwa ufaulu, hapa tulikomeshwa na hatari ya kupoteza uhusiano kati ya ma-DC, tunaweza kuishia na nguzo mbili ambazo haziendani kabisa.
Matokeo yake, kwa sasa imesimamishwa kwa kiwango cha uthabiti kwa kuandika EACH_QUORUM, kwa kusoma - LOCAL_QUORUM
Hitimisho fupi na hitimisho
Ili kutathmini suluhisho linalotokana na mtazamo wa usaidizi wa uendeshaji na matarajio ya maendeleo zaidi, tuliamua kufikiria ni wapi pengine maendeleo kama haya yanaweza kutumika.
Papo hapo, kisha data ikipata alama za programu kama vile “Lipa inapofaa” (tunapakia maelezo katika C*, kukokotoa kwa kutumia hati za Spark), kuhesabu madai kwa kujumlisha eneo kwa eneo, kuhifadhi majukumu na kukokotoa haki za ufikiaji wa mtumiaji kulingana na jukumu. tumbo.
Kama unaweza kuona, repertoire ni pana na tofauti. Na ikiwa tutachagua kambi ya wafuasi/wapinzani wa NoSQL, basi tutajiunga na wafuasi, kwa kuwa tulipokea faida zetu, na hasa pale tulipotarajia.
Hata chaguo la Cassandra nje ya boksi inaruhusu kuongeza usawa kwa wakati halisi, kutatua bila uchungu suala la kuongeza data kwenye mfumo. Tuliweza kuhamisha utaratibu wa upakiaji wa juu sana wa kuhesabu mikusanyiko ya simu kwenye mzunguko tofauti, na pia kutenganisha schema ya programu na mantiki, tukiondoa mazoea mabaya ya kuandika kazi maalum na vitu kwenye hifadhidata yenyewe. Tulipata fursa ya kuchagua na kusanidi, kuharakisha, ni DC gani tutafanyia mahesabu na zipi tutarekodi data, tulijiwekea bima dhidi ya ajali za nodi zote mbili na DC kwa ujumla.
Kutumia usanifu wetu kwa miradi mipya, na tayari kuwa na uzoefu fulani, ningependa kuzingatia mara moja nuances iliyoelezwa hapo juu, na kuzuia makosa fulani, laini nje pembe kali ambazo haziwezi kuepukwa hapo awali.
Kwa mfano, fuatilia sasisho za Cassandra kwa wakati ufaaokwa sababu matatizo machache tuliyopata yalikuwa yanajulikana na kusuluhishwa.
Usiweke hifadhidata yenyewe na Spark kwenye nodi sawa (au ugawanye madhubuti kwa kiasi cha matumizi yanayoruhusiwa ya rasilimali), kwani Spark inaweza kula OP zaidi kuliko inavyotarajiwa, na tutapata haraka nambari ya 1 kutoka kwenye orodha yetu.
Kuboresha ufuatiliaji na uwezo wa kiutendaji katika hatua ya majaribio ya mradi. Hapo awali, zingatia iwezekanavyo watumiaji wote wa suluhisho letu, kwa sababu hii ndio muundo wa hifadhidata hatimaye utategemea.
Zungusha mzunguko unaosababisha mara kadhaa kwa uboreshaji iwezekanavyo. Chagua ni sehemu gani zinaweza kusasishwa. Kuelewa ni majedwali gani ya ziada tunapaswa kutengeneza ili kuzingatia kwa usahihi na kikamilifu, na kisha kutoa habari inayohitajika wakati wa ombi (kwa mfano, kwa kudhani kuwa tunaweza kuhifadhi data sawa katika jedwali tofauti, kwa kuzingatia michanganuo tofauti kulingana na vigezo tofauti, tunaweza kuokoa kwa kiasi kikubwa muda wa CPU kwa maombi ya kusoma).
Wastani Toa mara moja kwa kuambatisha TTL na kusafisha data iliyopitwa na wakati.
Wakati wa kupakua data kutoka kwa Cassandra Mantiki ya maombi inapaswa kufanya kazi kwenye kanuni ya FETCH, ili si safu zote zinazopakiwa kwenye kumbukumbu mara moja, lakini zimechaguliwa kwa makundi.
Inashauriwa kabla ya kuhamisha mradi kwenye suluhisho lililoelezwa angalia uvumilivu wa hitilafu wa mfumo kwa kufanya mfululizo wa majaribio ya kuacha kufanya kazi, kama vile kupoteza data katika kituo kimoja cha data, urejeshaji wa data iliyoharibika kwa muda fulani, kuacha mtandao kati ya vituo vya data. Vipimo kama hivyo havitamruhusu tu kutathmini faida na hasara za usanifu uliopendekezwa, lakini pia itatoa mazoezi mazuri ya joto kwa wahandisi wanaowaongoza, na ustadi uliopatikana hautakuwa mbaya sana ikiwa kushindwa kwa mfumo kunatolewa tena katika uzalishaji.
Ikiwa tutafanya kazi na habari muhimu (kama vile data ya bili, hesabu ya deni la mteja), basi inafaa kuzingatia zana ambazo zitapunguza hatari zinazotokana na sifa za DBMS. Kwa mfano, tumia matumizi ya nodesync (Datastax), baada ya kutengeneza mkakati bora wa matumizi yake ili kwa ajili ya uthabiti, usijenge mzigo mkubwa kwa Cassandra na uitumie tu kwa meza fulani katika kipindi fulani.
Nini kinatokea kwa Cassandra baada ya miezi sita ya maisha? Kwa ujumla, hakuna matatizo ambayo hayajatatuliwa. Pia hatukuruhusu ajali zozote mbaya au upotezaji wa data. Ndio, tulilazimika kufikiria juu ya kulipa fidia kwa shida zingine ambazo hazijatokea hapo awali, lakini mwishowe hii haikufunika sana suluhisho letu la usanifu. Ikiwa unataka na usiogope kujaribu kitu kipya, na wakati huo huo hawataki kukata tamaa sana, basi uwe tayari kwa ukweli kwamba hakuna kitu cha bure. Utalazimika kuelewa, kuzama ndani ya hati na kukusanya tafuta yako ya kibinafsi zaidi ya suluhisho la zamani la urithi, na hakuna nadharia itakuambia mapema ni reki gani inayokungoja.
Chanzo: mapenzi.com