Nganti saiki, Odnoklassniki nyimpen babagan 50 TB data sing diproses ing wektu nyata ing SQL Server. Kanggo volume kuwi, iku meh mokal kanggo nyedhiyani cepet lan dipercaya, lan malah pusat data akses Gagal-toleran nggunakake SQL DBMS. Biasane, ing kasus kaya mengkono, salah sijine panyimpenan NoSQL digunakake, nanging ora kabeh bisa ditransfer menyang NoSQL: sawetara entitas mbutuhake jaminan transaksi ACID.
Iki mimpin kita nggunakake panyimpenan NewSQL, yaiku, DBMS sing menehi toleransi fault, skalabilitas lan kinerja sistem NoSQL, nanging ing wektu sing padha njaga ACID njamin menowo kanggo sistem klasik. Ana sawetara sistem industri sing bisa digunakake ing kelas anyar iki, mula kita ngetrapake sistem kasebut dhewe lan dilebokake ing operasi komersial.
Cara kerjane lan apa sing kedadeyan - maca ing ngisor potong.
Dina iki, pamirsa saben wulan Odnoklassniki luwih saka 70 yuta pengunjung unik. We jaringan sosial paling gedhe ing donya, lan ing antarane rong puluh situs kang kedhaftar nglampahi paling wektu. Infrastruktur OK nangani beban sing dhuwur banget: luwih saka sejuta panjalukan HTTP / detik saben ngarep. Bagéan saka armada server luwih saka 8000 potongan dumunung cedhak - ing papat pusat data Moskow, sing ngidini latensi jaringan kurang saka 1 ms ing antarane.
Kita wis nggunakake Cassandra wiwit 2010, wiwit karo versi 0.6. Dina iki ana sawetara rolas klompok ing operasi. Kluster paling cepet ngolah luwih saka 4 yuta operasi per detik, lan toko paling gedhe 260 TB.
Nanging, iki kabeh kluster NoSQL biasa sing digunakake kanggo panyimpenan data. We wanted kanggo ngganti panyimpenan konsisten utama, Microsoft SQL Server, kang wis digunakake wiwit founding Odnoklassniki. Panyimpenan kasebut kalebu luwih saka 300 mesin SQL Server Standard Edition, sing ngemot 50 TB data - entitas bisnis. Data iki diowahi minangka bagéan saka transaksi ACID lan mbutuhake .
Kanggo nyebarake data ing simpul SQL Server, kita nggunakake vertikal lan horisontal (sharing). Secara historis, kita nggunakake skema sharding data sing prasaja: saben entitas digandhengake karo token - fungsi saka ID entitas. Entitas kanthi token sing padha diselehake ing server SQL sing padha. Hubungan master-detail dileksanakake supaya token saka cathetan utama lan anak tansah cocog lan dumunung ing server sing padha. Ing jaringan sosial, meh kabeh cathetan digawe kanggo pangguna - tegese kabeh data pangguna ing siji subsistem fungsional disimpen ing siji server. Sing, transaksi bisnis meh tansah melu tabel saka siji SQL server, kang digawe iku bisa kanggo mesthekake konsistensi data nggunakake transaksi ACID lokal, tanpa perlu kanggo nggunakake. transaksi ACID sing disebarake.
Thanks kanggo sharding lan nyepetake SQL:
- Kita ora nggunakake watesan kunci Asing, amarga nalika sharding ID entitas bisa uga ana ing server liyane.
- Kita ora nggunakake prosedur sing disimpen lan pemicu amarga beban tambahan ing CPU DBMS.
- Kita ora nggunakake JOIN amarga kabeh kasebut ing ndhuwur lan akeh maca acak saka disk.
- Ing njaba transaksi, kita nggunakake tingkat isolasi Read Uncommitted kanggo nyuda deadlocks.
- Kita mung nindakake transaksi singkat (rata-rata luwih cendhek tinimbang 100 ms).
- Kita ora nggunakake UPDATE lan DELETE multi-baris amarga akeh deadlocks - nganyari mung siji rekaman sekaligus.
- Kita tansah nindakake pitakon mung ing indeks - pitakon kanthi rencana scan tabel lengkap kanggo kita tegese kakehan database lan nyebabake gagal.
Langkah-langkah kasebut ngidini kita nyuda kinerja maksimal saka server SQL. Nanging, masalah saya tambah akeh. Ayo padha ndeleng.
Masalah karo SQL
- Amarga kita nggunakake sharding sing ditulis dhewe, nambahake shards anyar ditindakake kanthi manual dening administrator. Kabeh wektu iki, replika data sing bisa diukur ora nglayani panjaluk.
- Nalika jumlah cathetan ing tabel mundhak, kacepetan selipan lan modifikasi suda; nalika nambah indeks menyang tabel sing ana, kacepetan mudhun kanthi faktor; nggawe lan nggawe maneh indeks dumadi kanthi downtime.
- Duwe jumlah cilik Windows kanggo SQL Server ing produksi nggawe manajemen infrastruktur angel
Nanging masalah utama yaiku
toleransi kesalahan
Server SQL klasik nduweni toleransi kesalahan sing kurang. Contone, sampeyan mung duwe siji server database, lan gagal saben telung taun. Sajrone wektu iki situs kasebut mudhun nganti 20 menit, sing bisa ditampa. Yen sampeyan duwe 64 server, mula situs kasebut mudhun saben telung minggu. Lan yen sampeyan duwe 200 server, mula situs kasebut ora bisa digunakake saben minggu. Iki masalah.
Apa sing bisa ditindakake kanggo nambah toleransi kesalahan server SQL? Wikipedia ngajak kita mbangun : ngendi ing cilik saka Gagal samubarang komponen ana serep.
Iki mbutuhake armada peralatan sing larang: akeh duplikasi, serat optik, panyimpenan sing dienggo bareng, lan kalebu cadangan ora bisa dipercaya: kira-kira 10% switching rampung kanthi gagal simpul cadangan kaya sepur ing mburi simpul utama.
Nanging kerugian utama kluster sing kasedhiya banget yaiku kasedhiyan nol yen pusat data sing ana gagal. Odnoklassniki nduweni papat pusat data, lan kita kudu mesthekake operasi yen ana kegagalan lengkap ing salah sijine.
Kanggo iki kita bisa nggunakake replikasi dibangun ing SQL Server. Solusi iki luwih larang amarga biaya piranti lunak lan nandhang masalah sing kondhang karo replikasi - telat transaksi sing ora bisa diprediksi kanthi replikasi sinkron lan telat nglamar replikasi (lan, minangka asil, ilang modifikasi) kanthi replikasi asinkron. Sing tersirat ndadekake pilihan iki ora bisa ditrapake kanggo kita.
Kabeh masalah iki mbutuhake solusi radikal, lan kita wiwit nganalisa kanthi rinci. Ing kene kita kudu ngerti apa sing utamane ditindakake SQL Server - transaksi.
Transaksi prasaja
Ayo nimbang transaksi sing paling gampang, saka sudut pandang programmer SQL sing ditrapake: nambah foto menyang album. Album lan foto disimpen ing macem-macem piring. Album kasebut duwe counter foto umum. Banjur transaksi kasebut dipérang dadi langkah-langkah ing ngisor iki:
- Kita ngunci album kanthi tombol.
- Nggawe entri ing tabel foto.
- Yen foto kasebut nduweni status umum, banjur tambahake counter foto umum menyang album, nganyari rekaman lan laku transaksi.
Utawa ing pseudocode:
TX.start("Albums", id);
Album album = albums.lock(id);
Photo photo = photos.create(…);
if (photo.status == PUBLIC ) {
album.incPublicPhotosCount();
}
album.update();
TX.commit();Kita weruh yen skenario sing paling umum kanggo transaksi bisnis yaiku maca data saka database menyang memori server aplikasi, ngganti soko lan nyimpen nilai anyar bali menyang database. Biasane ing transaksi kasebut, kita nganyari sawetara entitas, sawetara tabel.
Nalika nindakake transaksi, modifikasi bebarengan saka data sing padha saka sistem liyane bisa kedadeyan. Contone, Antispam bisa mutusake manawa pangguna kaya-kaya curiga lan mulane kabeh foto pangguna kudu ora umum maneh, kudu dikirim kanthi moderat, tegese ngganti foto.status menyang sawetara nilai liyane lan mateni counter sing cocog. Temenan, yen operasi iki dumadi tanpa njamin atomicity saka aplikasi lan isolasi saka modifikasi saingan, kaya ing , banjur asil ora bakal dadi apa sing dibutuhake - salah siji counter foto bakal nuduhake nilai sing salah, utawa ora kabeh foto bakal dikirim kanthi moderat.
Akeh kode sing padha, manipulasi macem-macem entitas bisnis ing siji transaksi, wis ditulis sajrone kabeh Odnoklassniki. Adhedhasar pengalaman migrasi menyang NoSQL saka Kita ngerti yen tantangan paling gedhe (lan investasi wektu) teka saka ngembangake kode kanggo njaga konsistensi data. Mulane, kita dianggep minangka syarat utama kanggo panyimpenan anyar minangka panentu kanggo transaksi ACID nyata kanggo logika aplikasi.
Persyaratan liyane sing ora kurang penting yaiku:
- Yen pusat data gagal, maca lan nulis menyang panyimpenan anyar kudu kasedhiya.
- Njaga kacepetan pembangunan saiki. Yaiku, nalika nggarap repositori anyar, jumlah kode kudu kira-kira padha, ora perlu nambah apa wae ing repositori, ngembangake algoritma kanggo ngrampungake konflik, njaga indeks sekunder, lsp.
- Kacepetan panyimpenan anyar kudu cukup dhuwur, nalika maca data lan nalika ngolah transaksi, sing kanthi efektif tegese solusi sing ketat sacara akademis, universal, nanging alon, kayata, umpamane, ora bisa ditrapake. .
- Skala otomatis on-the-fly.
- Nggunakake server murah biasa, tanpa kudu tuku hardware eksotis.
- Kemungkinan pangembangan panyimpenan dening pangembang perusahaan. Ing tembung liyane, prioritas diwenehi solusi proprietary utawa open source, luwih apik ing Jawa.
Keputusan, keputusan
Nganalisis solusi sing bisa ditindakake, kita nemokake rong pilihan arsitektur:
Kapisan yaiku njupuk server SQL lan ngetrapake toleransi kesalahan sing dibutuhake, mekanisme skala, kluster failover, resolusi konflik lan transaksi ACID sing bisa dipercaya lan cepet. We menehi rating pilihan iki banget non-trivial lan pegawe-intensif.
Opsi kapindho yaiku njupuk panyimpenan NoSQL sing wis digawe kanthi skala sing diimplementasikake, kluster failover, resolusi konflik, lan ngetrapake transaksi lan SQL dhewe. Sepisanan, malah tugas ngleksanakake SQL, ora kanggo sebutno transaksi ACID, katon kaya tugas sing bakal njupuk taun. Nanging banjur kita temen maujud sing fitur SQL pesawat digunakake ing laku minangka adoh saka ANSI SQL minangka adoh saka ANSI SQL. Ndelok CQL sing luwih cedhak, kita ngerti manawa cukup cedhak karo sing dibutuhake.
Cassandra lan CQL
Dadi, apa sing menarik babagan Cassandra, kemampuan apa sing diduweni?
Kaping pisanan, ing kene sampeyan bisa nggawe tabel sing ndhukung macem-macem jinis data; sampeyan bisa nindakake PILIH utawa UPDATE ing kunci utama.
CREATE TABLE photos (id bigint KEY, owner bigint,…);
SELECT * FROM photos WHERE id=?;
UPDATE photos SET … WHERE id=?;Kanggo njamin konsistensi data replika, Cassandra nggunakake . Ing kasus sing paling gampang, iki tegese nalika telung replika saka baris sing padha diselehake ing simpul kluster sing beda-beda, nulis kasebut dianggep sukses yen mayoritas simpul (yaiku, loro saka telu) ngonfirmasi sukses operasi nulis iki. . Data baris dianggep konsisten yen, nalika maca, mayoritas simpul dijajaki lan dikonfirmasi. Mangkono, kanthi telung replika, konsistensi data lengkap lan cepet dijamin yen siji simpul gagal. Pendekatan iki ngidini kita ngleksanakake skema sing luwih dipercaya: tansah ngirim panjalukan kanggo kabeh telung replika, ngenteni respon saka loro sing paling cepet. Tanggepan pungkasan saka replika katelu dibuwang ing kasus iki. A simpul sing telat nanggapi bisa uga duwe masalah serius - rem, koleksi sampah ing JVM, memori langsung mbalekake ing kernel Linux, Gagal hardware, pedhot saka jaringan. Nanging, iki ora mengaruhi operasi utawa data klien kanthi cara apa wae.
Pendekatan nalika kita ngubungi telung kelenjar lan nampa respon saka loro diarani : panjalukan kanggo replika ekstra dikirim malah sadurunge iku "mudhun".
Manfaat liyane saka Cassandra yaiku Batchlog, mekanisme sing njamin manawa pirang-pirang owah-owahan sing sampeyan lakoni bisa ditrapake utawa ora ditrapake. Iki ngidini kita ngatasi A ing ACID - atomicity metu saka kothak.
Sing paling cedhak karo transaksi ing Cassandra yaiku sing diarani "". Nanging padha adoh saka transaksi ACID "nyata": nyatane, iki minangka kesempatan kanggo nindakake ing data saka mung siji rekaman, nggunakake konsensus nggunakake protokol Paxos abot. Mulane, kacepetan transaksi kasebut kurang.
Apa kita padha ilang ing Cassandra
Dadi, kita kudu ngetrapake transaksi ACID nyata ing Cassandra. Kanthi nggunakake, kita bisa kanthi gampang ngetrapake rong fitur DBMS klasik liyane sing trep: indeks cepet sing konsisten, sing ngidini kita nindakake pilihan data ora mung kanthi kunci utama, lan generator ID nambah otomatis monoton.
C*siji
Mangkono DBMS anyar lair C*siji, dumadi saka telung jinis node server:
- Panyimpenan - (meh) server Cassandra standar sing tanggung jawab kanggo nyimpen data ing disk lokal. Nalika beban lan volume data saya tambah, jumlahe bisa gampang diukur nganti puluhan lan atusan.
- Koordinator transaksi - njamin eksekusi transaksi.
- Klien minangka server aplikasi sing ngetrapake operasi bisnis lan miwiti transaksi. Bisa uga ana ewonan klien kasebut.
Server kabeh jinis iku bagéan saka kluster umum, nggunakake protokol pesen Cassandra internal kanggo komunikasi karo saben liyane lan kanggo ijol-ijolan informasi cluster. Kanthi Heartbeat, server sinau babagan kegagalan bebarengan, njaga skema data siji - tabel, struktur lan replikasi; skema partisi, topologi cluster, dll.
Klien
Tinimbang pembalap standar, mode Fat Client digunakake. Simpul kasebut ora nyimpen data, nanging bisa dadi koordinator kanggo eksekusi panyuwunan, yaiku, Klien dhewe tumindak minangka koordinator panjaluke: takon replika panyimpenan lan ngrampungake konflik. Iki ora mung luwih dipercaya lan luwih cepet tinimbang driver standar, sing mbutuhake komunikasi karo koordinator remot, nanging uga ngijini sampeyan kanggo ngontrol transmisi panjalukan. Ing njaba transaksi mbukak ing klien, panjalukan dikirim menyang repositori. Yen klien wis mbukak transaksi, kabeh panjalukan ing transaksi dikirim menyang koordinator transaksi.
C*One Koordinator Transaksi
Koordinator minangka perkara sing ditindakake kanggo C * One saka awal. Tanggung jawab kanggo ngatur transaksi, kunci, lan urutan transaksi sing ditrapake.
Kanggo saben transaksi sing dilayani, koordinator ngasilake stempel wektu: saben transaksi sakteruse luwih gedhe tinimbang transaksi sadurunge. Wiwit sistem résolusi konflik Cassandra adhedhasar timestamp (saka rong cathetan konflik, siji karo timestamp paling anyar dianggep saiki), konflik bakal tansah ditanggulangi ing sih saka transaksi sakteruse. Mangkono kita dileksanakake - cara sing murah kanggo ngrampungake konflik ing sistem sing disebarake.
Kunci
Kanggo njamin isolasi, kita mutusake nggunakake cara sing paling gampang - kunci pesimis adhedhasar kunci utama rekaman. Ing tembung liya, ing transaksi, cathetan kudu dikunci dhisik, banjur diwaca, diowahi, lan disimpen. Mung sawise commit sukses rekaman bisa dikunci supaya transaksi saingan bisa digunakake.
Ngleksanakake ngunci kuwi prasaja ing lingkungan non-distribusi. Ing sistem sing disebarake, ana rong pilihan utama: ngleksanakake kunci sing disebarake ing kluster, utawa nyebarake transaksi supaya transaksi sing nglibatake rekaman sing padha tansah dilayani dening koordinator sing padha.
Wiwit ing kasus kita, data wis disebarake ing antarane klompok transaksi lokal ing SQL, diputusake kanggo nemtokake klompok transaksi lokal menyang koordinator: siji koordinator nindakake kabeh transaksi kanthi token saka 0 nganti 9, sing kapindho - kanthi token saka 10 nganti 19, lan liya-liyane. Akibaté, saben conto koordinator dadi master grup transaksi.
Banjur kunci bisa dileksanakake ing wangun HashMap banal ing memori koordinator.
Gagal koordinator
Wiwit siji koordinator eksklusif serves klompok transaksi, iku penting banget kanggo cepet nemtokake kasunyatan saka Gagal supaya nyoba kaloro kanggo nglakokaké transaksi bakal entek. Kanggo nggawe iki cepet lan dipercaya, kita nggunakake protokol irama kuorum sing disambungake kanthi lengkap:
Saben pusat data dadi tuan rumah paling ora rong node koordinator. Secara periodik, saben koordinator ngirim pesen detak jantung menyang koordinator liyane lan ngandhani babagan fungsine, uga pesen detak jantung sing ditampa saka koordinator ing kluster pungkasan.
Nampa informasi sing padha saka wong liya minangka bagéan saka pesen deg-degan, saben koordinator mutusake dhewe endi simpul kluster sing bisa digunakake lan sing ora, dipandu dening prinsip kuorum: yen simpul X wis nampa informasi saka mayoritas simpul ing kluster babagan normal. panrimo pesen saka simpul Y, banjur , Y dianggo. Lan kosok balene, sanalika mayoritas laporan ilang pesen saka simpul Y, banjur Y wis ora gelem. Iku penasaran yen kuorum ngandhani simpul X yen ora nampa pesen saka iku, banjur simpul X dhewe bakal nganggep dheweke gagal.
Pesen detak jantung dikirim kanthi frekuensi dhuwur, kira-kira 20 kali per detik, kanthi wektu 50 ms. Ing Jawa, angel njamin respon aplikasi sajrone 50 ms amarga dawane jeda sing bisa dibandhingake karo tukang sampah. Kita bisa entuk wektu nanggepi iki nggunakake kolektor sampah G1, sing ngidini kita nemtokake target sajrone GC ngaso. Nanging, kadhangkala, arang banget, kolektor ngaso ngluwihi 50 ms, sing bisa nyebabake deteksi kesalahan palsu. Kanggo nyegah kedadeyan kasebut, koordinator ora nglaporake kegagalan node remot nalika pesen deg-degan pisanan ilang, mung yen sawetara wis ilang saurutan. Iki carane kita bisa ndeteksi kegagalan node koordinator ing 200 ms.
Nanging ora cukup kanggo ngerti kanthi cepet simpul sing wis mandheg. Kita kudu nindakake soko babagan iki.
Reservasi
Skema klasik melu, ing acara saka Gagal master, miwiti Pemilu anyar nggunakake salah siji saka algoritma. Nanging, algoritma kasebut duwe masalah sing kondhang babagan konvergensi wektu lan dawa proses pemilihan kasebut. Kita bisa ngindhari penundaan tambahan kasebut kanthi nggunakake skema panggantos koordinator ing jaringan sing disambungake kanthi lengkap:
Ayo kita ngomong yen kita pengin nglakokake transaksi ing grup 50. Ayo nemtokake luwih dhisik skema panggantos, yaiku, simpul sing bakal nglakokake transaksi ing grup 50 yen ana kegagalan koordinator utama. Tujuane yaiku njaga fungsi sistem yen ana kegagalan pusat data. Ayo nemtokake manawa cadangan pisanan bakal dadi simpul saka pusat data liyane, lan cadangan kaloro bakal dadi simpul saka katelu. Skema iki dipilih sapisan lan ora owah nganti topologi kluster diganti, yaiku, nganti simpul anyar mlebu (sing kedadeyan arang banget). Prosedur kanggo milih master aktif anyar yen sing lawas gagal bakal tansah kaya ing ngisor iki: cadangan pisanan bakal dadi master aktif, lan yen wis mandheg fungsi, cadangan kaloro bakal dadi master aktif.
Skema iki luwih dipercaya tinimbang algoritma universal, amarga kanggo ngaktifake master anyar cukup kanggo nemtokake kegagalan sing lawas.
Nanging kepiye klien ngerti apa master sing digunakake saiki? Ora bisa ngirim informasi menyang ewu klien ing 50 ms. Kahanan bisa uga nalika klien ngirim panjaluk kanggo mbukak transaksi, durung ngerti manawa master iki ora bisa digunakake maneh, lan panjaluk kasebut bakal entek. Kanggo nyegah kedadeyan kasebut, klien spekulatif ngirim panjalukan kanggo mbukak transaksi menyang master grup lan loro cadangane bebarengan, nanging mung sing dadi master aktif saiki bakal nanggapi panjaluk kasebut. Klien bakal nggawe kabeh komunikasi sakteruse ing transaksi mung karo master aktif.
Panggonan master serep ditampa panjalukan kanggo transaksi sing ora duweke menyang antrian transaksi bayi, ngendi padha disimpen kanggo sawetara wektu. Yen master aktif mati, proses master anyar njaluk kanggo mbukak transaksi saka antrian lan nanggapi klien. Yen klien wis mbukak transaksi karo master lawas, banjur respon kapindho ora digatèkaké (lan, temenan, transaksi kuwi ora bakal rampung lan bakal diulang dening klien).
Carane transaksi bisa
Contone, klien ngirim panjaluk menyang koordinator kanggo mbukak transaksi kanggo entitas kasebut kanthi kunci utama. Koordinator ngunci entitas iki lan nyelehake ing meja kunci ing memori. Yen perlu, koordinator maca entitas iki saka panyimpenan lan nyimpen data asil ing negara transaksi ing memori koordinator.
Nalika klien pengin ngganti data ing transaksi, ngirim panjalukan kanggo koordinator kanggo ngowahi entitas, lan koordinator panggonan data anyar ing tabel status transaksi ing memori. Iki ngrampungake rekaman - ora ana rekaman sing digawe ing panyimpenan.
Nalika klien njaluk data sing diganti dhewe minangka bagéan saka transaksi aktif, koordinator tumindak kaya ing ngisor iki:
- yen ID wis ana ing transaksi, banjur data dijupuk saka memori;
- yen ora ana ID ing memori, banjur data ilang diwaca saka kelenjar panyimpenan, digabungake karo sing wis ing memori, lan asil diwenehi kanggo klien.
Mangkono, klien bisa maca owah-owahan dhewe, nanging klien liyane ora weruh owah-owahan iki, amarga padha disimpen mung ing memori koordinator, padha durung ing simpul Cassandra.
Nalika klien ngirim commit, negara sing ana ing memori layanan disimpen dening koordinator ing kumpulan log, lan dikirim minangka kumpulan mlebu menyang panyimpenan Cassandra. Toko nindakake kabeh sing perlu kanggo mesthekake yen paket iki atomically (rampung) Applied, lan bali respon kanggo koordinator, sing nerbitaké kunci lan nandheske sukses transaksi kanggo klien.
Lan kanggo muter maneh, koordinator mung kudu mbebasake memori sing dikuwasani dening negara transaksi.
Minangka asil dandan ing ndhuwur, kita ngetrapake prinsip ACID:
- Atomity. Iki minangka jaminan manawa ora ana transaksi sing bakal dicathet sebagian ing sistem; kabeh suboperasi bakal rampung, utawa ora ana sing bakal rampung. Kita netepi prinsip iki liwat batch log ing Cassandra.
- Konsistensi. Saben transaksi sing sukses, miturut definisi, mung nyathet asil sing bener. Yen, sawise mbukak transaksi lan nindakake bagean saka operasi, ditemokake yen asil ora bener, rollback ditindakake.
- Isolasi. Nalika transaksi kaleksanan, transaksi bebarengan ngirim ora mengaruhi asil. Transaksi saingan diisolasi nggunakake kunci pesimis ing koordinator. Kanggo maca ing njaba transaksi, prinsip isolasi diamati ing tingkat Read Committed.
- Kelestarian. Preduli saka masalah ing tingkat ngisor - sistem mati, hardware gagal - owah-owahan sing digawe dening transaksi sukses rampung kudu tetep wadi nalika operasi diterusake.
Maca kanthi indeks
Ayo njupuk tabel prasaja:
CREATE TABLE photos (
id bigint primary key,
owner bigint,
modified timestamp,
…)Nduwe ID (kunci utama), pemilik lan tanggal modifikasi. Sampeyan kudu nggawe panjalukan sing gampang banget - pilih data ing pemilik kanthi tanggal pangowahan "kanggo dina pungkasan".
SELECT *
WHERE owner=?
AND modified>?Supaya pitakon kasebut bisa diproses kanthi cepet, ing DBMS SQL klasik sampeyan kudu mbangun indeks kanthi kolom (pemilik, diowahi). Kita bisa nindakake iki kanthi gampang, amarga saiki duwe jaminan ACID!
Indeks ing C*One
Ana tabel sumber kanthi foto sing ID rekaman minangka kunci utama.
Kanggo indeks, C*One nggawe tabel anyar sing salinan asli. Tombol kasebut padha karo ekspresi indeks, lan uga kalebu kunci utama rekaman saka tabel sumber:
Saiki pitakon "pemilik kanggo dina pungkasan" bisa ditulis maneh minangka pilih saka tabel liyane:
SELECT * FROM i1_test
WHERE owner=?
AND modified>?Konsistensi data ing foto tabel sumber lan tabel indeks i1 dikelola kanthi otomatis dening koordinator. Adhedhasar skema data piyambak, nalika owah-owahan ditampa, koordinator ngasilake lan nyimpen owah-owahan ora mung ing tabel utama, nanging uga ing salinan. Ora ana tumindak tambahan sing ditindakake ing tabel indeks, log ora diwaca, lan ora ana kunci sing digunakake. Sing, nambah indeks nggunakake meh ora sumber daya lan wis sakbenere ora efek ing kacepetan nglamar modifikasi.
Nggunakake ACID, kita bisa ngetrapake indeks kaya SQL. Padha konsisten, bisa diukur, cepet, bisa disusun, lan dibangun ing basa pitakon CQL. Ora ana owah-owahan ing kode aplikasi sing dibutuhake kanggo ndhukung indeks. Kabeh iku prasaja kaya ing SQL. Lan sing paling penting, indeks ora mengaruhi kacepetan eksekusi modifikasi menyang tabel transaksi asli.
Ana apa
Kita ngembangake C * One telung taun kepungkur lan ngluncurake operasi komersial.
Apa sing kita entuk ing pungkasan? Ayo ngevaluasi iki nggunakake conto subsistem pangolahan lan panyimpenan foto, salah sawijining jinis data sing paling penting ing jaringan sosial. Kita ora ngomong babagan awak foto kasebut, nanging babagan kabeh jinis meta-informasi. Saiki Odnoklassniki duwe udakara 20 milyar cathetan kasebut, sistem ngolah 80 ewu panjaluk maca per detik, nganti 8 ewu transaksi ACID per detik sing ana gandhengane karo modifikasi data.
Nalika kita nggunakake SQL karo faktor replikasi = 1 (nanging ing RAID 10), metainformation foto disimpen ing kluster kasedhiya saka 32 mesin mlaku Microsoft SQL Server (plus 11 serep). 10 server uga diparengake kanggo nyimpen serep. Total 50 mobil larang. Ing wektu sing padha, sistem dioperasikake kanthi beban sing dirating, tanpa cadangan.
Sawise pindhah menyang sistem anyar, kita nampa faktor replikasi = 3 - salinan ing saben pusat data. Sistem iki kasusun saka 63 simpul panyimpenan Cassandra lan 6 mesin koordinator, kanggo total 69 server. Nanging mesin iki luwih murah, biaya total kira-kira 30% saka biaya sistem SQL. Ing wektu sing padha, beban tetep ing 30%.
Kanthi introduksi C*One, latensi uga suda: ing SQL, operasi nulis njupuk udakara 4,5 ms. Ing C*One - udakara 1,6 ms. Durasi transaksi rata-rata kurang saka 40 ms, komit rampung ing 2 ms, durasi maca lan nulis rata-rata 2 ms. Persentil kaping 99 - mung 3-3,1 ms, jumlah wektu entek wis suda kaping 100 - kabeh amarga nggunakake spekulasi sing nyebar.
Saiki, umume node SQL Server wis dinonaktifake; produk anyar dikembangake mung nggunakake C * One. Kita adaptasi C*One kanggo bisa digunakake ing awan , sing ndadekake bisa nyepetake panyebaran kluster anyar, nyederhanakake konfigurasi lan ngotomatisasi operasi. Tanpa kode sumber, nindakake iki bakal luwih angel lan rumit.
Saiki kita ngupayakake nransfer fasilitas panyimpenan liyane menyang awan - nanging iki crita sing beda.
Source: www.habr.com