Sinasabi nila na ang lahat ng bagay sa buhay ay sulit na subukan kahit isang beses. At kung nakasanayan mong magtrabaho kasama ang mga relational na DBMS, sulit na makilala ang NoSQL sa pagsasanay, una sa lahat, hindi bababa sa para sa pangkalahatang pag-unlad. Ngayon, dahil sa mabilis na pag-unlad ng teknolohiyang ito, maraming magkasalungat na opinyon at mainit na debate sa paksang ito, na lalo na nagpapasigla sa interes.
Kung susuriin mo ang kakanyahan ng lahat ng mga hindi pagkakaunawaan na ito, makikita mo na lumitaw ang mga ito dahil sa maling diskarte. Ang mga gumagamit ng mga database ng NoSQL nang eksakto kung saan sila kinakailangan ay nasisiyahan at natatanggap ang lahat ng mga pakinabang mula sa solusyon na ito. At ang mga eksperimento na umaasa sa teknolohiyang ito bilang isang panlunas sa lahat kung saan hindi ito naaangkop ay nabigo, na nawala ang mga lakas ng relational database nang hindi nakakakuha ng makabuluhang mga benepisyo.
Sasabihin ko sa iyo ang tungkol sa aming karanasan sa pagpapatupad ng solusyon batay sa Cassandra DBMS: kung ano ang kailangan naming harapin, kung paano kami nakaligtas sa mahihirap na sitwasyon, kung nakinabang kami sa paggamit ng NoSQL at kung saan kailangan naming mamuhunan ng mga karagdagang pagsisikap/pondo .
Ang unang gawain ay ang bumuo ng isang sistema na nagtatala ng mga tawag sa ilang uri ng imbakan.
Ang prinsipyo ng pagpapatakbo ng system ay ang mga sumusunod. Kasama sa input ang mga file na may partikular na istraktura na naglalarawan sa istruktura ng tawag. Pagkatapos ay tinitiyak ng application na ang istrakturang ito ay naka-imbak sa naaangkop na mga column. Sa hinaharap, ang mga naka-save na tawag ay ginagamit upang magpakita ng impormasyon sa pagkonsumo ng trapiko para sa mga subscriber (mga singil, tawag, kasaysayan ng balanse).
Medyo malinaw kung bakit pinili nila si Cassandra - nagsusulat siya na parang machine gun, madaling scalable, at fault-tolerant.
Kaya, ito ang ibinigay sa amin ng karanasan
Oo, ang isang nabigong node ay hindi isang trahedya. Ito ang esensya ng fault tolerance ni Cassandra. Pero ang isang node ay maaaring maging buhay at sa parehong oras ay nagsisimulang magdusa sa pagganap. Tulad ng nangyari, agad itong nakakaapekto sa pagganap ng buong kumpol.
Hindi ka poprotektahan ni Cassandra kung saan iniligtas ka ng Oracle sa mga hadlang nito. At kung ang may-akda ng application ay hindi naiintindihan ito nang maaga, kung gayon ang dobleng dumating para kay Cassandra ay hindi mas masahol kaysa sa orihinal. Kapag dumating ito, ilalagay namin ito.
Lubos na hindi nagustuhan ng IB ang libreng Cassandra sa labas ng kahon: Walang pag-log ng mga aksyon ng gumagamit, walang pagkakaiba-iba ng mga karapatan. Ang impormasyon tungkol sa mga tawag ay itinuturing na personal na data, na nangangahulugan na ang lahat ng mga pagtatangka na hilingin/baguhin ito sa anumang paraan ay dapat na naka-log na may posibilidad ng kasunod na pag-audit. Gayundin, kailangan mong magkaroon ng kamalayan sa pangangailangang paghiwalayin ang mga karapatan sa iba't ibang antas para sa iba't ibang user. Ang isang simpleng operation engineer at isang super admin na malayang makakapagtanggal ng buong keyspace ay magkaibang tungkulin, magkakaibang responsibilidad, at kakayahan. Kung walang ganoong pagkakaiba ng mga karapatan sa pag-access, ang halaga at integridad ng data ay agad na magdududa nang mas mabilis kaysa sa ANUMANG antas ng pagkakapare-pareho.
Hindi namin isinaalang-alang na ang mga tawag ay nangangailangan ng parehong seryosong analytics at pana-panahong pag-sample para sa iba't ibang kundisyon. Dahil ang mga napiling rekord ay dapat na tatanggalin at muling isusulat (bilang bahagi ng gawain, dapat nating suportahan ang proseso ng pag-update ng data kapag ang data ay unang pumasok sa ating loop nang hindi tama), si Cassandra ay hindi natin kaibigan dito. Si Cassandra ay parang alkansya - maginhawang maglagay ng mga bagay, ngunit hindi mo ito mabibilang.
Nakaranas kami ng problema sa paglilipat ng data sa mga zone ng pagsubok (5 node sa pagsubok kumpara sa 20 sa prom). Sa kasong ito, hindi magagamit ang dump.
Ang problema sa pag-update ng data schema ng isang application na sumusulat kay Cassandra. Ang isang rollback ay bubuo ng napakaraming lapida, na maaaring humantong sa pagkalugi sa produktibidad sa mga hindi inaasahang paraan.. Si Cassandra ay na-optimize para sa pag-record, at hindi masyadong nag-iisip bago sumulat. Ang anumang operasyon na may umiiral na data dito ay isa ring pag-record. Ibig sabihin, sa pamamagitan ng pagtanggal ng hindi kailangan, gagawa lang tayo ng higit pang mga tala, at ilan lamang sa mga ito ang mamarkahan ng mga lapida.
Mga timeout kapag naglalagay. Maganda si Cassandra sa recording, pero kung minsan ang papasok na daloy ay maaaring makabuluhang palaisipan sa kanya. Nangyayari ito kapag nagsimulang umikot ang application sa ilang talaan na hindi maipasok sa ilang kadahilanan. At kakailanganin namin ng totoong DBA na susubaybay sa gc.log, system at mga debug log para sa mabagal na mga query, mga sukatan sa nakabinbing compaction.
Ilang data center sa isang cluster. Saan magbabasa at saan magsusulat?
Marahil nahati sa pagbabasa at pagsusulat? At kung gayon, dapat bang mayroong DC na mas malapit sa aplikasyon para sa pagsusulat o pagbabasa? At hindi ba tayo magtatapos sa isang tunay na hating utak kung pipiliin natin ang maling antas ng pagkakapare-pareho? Mayroong maraming mga katanungan, maraming hindi kilalang mga setting, mga posibilidad na talagang gusto mong pag-usapan.
Kung paano kami nagdesisyon
Upang maiwasang lumubog ang node, hindi pinagana ang SWAP. At ngayon, kung may kakulangan ng memorya, ang node ay dapat bumaba at hindi lumikha ng malalaking gc na pag-pause.
Kaya, hindi na kami umaasa sa lohika sa database. Ang mga developer ng application ay muling nagsasanay sa kanilang sarili at nagsisimulang aktibong gumawa ng mga pag-iingat sa kanilang sariling code. Tamang-tama malinaw na paghihiwalay ng imbakan at pagproseso ng data.
Bumili kami ng suporta mula sa DataStax. Ang pag-develop ng boxed Cassandra ay tumigil na (ang huling commit ay noong Pebrero 2018). Kasabay nito, ang Datastax ay nag-aalok ng mahusay na serbisyo at isang malaking bilang ng mga binago at inangkop na mga solusyon para sa mga kasalukuyang solusyon sa IP.
Gusto ko ring tandaan na si Cassandra ay hindi masyadong maginhawa para sa mga query sa pagpili. Siyempre, ang CQL ay isang malaking hakbang pasulong para sa mga gumagamit (kumpara sa Trift). Ngunit kung mayroon kang buong mga departamento na nakasanayan na sa gayong maginhawang pagsali, libreng pag-filter ng anumang larangan at mga kakayahan sa pag-optimize ng query, at ang mga departamentong ito ay nagtatrabaho upang malutas ang mga reklamo at aksidente, kung gayon ang solusyon kay Cassandra ay tila pagalit at hangal sa kanila. At nagsimula kaming magpasya kung paano dapat gumawa ng mga sample ang aming mga kasamahan.
Isinaalang-alang namin ang dalawang opsyon. Sa unang opsyon, nagsusulat kami ng mga tawag hindi lamang sa C*, kundi pati na rin sa naka-archive na database ng Oracle. Tanging, hindi tulad ng C*, ang database na ito ay nag-iimbak ng mga tawag lamang para sa kasalukuyang buwan (sapat na lalim ng imbakan ng tawag para sa mga kaso ng recharging). Dito agad naming nakita ang sumusunod na problema: kung sumulat kami nang sabay-sabay, mawawala ang lahat ng mga pakinabang ng C* na nauugnay sa mabilis na pagpasok; kung sumulat kami nang asynchronously, walang garantiya na ang lahat ng kinakailangang tawag ay nakapasok sa Oracle. Mayroong isang plus, ngunit isang malaki: para sa operasyon ang parehong pamilyar na PL/SQL Developer ay nananatili, ibig sabihin, halos ipinapatupad namin ang pattern na "Facade." Isang alternatibong opsyon. Nagpapatupad kami ng mekanismo na nag-aalis ng mga tawag mula sa C*, kumukuha ng ilang data para sa pagpapayaman mula sa kaukulang mga talahanayan sa Oracle, sumasali sa mga resultang sample at nagbibigay sa amin ng resulta, na kahit papaano ay ginagamit namin (ibalik, ulitin, pag-aralan, hinahangaan). Cons: ang proseso ay medyo multi-step, at bilang karagdagan, walang interface para sa mga empleyado ng operasyon.
Sa huli, kami ay nanirahan sa pangalawang opsyon. Ang Apache Spark ay ginamit upang mag-sample mula sa iba't ibang mga garapon. Ang kakanyahan ng mekanismo ay nabawasan sa Java code, na, gamit ang tinukoy na mga susi (subscriber, oras ng tawag - mga key ng seksyon), ay kumukuha ng data mula sa C*, pati na rin ang kinakailangang data para sa pagpapayaman mula sa anumang iba pang database. Pagkatapos nito ay isasama nito ang mga ito sa memorya nito at ipinapakita ang resulta sa resultang talahanayan. Iginuhit namin ang isang web face sa ibabaw ng spark at ito ay naging medyo magagamit.
Kapag nilulutas ang problema ng pag-update ng data ng pagsubok sa industriya, muli naming isinaalang-alang ang ilang mga solusyon. Parehong paglilipat sa pamamagitan ng Sstloader at ang opsyong hatiin ang cluster sa test zone sa dalawang bahagi, na ang bawat isa ay halili na kabilang sa parehong cluster kasama ang promotional, kaya pinapagana nito. Kapag ina-update ang pagsubok, binalak na palitan ang mga ito: ang bahagi na nagtrabaho sa pagsubok ay na-clear at pumasok sa produksyon, at ang isa ay nagsisimulang magtrabaho nang hiwalay sa data. Gayunpaman, pagkatapos mag-isip muli, mas makatwiran naming tinasa ang data na karapat-dapat ilipat, at napagtanto namin na ang mga tawag mismo ay isang hindi tugmang entity para sa mga pagsubok, mabilis na nabuo kung kinakailangan, at ito ay ang promotional data set na walang halaga para sa paglipat sa pagsusulit. Mayroong ilang mga imbakan na bagay na nagkakahalaga ng paglipat, ngunit ang mga ito ay literal na isang pares ng mga talahanayan, at hindi masyadong mabigat. Samakatuwid kami bilang isang solusyon, muling sumagip si Spark, sa tulong kung saan isinulat namin at nagsimulang aktibong gumamit ng script para sa paglilipat ng data sa pagitan ng mga talahanayan, prom-test.
Ang aming kasalukuyang patakaran sa pag-deploy ay nagpapahintulot sa amin na magtrabaho nang walang mga rollback. Bago ang promo, mayroong mandatory test run, kung saan ang isang pagkakamali ay hindi masyadong mahal. Sa kaso ng pagkabigo, maaari mong palaging i-drop ang casespace at i-roll ang buong scheme mula sa simula.
To ensure continuous availability of Cassandra, kailangan mo dba at hindi lang siya. Ang bawat isa na nagtatrabaho sa application ay dapat na maunawaan kung saan at kung paano tingnan ang kasalukuyang sitwasyon at kung paano mag-diagnose ng mga problema sa isang napapanahong paraan. Upang gawin ito, aktibong ginagamit namin ang DataStax OpsCenter (Administration at pagsubaybay sa mga workload), mga sukatan ng system ng Cassandra Driver (bilang ng mga timeout para sa pagsulat sa C*, bilang ng mga timeout para sa pagbabasa mula sa C*, maximum latency, atbp.), subaybayan ang operasyon ng application mismo, nagtatrabaho kasama si Cassandra.
Nang naisip namin ang nakaraang tanong, napagtanto namin kung saan maaaring magsinungaling ang aming pangunahing panganib. Ito ay mga form ng pagpapakita ng data na nagpapakita ng data mula sa ilang independiyenteng mga query sa storage. Sa ganitong paraan makakakuha tayo ng medyo hindi pare-parehong impormasyon. Ngunit ang problemang ito ay magiging kasing-katuturan kung nagtrabaho lamang kami sa isang data center. Kaya ang pinaka-makatwirang bagay dito ay, siyempre, upang lumikha ng isang batch function para sa pagbabasa ng data sa isang third-party na application, na titiyakin na ang data ay natanggap sa isang solong yugto ng panahon. Tulad ng para sa paghahati sa pagbabasa at pagsulat sa mga tuntunin ng pagganap, dito kami ay napigilan ng panganib na sa ilang pagkawala ng koneksyon sa pagitan ng mga DC, maaari kaming magkaroon ng dalawang kumpol na ganap na hindi naaayon sa isa't isa.
Bilang resulta, sa ngayon huminto sa antas ng pagkakapare-pareho para sa pagsulat ng EACH_QUORUM, para sa pagbabasa - LOCAL_QUORUM
Maikling impresyon at konklusyon
Upang masuri ang nagresultang solusyon mula sa punto ng view ng suporta sa pagpapatakbo at mga prospect para sa karagdagang pag-unlad, nagpasya kaming mag-isip tungkol sa kung saan pa maaaring ilapat ang gayong pag-unlad.
Kaagad, pagkatapos ay ang pagmamarka ng data para sa mga programa tulad ng "Magbayad kapag ito ay maginhawa" (nag-load kami ng impormasyon sa C*, pagkalkula gamit ang mga script ng Spark), accounting para sa mga claim na may pinagsama-samang lugar, pag-iimbak ng mga tungkulin at pagkalkula ng mga karapatan sa pag-access ng user batay sa tungkulin matris.
Tulad ng nakikita mo, ang repertoire ay malawak at iba-iba. At kung pipiliin namin ang kampo ng mga tagasuporta/kalaban ng NoSQL, sasali kami sa mga tagasuporta, dahil natanggap namin ang aming mga pakinabang, at eksakto kung saan namin inaasahan.
Kahit na ang Cassandra na opsyon sa labas ng kahon ay nagbibigay-daan sa pahalang na pag-scale sa real time, ganap na walang sakit na paglutas sa isyu ng pagtaas ng data sa system. Nagawa naming ilipat ang isang napakataas na mekanismo ng pagkarga para sa pagkalkula ng mga pinagsama-samang tawag sa isang hiwalay na circuit, at paghiwalayin din ang schema at lohika ng aplikasyon, na inaalis ang masamang kasanayan sa pagsulat ng mga custom na trabaho at mga bagay sa mismong database. Nagkaroon kami ng pagkakataong pumili at mag-configure, para mapabilis, kung saang mga DC kami gagawa ng mga kalkulasyon at kung saan kami magtatala ng data, siniguro namin ang aming sarili laban sa mga pag-crash ng parehong mga indibidwal na node at ng DC sa kabuuan.
Ang paglalapat ng aming arkitektura sa mga bagong proyekto, at mayroon nang ilang karanasan, nais kong agad na isaalang-alang ang mga nuances na inilarawan sa itaas, at maiwasan ang ilang mga pagkakamali, pakinisin ang ilang matalim na sulok na hindi maiiwasan sa simula.
Halimbawa, subaybayan ang mga update ni Cassandra sa isang napapanahong paraandahil medyo marami na sa mga problemang natamo namin ay alam na at naayos na.
Huwag ilagay ang parehong database mismo at Spark sa parehong mga node (o mahigpit na hatiin sa dami ng pinahihintulutang paggamit ng mapagkukunan), dahil ang Spark ay maaaring kumain ng mas maraming OP kaysa sa inaasahan, at mabilis kaming makakakuha ng problema numero 1 mula sa aming listahan.
Pagbutihin ang pagsubaybay at kakayahan sa pagpapatakbo sa yugto ng pagsubok ng proyekto. Sa una, isaalang-alang hangga't maaari ang lahat ng potensyal na mamimili ng aming solusyon, dahil dito sa huli ay aasa ang istraktura ng database.
I-rotate ang resultang circuit ng ilang beses para sa posibleng pag-optimize. Piliin kung aling mga field ang maaaring i-serialize. Unawain kung anong mga karagdagang talahanayan ang dapat naming gawin upang maisaalang-alang nang tama at pinakamainam, at pagkatapos ay ibigay ang kinakailangang impormasyon kapag hiniling (halimbawa, sa pag-aakalang maaari naming iimbak ang parehong data sa iba't ibang mga talahanayan, na isinasaalang-alang ang iba't ibang mga breakdown ayon sa iba't ibang pamantayan, maaari kaming makatipid ng makabuluhang oras ng CPU para sa mga kahilingan sa pagbasa).
Karaniwan Kaagad na magbigay para sa paglakip ng TTL at paglilinis ng hindi napapanahong data.
Kapag nagda-download ng data mula kay Cassandra Ang logic ng application ay dapat gumana sa prinsipyo ng FETCH, upang hindi lahat ng mga hilera ay na-load sa memorya nang sabay-sabay, ngunit pinili sa mga batch.
Maipapayo bago ilipat ang proyekto sa inilarawang solusyon suriin ang fault tolerance ng system sa pamamagitan ng pagsasagawa ng serye ng mga pagsubok sa pag-crash, tulad ng pagkawala ng data sa isang data center, pagpapanumbalik ng nasirang data sa isang tiyak na panahon, pag-dropout ng network sa pagitan ng mga data center. Ang ganitong mga pagsubok ay hindi lamang magpapahintulot sa isa na suriin ang mga kalamangan at kahinaan ng iminungkahing arkitektura, ngunit magbibigay din ng mahusay na pagsasanay sa pag-init para sa mga inhinyero na nagsasagawa ng mga ito, at ang nakuha na kasanayan ay malayo sa kalabisan kung ang mga pagkabigo ng system ay muling ginawa sa produksyon.
Kung nagtatrabaho kami sa kritikal na impormasyon (tulad ng data para sa pagsingil, pagkalkula ng utang ng subscriber), dapat ding bigyang pansin ang mga tool na magbabawas sa mga panganib na dulot ng mga tampok ng DBMS. Halimbawa, gamitin ang nodesync utility (Datastax), na nakabuo ng pinakamainam na diskarte para sa paggamit nito sa pagkakasunud-sunod para sa pagkakapare-pareho, huwag gumawa ng labis na pagkarga kay Cassandra at gamitin lamang ito para sa ilang mga talahanayan sa isang tiyak na panahon.
Ano ang mangyayari kay Cassandra pagkatapos ng anim na buwan ng buhay? Sa pangkalahatan, walang mga hindi nalutas na problema. Hindi rin namin pinahintulutan ang anumang malubhang aksidente o pagkawala ng data. Oo, kailangan naming mag-isip tungkol sa pagbabayad para sa ilang mga problema na hindi pa lumitaw dati, ngunit sa huli ay hindi ito lubos na nag-ulap sa aming solusyon sa arkitektura. Kung gusto mo at hindi natatakot na subukan ang isang bagong bagay, at sa parehong oras ay hindi nais na maging masyadong bigo, pagkatapos ay maghanda para sa katotohanan na walang libre. Kailangan mong maunawaan, suriin ang dokumentasyon at tipunin ang iyong sariling indibidwal na rake nang higit pa kaysa sa lumang legacy na solusyon, at walang teorya ang magsasabi sa iyo nang maaga kung aling rake ang naghihintay para sa iyo.
Pinagmulan: www.habr.com