Padha ngomong yen kabeh ing urip iku worth nyoba ing paling sapisan. Lan yen sampeyan wis biasa nggarap DBMS relasional, mula sampeyan kudu kenal karo NoSQL ing praktik, pisanan kabeh, paling ora kanggo pangembangan umum. Saiki, amarga perkembangan teknologi iki kanthi cepet, ana akeh panemu sing bertentangan lan debat panas babagan topik iki, sing utamane narik minat.
Yen sampeyan nyelidiki inti saka kabeh perselisihan kasebut, sampeyan bisa ndeleng manawa kedadeyan kasebut amarga pendekatan sing salah. Wong-wong sing nggunakake database NoSQL persis ing ngendi sing dibutuhake, wareg lan nampa kabeh kaluwihan saka solusi iki. Lan eksperimen sing ngandelake teknologi iki minangka panacea sing ora bisa ditrapake, kuciwa, amarga ilang kekuwatan database hubungan tanpa entuk keuntungan sing signifikan.
Aku bakal pitutur marang kowe bab pengalaman kita ngleksanakake solusi adhedhasar Cassandra DBMS: apa kita kudu ngadhepi, carane kita metu saka kahanan angel, apa kita bisa entuk manfaat saka nggunakake NoSQL lan ngendi kita kudu nandur modal tambahan efforts / dana. .
Tugas wiwitan yaiku mbangun sistem sing ngrekam panggilan ing sawetara jinis panyimpenan.
Prinsip operasi sistem kasebut kaya ing ngisor iki. Input kalebu file kanthi struktur tartamtu sing nggambarake struktur telpon. Aplikasi kasebut banjur mesthekake yen struktur iki disimpen ing kolom sing cocog. Ing mangsa ngarep, telpon sing disimpen digunakake kanggo nampilake informasi babagan konsumsi lalu lintas kanggo pelanggan (biaya, telpon, riwayat imbangan).
Cetha banget kenapa dheweke milih Cassandra - dheweke nulis kaya senapan mesin, gampang diukur, lan tahan kesalahan.
Dadi, iki pengalaman sing diwenehake marang kita
Ya, simpul sing gagal dudu tragedi. Iki minangka inti saka toleransi kesalahan Cassandra. Nanging simpul bisa urip lan ing wektu sing padha wiwit nandhang sangsara ing kinerja. Ternyata, iki langsung mengaruhi kinerja kabeh kluster.
Cassandra ora bakal nglindhungi sampeyan ing ngendi Oracle nylametake sampeyan kanthi kendala. Lan yen penulis aplikasi ora ngerti iki ing advance, banjur dobel sing teka kanggo Cassandra ora Samsaya Awon saka asline. Sawise teka, kita bakal nyelehake.
IB ora seneng karo Cassandra gratis sing metu saka kothak: Ora ana logging tumindak pangguna, ora ana diferensiasi hak. Informasi babagan telpon dianggep minangka data pribadhi, tegese kabeh upaya kanggo njaluk / ngganti kanthi cara apa wae kudu dicathet kanthi kemungkinan audit sabanjure. Uga, sampeyan kudu ngerti kabutuhan kanggo misahake hak ing tingkat sing beda kanggo pangguna sing beda. Insinyur operasi sing prasaja lan admin super sing bisa mbusak kabeh spasi tombol kanthi bebas minangka peran, tanggung jawab, lan kompetensi sing beda. Tanpa diferensiasi hak akses kasebut, nilai lan integritas data bakal langsung ditakoni luwih cepet tinimbang tingkat konsistensi ANY.
Kita ora nganggep manawa telpon mbutuhake analytics serius lan sampling periodik kanggo macem-macem kahanan. Wiwit cathetan sing dipilih banjur kudu dibusak lan ditulis maneh (minangka bagéan saka tugas, kita kudu ndhukung proses nganyari data nalika data pisanan salah ngetik loop kita), Cassandra ora kanca kita kene. Cassandra kaya celengan - trep kanggo nyelehake barang, nanging sampeyan ora bisa ngetung.
Kita nemoni masalah nransfer data menyang zona tes (5 simpul ing test versus 20 ing prom). Ing kasus iki, dump ora bisa digunakake.
Masalah karo nganyari skema data saka aplikasi nulis kanggo Cassandra. Rollback bakal ngasilake akeh nisan, sing bisa nyebabake kerugian produktivitas kanthi cara sing ora bisa ditebak.. Cassandra dioptimalake kanggo ngrekam, lan ora mikir akeh sadurunge nulis. Operasi apa wae kanthi data sing ana ing kono uga minangka rekaman. Yaiku, kanthi mbusak sing ora perlu, kita mung bakal ngasilake luwih akeh cathetan, lan mung sawetara sing bakal ditandhani karo nisan.
Wektu entek nalika nglebokake. Cassandra ayu ing rekaman, nanging kadhangkala aliran mlebu bisa Ngartekno puzzle dheweke. Iki kedadeyan nalika aplikasi wiwit muter sawetara cathetan sing ora bisa dilebokake kanthi alesan. Lan kita butuh DBA nyata sing bakal ngawasi gc.log, log sistem lan debug kanggo pitakon alon, metrik babagan pemadatan sing ditundha.
Sawetara pusat data ing kluster. Saka ngendi maca lan nulis saka ngendi?
Mbok dipérang dadi maca lan nulis? Lan yen mangkono, kudu ana DC sing luwih cedhak karo aplikasi kanggo nulis utawa maca? Lan kita ora bakal mungkasi munggah karo otak pamisah nyata yen kita milih tingkat konsistensi salah? Ana akeh pitakonan, akeh setelan sing ora dingerteni, kemungkinan sing pancene pengin tinker.
Carane kita mutusaké
Kanggo nyegah simpul saka sink, SWAP dipateni. Lan saiki, yen ana kekurangan memori, simpul kudu mudhun lan ora nggawe jeda gc gedhe.
Dadi, kita ora ngandelake logika maneh ing basis data. Pangembang aplikasi lagi latihan maneh lan wiwit aktif ngati-ati ing kode dhewe. Pemisahan sing jelas saka panyimpenan lan pangolahan data.
Kita tuku dhukungan saka DataStax. Pangembangan Cassandra kothak wis mandheg (komit pungkasan yaiku ing Februari 2018). Ing wektu sing padha, Datastax nawakake layanan sing apik lan akeh solusi sing diowahi lan diadaptasi kanggo solusi IP sing wis ana.
Aku uga pengin Wigati sing Cassandra ora trep banget kanggo pitakonan pilihan. Mesthine, CQL minangka langkah gedhe kanggo pangguna (dibandhingake karo Trift). Nanging yen sampeyan duwe kabeh departemen sing wis rakulino kanggo gabung trep kuwi, free nyaring dening sembarang lapangan lan kapabilitas Optimization pitakonan, lan departemen iki digunakake kanggo mutusake masalah keluhan lan kacilakan, banjur solusi Cassandra katon musuhan lan bodho kanggo wong-wong mau. Lan kita wiwit mutusake kepiye kolega kudu nggawe conto.
Kita nimbang opsi loro. Ing pilihan pisanan, kita nulis telpon ora mung ing C *, nanging uga ing database Oracle arsip. Mung, ora kaya C*, database iki nyimpen telpon mung kanggo sasi saiki (ambane panyimpenan telpon cekap kanggo kasus ngisi daya). Ing kene kita langsung weruh masalah ing ngisor iki: yen kita nulis kanthi selaras, mula kita bakal kelangan kabeh kaluwihan C * sing digandhengake karo sisipan cepet; yen kita nulis kanthi ora sinkron, ora ana jaminan manawa kabeh panggilan sing dibutuhake mlebu ing Oracle. Ana siji plus, nanging sing gedhe: kanggo operasi sing padha karo PL / SQL Developer tetep, yaiku kita prakteke ngetrapake pola "Fasad". Pilihan alternatif. We ngleksanakake mekanisme sing unloads telpon saka C *, narik sawetara data kanggo pengayaan saka tabel sing cocog ing Oracle, nggabungake conto asil lan menehi kita asil, kang kita banjur nggunakake (muter maneh, mbaleni, njelasno, ngujo). Cons: proses cukup multi-langkah, lan ing Kajaba iku, ora ana antarmuka kanggo karyawan operasi.
Pungkasane, kita mutusake ing pilihan kapindho. Apache Spark digunakake kanggo sampel saka macem-macem kendi. Inti saka mekanisme wis suda kanggo kode Jawa, kang nggunakake tombol kasebut (langganan, wektu telpon - tombol bagean), narik metu data saka C *, uga data perlu kanggo pengayaan saka database liyane. Sawise iku gabung ing memori lan nampilake asil ing tabel asil. Kita nggambar pasuryan web liwat spark lan ternyata cukup migunani.
Nalika ngrampungake masalah nganyari data tes industri, kita maneh nimbang sawetara solusi. Loro-lorone transfer liwat Sstloader lan pilihan saka pamisah kluster ing zona test dadi rong bagéan, saben kang gantian belongs kanggo kluster padha karo siji promosi, mangkono kang powered by. Nalika nganyari tes kasebut, direncanakake kanggo ngganti: bagean sing makarya ing tes kasebut dibuwang lan dilebokake ing produksi, lan sing liyane wiwit nggarap data kanthi kapisah. Nanging, sawise mikir maneh, kita luwih rationally kabiji data sing worth nransfer, lan temen maujud sing telpon piyambak entitas inconsistent kanggo tes, cepet kui yen perlu, lan iku pesawat data promosi sing ora duwe nilai kanggo transfer menyang tes. Ana sawetara obyek panyimpenan sing worth obah, nanging iki secara harfiah saperangan tabel, lan ora abot banget. Mulane kita minangka solusi, Spark maneh teka kanggo ngluwari, karo bantuan saka kang kita wrote lan wiwit aktif nggunakake script kanggo nransfer data antarane tabel, prom-test.
Kabijakan penyebaran saiki ngidini kita bisa kerja tanpa mundur. Sadurunge promo, ana test run wajib, sing kesalahan ora larang. Yen gagal, sampeyan bisa tansah nyelehake casespace lan muter kabeh skema saka wiwitan.
Kanggo mesthekake kasedhiyan terus Cassandra, sampeyan kudu dba lan ora mung wong. Saben uwong sing nggarap aplikasi kasebut kudu ngerti ngendi lan carane ndeleng kahanan saiki lan carane diagnosa masalah ing wektu sing tepat. Kanggo nindakake iki, kita aktif nggunakake DataStax OpsCenter (Administrasi lan ngawasi beban kerja), metrik sistem Cassandra Driver (jumlah wektu entek kanggo nulis menyang C *, jumlah wektu entek kanggo maca saka C *, latensi maksimum, lan sapiturute), ngawasi operasi. saka aplikasi dhewe, nggarap Cassandra.
Nalika kita mikir babagan pitakonan sadurunge, kita ngerti endi risiko utama kita bisa uga ana. Iki minangka formulir tampilan data sing nampilake data saka sawetara pitakon independen menyang panyimpenan. Kanthi cara iki, kita bisa entuk informasi sing ora konsisten. Nanging masalah iki bakal cocog yen kita mung nggarap siji pusat data. Dadi, sing paling masuk akal ing kene, mesthi, nggawe fungsi batch kanggo maca data ing aplikasi pihak katelu, sing bakal mesthekake yen data ditampa ing wektu siji. Minangka kanggo divisi menyang maca lan nulis ing syarat-syarat kinerja, kene kita padha mandegake dening resiko sing karo sawetara mundhut saka sambungan antarane DCs, kita bisa mungkasi munggah karo rong klompok sing rampung inconsistent karo saben liyane.
Akibaté, kanggo saiki mandheg ing tingkat konsistensi kanggo nulis EACH_QUORUM, kanggo maca - LOCAL_QUORUM
Kesan singkat lan kesimpulan
Kanggo ngevaluasi solusi sing diasilake saka sudut pandang dhukungan operasional lan prospek kanggo pangembangan luwih lanjut, kita mutusake kanggo mikir babagan ing ngendi pangembangan kasebut bisa ditrapake.
Langsung saka bat, banjur data ngetung kanggo program kaya "Mbayar nalika iku trep" (kita mbukak informasi menyang C *, pitungan nggunakake Spark script), accounting kanggo claims karo agregasi dening wilayah, nyimpen peran lan ngitung hak akses pangguna adhedhasar peran. matriks.
Nalika sampeyan bisa ndeleng, repertoar amba lan mawarni-warni. Lan yen kita milih kamp panyengkuyung / mungsuh saka NoSQL, banjur kita bakal gabung panyengkuyung, amarga kita nampa kaluwihan kita, lan persis ing ngendi kita ngarepake.
Malah pilihan Cassandra metu saka kothak ngidini scaling horisontal ing wektu nyata, pancen painlessly mecahaken masalah nambah data ing sistem. Kita bisa mindhah mekanisme dhuwur banget kanggo ngetung agregat telpon menyang sirkuit sing kapisah, lan uga misahake skema lan logika aplikasi, nyingkirake praktik ala nulis proyek lan obyek khusus ing database dhewe. We entuk kesempatan kanggo milih lan ngatur, kanggo nyepetake, kang DCs kita bakal nindakake petungan lan kang gedhe-gedhe kita bakal ngrekam data ing, kita diasuransiake dhéwé marang kacilakan saka loro kelenjar individu lan DC minangka kabèh.
Nglamar arsitektur kita kanggo proyek anyar, lan wis duwe sawetara pengalaman, aku kaya kanggo langsung njupuk menyang akun nuansa ing ndhuwur, lan nyegah sawetara kesalahane, Gamelan metu sawetara sudhut cetha sing ora bisa nyingkiri pisanan.
Contone, nglacak nganyari Cassandra ing proses pas wektuneamarga sawetara masalah sing kita entuk wis dingerteni lan diatasi.
Aja sijine loro database dhewe lan Spark ing kelenjar padha (utawa strictly dibagi dening jumlah nggunakake sumber allowable), wiwit Spark bisa mangan OP luwih saka samesthine, lan kita bakal cepet njaluk masalah nomer 1 saka dhaftar kita.
Ningkatake ngawasi lan kompetensi operasional ing tahap uji coba proyek. Kaping pisanan, elinga kabeh konsumen potensial saka solusi kita, amarga iki struktur database pungkasane bakal gumantung.
Puter sirkuit asil kaping pirang-pirang kanggo optimasi bisa. Pilih kolom sing bisa serialized. Ngerti apa tabel tambahan sing kudu kita lakoni supaya bisa dianggep paling bener lan optimal, banjur menehi informasi sing dibutuhake nalika dijaluk (contone, kanthi nganggep manawa kita bisa nyimpen data sing padha ing tabel sing beda-beda, kanthi nganggep kerusakan sing beda-beda miturut kritéria beda, kita bisa nyimpen wektu CPU Ngartekno kanggo panjalukan diwaca).
Ora apik Langsung nyedhiyani kanggo masang TTL lan ngresiki data outdated.
Nalika ngundhuh data saka Cassandra Logika aplikasi kudu digunakake ing prinsip FETCH, supaya ora kabeh larik dimuat menyang memori bebarengan, nanging dipilih ing kumpulan.
Disaranake sadurunge nransfer proyek menyang solusi sing diterangake mriksa toleransi fault sistem dening nganakake seri saka tes kacilakan, kayata mundhut data ing siji pusat data, mulihake data sing rusak sajrone wektu tartamtu, putus jaringan ing antarane pusat data. Tes kasebut ora mung ngidini sampeyan ngevaluasi pro lan kontra arsitektur sing diusulake, nanging uga bakal nyedhiyakake praktik pemanasan sing apik kanggo para insinyur sing nindakake, lan katrampilan sing dipikolehi bakal adoh banget yen gagal sistem diprodhuksi ing produksi.
Yen kita nggarap informasi kritis (kayata data kanggo tagihan, pitungan utang pelanggan), iku uga worth mbayar manungsa waé kanggo piranti sing bakal ngurangi risiko njedhul amarga fitur saka DBMS. Contone, gunakake utilitas nodesync (Datastax), sing wis ngembangake strategi sing optimal kanggo panggunaane marga saka konsistensi, ora nggawe mbukak gedhe banget ing Cassandra lan nggunakake mung kanggo tabel tartamtu ing wektu tartamtu.
Apa kedaden kanggo Cassandra sawise nem sasi urip? Umumé, ora ana masalah sing ora ditanggulangi. Kita uga ora ngidini kacilakan serius utawa mundhut data. Ya, kita kudu mikir babagan menehi ganti rugi kanggo sawetara masalah sing durung nate kedadeyan, nanging ing pungkasan iki ora ngganggu solusi arsitektur kita. Yen sampeyan pengin lan ora wedi kanggo nyoba soko anyar, lan ing wektu sing padha ora pengin banget kuciwa, banjur siyap kanggo kasunyatan sing ora ana free. Sampeyan bakal kudu ngerti, delve menyang dokumentasi lan klumpukne rake individu dhewe luwih saka ing solusi warisan lawas, lan ora teori bakal pitutur marang kowe ing advance kang rake nunggu sampeyan.
Source: www.habr.com