BASE vs ASAM

6.1 Peperangan Singkatan: BASE vs. ASAM

Database relasional populer, kayata MySQL, muncul mung adhedhasar ACID. Nanging sajrone sepuluh taun kepungkur, sing diarani database NoSQL, sing nggabungake pirang-pirang jinis database sing beda-beda miturut jeneng iki, wis rampung kanthi apik tanpa ACID. Nyatane, ana akeh pangembang sing nggarap database NoSQL lan ora peduli babagan transaksi lan linuwih. Ayo padha ndeleng apa padha bener.

Sampeyan ora bisa ngomong ing umum babagan database NoSQL, amarga iku mung abstraksi apik. Database NoSQL beda-beda saka saben liyane ing desain subsistem panyimpenan data, lan malah ing model data: NoSQL iku loro document-oriented CouchDB lan grafik Neo4J. Nanging yen kita pirembagan bab mau ing konteks transaksi, kabeh padha cenderung padha ing siji bab: padha nyedhiyani versi winates saka atomicity lan isolasi, lan mulane ora nyedhiyani njamin ACID. Kanggo ngerti apa tegese, ayo mangsuli pitakon: apa sing ditawakake, yen ora ACID? ora apa-apa?

Ora temenan. Sawise kabeh, dheweke, kaya database relasional, uga kudu ngedol awake dhewe ing paket sing apik. Lan padha teka kanthi singkatan "kimia" - BASE.

6.2 BASE minangka antagonis

Lan ing kene maneh aku ora bakal pindhah ing urutan huruf, nanging aku bakal miwiti karo istilah dhasar - konsistensi. Aku kudu level efek pangenalan, amarga konsistensi iki ora ana hubungane karo konsistensi saka ACID. Masalah karo konsistensi istilah iku digunakake ing akeh banget konteks. Nanging konsistensi iki nduweni konteks panggunaan sing luwih akeh, lan iki pancen konsistensi sing dibahas nalika ngrembug sistem sing disebarake.

Database relasional sing kita rembugan ing ndhuwur nyedhiyakake tingkat isolasi transaksi sing beda-beda, lan sing paling ketat mesthekake yen siji transaksi ora bisa ndeleng owah-owahan sing ora bener sing ditindakake dening transaksi liyane. Yen sampeyan lagi ngadeg ing checkout ing toko, lan ing wayahe dhuwit kanggo nyewa ditarik saka akun, nanging transaksi karo transfer dhuwit kanggo nyewa gagal lan akun bali menyang nilai sadurunge (dhuwit iku ora didebit), banjur transaksi pambayaran sampeyan ing kasir ora bakal ngelingi kabeh wong sing sadurunge nyeret - sawise kabeh, transaksi kasebut ora nate ditindakake, lan adhedhasar syarat isolasi transaksi, owah-owahan sauntara ora bisa dingerteni dening transaksi liyane.

Akeh basis data NoSQL ora menehi jaminan isolasi lan nawakake "konsistensi pungkasane" sing pungkasane sampeyan bakal bisa ndeleng data sing bener, nanging ana kemungkinan transaksi sampeyan bakal maca nilai sing ora bener - yaiku, sementara, utawa sebagian dianyari, utawa ketinggalan jaman. Bisa uga data bakal konsisten ing mode "lazy" nalika maca ("lazily ing wektu maca").

NoSQL disusun minangka basis data kanggo analytics wektu nyata, lan kanggo nggayuh kacepetan sing luwih gedhe, dheweke ngorbanake konsistensi. Lan Eric Brewer, wong sing padha nggawe istilah BASE, ngrumusake "teorema CAP", miturut:

Kanggo implementasine komputasi sing disebarake, sampeyan bisa nyedhiyani ora luwih saka loro saka telung sifat ing ngisor iki:

• konsistensi data ( konsistensi ) - data ing macem-macem simpul (kasus) ora mbantah siji liyane;
• kasedhiyan ( kasedhiyan ) - panjalukan apa wae menyang sistem sing disebarake diakhiri kanthi respon sing bener, nanging tanpa njamin yen respon kabeh kelenjar sistem padha;
• toleransi pemisahan (toleransi pemisahan ) - Malah yen ora ana sambungan antarane kelenjar, padha terus bisa independen saka saben liyane.

Yen sampeyan pengin panjelasan sing gampang banget babagan CAP, mula kene.

Ana panemu sing teorema CAP ora bisa, lan umume dirumuske banget abstrak. Salah siji cara utawa liyane, database NoSQL asring nolak konsistensi ing konteks teorema CAP, kang njlèntrèhaké kahanan ing ngisor iki: data wis dianyari ing kluster karo sawetara kedadean, nanging owah-owahan durung diselarasake ing kabeh kedadean. Elinga, aku nyebutake conto DynamoDB ing ndhuwur, sing ngandhani: owah-owahan sampeyan dadi awet - iki HTTP 200 kanggo sampeyan - nanging aku mung weruh owah-owahan sawise 10 detik? Conto liyane saka urip saben pangembang yaiku DNS, sistem jeneng domain. Yen ana sing ora ngerti, mula iki persis "kamus" sing nerjemahake alamat http (s) menyang alamat IP.

Rekaman DNS sing dianyari disebarake menyang server miturut setelan interval caching - mula nganyari ora langsung katon. Inggih, inkonsistensi temporal sing padha (yaiku, pungkasane konsistensi) bisa kedadeyan ing kluster database relasional (sebutake, MySQL) - sawise kabeh, konsistensi iki ora ana hubungane karo konsistensi saka ACID. Mulane, penting kanggo mangerteni yen ing pangertèn iki, database SQL lan NoSQL ora mungkin beda banget nalika nerangake sawetara kedadeyan ing kluster.

Kajaba iku, konsistensi end-to-end bisa ateges manawa panjalukan nulis bakal ditindakake: yaiku, kabeh data bakal ditulis, nanging nilai sing pungkasane bakal ditampa ora bakal dadi sing pungkasan ing antrian nulis. .

Basis data NoSQL non-ACID duweni "kahanan alus" amarga model konsistensi end-to-end, sing tegese kahanan sistem bisa diganti liwat wektu, sanajan tanpa input. Nanging sistem kasebut ngupayakake nyedhiyakake aksesibilitas sing luwih gedhe. Nyedhiyakake kasedhiyan 100% dudu tugas sing ora pati penting, mula kita ngomong babagan "kasedhiya dhasar". Lan bebarengan telung konsep iki: "dasar kasedhiya", "kahanan alus" ("negara alus") lan "konsistensi pungkasan" mbentuk akronim BASE.

Jujur, konsep BASE misale jek dadi bungkus pemasaran sing luwih kosong tinimbang ACID - amarga ora menehi apa-apa sing anyar lan ora menehi ciri database kanthi cara apa wae. Lan masang label (ACID, BASE, CAP) menyang database tartamtu mung bisa mbingungake pangembang. Aku mutusake kanggo ngenalake sampeyan istilah iki, amarga angel dilewati nalika sinau database, nanging saiki sampeyan ngerti apa iku, aku pengin sampeyan lali babagan iki sanalika bisa. Lan ayo bali menyang konsep isolasi.

6.3 Dadi basis data BASE ora cocog karo kritéria ACID?

Ateges, ing ngendi basis data ACID beda karo non-ACID, yaiku non-ACID sejatine ora ngisolasi. Iki penting kanggo ngerti. Nanging luwih penting kanggo maca dokumentasi database lan nyoba cara sing ditindakake dening wong lanang saka proyek Hermitage. Ora pati penting kepiye para pangripta iki utawa database kasebut nyebat gagasan - ASAM utawa BASE, CAP utawa ora CAP. Sing penting yaiku apa persis iki utawa database kasebut nyedhiyakake.

Yen panyipta basis data ngaku menehi jaminan ACID, mula ana alesan kanggo iki, nanging disaranake nyoba dhewe kanggo ngerti apa iki lan kepiye. Yen dheweke ngumumake manawa database kasebut ora menehi jaminan kasebut, mula iki bisa uga tegese:

• DB ora menehi jaminan atomisitas. Nalika sawetara database NoSQL nawakake API kapisah kanggo operasi atom (contone DynamoDB);

• DB ora menehi jaminan isolasi. Iki bisa uga ateges, contone, sing database ora bakal nulis data ing urutan kang padha ditulis.

Minangka kanggo jaminan kekiatan, akeh database kompromi ing titik iki kanggo kinerja. Nulis menyang disk operasi dawa banget, lan ana sawetara cara kanggo ngatasi masalah iki. Aku ora pengin pindhah menyang teori database akeh, nanging supaya sampeyan kira-kira ngerti cara kanggo katon, Aku bakal njlèntrèhaké ing istilah umum carane database beda ngatasi masalah karo kekiatan.

Kanggo mbandhingake database sing beda-beda, ing antarane, sampeyan kudu ngerti apa struktur data sing ndasari panyimpenan data lan subsistem pengambilan saka database tartamtu. Singkat: basis data sing beda duwe implementasi indeksasi sing beda - yaiku, ngatur akses menyang data. Sawetara wong ngidini sampeyan nulis data luwih cepet, liyane - luwih cepet maca. Nanging ora bisa dikandhakake kanthi umum yen sawetara struktur data nggawe daya tahan luwih dhuwur utawa luwih murah.

6.4 carane beda database indeks data, lan carane iki mengaruhi kekiatan, lan liyane

Ana rong pendekatan utama kanggo nyimpen lan njupuk data.

Cara paling gampang kanggo nyimpen data yaiku nambahake operasi menyang mburi file kanthi cara log-kaya (yaiku, operasi append tansah ana): ora masalah yen kita pengin nambah, ngganti utawa mbusak data - kabeh. Operasi CRUD mung ditulis ing log. Nggoleki log ora efisien, lan ing kana indeks kasebut ana - struktur data khusus sing nyimpen metadata babagan persis ing ngendi data disimpen. Strategi indeksasi paling gampang kanggo log yaiku peta hash sing nglacak kunci lan nilai. Nilai kasebut bakal dadi referensi kanggo offset byte kanggo data sing ditulis ing njero file, yaiku log (log) lan disimpen ing disk. Struktur data iki disimpen kabeh ing memori, nalika data dhewe ing disk, lan disebut wit LSM (log kabentuk gabung).

Sampeyan mbokmenawa kepingin weruh: yen kita nulis operasi kita ing jurnal kabeh wektu, banjur bakal tuwuh exorbitantly? Ya, lan mulane teknik pemadatan diciptakake, sing "ngresiki" data kanthi periodisitas, yaiku, mung ninggalake nilai sing paling relevan kanggo saben tombol, utawa mbusak. Lan yen kita duwe luwih saka siji log ing disk, nanging sawetara, lan kabeh diurutake, mula kita bakal entuk struktur data anyar sing diarani SSTable ("tabel string sing diurut"), lan iki mesthi bakal nambah kinerja kita. Yen kita pengin ngurutake ing memori, kita bakal entuk struktur sing padha - sing diarani MemTable, nanging masalah kasebut yaiku yen ana kacilakan database fatal, banjur data sing ditulis pungkasan (dumunung ing MemTable, nanging durung ditulis kanggo disk) ilang. Bener,

Pendekatan liyane kanggo indeksasi adhedhasar B-wit ("B-wit"). Ing B-wit, data ditulis menyang disk ing kaca ukuran tetep. Pamblokiran data iki asring ukurane watara 4 KB lan duwe pasangan nilai kunci sing diurutake miturut kunci. Siji simpul B-tree kaya array kanthi pranala menyang sawetara kaca. Maks. jumlah pranala ing larik disebut faktor cabang. Saben kisaran kaca minangka simpul B-wit liyane kanthi pranala menyang kisaran kaca liyane.

Pungkasane, ing level sheet, sampeyan bakal nemokake kaca individu. Ide iki padha karo penunjuk ing basa pamrograman tingkat rendah, kajaba referensi kaca iki disimpen ing disk tinimbang ing memori. Nalika INSERT lan DELETE dumadi ing basis data, sawetara simpul bisa dipérang dadi rong subtree kanggo cocog karo faktor cabang. Yen database gagal kanggo alesan apa wae ing tengah proses, integritas data bisa kompromi. Kanggo nyegah kedadeyan kasebut, database nggunakake B-wit njaga "log nulis-ahead", utawa WAL, ing ngendi saben transaksi dicathet. WAL iki digunakake kanggo mulihake kahanan B-wit yen rusak. Lan misale jek sing iki ndadekake database nggunakake B-wit luwih apik ing syarat-syarat kekiatan. Nanging database basis LSM uga bisa njaga file sing ateges nindakake fungsi padha WAL. Mulane, aku bakal mbaleni apa sing wis dakkandhakake, lan bisa uga luwih saka sepisan: ngerti mekanisme operasi database sing sampeyan pilih.

Nanging sing mesthine babagan wit-B iku apik kanggo transaksi: saben tombol mung ana ing sak panggonan ing indeks, dene subsistem panyimpenan jurnal bisa duwe pirang-pirang salinan kunci sing padha ing pecahan sing beda-beda (contone, nganti kompaksi sabanjure ditindakake).

Nanging, desain indeks langsung mengaruhi kinerja database. Kanthi wit LSM, nulis menyang disk urutan, lan B-wit nimbulaké sawetara akses disk acak, supaya nulis operasi luwih cepet karo LSM saka karo B-wit. Bentenipun utamané pinunjul kanggo hard disk drive Magnetik (HDD), ngendi nulis urutan luwih cepet saka nulis acak. Maca luwih alon ing wit LSM amarga sampeyan kudu ndeleng sawetara struktur data lan tabel SS sing beda-beda ing tahap pemadatan sing beda. Ing luwih rinci katon kaya iki. Yen kita nggawe query database prasaja karo LSM, kita bakal katon munggah tombol ing MemTable. Yen ora ana, kita waca ing SSTable paling anyar; yen ora ana, banjur kita katon ing SSTable penultimate, lan ing. Yen kunci sing dijaluk ora ana, banjur karo LSM kita bakal ngerti pungkasan iki. Wit LSM digunakake ing, contone: LevelDB, RocksDB, Cassandra lan HBase.

Aku njlèntrèhaké kabeh kanthi rinci supaya sampeyan ngerti yen nalika milih database, sampeyan kudu nimbang macem-macem perkara: contone, apa sampeyan ngarepake nulis utawa maca data luwih akeh. Lan aku durung nyebataken prabédan ing model data (apa sampeyan kudu ngliwati data, minangka model grafik ngidini? Apa ana hubungan antarane unit beda ing data sampeyan - banjur database relasional bakal teka kanggo ngluwari?), lan 2 jinis skema data - nalika nulis (kaya ing akeh NoSQL) lan maca (kaya ing relasional).

Yen kita bali menyang aspek daya tahan, kesimpulan bakal kaya ing ngisor iki: database apa wae sing nulis menyang disk, preduli saka mekanisme indeksasi, bisa menehi jaminan sing apik kanggo daya tahan data sampeyan, nanging sampeyan kudu ngatasi saben database tartamtu. , apa persis nawakake.

6.5 Cara kerja DB ing memori

Miturut cara, saliyane database sing nulis menyang disk, ana uga sing disebut "ing-memori" database sing dianggo utamané karo RAM. Ing cendhak, ing-memori database biasane kurban kekiatan ngisor kanggo marga saka kacepetan nulis lan maca luwih cepet, nanging iki bisa uga cocok kanggo sawetara aplikasi.

Kasunyatan iku memori RAM wis dawa wis luwih larang saka disk, nanging bubar wis wiwit cepet dadi luwih murah, kang wis diwenehi munggah kanggo jinis anyar saka database - kang logis, diwenehi kacepetan maca lan nulis data saka RAM. Nanging sampeyan bakal takon kanthi bener: kepiye keamanan data database kasebut? Ing kene maneh, sampeyan kudu ndeleng rincian implementasine. Umumé, pangembang database kasebut nawakake mekanisme ing ngisor iki:

• Sampeyan bisa nggunakake RAM powered by batre;
• Sampeyan bisa nulis log pangowahan menyang disk (kaya WAL kasebut ing ndhuwur), nanging ora data dhewe;
• Sampeyan bisa kanthi periodik nulis salinan negara basis data menyang disk (sing, tanpa nggunakake opsi liyane, ora menehi jaminan, nanging mung nambah daya tahan);
• Sampeyan bisa niru kahanan RAM kanggo mesin liyane.

Contone, ing-memori Redis database, kang utamané dipigunakaké minangka antrian pesen utawa cache, kurang kekiatan saka ACID: iku ora njamin printah kasil kaleksanan bakal disimpen ing disk, amarga Redis flushes data menyang disk (yen duwe kegigihan aktif) mung asynchronously, ing interval biasa.

Nanging, iki ora kritis kanggo kabeh aplikasi: Aku nemokake conto editor online koperasi EtherPad, sing flushed saben 1-2 detik, lan duweni potensi pangguna bisa ilang sawetara aksara utawa tembung, kang meh ora kritis. Yen ora, amarga database ing memori apik amarga nyedhiyakake model data sing bakal angel dileksanakake karo indeks disk, Redis bisa digunakake kanggo ngleksanakake transaksi - antrian prioritas ngidini sampeyan nindakake iki.