Nepi ka ayeuna, Odnoklassniki nyimpen kira-kira 50 TB data anu diolah sacara real waktos dina SQL Server. Pikeun volume sapertos kitu, ampir teu mungkin pikeun nyayogikeun aksés anu gancang sareng dipercaya, sareng bahkan pusat data aksés toleran gagalna nganggo SQL DBMS. Biasana, dina kasus sapertos kitu, salah sahiji panyimpen NoSQL dianggo, tapi henteu sadayana tiasa ditransfer ka NoSQL: sababaraha éntitas ngabutuhkeun jaminan transaksi ACID.
Ieu ngakibatkeun urang kana pamakéan gudang NewSQL, nyaeta, a DBMS nu nyadiakeun toleransi sesar, scalability jeung kinerja sistem NoSQL, tapi dina waktos anu sareng ngajaga ACID jaminan akrab jeung sistem klasik. Aya sababaraha sistem industri anu tiasa dianggo tina kelas anyar ieu, janten kami ngalaksanakeun sistem sapertos kitu nyalira sareng nempatkeun kana operasi komérsial.
Kumaha gawéna sarta naon anu lumangsung - baca handapeun cut.
Kiwari, panongton bulanan Odnoklassniki langkung ti 70 juta sémah unik. Urang jaringan sosial pangbadagna di dunya, sarta diantara dua puluh situs nu pamaké méakkeun paling waktos. Infrastruktur OK nanganan beban anu luhur pisan: langkung ti sajuta pamundut HTTP / detik per payun. Bagian tina armada server langkung ti 8000 lembar lokasina caket - dina opat pusat data Moscow, anu ngamungkinkeun latency jaringan kirang ti 1 md diantara aranjeunna.
Kami parantos nganggo Cassandra ti 2010, dimimitian ku versi 0.6. Dinten aya sababaraha belasan klaster beroperasi. Kluster panggancangna ngolah langkung ti 4 juta operasi per detik, sareng toko panggedéna 260 TB.
Nanging, ieu sadayana klaster NoSQL biasa dianggo pikeun neundeun data. Urang hayang ngaganti gudang konsisten utama, Microsoft SQL Server, nu geus dipaké saprak ngadegna Odnoklassniki. Panyimpenan diwangun ku langkung ti 300 mesin SQL Server Standard Edition, anu ngandung 50 TB data - éntitas bisnis. Data ieu dirobah salaku bagian tina transaksi ACID sarta merlukeun .
Pikeun ngadistribusikaeun data ka sakuliah titik SQL Server, kami dipaké duanana vertikal sarta horizontal (sharding). Dina sajarahna, urang ngagunakeun skéma sharding data basajan: unggal éntitas ieu pakait sareng token - fungsi tina ID éntitas. Éntitas sareng token anu sami disimpen dina server SQL anu sami. Hubungan master-detail dilaksanakeun supados token tina rékaman utama sareng anak salawasna cocog sareng ayana dina server anu sami. Dina jaringan sosial, ampir kabéh rékaman dihasilkeun atas nama pamaké - nu hartina sakabéh data pamaké dina hiji subsistem fungsi disimpen dina hiji server. Nyaéta, transaksi bisnis ampir sok ngalibetkeun tabel tina hiji server SQL, anu ngamungkinkeun pikeun mastikeun konsistensi data nganggo transaksi ACID lokal, tanpa kedah dianggo. transaksi ACID disebarkeun.
Hatur nuhun kana sharding sareng nyepetkeun SQL:
- Kami henteu nganggo konstrain konci Asing, sabab nalika sharding ID éntitas tiasa aya dina server anu sanés.
- Kami henteu nganggo prosedur anu disimpen sareng pemicu kusabab beban tambahan dina CPU DBMS.
- Kami henteu nganggo JOINs kusabab sadayana di luhur sareng seueur bacaan acak tina disk.
- Di luar transaksi, kami nganggo tingkat isolasi Baca Uncommitted pikeun ngirangan jalan buntu.
- Urang ngalakukeun ukur transaksi pondok (rata-rata pondok ti 100 mdet).
- Kami henteu nganggo UPDATE sareng DELETE multi-baris kusabab jumlah deadlocks anu ageung - kami ngamutahirkeun ngan hiji catetan dina hiji waktos.
- Urang salawasna ngalakukeun queries ukur dina indéks - query kalawan rencana scan tabel pinuh pikeun urang hartina overloading database sarta ngabalukarkeun gagal.
Léngkah-léngkah ieu ngamungkinkeun urang pikeun nyepetkeun kinerja maksimal tina server SQL. Sanajan kitu, masalah jadi beuki loba. Hayu urang tingali aranjeunna.
Masalah sareng SQL
- Kusabab urang ngagunakeun sharding ditulis sorangan, nambahkeun shards anyar dipigawé sacara manual ku pangurus. Sadaya waktos ieu, réplika data anu tiasa skala henteu ngalayanan pamundut.
- Nalika jumlah rékaman dina tabél nambahan, laju sisipan sareng modifikasi turun; nalika nambihan indéks kana méja anu tos aya, laju turun ku hiji faktor; nyiptakeun sareng nyiptakeun ulang indéks lumangsung kalayan downtime.
- Ngabogaan jumlah leutik Windows pikeun SQL Server dina produksi ngajadikeun manajemén infrastruktur hésé
Tapi masalah utama nyaéta
toleransi kasalahan
Pangladén SQL klasik ngagaduhan kasabaran kasalahan anu goréng. Anggap anjeun ngan ukur gaduh hiji server database, sareng éta gagal sakali unggal tilu taun. Antukna situs ieu turun salila 20 menit, nu bisa ditarima. Upami anjeun gaduh 64 server, maka situsna turun sakali unggal tilu minggu. Sareng upami anjeun ngagaduhan 200 server, maka situs éta henteu tiasa dianggo unggal minggu. Ieu masalah.
Naon anu tiasa dilakukeun pikeun ningkatkeun kasabaran kasalahan tina server SQL? Wikipedia ngajak urang ngawangun : dimana bisi gagalna salah sahiji komponén aya cadangan.
Ieu ngabutuhkeun armada alat anu mahal: seueur duplikasi, serat optik, panyimpenan anu dibagi, sareng kalebet cagar henteu tiasa dipercaya: sakitar 10% switch ditungtungan ku gagalna titik cadangan sapertos karéta di tukangeun titik utama.
Tapi kalemahan utama tina klaster anu sayogi pisan nyaéta kasadiaan enol upami pusat data dimana lokasina gagal. Odnoklassniki ngagaduhan opat pusat data, sareng urang kedah mastikeun operasi upami aya gagal lengkep dina salah sahijina.
Pikeun ieu urang tiasa nganggo réplikasi diwangun kana SQL Server. Solusi ieu langkung mahal kusabab biaya parangkat lunak sareng ngalaman masalah anu terkenal sareng réplikasi - telat transaksi anu teu diprediksi sareng réplikasi sinkron sareng telat dina nerapkeun réplikasi (sareng, salaku hasilna, modifikasi leungit) sareng réplikasi asinkron. Nu tersirat ngajadikeun pilihan ieu sagemblengna inapplicable ka urang.
Sadaya masalah ieu peryogi solusi radikal, sareng urang mimiti nganalisis aranjeunna sacara rinci. Di dieu urang kudu meunang acquainted jeung naon SQL Server utamana teu - transaksi.
Transaksi basajan
Hayu urang nganggap transaksi pangbasajanna, ti sudut pandang hiji programmer SQL dilarapkeun: nambahkeun poto ka albeum. Albeum sareng poto disimpen dina piring anu béda. Albeum ngabogaan counter poto umum. Teras transaksi sapertos kitu dibagi kana léngkah-léngkah ieu:
- Urang ngonci albeum ku konci.
- Jieun entri dina tabel poto.
- Upami potona ngagaduhan status umum, teras tambahkeun konter poto umum kana albeum, ngapdet catetan sareng bunuh transaksi.
Atawa dina pseudocode:
TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);
if (photo.status == PUBLIC ) {
album.incPublicPhotosCount();
}
album.update();
TX.commit();Kami ningali yén skenario anu paling umum pikeun transaksi bisnis nyaéta maca data tina pangkalan data kana mémori pangladén aplikasi, ngarobih hiji hal sareng ngahémat nilai anyar deui kana pangkalan data. Biasana dina transaksi sapertos urang ngamutahirkeun sababaraha éntitas, sababaraha tabel.
Nalika ngalaksanakeun transaksi, modifikasi sakaligus tina data anu sami tina sistem anu sanés tiasa lumangsung. Contona, Antispam bisa mutuskeun yén pamaké téh kumaha bae curiga sahingga sakabeh poto pamaké kudu euweuh publik, maranéhanana kudu dikirim pikeun moderation, nu hartina ngarobah photo.status kana sababaraha nilai sejen tur mareuman counters pakait. Jelas, lamun operasi ieu lumangsung tanpa jaminan atomicity tina aplikasi jeung isolasi modifikasi competing, saperti dina , mangka hasilna moal jadi naon diperlukeun - boh counter poto bakal nembongkeun nilai salah, atawa teu sakabeh poto bakal dikirim pikeun moderation.
Seueur kode anu sami, ngamanipulasi rupa-rupa éntitas bisnis dina hiji transaksi, parantos diserat sapanjang sadaya ayana Odnoklassniki. Dumasar pangalaman migrasi ka NoSQL ti Urang terang yén tantangan pangbadagna (sareng investasi waktos) asalna tina ngamekarkeun kode pikeun ngajaga konsistensi data. Ku alatan éta, urang dianggap sarat utama pikeun neundeun anyar pikeun nyadiakeun keur transaksi ACID nyata pikeun logika aplikasi.
Sarat séjénna, teu kurang pentingna, nyaéta:
- Upami pusat data gagal, maca sareng nyerat kana panyimpenan énggal kedah sayogi.
- Ngajaga laju pangwangunan ayeuna. Nyaéta, nalika damel sareng gudang énggal, jumlah kode kedah sami-sami; teu kedah nambihan nanaon kana gudang, ngamekarkeun algoritma pikeun ngarengsekeun konflik, ngajaga indéks sekundér, jsb.
- Laju gudang anyar kedah rada luhur, boh nalika maca data sareng nalika ngolah transaksi, anu sacara efektif hartosna yén solusi akademik anu ketat, universal, tapi laun, sapertos, contona, henteu tiasa dianggo. .
- Skala otomatis on-the-fly.
- Ngagunakeun server mirah biasa, tanpa kudu meuli hardware aheng.
- Kamungkinan ngembangkeun gudang ku pamekar parusahaan. Dina basa sejen, prioritas dibikeun ka proprietary atanapi open source solusi, preferably di Java.
Kaputusan, kaputusan
Nganalisis solusi anu mungkin, kami dugi ka dua pilihan arsitéktur anu mungkin:
Kahiji nyaeta nyandak sagala server SQL sarta nerapkeun kasabaran sesar diperlukeun, mékanisme skala, failover klaster, resolusi konflik sarta disebarkeun, dipercaya jeung gancang transaksi ACID. Urang dipeunteun pilihan ieu pisan non-trivial jeung kuli-intensif.
Pilihan kadua nyaéta nyandak panyimpenan NoSQL anu siap-siap sareng skala anu dilaksanakeun, klaster failover, résolusi konflik, sareng ngalaksanakeun transaksi sareng SQL nyalira. Dina glance kahiji, sanajan tugas ngalaksanakeun SQL, teu nyebut transaksi ACID, Sigana mah tugas nu bakal nyandak taun. Tapi teras urang sadar yén set fitur SQL anu kami anggo dina praktékna jauh ti ANSI SQL tebih ti ANSI SQL. Ningali langkung caket kana CQL, urang sadar yén éta caket pisan sareng anu urang peryogikeun.
Cassandra jeung CQL
Janten, naon anu pikaresepeun ngeunaan Cassandra, naon kamampuanana?
Anu mimiti, di dieu anjeun tiasa nyiptakeun tabel anu ngadukung sababaraha jinis data; anjeun tiasa ngalakukeun PILIH atanapi UPDATE dina konci primér.
CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;Pikeun mastikeun konsistensi data replika, Cassandra ngagunakeun . Dina kasus pangbasajanna, ieu ngandung harti yén nalika tilu réplika baris anu sami disimpen dina titik anu béda tina kluster, nyeratna dianggap suksés upami seuseueurna titik (nyaéta, dua tina tilu) mastikeun kasuksésan operasi nyerat ieu. . Data runtuyan dianggap konsisten lamun, nalika maca, mayoritas titik anu ngajajal tur dikonfirmasi aranjeunna. Ku kituna, kalawan tilu réplika, konsistensi data lengkep jeung instan dijamin lamun hiji titik gagal. Pendekatan ieu ngamungkinkeun urang pikeun nerapkeun skéma anu langkung dipercaya: salawasna ngirimkeun pamundut ka tilu réplika, ngantosan réspon ti dua anu panggancangna. Réspon telat tina réplika katilu dipiceun dina hal ieu. Titik anu telat ngaréspon tiasa gaduh masalah anu serius - rem, pangumpulan sampah di JVM, ngarebut deui mémori langsung dina kernel Linux, gagalna hardware, disconnection tina jaringan. Nanging, ieu henteu mangaruhan operasi atanapi data klien dina cara naon waé.
Pendekatan nalika urang ngahubungi tilu titik sareng nampi réspon ti dua disebut : pamundut pikeun réplika tambahan dikirim malah saméméh éta "ragrag".
Kauntungan sejen tina Cassandra nyaeta Batchlog, mékanisme nu ensures yén bets parobahan Anjeun jieun boh pinuh dilarapkeun atawa teu dilarapkeun pisan. Hal ieu ngamungkinkeun urang pikeun ngajawab A dina ACID - atomicity out of the box.
Hal anu paling caket kana transaksi di Cassandra nyaéta anu disebut "". Tapi aranjeunna tebih tina transaksi asam "nyata": kanyataanna, ieu mangrupikeun kasempetan pikeun ngalakukeun on data tina ngan hiji catetan, ngagunakeun konsensus ngagunakeun protokol Paxos heavyweight. Ku alatan éta, laju transaksi sapertos low.
Naon kami leungit di Cassandra
Janten, urang kedah ngalaksanakeun transaksi ACID nyata di Cassandra. Ngagunakeun nu urang bisa kalayan gampang nerapkeun dua fitur merenah séjén tina DBMS klasik: indéks gancang konsisten, nu bakal ngidinan urang pikeun ngalakukeun selections data teu ukur ku konci primér, sarta generator biasa monotonik otomatis-incrementing ID.
C*Hiji
Ku kituna lahir DBMS anyar C*Hiji, diwangun ku tilu jinis titik server:
- Panyimpenan - (ampir) server Cassandra standar anu tanggung jawab pikeun nyimpen data dina disk lokal. Salaku beban sarta volume data tumuwuh, kuantitas maranéhanana bisa gampang diskalakeun kana puluhan sarta ratusan.
- Koordinator Transaksi - mastikeun palaksanaan transaksi.
- Klién mangrupikeun server aplikasi anu ngalaksanakeun operasi bisnis sareng ngamimitian transaksi. Aya tiasa rébuan klien sapertos.
Server sakabeh tipe mangrupakeun bagian tina hiji klaster umum, ngagunakeun protokol pesen Cassandra internal pikeun komunikasi saling jeung pikeun tukeur informasi klaster. Kalayan Heartbeat, server diajar ngeunaan gagalna silih, ngajaga skéma data tunggal - tabel, struktur sareng réplikasina; skéma partisi, topologi klaster, jsb.
klien
Gantina supir standar, mode Fat Client dianggo. Titik sapertos kitu henteu nyimpen data, tapi tiasa janten koordinator pikeun palaksanaan pamundut, nyaéta, Klién sorangan bertindak salaku koordinator pamundutana: naroskeun réplika panyimpen sareng ngabéréskeun konflik. Ieu mah ngan ukur langkung dipercaya sareng langkung gancang tibatan supir standar, anu peryogi komunikasi sareng koordinator jauh, tapi ogé ngamungkinkeun anjeun pikeun ngatur pangiriman pamundut. Di luar transaksi dibuka dina klien, requests dikirim ka repositories. Upami klien parantos muka transaksi, maka sadaya pamundut dina transaksi dikirim ka koordinator transaksi.
C* Koordinator Transaksi Hiji
Koordinator mangrupikeun hal anu kami laksanakeun pikeun C * Hiji ti mimiti. Éta tanggung jawab pikeun ngatur transaksi, ngonci, sareng urutan dimana transaksi diterapkeun.
Pikeun unggal transaksi dilayanan, koordinator ngahasilkeun timestamp a: unggal transaksi saterusna leuwih gede dibandingkeun transaksi saméméhna. Kusabab sistem resolusi konflik Cassandra dumasar kana timestamp (dua rékaman conflicting, hiji jeung timestamp panganyarna dianggap ayeuna), konflik bakal salawasna direngsekeun dina kahadean transaksi saterusna. Kitu we dilaksanakeun - cara anu murah pikeun ngabéréskeun konflik dina sistem anu disebarkeun.
Konci
Pikeun mastikeun isolasi, urang mutuskeun pikeun ngagunakeun métode pangbasajanna - konci pesimis dumasar kana konci primér catetan. Dina basa sejen, dina transaksi, rékaman kudu dikonci heula, ngan lajeng dibaca, dirobah, sarta disimpen. Ngan saatos komitmen anu suksés tiasa ngarékam dikonci supados transaksi saingan tiasa dianggo.
Ngalaksanakeun konci sapertos kitu saderhana dina lingkungan anu henteu disebarkeun. Dina sistem anu disebarkeun, aya dua pilihan utama: boh ngalaksanakeun ngonci anu disebarkeun dina kluster, atanapi ngadistribusikaeun transaksi supados transaksi anu ngalibetkeun catetan anu sami dilayanan ku koordinator anu sami.
Kusabab dina hal urang data geus disebarkeun diantara grup transaksi lokal di SQL, éta ieu mutuskeun pikeun napelkeun Grup transaksi lokal pikeun koordinator: hiji koordinator ngalakukeun sagala transaksi kalayan tokens ti 0 nepi ka 9, kadua - kalawan tokens ti 10 nepi ka 19, teras salajengna. Hasilna, unggal instansi koordinator janten master sahiji grup transaksi.
Teras konci tiasa dilaksanakeun dina bentuk HashMap banal dina mémori koordinator.
Kagagalan koordinator
Kusabab hiji koordinator sacara éksklusif ngalayanan sakelompok transaksi, éta penting pisan pikeun gancang nangtukeun kanyataan gagalna supados usaha kadua pikeun ngaéksekusi transaksi bakal waktosna. Pikeun ngajantenkeun ieu gancang sareng dipercaya, kami nganggo protokol ketukan pendengaran kuorum anu lengkep:
Unggal puseur data boga sahenteuna dua titik koordinator. Périodik, unggal koordinator ngirim pesen keteg jajantung ka koordinator sejen tur informs aranjeunna ngeunaan fungsi na, kitu ogé seratan keteg jajantung eta narima ti mana koordinator dina klaster panungtungan waktu.
Narima informasi sarupa ti batur salaku bagian tina pesen keteg jajantung maranéhanana, unggal koordinator mutuskeun sorangan mana titik kluster fungsi jeung nu henteu, dipandu ku prinsip quorum: lamun titik X geus narima informasi ti mayoritas titik dina klaster ngeunaan normal. resi pesen ti titik Y, lajeng , Y jalan. Sabalikna, pas seuseueurna ngalaporkeun pesen anu leungit tina titik Y, teras Y nampik. Panasaran lamun kuorum ngawartosan titik X yén éta henteu deui nampi pesen ti dinya, teras titik X sorangan bakal nganggap dirina gagal.
Talatah keteg jajantung dikirim kalayan frékuénsi luhur, kira-kira 20 kali per detik, kalayan periode 50 mdet. Di Java, hese ngajamin réspon aplikasi dina 50 mdet kusabab panjangna jeda anu dibandingkeun disababkeun ku tukang sampah. Kami tiasa ngahontal waktos réspon ieu nganggo kolektor sampah G1, anu ngamungkinkeun urang pikeun nangtukeun udagan salami GC jeda. Nanging, sakapeung, jarang, kolektor ngareureuhkeun langkung ti 50 mdet, anu tiasa nyababkeun deteksi kasalahan palsu. Pikeun nyegah ieu kajadian, koordinator henteu ngalaporkeun kagagalan titik jauh nalika seratan keteg jajantung munggaran ngaleungit, ngan lamun sababaraha geus ngiles sakaligus. Ieu kumaha urang junun ngadeteksi gagalna titik koordinator dina 200 Ibu.
Tapi éta henteu cekap pikeun gancang ngartos titik mana anu lirén. Urang kudu ngalakukeun hal ngeunaan ieu.
Reservasi
Skéma klasik ngalibatkeun, dina acara gagal master, dimimitian pamilihan anyar ngagunakeun salah sahiji algoritma. Sanajan kitu, algoritma misalna boga masalah well-dipikawanoh kalawan konvergénsi waktu jeung panjangna prosés pamilihan sorangan. Urang tiasa ngahindarkeun telat tambahan sapertos nganggo skéma ngagantian koordinator dina jaringan anu disambungkeun pinuh:
Hayu urang nyebutkeun urang rék ngaéksekusi urus dina grup 50. Hayu urang nangtukeun sateuacanna skéma ngagantian, nyaeta, nu titik bakal ngaéksekusi transaksi di grup 50 dina acara gagalna koordinator utama. Tujuan kami nyaéta pikeun ngajaga fungsionalitas sistem upami aya kagagalan pusat data. Hayu urang nangtukeun yén cadangan kahiji bakal titik ti puseur data sejen, sarta cadangan kadua bakal titik ti katilu. Skéma ieu dipilih sakali sarta henteu robah nepi ka topologi klaster robah, nyaeta, nepi ka titik anyar asupkeun eta (anu kajadian pisan jarang). Prosedur pikeun milih master aktif anyar lamun nu heubeul gagal bakal salawasna jadi kieu: cadangan kahiji bakal jadi master aktif, sarta lamun geus eureun fungsi, cadangan kadua bakal jadi master aktif.
Skéma ieu langkung dipercaya tibatan algoritma universal, sabab pikeun ngaktipkeun master énggal cukup pikeun nangtukeun gagalna anu lami.
Tapi kumaha klien bakal ngartos mana master anu damel ayeuna? Teu mungkin pikeun ngirim inpormasi ka rébuan klien dina 50 mdet. Hiji kaayaan mungkin lamun klien ngirimkeun pamundut pikeun muka transaksi, teu acan terang yen master ieu euweuh fungsi, sarta pamundut bakal waktos kaluar. Pikeun nyegah ieu kajadian, klien spekulatif ngirim pamundut pikeun muka transaksi ka master grup na duanana cadangan na sakaligus, tapi ngan hiji anu master aktif dina momen bakal ngabales pamundut ieu. Klién bakal ngajantenkeun sadaya komunikasi salajengna dina transaksi ngan sareng master aktip.
Nyadangkeun Masters tempat narima requests pikeun transaksi anu henteu maranéhanana kana antrian transaksi unborn, dimana aranjeunna disimpen pikeun sawatara waktu. Lamun master aktip maot, prosés master anyar requests pikeun muka transaksi tina antrian sarta responds ka klien nu. Upami klien parantos muka transaksi sareng master lami, maka réspon kadua teu dipaliré (sareng, écés, transaksi sapertos kitu moal réngsé sareng bakal diulang ku klien).
Kumaha urus jalan
Hayu urang nyebutkeun hiji klien dikirim pamundut ka koordinator pikeun muka transaksi pikeun hiji éntitas misalna jeung kitu jeung kitu jeung ieu konci primér. Koordinator ngonci éntitas ieu sareng nempatkeun kana méja konci dina mémori. Upami diperlukeun, koordinator maca éntitas ieu ti gudang tur nyimpen data hasilna dina kaayaan urus dina mémori koordinator urang.
Lamun klien hayang ngarobah data dina urus a, ngirimkeun pamundut ka koordinator pikeun ngaropea entitas, sarta koordinator nempatkeun data anyar dina tabel status urus dina mémori. Ieu ngalengkepan ngarékam - teu aya rékaman anu dilakukeun pikeun neundeun.
Nalika klien nyuhunkeun data anu dirobih nyalira salaku bagian tina transaksi aktip, koordinator tindakan sapertos kieu:
- upami ID parantos aya dina transaksi, teras datana dicandak tina mémori;
- upami teu aya ID dina mémori, teras data anu leungit dibaca tina tempat panyimpen, digabungkeun sareng anu parantos aya dina mémori, sareng hasilna dipasihkeun ka klien.
Ku kituna, klien nu bisa maca parobahanana sorangan, tapi klien sejenna teu ningali parobahan ieu, sabab disimpen ukur dina mémori koordinator, aranjeunna henteu acan dina titik Cassandra.
Nalika klien ngirim komitmen, kaayaan anu aya dina mémori jasa disimpen ku koordinator dina bets log, sarta dikirim salaku bets asup ka gudang Cassandra. Toko ngalakukeun sagalana diperlukeun pikeun mastikeun yén pakét ieu atomically (lengkep) dilarapkeun, sarta balik respon kana koordinator, anu ngaleupaskeun konci na confirms kasuksésan transaksi ka klien nu.
Jeung rollback, koordinator hijina perlu ngosongkeun memori dikawasaan ku kaayaan urus.
Salaku hasil tina perbaikan di luhur, kami nerapkeun prinsip ACID:
- Atomitas. Ieu mangrupikeun jaminan yén teu aya transaksi anu bakal dirékam sawaréh dina sistem; boh sadaya suboperasina bakal réngsé, atanapi henteu aya anu réngsé. Urang taat kana prinsip ieu ngaliwatan bets log di Cassandra.
- Konsistensi. Unggal urus suksés, ku harti, ngan catetan hasil valid. Upami, saatos muka transaksi sareng ngalaksanakeun bagian tina operasi, mendakan yén hasilna henteu sah, balikan deui dilaksanakeun.
- Isolasi. Nalika transaksi dieksekusi, transaksi sakaligus teu kedah mangaruhan hasilna. Transaksi bersaing diisolasi nganggo konci pesimis dina koordinator. Pikeun maca di luar transaksi, prinsip isolasi dititénan dina tingkat Read Committed.
- Sustainability. Henteu paduli masalah dina tingkat handap - sistem blackout, gagalna hardware - parobahan anu dilakukeun ku transaksi anu suksés réngsé kedah tetep dijaga nalika operasi diteruskeun.
Bacaan ku indéks
Hayu urang nyandak tabel basajan:
CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)Cai mibanda hiji ID (konci primér), boga jeung tanggal modifikasi. Anjeun kedah ngadamel pamenta anu saderhana - pilih data anu gaduh sareng tanggal parobihan "pikeun dinten terakhir".
SELECT *
WHERE owner=?
AND modified>?Supados query sapertos diolah gancang, dina DBMS SQL Palasik anjeun kudu ngawangun hiji indéks ku kolom (boga, dirobah). Urang tiasa ngalakukeun ieu rada gampang, sabab urang ayeuna gaduh jaminan ACID!
Indéks dina C * Hiji
Aya tabel sumber sareng poto dimana ID catetan mangrupikeun konci primér.
Pikeun indéks, C * Hiji nyieun tabel anyar nu mangrupa salinan aslina. Koncina sami sareng ekspresi indéks, sareng éta ogé kalebet konci primér rékaman tina tabel sumber:
Ayeuna pamundut pikeun "boga dinten terakhir" tiasa ditulis deui salaku pilih tina méja anu sanés:
SELECT * FROM i1_test
WHERE owner=?
AND modified>?Konsistensi data dina poto tabel sumber na tabel indéks i1 dijaga otomatis ku koordinator. Dumasar kana skéma data nyalira, nalika parobahan ditampi, koordinator ngahasilkeun sareng nyimpen parobahan henteu ngan ukur dina tabel utama, tapi ogé dina salinan. Henteu aya tindakan tambahan anu dilakukeun dina méja indéks, log henteu dibaca, sareng henteu aya konci anu dianggo. Hartina, nambahkeun indéks meakeun ampir euweuh sumberdaya sarta ampir euweuh pangaruh dina laju nerapkeun modifikasi.
Ngagunakeun ACID, urang bisa nerapkeun indexes SQL-kawas. Aranjeunna konsisten, scalable, gancang, composable, sarta diwangun kana basa query CQL. Taya parobahan kode aplikasi diperlukeun pikeun ngarojong indéks. Sadayana saderhana sapertos dina SQL. Jeung paling importantly, indexes teu mangaruhan laju palaksanaan modifikasi kana tabel urus aslina.
Aya naon
Kami ngembangkeun C * One tilu taun ka pengker sareng ngaluncurkeun kana operasi komérsial.
Naon anu urang meunang tungtungna? Hayu urang meunteun ieu nganggo conto ngolah poto sareng subsistem neundeun, salah sahiji jinis data anu paling penting dina jaringan sosial. Kami henteu ngawangkong ngeunaan awak poto sorangan, tapi ngeunaan sagala jinis meta-informasi. Ayeuna Odnoklassniki gaduh ngeunaan 20 milyar rékaman sapertos kitu, sistem ngolah 80 rébu pamundut dibaca per detik, dugi ka 8 rébu transaksi ACID per detik anu aya hubunganana sareng modifikasi data.
Nalika kami nganggo SQL kalayan faktor réplikasi = 1 (tapi dina RAID 10), metainformasi poto disimpen dina klaster anu sayogi 32 mesin anu ngajalankeun Microsoft SQL Server (tambah 11 cadangan). 10 server ogé dialokasikeun pikeun nyimpen cadangan. Jumlahna aya 50 mobil mahal. Dina waktu nu sarua, sistem dioperasikeun dina beban dipeunteun, tanpa cagar.
Saatos migrasi ka sistem anyar, kami nampi faktor réplikasi = 3 - salinan di unggal pusat data. Sistim nu diwangun ku 63 titik gudang Cassandra jeung 6 mesin koordinator, jumlahna aya 69 server. Tapi mesin-mesin ieu langkung mirah, total biayana sakitar 30% tina biaya sistem SQL. Dina waktos anu sami, beban dijaga dina 30%.
Kalayan ngenalkeun C*One, latency ogé turun: dina SQL, operasi nulis nyandak sakitar 4,5 mdet. Dina C * Hiji - ngeunaan 1,6 mdet. Durasi transaksi rata-rata kirang ti 40 mdet, komitmen réngsé dina 2 mdet, durasi maca sareng nyerat rata-rata 2 mdet. Persentil ka-99 - ngan ukur 3-3,1 mdet, jumlah waktosna parantos turun ku 100 kali - sadayana kusabab pamakean spekulasi anu nyebar.
Ayeuna, kalolobaan titik SQL Server parantos dinonaktipkeun; produk anyar dikembangkeun ngan ukur nganggo C * One. Urang diadaptasi C * Hiji pikeun digawé di awan urang , anu ngamungkinkeun pikeun nyepetkeun panyebaran klaster énggal, nyederhanakeun konfigurasi sareng ngajadikeun otomatis operasi. Tanpa kode sumber, ngalakukeun ieu bakal langkung hese sareng pajeulit.
Ayeuna kami nuju ngusahakeun nransferkeun fasilitas panyimpen kami anu sanés ka méga - tapi éta mangrupikeun carita anu béda.
sumber: www.habr.com