Maranéhanana ngomong yén sagalana dina kahirupan sia coba sahenteuna sakali. Sareng upami anjeun biasa damel sareng DBMS relasional, maka anjeun kedah kenal sareng NoSQL dina prakték, mimitina, sahenteuna pikeun pangwangunan umum. Ayeuna, alatan ngembangkeun gancang tina téhnologi ieu, aya loba pamadegan conflicting jeung debat dipanaskeun dina topik ieu, utamana suluh dipikaresep.
Lamun delve kana hakekat sadaya sengketa ieu, anjeun bisa nempo yén maranéhna timbul alatan pendekatan salah. Jalma anu ngagunakeun database NoSQL persis dimana aranjeunna diperlukeun wareg jeung narima sagala kaunggulan tina solusi ieu. Sareng ékspérimén anu ngandelkeun téknologi ieu salaku panacea dimana éta henteu tiasa dianggo pisan kuciwa, kaleungitan kakuatan basis data hubungan tanpa kéngingkeun kauntungan anu signifikan.
Kuring bakal nyarioskeun ka anjeun ngeunaan pangalaman urang dina ngalaksanakeun solusi dumasar kana Cassandra DBMS: naon anu kedah urang hadapi, kumaha urang kaluar tina kaayaan susah, naha urang tiasa nyandak kauntungan tina ngagunakeun NoSQL sareng dimana urang kedah investasi usaha / dana tambahan. .
Tugas awal nyaéta ngawangun sistem anu ngarékam telepon dina sababaraha jinis panyimpenan.
Prinsip operasi sistem nyaéta kieu. Input kalebet file kalayan struktur khusus anu ngajelaskeun struktur telepon. aplikasi nu lajeng ensures yén struktur ieu disimpen dina kolom luyu. Ka hareupna, telepon anu disimpen dianggo pikeun nunjukkeun inpormasi ngeunaan konsumsi lalu lintas pikeun palanggan (biaya, telepon, sajarah kasaimbangan).
Ieu rada jelas naha maranéhna milih Cassandra - manéhna nulis kawas gun mesin, gampang scalable, sarta lepat-toleran.
Janten, ieu pangalaman anu masihan kami
Leres, titik anu gagal sanés tragedi. Ieu hakekat toleransi kasalahan Cassandra urang. Tapi titik hiji bisa hirup tur dina waktos anu sareng ngawitan sangsara dina kinerja. Salaku tétéla, ieu langsung mangaruhan kinerja sakabéh klaster.
Cassandra moal ngajaga anjeun dimana Oracle nyalametkeun anjeun kalayan konstrain na. Sareng upami panulis aplikasi éta henteu ngartos sateuacanna, maka dobel anu sumping ka Cassandra henteu langkung parah tibatan anu asli. Sakali éta sumping, kami bakal nempatkeun éta.
IB teu resep pisan kana Cassandra gratis tina kotak: Henteu aya logging tindakan pangguna, henteu aya diferensiasi hak. Inpormasi ngeunaan telepon dianggap data pribadi, anu hartosna yén sadaya usaha pikeun nyuhunkeun / ngarobih ku cara naon waé kedah log in sareng kamungkinan pamariksaan salajengna. Ogé, anjeun kedah sadar kana kabutuhan pikeun misahkeun hak dina tingkat anu béda pikeun pangguna anu béda. Insinyur operasi saderhana sareng admin super anu tiasa ngahapus sadayana rohangan konci sacara bébas nyaéta peran anu béda, tanggung jawab anu béda, sareng kompetensi. Tanpa diferensiasi hak aksés sapertos kitu, nilai sareng integritas data bakal langsung ditaroskeun langkung gancang tibatan tingkat konsistensi ANY.
Kami henteu nganggap yén telepon butuh analitik serius sareng sampling périodik pikeun sababaraha kaayaan. Kusabab rékaman nu dipilih lajeng sakuduna dituju dihapus sarta ditulis deui (salaku bagian tina tugas, urang kudu ngarojong prosés ngamutahirkeun data lamun data mimitina diasupkeun loop urang salah), Cassandra teu sobat urang dieu. Cassandra sapertos celengan - éta gampang pikeun nempatkeun barang-barang, tapi anjeun henteu tiasa ngitung.
Kami ngalaman masalah nransferkeun data ka zona uji (5 titik dina tés versus 20 dina prom). Dina hal ieu, dump teu bisa dipaké.
Masalah sareng ngamutahirkeun schema data hiji aplikasi nulis ka Cassandra. A rollback bakal ngahasilkeun loba pisan tombstones, nu bisa ngakibatkeun leungitna produktivitas dina cara unpredictable.. Cassandra dioptimalkeun pikeun ngarékam, sareng henteu mikir pisan sateuacan nyerat. Sakur operasi anu aya data anu aya di jerona ogé ngarékam. Nyaéta, ku ngahapus anu teu perlu, urang ngan saukur bakal ngahasilkeun langkung seueur rékaman, sareng ngan ukur sababaraha di antarana bakal ditandaan ku batu nisan.
Timeouts nalika inserting. Cassandra geulis di rekaman, tapi kadang aliran asup nyata bisa puzzles dirina. Ieu lumangsung nalika aplikasi mimiti siklus sabudeureun sababaraha rékaman nu teu bisa diselapkeun pikeun sababaraha alesan. Sarta kami bakal butuh DBA nyata anu bakal ngawas gc.log, Sistim na debug log pikeun queries slow, metrics on compaction pending.
Sababaraha puseur data dina klaster. Ti mana maca sareng dimana nyerat?
Sugan dibagi kana maca jeung nulis? Sareng upami kitu, kedah aya DC anu langkung caket kana aplikasi pikeun nyerat atanapi maca? Sarta urang moal mungkas nepi ka otak pamisah nyata lamun urang milih tingkat konsistensi salah? Aya seueur patarosan, seueur setélan anu teu dipikanyaho, kamungkinan anu anjeun hoyong terangkeun.
Kumaha urang mutuskeun
Pikeun nyegah titik tilelep, SWAP ditumpurkeun. Sareng ayeuna, upami aya kakurangan mémori, titik kedah turun sareng henteu nyiptakeun jeda gc anu ageung.
Janten, urang henteu deui ngandelkeun logika dina pangkalan data. Pamekar aplikasi ngalatih deui diri sareng mimiti aktip nyandak pancegahan dina kode sorangan. Idéal separation jelas gudang data jeung ngolah.
Urang dibeuli rojongan ti DataStax. Pangembangan Cassandra kotak parantos lirén (komitmen terakhir nyaéta dina bulan Pebruari 2018). Dina waktos anu sami, Datastax nawiskeun jasa anu saé sareng sajumlah ageung solusi anu dirobih sareng diadaptasi pikeun solusi IP anu tos aya.
Kuring ogé hoyong dicatet yén Cassandra teu pisan merenah pikeun queries Pilihan. Tangtosna, CQL mangrupikeun léngkah anu ageung pikeun pangguna (dibandingkeun sareng Trift). Tapi lamun boga sakabéh departemén anu biasa ngagabung merenah sapertos, bebas nyaring ku widang naon waé jeung kamampuhan optimasi query, sarta departemén ieu digawé pikeun ngabéréskeun keluhan jeung kacilakaan, lajeng solusi on Cassandra sigana mumusuhan jeung bodo ka aranjeunna. Sareng urang mimiti mutuskeun kumaha kolega urang kedah ngadamel conto.
Urang tempo dua pilihan.Dina pilihan kahiji, urang nulis nelepon teu ngan dina C*, tapi ogé dina database Oracle diarsipkeun. Ngan, teu saperti C*, database ieu nyimpen telepon ngan keur bulan ayeuna (jero gudang telepon cukup keur recharging kasus). Di dieu urang langsung ningali masalah di handap ieu: lamun urang nulis sinkron, mangka urang leungit sagala kaunggulan C * pakait sareng panempatan gancang; lamun urang nulis asynchronously, teu aya jaminan yén sakabéh sauran perlu asup ka Oracle. Aya hiji tambah, tapi hiji badag: pikeun operasi sarua akrab PL / SQL Pamekar tetep, nyaéta urang praktis nerapkeun pola "Facade". Pilihan alternatif. Urang nerapkeun mékanisme nu unloads nelepon ti C *, narik sababaraha data pikeun pengayaan ti tabel pakait dina Oracle, ngagabung sampel hasilna tur masihan kami hasilna, nu lajeng kami kumaha bae nganggo (gulung deui, ulang, nganalisis, admire). Kontra: prosésna cukup multi-hambalan, sareng salian ti éta, henteu aya antarmuka pikeun pagawé operasi.
Tungtungna, urang netep dina pilihan kadua. Apache Spark dipaké pikeun sampel tina kendi béda. Hakekat mékanisme geus diréduksi jadi kode Java, nu, ngagunakeun konci dieusian (palanggan, waktu panggero - konci bagian), narik kaluar data ti C *, kitu ogé data diperlukeun pikeun pengayaan ti sagala database séjén. Sanggeus éta ngagabung aranjeunna dina mémori sarta mintonkeun hasil dina tabel hasilna. Kami ngagambar raray wéb dina narik sareng tétéla tiasa dianggo.
Nalika ngarengsekeun masalah ngamutahirkeun data uji industri, urang deui mertimbangkeun sababaraha solusi. Duanana mindahkeun via Sstloader sarta pilihan tina bengkahna klaster dina zona test kana dua bagian, nu masing-masing ganti milik klaster sarua jeung hiji promosi, sahingga keur Powered by eta. Nalika ngamutahirkeun tés, éta direncanakeun pikeun swap aranjeunna: bagian anu digarap dina tés diberesihan tur diasupkeun kana produksi, sarta séjén dimimitian pikeun digawe sareng data nyalira. Sanajan kitu, sanggeus mikir deui, urang leuwih rationally ditaksir data anu patut mindahkeun, sarta sadar yén panggero sorangan mangrupa éntitas inconsistent pikeun tés, gancang dihasilkeun lamun perlu, sarta eta teh promosi set data nu teu boga nilai pikeun mindahkeun ka nguji. Aya sababaraha objék panyimpen anu pantes dipindah, tapi ieu sacara harfiah mangrupikeun sababaraha méja, sareng henteu beurat pisan. Ku kituna urang salaku solusi, Spark deui sumping ka nyalametkeun teh, kalayan bantuan nu urang nulis sarta mimiti aktip ngagunakeun Aksara pikeun mindahkeun data antara tabel, prom-test.
Kabijakan panyebaran kami ayeuna ngamungkinkeun urang damel tanpa mundur. Sateuacan promo, aya uji coba wajib, dimana kasalahan henteu mahal. Dina hal gagal, anjeun salawasna bisa leupaskeun casespace jeung gulung sakabéh skéma ti mimiti.
Pikeun mastikeun kasadiaan kontinyu tina Cassandra, anjeun peryogi dba teu ngan anjeunna. Saha waé anu damel sareng aplikasina kedah ngartos dimana sareng kumaha ningali kaayaan ayeuna sareng kumaha ngadiagnosa masalah dina waktosna. Jang ngalampahkeun ieu, kami aktip ngagunakeun DataStax OpsCenter (Administrasi sarta ngawas workloads), metrics sistem Supir Cassandra (Jumlah timeouts pikeun nulis ka C *, jumlah timeouts pikeun maca tina C *, latency maksimum, jsb), monitor operasi. tina aplikasi sorangan, gawé bareng Cassandra.
Nalika urang mikirkeun patarosan sateuacana, urang sadar dimana résiko utama urang tiasa bohong. Ieu mangrupikeun bentuk tampilan data anu nampilkeun data tina sababaraha patarosan mandiri ka panyimpenan. Ku cara ieu urang tiasa nampi inpormasi anu teu konsisten. Tapi masalah ieu bakal jadi sagampil relevan lamun urang digawé kalayan ngan hiji puseur data. Janten hal anu paling lumrah di dieu nyaéta, tangtosna, nyiptakeun fungsi batch pikeun maca data dina aplikasi pihak katilu, anu bakal mastikeun yén data ditampi dina hiji waktos. Sedengkeun pikeun division kana maca jeung nulis dina watesan kinerja, didieu urang dieureunkeun ku resiko nu mibanda sababaraha leungitna sambungan antara DCs, urang bisa mungkas nepi ka dua klaster anu sagemblengna inconsistent saling.
Hasilna, pikeun ayeuna dieureunkeun dina tingkat konsistensi pikeun nulis EACH_QUORUM, pikeun bacaan - LOCAL_QUORUM
kesan ringkes jeung conclusions
Pikeun meunteun solusi anu dihasilkeun tina sudut pandang pangrojong operasional sareng prospek pikeun pangwangunan salajengna, kami mutuskeun pikeun mikirkeun dimana waé pamekaran sapertos kitu tiasa diterapkeun.
Langsung kaluar bat, lajeng data nyetak pikeun program kawas "Bayar lamun éta merenah" (urang muka informasi kana C *, itungan ngagunakeun Aksara Spark), akuntansi pikeun klaim kalawan aggregation dumasar wewengkon, nyimpen kalungguhan jeung ngitung hak aksés pamaké dumasar kana peran. matriks.
Sakumaha anjeun tiasa tingali, repertoire lega sareng rupa-rupa. Sareng upami urang milih kubu pendukung / lawan NoSQL, maka urang bakal gabung sareng pendukung, sabab kami nampi kauntungan, sareng persis dimana kami ngarepkeun.
Malah pilihan Cassandra out of the box ngamungkinkeun skala horisontal sacara real waktos, leres pisan henteu aya rasa nyeri pikeun ngarengsekeun masalah paningkatan data dina sistem. Urang éta bisa mindahkeun mékanisme pisan tinggi-beban keur ngitung aggregates panggero kana sirkuit misah, sarta ogé misahkeun schema aplikasi jeung logika, meunang leupas tina praktek goréng nulis jobs custom jeung objék dina database sorangan. Kami ngagaduhan kasempetan pikeun milih sareng ngonpigurasikeun, pikeun nyepetkeun, mana DC anu bakal kami laksanakeun sareng mana anu bakal kami ngarékam data, kami ngajamin diri ngalawan kacilakaan tina titik individu sareng DC sacara gembleng.
Nerapkeun arsitéktur kami pikeun proyék-proyék anyar, sareng parantos gaduh sababaraha pangalaman, kuring hoyong langsung tumut kana nuansa anu dijelaskeun di luhur, sareng nyegah sababaraha kasalahan, ngaleungitkeun sababaraha sudut anu seukeut anu henteu tiasa dihindari mimitina.
Contona, ngalacak apdet Cassandra dina waktosnasabab rada sababaraha masalah anu kami ngagaduhan parantos terang sareng dibereskeun.
Entong nempatkeun database sorangan sareng Spark dina titik anu sami (atawa mastikeun ngabagi jumlah pamakéan sumberdaya allowable), saprak Spark bisa dahar leuwih OP ti ekspektasi, sarta kami bakal gancang meunang masalah nomer 1 tina daptar kami.
Ningkatkeun ngawaskeun sareng kompeténsi operasional dina tahap tés proyék. Mimitina, perhatikeun saloba mungkin sadaya konsumén poténsial solusi kami, sabab ieu téh naon struktur database pamustunganana bakal gumantung kana.
Rotasikeun sirkuit anu dihasilkeun sababaraha kali pikeun optimasi mungkin. Pilih widang mana nu bisa serialized. Ngartos naon tabel tambahan urang kudu nyieun guna paling bener tur optimal tumut kana akun, lajeng nyadiakeun informasi diperlukeun kana pamundut (contona, ku asumsina yén urang bisa nyimpen data anu sarua dina tabel béda, nyokot kana akun breakdowns béda nurutkeun kana kriteria béda, urang tiasa ngahemat waktos CPU nyata pikeun requests dibaca).
lumayan Langsung nyadiakeun keur ngalampirkeun TTL jeung meresihan data luntur.
Nalika ngundeur data ti Cassandra Logika aplikasi kedah dianggo dina prinsip FETCH, supados henteu sadayana baris dimuat kana mémori sakaligus, tapi dipilih dina bets.
Disarankeun sateuacan mindahkeun proyék kana solusi anu dijelaskeun pariksa toleransi lepat sistem urang ku ngalakonan runtuyan tés kacilakaan, kayaning leungitna data dina hiji puseur data, restorasi data ruksak dina jangka waktu nu tangtu, jaringan dropout antara puseur data. Tés sapertos kitu henteu ngan ukur tiasa ngira-ngira pro sareng kontra ngeunaan arsitéktur anu diusulkeun, tapi ogé bakal nyayogikeun prakték pemanasan anu hadé pikeun insinyur anu ngalaksanakeunana, sareng kaahlian anu kaala bakal tebih tina kaleuleuwihan upami gagal sistem diproduksi dina produksi.
Upami urang damel sareng inpormasi kritis (sapertos data pikeun tagihan, itungan hutang palanggan), maka éta ogé patut nengetan alat anu bakal ngirangan résiko anu timbul kusabab fitur DBMS. Contona, make utilitas nodesync (Datastax), sanggeus ngembangkeun hiji strategi optimal pikeun pamakéan dina urutan demi konsistensi, ulah nyieun hiji beban kaleuleuwihan on Cassandra tur ngagunakeun eta ngan pikeun tabel tangtu dina jangka waktu nu tangtu.
Naon kajadian ka Cassandra sanggeus genep bulan hirup? Sacara umum, euweuh masalah unresolved. Kami ogé henteu ngijinkeun kacilakaan serius atanapi leungitna data. Leres, urang kedah mikirkeun pikeun ngimbangan sababaraha masalah anu saacanna henteu timbul, tapi dina tungtungna ieu henteu ngaganggu solusi arsitéktur urang. Upami anjeun hoyong sareng henteu sieun nyobian anu énggal, sareng dina waktos anu sami henteu hoyong kuciwa teuing, teras siap-siap pikeun kanyataan yén teu aya anu gratis. Anjeun bakal kedah ngartos, delve kana dokuméntasi jeung ngumpul rake individu sorangan leuwih ti dina leyuran warisan heubeul, tur euweuh téori bakal ngabejaan Anjeun sateuacanna nu rake ngantosan anjeun.
sumber: www.habr.com