Ya, TiDB ditulis dalam bahasa go. TiDB ialah pangkalan data NewSQL yang diedarkan ia menyokong pengembangan anjal mendatar, urus niaga ACID, SQL standard, sintaks MySQL dan protokol MySQL, dan mempunyai ketekalan data yang kukuh dan ciri ketersediaan tinggi. PD dalam seni bina TiDB menyimpan maklumat meta kluster, seperti nod TiKV yang dihidupkan oleh PD juga bertanggungjawab untuk pengimbangan beban dan pembahagian data kluster. PD menyokong pengedaran data dan toleransi kesalahan dengan membenamkan dsb; PD ditulis dalam bahasa go.
Persekitaran pengendalian tutorial ini: sistem Windows 7, GO versi 1.18, komputer Dell G3.
Terdapat banyak projek heavyweight dalam bahasa Go, dan projek sumber terbuka Go yang paling berkuasa di China mungkin TiDB. TiDB ialah pangkalan data yang diedarkan, yang mungkin tidak diketahui oleh ramai orang. Izinkan saya bercakap dengan anda tentang topik ini hari ini.
TiDB mempunyai reka bentuk yang ringkas, dan tapak web serta kod rasminya sangat mudah dibaca Ia merupakan projek sumber terbuka pilihan pertama untuk mempelajari pangkalan data teragih.
Pangkalan data, sistem pengendalian dan pengkompil secara kolektif dipanggil tiga sistem utama, yang boleh dikatakan sebagai asas kepada keseluruhan perisian komputer.
Ramai orang telah menggunakan pangkalan data, tetapi hanya sedikit yang melaksanakan pangkalan data, terutamanya pangkalan data teragih. Memahami prinsip pelaksanaan dan butiran pangkalan data boleh, dalam satu pihak, meningkatkan kemahiran peribadi dan membantu membina sistem lain, dan sebaliknya, ia juga boleh membantu menggunakan pangkalan data dengan baik.
TiDB ialah pangkalan data NewSQL yang diedarkan . Ia menyokong pengembangan elastik mendatar, transaksi ACID, SQL standard, sintaks MySQL dan protokol MySQL, dan mempunyai ciri ketersediaan tinggi konsistensi data yang kukuh Ia bukan sahaja sesuai untuk OLTP senario tetapi juga OLAP Pangkalan data hibrid untuk senario.
OLTP: Pemprosesan Transaksi Dalam Talian, dalam talian pemprosesan transaksi.
OLAP: Pemprosesan Analitik Dalam Talian, dalam talian pemprosesan analitik .
TiDB sangat serasi dengan protokol MySQL 5.7, MySQL 5.7 biasa fungsi dan tatabahasa. Walaupun TiDB menyokong sintaks dan protokol MySQL, TiDB ialah produk yang dibangunkan sepenuhnya secara bebas oleh pasukan PingCAP dan tidak dibangunkan berdasarkan MySQL.
Alat sistem (PHPMyAdmin, Navicat, MySQL Workbench, mysqldump, Mydumper, Myloader), pelanggan, dll. dalam ekosistem MySQL 5.7 semuanya boleh digunakan untuk TiDB.
TiDB pada masa ini tidak menyokong pencetus, prosedur tersimpan, fungsi tersuai dan kunci asing.
TiDB sangat mudah digunakan Anda boleh menggunakan gugusan TiDB sebagai MySQL boleh digunakan dalam mana-mana aplikasi yang menggunakan MySQL sebagai perkhidmatan storan bahagian belakang, dan pada asasnya tidak perlu mengubah suai kod aplikasi Pada masa yang sama, alat pengurusan MySQL yang paling popular boleh digunakan untuk mengurus TiDB.
Selagi bahasa pengaturcaraan menyokong Klien/Pemandu MySQL, anda boleh menggunakan TiDB secara langsung.
Sama ada beberapa nod di satu tempat atau merentasi berbilang pusat data Untuk berbilang nod , TiDB menyokong transaksi yang diedarkan ACID .
Model transaksi TiDB diilhamkan oleh Google Model Percolator Badan utama ialah protokol komit dua fasa, dengan beberapa praktikal. pengoptimuman. Model ini bergantung pada penugas cap masa yang memberikan cap masa yang meningkat secara monoton pada setiap transaksi supaya konflik transaksi dikesan. Dalam kelompok TiDB, PD memainkan peranan pengedar cap masa .
TiDB tidak perlu menyokong XA untuk memenuhi transaksi merentas pangkalan data seperti model urus niaga teragih TiDO sendiri jauh lebih tinggi daripada XA dari segi prestasi dan kestabilan, jadi ia tidak Tidak perlu menyokong XA. .
Berbanding dengan pangkalan data bersendirian tradisional, TiDB mempunyai kelebihan berikut:
Ringkasnya, TiDB sesuai untuk senario dengan ciri berikut：
Satu klik pengembangan atau pengurangan mendatar
Terima kasih kepada reka bentuk seni bina storan dan pemisahan pengiraan TiDB, pengiraan boleh dilakukan atas permintaan , dan storan dikembangkan atau dikurangkan masing-masing dalam talian, dan proses pengembangan atau pengurangan adalah telus kepada kakitangan operasi dan penyelenggaraan aplikasi.
Ketersediaan tinggi gred kewangan
Data disimpan dalam berbilang salinan dan salinan data menyegerakkan log transaksi melalui protokol Multi-Raft , hanya transaksi yang berjaya yang ditulis oleh majoriti boleh diserahkan, memastikan konsistensi data yang kukuh dan kegagalan beberapa replika tidak menjejaskan ketersediaan data. Strategi seperti lokasi geografi replika dan bilangan replika boleh dikonfigurasikan mengikut keperluan untuk memenuhi keperluan tahap toleransi bencana yang berbeza.
HTAP masa nyata
Menyediakan dua enjin storan: enjin storan baris TiKV dan enjin storan lajur TiFlash lulus protokol Multi -The Raft Learner menyalin data daripada TiKV dalam masa nyata, memastikan konsistensi data yang kukuh antara enjin storan baris TiKV dan enjin storan lajur TiFlash. TiKV dan TiFlash boleh digunakan pada mesin yang berbeza atas permintaan untuk menyelesaikan masalah pengasingan sumber HTAP.
Pangkalan data teragih asli awan
Pangkalan data teragih yang direka khas untuk awan, tersedia melalui penggunaan TiDB Operator Implement alatan dan automasi dalam awan awam, awan peribadi dan awan hibrid.
Serasi dengan protokol MySQL 5.7 dan ekosistem MySQL
Serasi dengan protokol MySQL 5.7, fungsi biasa MySQL, ekosistem MySQL , Aplikasi boleh dipindahkan daripada MySQL ke TiDB tanpa memerlukan atau mengubah suai sejumlah kecil kod. Menyediakan pelbagai alatan migrasi data untuk membantu aplikasi menyelesaikan migrasi data dengan mudah.
Selaras dengan Senario data dengan atribut industri kewangan yang memerlukan prestasi tinggi, kebolehpercayaan yang tinggi, ketersediaan sistem yang tinggi, skalabiliti dan pemulihan bencana
Seperti yang kita semua tahu, industri kewangan mempunyai keperluan yang tinggi untuk konsistensi data, kebolehpercayaan yang tinggi , dan sistem tinggi Keperluan Ketersediaan, skalabiliti dan pemulihan bencana adalah tinggi. Penyelesaian tradisional ialah dua bilik komputer di bandar yang sama menyediakan perkhidmatan, dan satu bilik komputer di tempat lain menyediakan keupayaan pemulihan bencana data tetapi tiada perkhidmatan Penyelesaian ini mempunyai kelemahan berikut: penggunaan sumber yang rendah, kos penyelenggaraan yang tinggi, RTO (Objektif Masa Pemulihan) dan RPO (Objektif Titik Pemulihan) tidak boleh benar-benar mencapai nilai yang diharapkan oleh perusahaan. TiDB menggunakan protokol Multi-Raft berbilang salinan untuk menjadualkan data ke bilik komputer, rak dan mesin yang berbeza Apabila sesetengah mesin gagal, sistem boleh bertukar secara automatik untuk memastikan bahawa RTO sistem
Data besar-besaran dan senario OLTP berkonkurensi tinggi dengan kapasiti storan, kebolehskalaan dan keperluan konkurensi yang tinggi
Dengan perkembangan pesat perniagaan, data telah menunjukkan pertumbuhan yang meletup Pangkalan data bersendirian tradisional tidak dapat memenuhi keperluan kapasiti pangkalan data disebabkan oleh pertumbuhan data yang meletup Penyelesaian yang boleh dilaksanakan adalah dengan menggunakan produk middleware dengan sub-pangkalan data dan sub-jadual atau NewSQL pangkalan data untuk menggantikan atau menggunakan peranti Storan mewah, dsb. Yang paling menjimatkan kos antaranya ialah pangkalan data NewSQL, seperti TiDB. TiDB mengguna pakai seni bina pengkomputeran dan pemisahan storan, yang masing-masing boleh mengembangkan dan mengecilkan pengkomputeran dan storan Pengkomputeran menyokong maksimum 512 nod, setiap nod menyokong maksimum 1000 serentak, dan kapasiti kluster menyokong tahap PB maksimum.
Senario HTAP masa nyata
Dengan perkembangan pesat 5G, Internet of Things dan kecerdasan buatan, perusahaan Semakin banyak data akan dihasilkan, dan skalanya mungkin mencapai ratusan tahap TB atau bahkan PB Penyelesaian tradisional adalah untuk memproses transaksi dalam talian melalui pangkalan data OLTP, dan menggunakan alat ETL untuk menyegerakkan data ke pangkalan data OLAP untuk analisis data. Penyelesaian pemprosesan ini mempunyai banyak masalah seperti kos penyimpanan yang tinggi dan prestasi masa nyata yang lemah. TiDB memperkenalkan enjin storan lajur TiFlash dalam versi 4.0 dan menggabungkannya dengan enjin storan baris TiKV untuk membina pangkalan data HTAP sebenar Dengan peningkatan kecil dalam kos storan, pemprosesan transaksi dalam talian dan analisis data masa nyata boleh dilakukan dalam sistem yang sama , sangat menjimatkan kos perusahaan.
Pengagregatan data dan senario pemprosesan sekunder
Pada masa ini, data perniagaan kebanyakan perusahaan bertaburan dalam sistem yang berbeza tanpa ringkasan bersatu Semasa perniagaan berkembang, tahap membuat keputusan perusahaan perlu memahami status perniagaan keseluruhan syarikat untuk membuat keputusan tepat pada masanya. , jadi adalah perlu untuk Mengumpul data yang bertaburan dalam pelbagai sistem ke dalam sistem yang sama dan melakukan pemprosesan sekunder untuk menjana laporan T 0 atau T 1. Penyelesaian biasa tradisional ialah menggunakan ETL Hadoop untuk melengkapkannya, tetapi sistem Hadoop terlalu kompleks, dan kos operasi dan penyelenggaraan serta penyimpanan terlalu tinggi untuk memenuhi keperluan pengguna. Berbanding dengan Hadoop, TiDB adalah lebih mudah. Perniagaan menyegerakkan data ke TiDB melalui alat ETL atau alat penyegerakan TiDB boleh dijana secara langsung dalam TiDB melalui SQL.
TiDB ialah sistem teragih. Kelompok ujian TiDB yang paling asas biasanya terdiri daripada 2 tika TiDB, 3 tika TiKV, 3 tika PD dan tika TiFlash pilihan. Melalui TiUP Playground, anda boleh membina kluster ujian asas di atas dengan cepat. Langkah-langkahnya adalah seperti berikut:
langkah1.
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
Selepas pemasangan selesai, ia akan memaparkan:
Successfully set mirror to https://tiup-mirrors.pingcap.com Detected shell: bash Shell profile: /home/user/.bashrc /home/user/.bashrc has been modified to add tiup to PATH open a new terminal or source /home/user/.bashrc to use it Installed path: /home/user/.tiup/bin/tiup =============================================== Have a try: tiup playground ===============================================
langkah 2. Isytiharkan pembolehubah persekitaran global. source ${your_shell_profile}
source /home/user/.bashrc
langkah3. Jalankan arahan berikut dalam sesi semasa untuk memulakan kluster.
tiup playground
langkah4, pengesahan. [Kini anda boleh menggunakan TiDB sama seperti MySQL]
#新开启一个 session 以访问 TiDB 数据库。 #使用 TiUP client 连接 TiDB： tiup client #也可使用 MySQL 客户端连接 TiDB mysql --host 127.0.0.1 --port 4000 -u root #通过 http://127.0.0.1:9090 访问 TiDB 的 Prometheus 管理界面。 #通过 http://127.0.0.1:2379/dashboard 访问 TiDB Dashboard 页面，默认用户名为 root，密码为空。 #通过 http://127.0.0.1:3000 访问 TiDB 的 Grafana 界面，默认用户名和密码都为 admin。
PD menyimpan maklumat meta gugusan, seperti kunci nod TiKV dihidupkan; PD juga Bertanggungjawab untuk pengimbangan beban kelompok dan serpihan data. PD menyokong pengedaran data dan toleransi kesalahan dengan membenamkan dsb. PD ditulis dalam bahasa go.
TiKV ialah enjin storan Nilai-Kunci teragih yang menyediakan urus niaga Ia direka berdasarkan Google Spanner dan HBase, tetapi dipisahkan daripada yang asas HDFS yang kompleks. Simpan nilai nilai kunci dalam cakera tempatan melalui RocksDB, dan gunakan protokol Raft untuk replikasi untuk mengekalkan konsistensi data dan pemulihan bencana. TiKV ditulis dalam bahasa Rust.
enjin Nilai-Kunci yang diedarkan secara global ] dan cara mencapai toleransi kesalahan berbilang salinan. Nod Storan
Pelayan TiKV: Bertanggungjawab untuk menyimpan data Dari luar, TiKV ialah enjin storan Nilai Kunci yang diedarkan yang menyediakan transaksi. Unit asas untuk menyimpan data ialah Rantau Setiap Rantau bertanggungjawab untuk menyimpan data Julat Utama (julat kiri-tertutup dan kanan-buka dari StartKey ke EndKey Setiap nod TiKV bertanggungjawab untuk berbilang Wilayah. API TiKV menyediakan sokongan asli untuk urus niaga teragih pada tahap pasangan nilai kunci KV, dan menyediakan tahap pengasingan SI (Snapshot) secara lalai, yang juga merupakan teras sokongan TiDB untuk transaksi teragih di peringkat SQL. Selepas lapisan SQL TiDB melengkapkan penghuraian SQL, ia akan menukar pelan pelaksanaan SQL menjadi panggilan sebenar kepada API TiKV. Oleh itu, data disimpan dalam TiKV. Di samping itu, data dalam TiKV secara automatik mengekalkan berbilang salinan (tiga salinan secara lalai), secara semula jadi menyokong ketersediaan tinggi dan failover automatik. TiFlash: TiFlash ialah jenis nod storan khas. Berbeza daripada nod TiKV biasa, dalam TiFlash, data disimpan dalam bentuk kolumnar, dan fungsi utamanya adalah untuk mempercepatkan senario analisis.
1. Bolehkah ia menyokong pemulihan bencana pusat data?
2. Adakah kelajuan menulis cukup pantas? 3. Selepas data disimpan, adakah ia mudah dibaca?
4. Bagaimana untuk mengubah suai data yang disimpan? Bagaimana untuk menyokong pengubahsuaian serentak?
5. Bagaimana untuk mengubah suai berbilang rekod secara atom?
Projek TiKV menyelesaikan masalah di atas dengan baik. Jadi
TiKV menggunakan Raft untuk replikasi data Setiap perubahan data akan direkodkan sebagai log Raft fungsi replikasi menyegerakkan data kepada kebanyakan nod Kumpulan dengan selamat dan boleh dipercayai. TiKV tidak memilih untuk menulis data terus ke cakera sebaliknya, ia menyimpan data dalam RocksDB RocksDB bertanggungjawab untuk pelaksanaan data tertentu. [RocksDB ialah enjin storan bersendirian sumber terbuka yang sangat baik . 】 Dengan menggunakan algoritma konsensus Raft, data disalin ke dalam berbilang salinan antara nod TiKV untuk memastikan keselamatan data apabila nod gagal. Sebenarnya, di bawah hud, TiKV menggunakan model Mesin Negeri log replikasi (Mesin Negeri) untuk mereplikasi data. Untuk permintaan tulis, data ditulis kepada Pemimpin, yang kemudiannya menyalin arahan kepada Pengikutnya dalam bentuk log. Apabila majoriti nod dalam kluster menerima log ini, log itu dilakukan dan mesin keadaan berubah dengan sewajarnya. Untuk sistem KV, terdapat dua penyelesaian biasa untuk mengedarkan data pada berbilang mesin: satu ialah Hash dilakukan berdasarkan Kunci, dan nod storan yang sepadan dipilih berdasarkan nilai Hash; yang satu lagi adalah untuk membahagikan Julat, dan Kunci berterusan tertentu disimpan pada nod storan. Untuk menyokong pertanyaan julat, TiKV memilih kaedah kedua, membahagikan keseluruhan ruang Nilai-Kekunci kepada banyak segmen, setiap segmen ialah satu siri Kunci berturut-turut, kami memanggil setiap segmen sebagai Rantau, dan kami akan cuba memastikan data yang disimpan di setiap Rantau tidak melebihi saiz tertentu (saiz ini boleh dikonfigurasikan, pada masa ini lalai ialah 96Mb). Setiap Wilayah boleh diterangkan dengan selang kiri-tutup dan kanan buka dari StartKey ke EndKey. Selepas membahagikan data kepada Wilayah, dua perkara penting akan dilakukan: Gunakan Rantau sebagai unit, sebarkan data pada semua nod dalam gugusan dan cuba pastikan bilangan Wilayah yang disampaikan pada setiap nod adalah lebih kurang sama. Data dibahagikan kepada banyak Wilayah mengikut Kekunci, dan data setiap Wilayah hanya akan disimpan pada satu nod. Sistem kami akan mempunyai komponen [PD] yang bertanggungjawab untuk mengagihkan Wilayah sekata yang mungkin pada semua nod dalam kelompok, jadi pada satu pihak ia mencapai pengembangan kapasiti storan mendatar (selepas menambah nod baharu, Wilayah pada nod lain akan dijadualkan secara automatik). Sebaliknya, pengimbangan beban juga dicapai (tidak akan ada situasi di mana nod tertentu mempunyai banyak data dan nod lain mempunyai sedikit data). Pada masa yang sama, untuk memastikan pelanggan lapisan atas boleh mengakses data yang diperlukan, komponen [PD] dalam sistem juga akan merekodkan pengedaran Rantau pada nod Iaitu, melalui mana-mana Kunci, anda boleh pertanyaan di Rantau mana Kunci berada, dan nod mana Rantau sedang dihidupkan. Lakukan replikasi Rakit dan pengurusan ahli dalam unit Wilayah. TiKV mereplikasi data dalam unit Wilayah, iaitu, data Wilayah akan menyimpan berbilang salinan, dan setiap salinan dipanggil Replika. Replika menggunakan Raft untuk mengekalkan konsistensi data (akhirnya disebut Raft Berbilang Replika dalam Wilayah akan disimpan pada nod yang berbeza untuk membentuk Kumpulan Rakit). Satu Replika akan bertindak sebagai Ketua Kumpulan ini, dan satu lagi Replika akan bertindak sebagai Pengikut. Semua bacaan dan penulisan dilakukan melalui Pemimpin, yang kemudiannya disalin kepada Pengikut. Setelah memahami Wilayah, anda seharusnya dapat memahami gambar berikut: Data dilakukan di Wilayah Dengan penyebaran dan replikasi, anda mempunyai sistem KeyValue teragih dengan keupayaan toleransi bencana tertentu Anda tidak perlu lagi bimbang tentang kehilangan data atau kegagalan cakera menyebabkan kehilangan data. Jika dua Pelanggan mengubah suai Nilai Kunci pada masa yang sama, jika tiada MVCC, data perlu dikunci , dalam senario yang diedarkan, ia boleh menyebabkan masalah prestasi dan kebuntuan. Pelaksanaan MVCC TiKV dilaksanakan dengan menambahkan Versi selepas Kunci. 对于同一个 Key 的多个版本，把版本号较大的放在前面，版本号小的放在后面。这样当用户通过一个 Key + Version 来获取 Value 的时候，可以将 Key 和 Version 构造出 MVCC 的 Key，也就是 Key-Version。然后可以直接 Seek(Key-Version)，定位到第一个大于等于这个 Key-Version 的位置。 TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。Garbage Collection (GC) 的任务便是清理不再需要的旧数据。 一个 TiDB 集群中会有一个 TiDB 实例被选举为 GC leader，GC 的运行由 GC leader 来控制。 GC 会被定期触发。每次 GC 时，首先，TiDB 会计算一个称为 safe point 的时间戳，接下来 TiDB 会在保证 safe point 之后的快照全部拥有正确数据的前提下，删除更早的过期数据。每一轮 GC 分为以下三个步骤： step1：“Resolve Locks” 【清理锁】阶段会对所有 Region 扫描 safe point 之前的锁，并清理这些锁。 step2：“Delete Ranges” 【删除区间】阶段快速地删除由于 step3：“Do GC”【进行GC清理】阶段每个 TiKV 节点将会各自扫描该节点上的数据，并对每一个 key 删除其不再需要的旧版本。 默认配置下，GC 每 10 分钟触发一次，每次 GC 会保留最近 10 分钟内的数据（即默认 GC life time 为 10 分钟，safe point 的计算方式为当前时间减去 GC life time）。如果一轮 GC 运行时间太久，那么在一轮 GC 完成之前，即使到了下一次触发 GC 的时间也不会开始下一轮 GC。另外，为了使持续时间较长的事务能在超过 GC life time 之后仍然可以正常运行，safe point 不会超过正在执行中的事务的开始时间 (start_ts)。 从 SQL 的角度了解了数据是如何存储，以及如何用于计算。 TiDB 在 TiKV 提供的分布式存储能力基础上，构建了兼具优异的交易处理能力与良好的数据分析能力的计算引擎。 TiDB Server：SQL 解析层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。 可以将关系模型简单理解为 Table 和 SQL 语句，那么问题变为如何在 KV 结构上保存 Table 以及如何在 KV 结构上运行 SQL 语句。 SQL 和 KV 结构之间存在巨大的区别，那么如何能够方便高效地进行映射，就成为一个很重要的问题。一个好的映射方案必须有利于对数据操作的需求。 首先我们需要将计算尽量靠近存储节点，以避免大量的 RPC 调用。其次，我们需要将 Filter 也下推到存储节点进行计算，这样只需要返回有效的行，避免无意义的网络传输。最后，我们可以将聚合函数、GroupBy 也下推【计算下推】到存储节点，进行预聚合，每个节点只需要返回一个 Count 值即可，再由 tidb-server 将 Count 值 Sum 起来【并行算子】。 这里有一个数据逐层返回的示意图： 实际上 TiDB 的 SQL 层要复杂的多，模块以及层次非常多，下面这个图【SQL引擎架构】列出了重要的模块以及调用关系： Proses ringkas pengembalian pertanyaan SQL: Permintaan SQL pengguna akan dihantar ke pelayan-tidb secara langsung atau melalui pelayan-pemuatan Tidb akan menghuraikan Paket Protokol MySQL, mendapatkan kandungan permintaan, dan kemudian melaksanakan analisis sintaks. Perumusan dan pengoptimuman pelan pertanyaan, melaksanakan rancangan pertanyaan untuk mendapatkan dan memproses data. Semua data disimpan dalam kelompok TiKV, jadi dalam proses ini pelayan-tidb perlu berinteraksi dengan pelayan-tikv untuk mendapatkan data. Akhir sekali, tidb-server perlu mengembalikan hasil pertanyaan kepada pengguna. Dalam TiDB, proses daripada teks pertanyaan input kepada keputusan pelaksanaan pelan pelaksanaan akhir boleh dilihat dalam rajah di bawah: Pada masa yang sama, apabila TiDB melaksanakan penyata PREPARE, anda boleh memilih untuk mendayakan caching untuk mengurangkan kos TiDB menjana pelan pelaksanaan - Caching pelan pelaksanaan. Keperluan penjadualan Replika perlu diedarkan pada mesin dengan atribut berbeza mengikut topologi. Kekalkan kapasiti storan yang sekata bagi setiap nod. PD terus mengumpul maklumat melalui Store [iaitu nod TiKV] atau paket degupan jantung Leader untuk mendapatkan keseluruhannya data terperinci kluster, dan menjana urutan operasi penjadualan berdasarkan maklumat ini dan dasar penjadualan Setiap kali ia menerima paket degupan jantung daripada Ketua Wilayah, PD akan menyemak sama ada terdapat sebarang operasi yang perlu dilakukan pada Wilayah ini mesej paket degupan jantung, PD akan Operasi yang diperlukan dikembalikan kepada Ketua Wilayah, dan keputusan pelaksanaan dipantau dalam paket degupan jantung berikutnya. Ambil perhatian bahawa operasi di sini hanyalah cadangan untuk Ketua Wilayah, dan tiada jaminan bahawa ia akan dilaksanakan sama ada dan bila ia akan dilaksanakan ditentukan oleh Ketua Wilayah itu sendiri berdasarkan status semasanya. Amalan terbaik TiDB berkait rapat dengan prinsip pelaksanaannya. Adalah disyorkan untuk memahami beberapa mekanisme pelaksanaan asas . Termasuk Rakit, urus niaga teragih, serpihan data, pengimbangan beban, skim pemetaan SQL ke KV, kaedah pelaksanaan indeks sekunder dan enjin pelaksanaan teragih. Raft ialah protokol konsisten yang boleh memberikan jaminan replikasi data konsistensi yang kuat Lapisan paling bawah TiDB menggunakan Raft untuk menyegerakkan data. . Setiap penulisan mesti menulis kepada majoriti salinan sebelum kejayaan boleh dikembalikan kepada dunia luar Dengan cara ini, walaupun beberapa salinan hilang, data terkini dapat dipastikan dalam sistem. Sebagai contoh, jika terdapat maksimum 3 salinan, setiap menulis kepada 2 salinan akan dianggap berjaya Pada bila-bila masa, jika hanya satu salinan hilang, sekurang-kurangnya satu daripada dua salinan yang masih ada akan mempunyai data terkini. Berbanding dengan kaedah penyegerakan Master-Slave, yang juga menjimatkan tiga salinan, kaedah Raft adalah lebih cekap kerana kelewatan menulis bergantung pada dua salinan terpantas, bukan yang paling perlahan. Oleh itu, apabila menggunakan penyegerakan Rakit, adalah mungkin untuk tinggal di berbilang lokasi. Dalam senario tipikal tiga pusat di dua tempat, setiap penulisan hanya perlu berjaya di pusat data tempatan dan pusat data berdekatan untuk memastikan konsistensi data, dan tidak perlu berjaya dalam ketiga-tiga pusat data. TiDB menyediakan transaksi teragih yang lengkap dan model transaksi dioptimumkan berdasarkan Google Percolator. Kunci Optimistik Model transaksi optimistik TiDB hanya akan melaksanakan pengesanan konflik apabila ia benar-benar diserahkan. Jika terdapat konflik, anda perlu mencuba lagi. Model ini akan menjadi agak tidak cekap dalam senario dengan konflik yang serius, kerana operasi sebelum mencuba semula adalah tidak sah dan perlu diulang. Untuk mengambil contoh yang melampau, gunakan pangkalan data sebagai kaunter Jika keselarasan akses agak tinggi, akan berlaku konflik yang serius, mengakibatkan sejumlah besar percubaan semula atau tamat masa. Tetapi jika konflik akses tidak begitu serius, maka model penguncian optimistik adalah lebih cekap. Dalam senario dengan konflik yang serius, disyorkan untuk menggunakan penguncian pesimis atau menyelesaikan masalah pada peringkat seni bina sistem, seperti meletakkan kaunter dalam Redis. Kunci pesimis Mod transaksi pesimis TiDB pada asasnya adalah sama seperti MySQL. Ia akan dikunci semasa fasa pelaksanaan apabila tiba dahulu , asas layan pertama untuk mengelakkan konflik Mencuba semula dalam situasi tertentu boleh memastikan kadar kejayaan transaksi dengan lebih banyak konflik. Penguncian pesimis juga menyelesaikan senario di mana anda ingin mengunci data terlebih dahulu melalui Had saiz urus niaga Memandangkan transaksi yang diedarkan perlu dilakukan dalam dua fasa, dan lapisan bawah juga memerlukan replikasi Rakit, jika transaksi sangat besar, penyerahan proses akan menjadi sangat lama. Ia lambat dan akan menyekat proses salinan Raft berikut. Untuk mengelakkan sistem daripada tersekat, kami telah mengehadkan saiz transaksi [satu transaksi mengandungi tidak lebih daripada 5,000 pernyataan SQL (lalai)]. TiKV membahagikan data asas secara automatik mengikut Julat Kunci. Setiap Rantau ialah julat Kunci, selang kiri tertutup dan kanan buka dari PD akan menjadualkan pemuatan kluster berdasarkan status keseluruhan kluster TiKV. Penjadualan adalah berdasarkan Wilayah sebagai unit, dan dasar yang dikonfigurasikan oleh PD digunakan sebagai logik penjadualan, dan diselesaikan secara automatik. TiDB secara automatik memetakan struktur SQL kepada struktur KV. Ringkasnya, TiDB melaksanakan operasi berikut: anda boleh melihat bahawa data atau indeks dalam jadual akan mempunyai awalan yang sama, supaya dalam TiKV Ruang kunci, Nilai-Kekunci ini akan berada di kedudukan bersebelahan. Kemudian apabila jumlah penulisan adalah besar dan tertumpu pada jadual, ia akan menyebabkan titik panas menulis, terutamanya apabila beberapa nilai indeks dalam data yang ditulis secara berterusan juga berterusan (seperti masa kemas kini, medan yang meningkat mengikut masa). , akan membentuk tempat liputan tulis pada beberapa Wilayah dan menjadi hambatan bagi keseluruhan sistem. Begitu juga, jika semua operasi membaca data tertumpu dalam julat yang kecil (seperti berpuluh-puluh ribu atau ratusan ribu baris data berturut-turut), ia boleh menyebabkan titik liputan akses data. TiDB menyokong indeks sekunder yang lengkap dan merupakan indeks global Banyak pertanyaan boleh dioptimumkan melalui indeks. Jika anda menggunakan indeks sekunder dengan baik, ia adalah sangat penting untuk perniagaan anda. Banyak pengalaman mengenai MySQL masih boleh digunakan untuk TiDB, namun, TiDB juga mempunyai beberapa ciri tersendiri yang perlu anda perhatikan terutamanya langkah berjaga-jaga apabila menggunakan indeks sekunder pada bahan TiDB. Lebih banyak indeks sekunder, lebih baik. Adalah lebih sesuai untuk membuat indeks pada lajur dengan diskriminasi yang agak besar [kardinaliti]. Apabila terdapat berbilang syarat pertanyaan, anda boleh memilih indeks gabungan dan memberi perhatian kepada prinsip awalan paling kiri. Perbezaan antara pertanyaan melalui indeks dan terus mengimbas Jadual. Soal konkurensi. Data tersebar di banyak Wilayah, jadi TiDB akan melakukan pertanyaan serentak Konkurensi lalai agak konservatif, kerana konkurensi yang terlalu tinggi akan menggunakan banyak sumber sistem. Untuk pertanyaan jenis OLTP, yang selalunya tidak melibatkan jumlah data yang besar, konkurensi rendah sudah boleh memenuhi keperluan. Jadi TiDB menyokong pelarasan konkurensi pertanyaan melalui Pembolehubah Sistem. [tidb_distsql_scan_concurrency, tidb_index_lookup_size, tidb_index_lookup_concurrency, tidb_index_serial_scan_concurrency, dll.] Jaminan susunan keputusan melalui indeks. [Selain digunakan untuk menapis data, indeks juga boleh digunakan untuk mengisih data Pertama, ID baris diperoleh dalam susunan indeks, dan kemudian kandungan baris dikembalikan dalam susunan pengembalian baris. ID. Ini memastikan bahawa hasil yang dikembalikan disusun mengikut urutan indeks. 】 turut menyokong pengindeksan terbalik. [Kelajuan semasa adalah lebih perlahan daripada Imbasan berurutan, biasanya 20% lebih perlahan Apabila data kerap diubah suai dan terdapat banyak versi, ia akan menjadi lebih perlahan. Jika boleh, adalah disyorkan untuk mengelakkan Imbasan terbalik indeks] Untuk lebih banyak pengetahuan berkaitan pengaturcaraan, sila lawati: Video Pengaturcaraan! ! Atas ialah kandungan terperinci Adakah tidb bahasa pergi?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!Raft dan RocksDB
Konsep wilayah
MVCC
#简单来说，没有 MVCC 之前，可以把 TiKV 看做这样的
Key1 -> Value
Key2 -> Value
……
KeyN -> Value
#有了 MVCC 之后，TiKV 的 Key 排列是这样的：
Key1-Version3 -> Value
Key1-Version2 -> Value
Key1-Version1 -> Value
……
Key2-Version4 -> Value
Key2-Version3 -> Value
Key2-Version2 -> Value
Key2-Version1 -> Value
……
KeyN-Version2 -> Value
KeyN-Version1 -> Value
……
GC
DROP TABLE/DROP INDEX 等操作产生的整区间的废弃数据。
2、TiDB数据库的计算——TiDB Server
SQL映射KV
分布式SQL运算
Proses pelaksanaan SQL
3. Penjadualan pangkalan data TiDB - PD ServerPD (Placement Driver) ialah modul pengurusan gugusan TiDB dan juga bertanggungjawab untuk kluster Penjadualan data masa nyata.
Senario penjadualan
Pelayan PD (Pemacu Peletakan): Modul pengurusan maklumat meta bagi keseluruhan kelompok TiDB , bertanggungjawab untuk penyimpanan Ia menyediakan pengedaran data masa nyata bagi setiap nod TiKV dan topologi keseluruhan kluster, menyediakan antara muka pengurusan dan kawalan Papan Pemuka TiDB, dan memberikan ID transaksi kepada transaksi yang diedarkan. PD bukan sahaja menyimpan maklumat meta, tetapi juga mengeluarkan arahan penjadualan data kepada nod TiKV tertentu berdasarkan status pengedaran data yang dilaporkan dalam masa nyata oleh nod TiKV Ia boleh dikatakan sebagai "otak" keseluruhan kluster. Di samping itu, PD itu sendiri terdiri daripada sekurang-kurangnya 3 nod untuk menyediakan ketersediaan yang tinggi. Adalah disyorkan untuk menggunakan bilangan ganjil nod PD.
Kategori 1: Sebagai sistem storan ketersediaan tinggi yang diedarkan, keperluan yang mesti dipenuhi termasuk beberapa : [Fungsi pemulihan bencana]
Bilangan salinan tidak boleh lebih atau kurang.
Mengekalkan pengagihan Pemimpin yang sekata di seluruh kluster.
Operasi Penjadualan
Operasi asas penjadualan merujuk kepada dasar untuk memenuhi penjadualan. Keperluan penjadualan di atas boleh disusun dalam tiga operasi berikut: Tambah salinan
Padam salinanLetakkan peranan Ketua di antara salinan Rakit yang berbeza Pemindahan kumpulan
Status TiKV Store secara khusus dibahagikan kepada Atas, Putus Sambungan, Luar Talian, Bawah dan Batu Nisan. Hubungan antara setiap status adalah seperti berikut: AddReplicaRemoveReplicaTransferLeader
Strategi penjadualan
Pelaksanaan penjadualan
5 Amalan terbaik TiDB
Raft
Transaksi Teragih
select for update. Tetapi jika senario perniagaan itu sendiri mempunyai konflik yang lebih sedikit, prestasi penguncian optimistik akan menjadi lebih berfaedah.
Pemecahan data
StartKey hingga EndKey. Jika jumlah keseluruhan Nilai-Kunci dalam Rantau melebihi nilai tertentu, ia akan dipisahkan secara automatik. Bahagian ini telus kepada pengguna.
Pengimbangan Beban
SQL pada KV
TableID dan ID baris diakhiri TableID IndexID, dan nilai indeks ialah Dengan membina akhiran
Indeks Sekunder
Untuk Pertanyaan jenis OLAP, tahap keselarasan yang lebih tinggi selalunya diperlukan.
Penggunaan kata kunci Jenis dalam Go
Cara melaksanakan senarai terpaut dalam go
Apakah perisian pengaturcaraan bahasa Go?
Bagaimana untuk belajar bahasa go dari 0 asas
Bagaimana untuk menentukan pembolehubah dalam golang
Apakah kaedah untuk melaksanakan lebihan beban operator dalam bahasa Go?
Apakah pengendali dalam bahasa Go?
Apakah kaedah penukaran data dalam golang?
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
