🥇Selengkapnya pangembang kudu ngerti babagan database

Cathetan. nerjemahake.: Jaana Dogan minangka insinyur berpengalaman ing Google sing saiki lagi nggarap observasi layanan produksi perusahaan sing ditulis ing Go. Ing artikel iki, kang gained popularitas gedhe antarane pirsawan Inggris-speaking, dheweke diklumpukake ing 17 TCTerms rincian technical penting babagan DBMSs (lan kadhangkala sistem mbagekke ing umum) sing migunani kanggo nimbang kanggo pangembang aplikasi gedhe / nuntut.

Umume sistem komputer nglacak negarane lan, mula, mbutuhake sawetara sistem panyimpenan data. Aku nglumpukake kawruh babagan database sajrone wektu sing suwe, ing sadawane dalan nggawe kesalahan desain sing nyebabake mundhut data lan mati. Ing sistem sing ngolah volume akeh informasi, basis data dumunung ing jantung arsitektur sistem lan minangka unsur kunci kanggo milih solusi sing optimal. Senadyan kasunyatan manawa kerjane basis data ditrapake kanthi teliti, masalah sing diantisipasi dening pangembang aplikasi asring mung pucuk gunung es. Ing seri artikel iki, aku nuduhake sawetara gagasan sing bakal migunani kanggo pangembang sing ora duwe spesialisasi ing lapangan iki.

Bejo yen 99,999% wektu jaringan ora nyebabake masalah.
ACID tegese macem-macem.
Saben database duwe mekanisme dhewe kanggo njamin konsistensi lan isolasi.
Pamblokiran optimis bisa nylametake nalika angel njaga sing biasa.
Ana anomali liyane kajaba maca reged lan mundhut data.
Database lan pangguna ora mesthi setuju babagan tumindak.
Sharding tingkat aplikasi bisa dipindhah ing njaba aplikasi.
Autoincrementing bisa mbebayani.
Data basi bisa migunani lan ora perlu dikunci.
Distorsi khas kanggo sumber wektu apa wae.
Tundha duwe akeh makna.
Persyaratan kinerja kudu dievaluasi kanggo transaksi tartamtu.
Transaksi nested bisa mbebayani.
Transaksi ngirim ora disambungake menyang negara aplikasi.
Perencana pitakon bisa ngandhani akeh babagan database.
Migrasi online angel, nanging bisa.
Tambah pinunjul ing database entails Tambah ing unpredictability.

Aku arep matur nuwun marang Emmanuel Odeke, Rein Henrichs lan liya-liyane kanggo tanggapan babagan versi sadurunge artikel iki.

Bejo yen 99,999% wektu jaringan ora nyebabake masalah.

Pitakonan tetep babagan carane dipercaya teknologi jaringan modern lan sepira kerepe sistem mudhun amarga gagal jaringan. Informasi babagan masalah iki langka lan riset asring didominasi dening organisasi gedhe kanthi jaringan, peralatan lan personel khusus.

Kanthi tingkat kasedhiyan 99,999% kanggo Spanner (database sing disebarake sacara global Google), Google nyatakake yen mung 7,6% masalah sing gegandhengan karo jaringan. Ing wektu sing padha, perusahaan kasebut nyebut jaringan khusus kasebut minangka "pilar utama" kasedhiyan dhuwur. sinau Bailis lan Kingsbury, sing ditindakake ing 2014, tantangan salah sawijining "misconceptions babagan komputasi disebarake", sing dirumusake Peter Deutsch ing taun 1994. Apa jaringan kasebut pancen dipercaya?

Riset lengkap ing njaba perusahaan raksasa, sing ditindakake kanggo Internet sing luwih akeh, ora ana. Ana uga ora cukup data saka pemain utama babagan apa persentasi masalah pelanggan sing ana hubungane karo jaringan. Kita uga ngerti babagan gangguan ing tumpukan jaringan panyedhiya maya gedhe sing bisa ngilangi kabeh potongan Internet sajrone pirang-pirang jam mung amarga minangka acara profil dhuwur sing mengaruhi akeh wong lan perusahaan. Pateni jaringan bisa nyebabake masalah ing akeh kasus, sanajan ora kabeh kasus kasebut dadi sorotan. Klien layanan awan uga ora ngerti apa-apa babagan panyebab masalah. Yen ana kegagalan, meh mokal kanggo ngubungake kesalahan jaringan ing sisih panyedhiya layanan. Kanggo wong-wong mau, layanan pihak katelu minangka kothak ireng. Ora mungkin kanggo netepake dampak kasebut tanpa dadi panyedhiya layanan gedhe.

Given apa laporan pemain amba bab sistem sing, iku aman kanggo ngomong sampeyan ana ing luck yen kangelan jaringan mung persentasi cilik saka masalah downtime potensial. Komunikasi jaringan isih nandhang sangsara saka perkara biasa kayata kegagalan hardware, owah-owahan topologi, owah-owahan konfigurasi administratif, lan pemadaman listrik. Bubar, aku kaget ngerti yen dhaptar masalah bisa ditambahake cokotan hiu (ya, sampeyan krungu bener).

ASAM tegese macem-macem

Akronim ACID singkatan saka Atomicity, Consistency, Isolation, Reliability. Properti transaksi kasebut ditujokake kanggo njamin kesahihan yen ana kegagalan, kesalahan, kegagalan hardware, lsp. Tanpa ACID utawa skema sing padha, bakal angel kanggo pangembang aplikasi mbedakake antarane tanggung jawab lan tanggung jawab database. Umume basis data transaksional relasional nyoba cocog karo ACID, nanging pendekatan anyar kaya NoSQL wis nyebabake akeh database tanpa transaksi ACID amarga larang kanggo dileksanakake.

Nalika aku pisanan mlebu industri, pimpinan teknis kita ngomong babagan relevansi konsep ACID. Kanggo adil, ACID dianggep minangka gambaran kasar tinimbang standar implementasine sing ketat. Dina iki aku nemokake iku paling migunani amarga ngundakake kategori tartamtu saka masalah (lan nyaranake sawetara solusi bisa).

Ora saben DBMS cocog karo ACID; Ing wektu sing padha, implementasi basis data sing ndhukung ACID mangertos sakumpulan syarat kanthi beda. Salah sawijining sebab kenapa implementasi ACID ora pati jelas amarga akeh trade-off sing kudu ditindakake kanggo ngetrapake syarat ACID. Pangripta bisa uga nampilake database sing cocog karo ACID, nanging interpretasi kasus pinggiran bisa beda-beda sacara dramatis, uga mekanisme kanggo nangani acara "ora mungkin". Paling ora, pangembang bisa entuk pangerten tingkat dhuwur babagan seluk-beluk implementasi dhasar kanggo entuk pangerten sing tepat babagan prilaku khusus lan desain trade-off.

Debat babagan apa MongoDB tundhuk karo syarat ACID terus sanajan sawise diluncurake versi 4. MongoDB wis suwe ora didhukung logging, senajan data standar wis setya menyang disk ora luwih saka sapisan saben 60 detik. Bayangake skenario ing ngisor iki: aplikasi ngirim rong tulisan (w1 lan w2). MongoDB kasil nyimpen w1, nanging w2 ilang amarga gagal hardware.

Diagram sing nggambarake skenario. MongoDB nabrak sadurunge bisa nulis data menyang disk

Nggawe disk minangka proses sing larang. Kanthi ngindhari komitmen sing kerep, pangembang nambah kinerja rekaman kanthi biaya linuwih. MongoDB saiki ndhukung logging, nanging tulisan sing reged isih bisa nyebabake integritas data amarga log dijupuk saben 100ms kanthi standar. Yaiku, skenario sing padha isih bisa ditindakake kanggo log lan owah-owahan sing ditampilake, sanajan risiko kasebut luwih murah.

Saben database duwe konsistensi lan mekanisme isolasi dhewe

Saka syarat ACID, konsistensi lan isolasi nduweni jumlah implementasine sing paling akeh amarga macem-macem trade-off luwih akeh. Sampeyan kudu ngomong yen konsistensi lan isolasi minangka fungsi sing cukup larang. Dheweke mbutuhake koordinasi lan nambah kompetisi kanggo konsistensi data. Kerumitan masalah mundhak sacara signifikan nalika perlu kanggo skala database kanthi horisontal ing sawetara pusat data (utamane yen ana ing wilayah geografis sing beda). Entuk tingkat konsistensi sing dhuwur banget angel, amarga uga nyuda kasedhiyan lan nambah segmentasi jaringan. Kanggo panjelasan sing luwih umum babagan fenomena iki, aku menehi saran supaya sampeyan ngrujuk Teorema CAP. Iku uga worth kang lagi nyimak sing aplikasi bisa nangani jumlah cilik inconsistency, lan programer bisa ngerti nuansa saka masalah uga cukup kanggo ngleksanakake logika tambahan ing aplikasi kanggo nangani inconsistency tanpa gumantung banget ing database kanggo nangani.

DBMS asring nyedhiyakake tingkat isolasi sing beda. Pangembang aplikasi bisa milih sing paling efektif adhedhasar pilihane. Kurang isolasi ngidini kanggo nambah kacepetan, nanging uga nambah risiko lomba data. insulasi dhuwur nyuda kemungkinan iki, nanging slows mudhun karya lan bisa mimpin kanggo kompetisi, kang bakal mimpin kanggo rem kuwi ing basa sing gagal miwiti.

Review model concurrency ana lan hubungan antarane

Standar SQL nemtokake mung papat tingkat isolasi, sanajan ing teori lan praktik ana luwih akeh. Jepson.io nawakake ringkesan banget model concurrency ana. Contone, Google Spanner njamin serializability external karo sinkronisasi jam, lan sanajan iki lapisan isolasi ketat, iku ora ditetepake ing lapisan isolasi standar.

Standar SQL nyebutake tingkat isolasi ing ngisor iki:

Serialisable (paling kenceng lan larang): Eksekusi Serializable duwe efek sing padha karo sawetara eksekusi transaksi berurutan. Eksekusi sekuensial tegese saben transaksi sakteruse mung diwiwiti sawise sing sadurunge rampung. Sampeyan kudu nyatet sing tingkat Serialisable asring dipun ginakaken minangka supaya disebut-isolasi gambar asli seko (contone, ing Oracle) amarga beda interpretasi, sanajan isolasi gambar asli seko dhewe ora dituduhake ing standar SQL.
Wacan sing bisa diulang: Cathetan sing ora setya ing transaksi saiki kasedhiya kanggo transaksi saiki, nanging owah-owahan sing ditindakake dening transaksi liyane (kayata baris anyar) ora katon.
Read komitmen: Data uncommitted ora kasedhiya kanggo transaksi. Ing kasus iki, transaksi mung bisa ndeleng data setya, lan maca phantom bisa kelakon. Yen transaksi nglebokake lan nggawe baris anyar, transaksi saiki bakal bisa ndeleng nalika ditakoni.
Maca ora setya (tingkat paling ketat lan larang): Reged diwaca diijini, transaksi bisa ndeleng owah-owahan uncommitted digawe dening transaksi liyane. Ing praktik, level iki bisa uga migunani kanggo perkiraan kasar, kayata pitakon COUNT(*) ing meja.

Tingkat Serialisable nyilikake risiko lomba data, nalika sing paling larang kanggo ngleksanakake lan asil ing mbukak competitive paling dhuwur ing sistem. Tingkat isolasi liyane luwih gampang ditindakake, nanging nambah kemungkinan balapan data. Sawetara DBMS ngidini sampeyan nyetel tingkat isolasi khusus, liyane duwe pilihan sing kuat lan ora kabeh level didhukung.

Dhukungan kanggo tingkat isolasi asring diiklanake ing DBMS tartamtu, nanging mung sinau kanthi ati-ati babagan prilaku sing bisa mbukak apa sing kedadeyan.

Review anomali concurrency ing tingkat isolasi beda kanggo DBMS beda

Martin Kleppmann ing proyeke pertapaan Mbandhingake tingkat isolasi sing beda-beda, ngobrol babagan anomali konkurensi, lan manawa database bisa netepi level isolasi tartamtu. Riset Kleppmann nuduhake carane beda pangembang database mikir babagan tingkat isolasi.

Pamblokiran optimis bisa nylametake nalika angel njaga sing biasa.

Pamblokiran bisa larang banget, ora mung amarga nambah kompetisi ing database, nanging uga amarga mbutuhake server aplikasi kanggo terus nyambung menyang database. Segmentasi jaringan bisa nambah kahanan ngunci eksklusif lan nyebabake deadlocks sing angel diidentifikasi lan diatasi. Ing kasus nalika ngunci eksklusif ora cocok, ngunci optimistis mbantu.

Kunci optimistis minangka cara nalika maca senar, njupuk versi, checksum, utawa wektu modifikasi pungkasan. Iki ngidini sampeyan mesthekake yen ora ana owah-owahan versi atom sadurunge ngganti entri:

UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1

Ing kasus iki, nganyari tabel products ora bakal ditindakake yen operasi liyane sadurunge nggawe owah-owahan ing baris iki. Yen ora ana operasi liyane sing ditindakake ing baris iki, owah-owahan kanggo siji baris bakal kedadeyan lan kita bisa ujar manawa nganyari kasebut sukses.

Ana anomali liyane kajaba maca reged lan mundhut data

Nalika nerangake konsistensi data, fokus ing potensial kanggo kahanan lomba sing bisa mimpin kanggo maca reged lan mundhut data. Nanging, anomali data ora mandheg ing kono.

Salah sawijining conto anomali kasebut yaiku ngrekam distorsi (nulis miring). Distorsi angel dideteksi amarga biasane ora digoleki kanthi aktif. Padha ora amarga maca reged utawa mundhut data, nanging kanggo nglanggar alangan logis diselehake ing data.

Contone, ayo nimbang aplikasi ngawasi sing mbutuhake siji operator supaya on-call saben wektu:

BEGIN tx1;                      BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0                               SELECT COUNT(*)
                                FROM operators
                                WHERE oncall = TRUE;
                                0
UPDATE operators                UPDATE operators
SET oncall = TRUE               SET oncall = TRUE
WHERE userId = 4;               WHERE userId = 2;
COMMIT tx1;                     COMMIT tx2;

Ing kahanan ing ndhuwur, rekaman korupsi bakal kelakon yen loro transaksi kasil dilakoni. Sanajan ora ana maca sing reged utawa mundhut data, integritas data kasebut dikompromi: saiki wong loro dianggep on-call bebarengan.

Isolasi serial, desain skema, utawa watesan basis data bisa mbantu ngilangi korupsi nulis. Pangembang kudu bisa ngenali anomali kasebut sajrone pangembangan supaya ora ana ing produksi. Ing wektu sing padha, distorsi rekaman angel banget digoleki ing basis kode. Utamane ing sistem gedhe, nalika tim pangembangan beda tanggung jawab kanggo ngleksanakake fungsi adhedhasar tabel sing padha lan ora setuju karo spesifik akses data.

Database lan pangguna ora mesthi setuju apa sing kudu ditindakake

Salah sawijining fitur utama database yaiku njamin urutan eksekusi, nanging pesenan iki bisa uga ora transparan kanggo pangembang piranti lunak. Database nglakokaké transaksi ing urutan sing ditampa, ora ing urutan programer. Urutan transaksi angel diprediksi, utamane ing sistem paralel sing akeh dimuat.

Sajrone pembangunan, utamane nalika nggarap perpustakaan sing ora mblokir, gaya sing ora apik lan keterbacaan sing kurang bisa nyebabake pangguna percaya yen transaksi ditindakake kanthi urutan, nalika nyatane bisa teka ing database kanthi urutan apa wae.

Sepisanan, ing program ing ngisor iki, T1 lan T2 diarani kanthi urutan, nanging yen fungsi kasebut ora mblokir lan langsung ngasilake asil ing wangun janji, banjur urutan telpon bakal ditemtokake dening wektu nalika padha mlebu database:

asil1 = T1 () // asil nyata janji
hasil 2 = T2()

Yen atomicity dibutuhake (yaiku, kabeh operasi kudu rampung utawa dibatalake) lan masalah urutan, banjur operasi T1 lan T2 kudu ditindakake ing siji transaksi.

Sharding tingkat aplikasi bisa dipindhah ing njaba aplikasi

Sharding minangka metode pamisahan database kanthi horisontal. Sawetara database bisa kanthi otomatis pamisah data horisontal, nalika liyane ora bisa, utawa ora banget apik ing. Nalika arsitek data / pangembang bisa prédhiksi persis carane data bakal diakses, padha bisa nggawe partisi horisontal ing ruang panganggo tinimbang delegating karya iki kanggo database. Proses iki diarani "sharding level aplikasi" (Sharding tingkat aplikasi).

Sayange, jeneng iki asring nggawe misconception sing sharding urip ing layanan aplikasi. Ing kasunyatan, bisa dileksanakake minangka lapisan kapisah ing ngarep database. Gumantung ing wutah data lan iterasi skema, syarat sharding bisa dadi cukup rumit. Sawetara strategi bisa entuk manfaat saka kemampuan kanggo ngulang tanpa kudu redeploy server aplikasi.

Conto arsitektur ing ngendi server aplikasi dipisahake saka layanan sharding

Ngalih sharding menyang layanan sing kapisah ngembangake kemampuan kanggo nggunakake strategi sharding sing beda-beda tanpa perlu redeploy aplikasi. Vitess minangka conto sistem sharding ing tingkat aplikasi. Vitess nyedhiyakake sharding horisontal kanggo MySQL lan ngidini klien nyambungake liwat protokol MySQL. Sistem kasebut mbagi data menyang simpul MySQL sing beda-beda sing ora ngerti apa-apa.

Autoincrementing bisa mbebayani

AUTOINCREMENT minangka cara umum kanggo ngasilake kunci utama. Ana asring kasus nalika database digunakake minangka ID generator, lan database ngandhut tabel dirancang kanggo generate pengenal. Ana sawetara alasan kenapa nggawe kunci utama nggunakake nambah otomatis ora cocog:

Ing basis data sing disebarake, nambah otomatis minangka masalah serius. Kanggo ngasilake ID, kunci global dibutuhake. Nanging, sampeyan bisa ngasilake UUID: iki ora mbutuhake interaksi antarane simpul database sing beda. Nambah otomatis kanthi kunci bisa nyebabake perselisihan lan nyuda kinerja sisipan ing kahanan sing disebarake. Sawetara DBMS (contone, MySQL) mbutuhake konfigurasi khusus lan perhatian sing luwih ati-ati kanggo ngatur replikasi master-master kanthi bener. Lan gampang nggawe kesalahan nalika ngatur, sing bakal nyebabake gagal ngrekam.
Sawetara database duwe algoritma pemisahan adhedhasar kunci utama. ID berturut-turut bisa nyebabake hot spot sing ora bisa ditebak lan nambah beban ing sawetara partisi nalika liyane tetep nganggur.
Kunci utama minangka cara paling cepet kanggo ngakses baris ing basis data. Kanthi cara sing luwih apik kanggo ngenali cathetan, ID urutan bisa ngowahi kolom sing paling penting ing tabel dadi kolom sing ora ana guna sing diisi nilai sing ora ana gunane. Mula, yen bisa, pilih kunci utama sing unik lan alami (contone, jeneng pangguna).

Sadurunge mutusake pendekatan, nimbang pengaruh ID nambah otomatis lan UUID ing indeksasi, partisi, lan sharding.

Data basi bisa migunani lan ora mbutuhake ngunci

Multiversion Concurrency Control (MVCC) ngetrapake akeh syarat konsistensi sing dibahas ing ndhuwur. Sawetara database (contone, Postgres, Spanner) nggunakake MVCC kanggo "feed" transaksi karo snapshots-versi lawas saka database. Transaksi snapshot uga bisa serial kanggo mesthekake konsistensi. Nalika maca saka snapshot lawas, data lawas diwaca.

Maca data sing rada basi bisa migunani, contone, nalika ngasilake analytics saka data utawa ngitung nilai agregat.

Kauntungan pisanan nggarap data warisan yaiku latensi sing sithik (utamane yen basis data disebar ing macem-macem geografi). Kapindho yaiku transaksi mung diwaca ora dikunci. Iki minangka kauntungan pinunjul kanggo aplikasi sing maca akeh, anggere bisa nangani data basi.

Server aplikasi maca data saka replika lokal sing kedaluwarsa 5 detik, sanajan versi paling anyar kasedhiya ing sisih liya Samudra Pasifik

DBMS kanthi otomatis ngresiki versi lawas lan, ing sawetara kasus, ngidini sampeyan nindakake iki miturut panyuwunan. Contone, Postgres ngidini pangguna nindakake VACUUM ing panyuwunan, lan uga periodik nindakake operasi iki kanthi otomatis. Spanner mbukak tukang sampah kanggo nyingkirake jepretan sing luwih lawas saka jam.

Sembarang sumber wektu tundhuk distorsi

Rahasia paling apik ing ilmu komputer yaiku kabeh API wektu ngapusi. Nyatane, mesin kita ora ngerti wektu saiki sing tepat. Komputer ngemot kristal kuarsa sing ngasilake getaran sing digunakake kanggo njaga wektu. Nanging, dheweke ora cukup akurat lan bisa uga ana ing ngarep / ketinggalan wektu sing tepat. Shift bisa tekan 20 detik saben dina. Mulane, wektu ing komputer kita kudu disinkronake kanthi periodik karo jaringan.

Server NTP digunakake kanggo sinkronisasi, nanging proses sinkronisasi dhewe kena tundha jaringan. Malah nyinkronake karo server NTP ing pusat data sing padha mbutuhake sawetara wektu. Cetha yen nggarap server NTP umum bisa nyebabake distorsi sing luwih gedhe.

Jam atom lan pasangan GPS luwih apik kanggo nemtokake wektu saiki, nanging larang lan mbutuhake persiyapan sing rumit, mula ora bisa diinstal ing saben mobil. Amarga iki, pusat data nggunakake pendekatan berjenjang. Jam atom lan/utawa GPS nuduhake wektu sing tepat, banjur disiarake menyang mesin liyane liwat server sekunder. Iki tegese saben mesin bakal ngalami offset tartamtu saka wektu sing tepat.

Kahanan kasebut saya tambah akeh amarga aplikasi lan basis data asring ana ing mesin sing beda (yen ora ana ing pusat data sing beda). Mangkono, wektu bakal beda-beda ora mung ing kelenjar DB sing disebarake ing macem-macem mesin. Uga bakal beda ing server aplikasi.

Google TrueTime njupuk pendekatan sing beda banget. Umume wong percaya yen kemajuan Google ing arah iki diterangake kanthi transisi banal menyang jam atom lan GPS, nanging iki mung bagean saka gambar gedhe. Mangkene carane TrueTime bisa digunakake:

TrueTime nggunakake rong sumber sing beda: GPS lan jam atom. Jam iki duwe mode kegagalan sing ora ana hubungane. [ndeleng kaca 5 kanggo katrangan kene - kira-kira. transl.), supaya panggunaan bebarengan nambah linuwih.
TrueTime duwe API sing ora biasa. Iki ngasilake wektu minangka interval kanthi kesalahan pangukuran lan kahanan sing durung mesthi. Wektu nyata ing wektu ana ing antarane wates ndhuwur lan ngisor interval. Spanner, basis data sing disebarake Google, mung ngenteni nganti aman kanggo ngomong yen wektu saiki ora ana jangkauan. Cara iki ngenalake sawetara latensi menyang sistem, utamane yen kahanan sing durung mesthi ing master dhuwur, nanging njamin bener sanajan ing kahanan sing disebarake sacara global.

Komponen Spanner nggunakake TrueTime, ngendi TT.now () ngasilake interval, supaya Spanner mung turu nganti titik sing bisa manteb ing ati sing wektu saiki wis liwati titik tartamtu.

Suda akurasi kanggo nemtokake wektu saiki tegese nambah durasi operasi Spanner lan nyuda kinerja. Pramila penting kanggo njaga akurasi sing paling dhuwur sanajan ora bisa entuk jam tangan sing akurat.

Tundha duwe akeh makna

Yen sampeyan takon rolas ahli babagan apa wektu tundha, sampeyan bakal entuk jawaban sing beda. Ing latensi DBMS asring diarani "latensi basis data" lan beda karo sing dirasakake klien. Kasunyatan iku klien mirsani jumlah wektu tundha jaringan lan tundha database. Kemampuan kanggo ngisolasi jinis latensi iku penting nalika debugging masalah sing saya akeh. Nalika ngumpulake lan nampilake metrik, tansah nyoba kanggo njaga mripat ing loro jinis.

Persyaratan kinerja kudu dievaluasi kanggo transaksi tartamtu

Kadhangkala karakteristik kinerja DBMS lan watesan kasebut ditemtokake ing babagan nulis / maca throughput lan latensi. Iki nyedhiyakake ringkesan umum paramèter sistem kunci, nanging nalika ngevaluasi kinerja DBMS anyar, pendekatan sing luwih lengkap yaiku ngevaluasi operasi kritis kanthi kapisah (kanggo saben pitakon lan/utawa transaksi). Tuladha:

Tulis throughput lan latensi nalika nglebokake baris anyar menyang tabel X (kanthi 50 yuta larik) kanthi watesan tartamtu lan bantalan baris ing tabel sing gegandhengan.
Wektu tundha nampilake kanca kanca pangguna tartamtu nalika jumlah kanca rata-rata 500.
Latensi kanggo njupuk 100 entri paling dhuwur saka riwayat pangguna nalika pangguna ngetutake 500 pangguna liyane kanthi entri X saben jam.

Evaluasi lan eksperimen bisa uga kalebu kasus kritis kasebut nganti sampeyan yakin manawa database kasebut cocog karo syarat kinerja. Aturan jempol sing padha uga njupuk risak iki nalika ngumpulake metrik latensi lan nemtokake SLO.

Waca kardinalitas dhuwur nalika ngumpulake metrik kanggo saben operasi. Gunakake log, koleksi acara, utawa tracing sing disebarake kanggo entuk data debugging kanthi daya dhuwur. Ing artikel "Pengin Debug Latency?»Sampeyan bisa akrab karo metodologi debugging tundha.

Transaksi nested bisa mbebayani

Ora saben DBMS ndhukung transaksi nested, nanging nalika nindakake, transaksi kasebut bisa nyebabake kesalahan sing ora dikarepke sing ora gampang dideteksi (yaiku, mesthine ana sawetara anomali).

Sampeyan bisa ngindhari nggunakake transaksi bersarang nggunakake perpustakaan klien sing bisa ndeteksi lan ngliwati. Yen transaksi bersarang ora bisa ditinggalake, ati-ati khusus ing implementasine kanggo ngindhari kahanan sing ora dikarepke nalika transaksi sing wis rampung ora sengaja dibatalake amarga ana sing bersarang.

Transaksi encapsulating ing lapisan sing beda-beda bisa nyebabake transaksi nested sing ora dikarepke, lan saka sudut pandang readability kode, bisa dadi angel kanggo mangerteni maksud penulis. Deleng program ing ngisor iki:

with newTransaction():
   Accounts.create("609-543-222")
   with newTransaction():
       Accounts.create("775-988-322")
       throw Rollback();

Apa sing bakal dadi output saka kode ing ndhuwur? Apa bakal muter maneh transaksi loro, utawa mung sing njero? Apa sing kedadeyan yen kita ngandelake pirang-pirang lapisan perpustakaan sing nggawe transaksi kanggo kita? Apa kita bakal bisa ngenali lan nambah kasus kaya ngono?

Bayangake lapisan data kanthi macem-macem operasi (contone. newAccount) wis dileksanakake ing transaksi dhewe. Apa sing kedadeyan yen sampeyan mbukak minangka bagean saka logika bisnis tingkat sing luwih dhuwur sing mlaku ing transaksi dhewe? Apa isolasi lan konsistensi ing kasus iki?

function newAccount(id string) {
  with newTransaction():
      Accounts.create(id)
}

Tinimbang nggoleki jawaban kanggo pitakonan sing ora ana telas kasebut, luwih becik ngindhari transaksi bersarang. Sawise kabeh, lapisan data sampeyan bisa kanthi gampang nindakake operasi tingkat dhuwur tanpa nggawe transaksi dhewe. Kajaba iku, logika bisnis dhewe bisa miwiti transaksi, nindakake operasi kasebut, nindakake utawa mbatalake transaksi.

function newAccount(id string) {
   Accounts.create(id)
}
// In main application:
with newTransaction():
   // Read some data from database for configuration.
   // Generate an ID from the ID service.
   Accounts.create(id)
   Uploads.create(id) // create upload queue for the user.

Transaksi ngirim ora disambungake menyang negara aplikasi

Kadhangkala nggodho nggunakake negara aplikasi ing transaksi kanggo ngganti nilai tartamtu utawa paramèter pitakon tweak. Nuansa kritis sing kudu ditimbang yaiku ruang lingkup aplikasi sing bener. Klien asring miwiti maneh transaksi nalika ana masalah jaringan. Yen transaksi banjur gumantung ing negara sing lagi diganti dening sawetara proses liyane, iku bisa milih nilai salah gumantung ing kamungkinan saka lomba data. Transaksi kudu nimbang risiko kahanan lomba data ing aplikasi.

var seq int64
with newTransaction():
    newSeq := atomic.Increment(&seq)
    Entries.query(newSeq)
    // Other operations...

Transaksi ing ndhuwur bakal nambah nomer urutan saben-saben dieksekusi, preduli saka asil pungkasan. Yen komit gagal amarga masalah jaringan, panyuwunan bakal dileksanakake kanthi nomer urutan sing beda nalika sampeyan nyoba maneh.

Perencana pitakon bisa ngandhani akeh babagan database

Perencana pitakon nemtokake cara query bakal dieksekusi ing basis data. Dheweke uga nganalisa panjaluk lan ngoptimalake sadurunge dikirim. Planners mung bisa nyedhiyani sawetara prakiraan bisa adhedhasar sinyal ing pembuangan. Contone, apa cara telusuran sing paling apik kanggo pitakon ing ngisor iki?

SELECT * FROM articles where author = "rakyll" order by title;

Asil bisa dijupuk kanthi rong cara:

Scan tabel lengkap: Sampeyan bisa ndeleng ing saben entri ing tabel lan bali artikel karo jeneng penulis cocog, lan banjur supaya wong.
Pindai indeks: Sampeyan bisa nggunakake indeks kanggo nemokake ID sing cocog, njaluk larik kasebut, banjur dhawuh.

Tugas perencana pitakon yaiku nemtokake strategi sing paling apik. Perlu dipikirake manawa perencana pitakon mung duwe kemampuan prediksi sing winates. Iki bisa nyebabake keputusan sing ala. DBA utawa pangembang bisa digunakake kanggo diagnosa lan nyetel pitakon sing kurang apik. Versi anyar saka DBMS bisa ngonfigurasi perencana pitakon, lan diagnosis mandiri bisa mbantu nalika nganyari database yen versi anyar nyebabake masalah kinerja. Log pitakon alon, laporan masalah latensi, utawa statistik wektu eksekusi bisa mbantu ngenali pitakon sing mbutuhake optimasi.

Sawetara metrik sing diwenehake dening perencana pitakon bisa uga kena gangguan (utamane nalika ngira latensi utawa wektu CPU). Tambahan sing apik kanggo panjadwal yaiku alat kanggo nglacak lan nglacak jalur eksekusi. Dheweke ngidini sampeyan diagnosa masalah kasebut (alas, ora kabeh DBMS nyedhiyakake alat kasebut).

Migrasi online angel nanging bisa

Migrasi online, migrasi langsung, utawa migrasi wektu nyata tegese pindhah saka siji database menyang database liyane tanpa downtime utawa korupsi data. Migrasi langsung luwih gampang ditindakake yen transisi dumadi ing DBMS/mesin sing padha. Kahanan dadi luwih rumit nalika kudu pindhah menyang DBMS anyar kanthi syarat kinerja lan skema sing beda.

Ana macem-macem model migrasi online. Punika salah satunggalipun:

Aktifake entri pindho ing loro database. Basis data anyar ing tahap iki ora duwe kabeh data, nanging mung nampa data paling anyar. Sawise sampeyan yakin babagan iki, sampeyan bisa nerusake menyang langkah sabanjure.
Aktifake maca saka loro database.
Konfigurasi sistem supaya maca lan nulis ditindakake utamane ing database anyar.
Mungkasi nulis menyang database lawas nalika terus maca data saka iku. Ing tataran iki, database anyar isih tanpa sawetara data. Padha kudu disalin saka database lawas.
Basis data lawas mung diwaca. Nyalin data sing ilang saka database lawas menyang sing anyar. Sawise migrasi rampung, ngalih path menyang database anyar, lan mungkasi lawas lan mbusak saka sistem.

Kanggo informasi tambahan, aku saranake hubungi artikel, sing rincian strategi migrasi Stripe adhedhasar model iki.

Tambah pinunjul ing database entails Tambah ing unpredictability

Wutah basis data nyebabake masalah sing ora bisa diprediksi sing ana gandhengane karo skala. Sing luwih ngerti babagan struktur internal database, luwih apik kita bisa prédhiksi kepiye ukurane. Nanging, sawetara wektu isih ora bisa diramalake.
Nalika basis tuwuh, asumsi lan pangarepan sadurunge babagan volume data lan syarat bandwidth jaringan bisa dadi ketinggalan jaman. Iki nalika pitakonan muncul babagan perombakan desain utama, perbaikan operasional skala gedhe, panyebaran maneh, utawa migrasi menyang DBMS liyane kanggo ngindhari masalah potensial.

Nanging aja mikir yen kawruh banget babagan struktur internal database sing ana mung siji-sijine sing perlu. Timbangan anyar bakal nggawa wong anyar sing ora dingerteni. Titik nyeri sing ora bisa ditebak, distribusi data sing ora rata, bandwidth lan masalah hardware sing ora dikarepke, lalu lintas sing terus saya tambah lan segmen jaringan anyar bakal meksa sampeyan mikir maneh pendekatan database, model data, model penyebaran, lan ukuran database.

...

Nalika aku wiwit mikir babagan nerbitake artikel iki, wis ana limang item liyane ing dhaptar asliku. Banjur teka nomer ageng gagasan anyar babagan apa maneh sing bisa ditutupi. Mulane, artikel kasebut nyentuh masalah sing paling ora jelas sing mbutuhake perhatian maksimal. Nanging, iki ora ateges topik kasebut wis kesel lan aku ora bakal bali maneh ing materi sing bakal teka lan ora bakal ngganti sing saiki.

PS

Waca uga ing blog kita:

Source: www.habr.com

Pangembang liyane kudu ngerti babagan database