Adakah tidb bahasa pergi?-Golang-php.cn

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.

Adakah tidb bahasa pergi?

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.

1. Pengenalan kepada TiDB

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 .

Sangat serasi dengan MySQL 5.7

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.

Kemudahan penggunaan

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.

Menyokong transaksi yang diedarkan

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:

Seni bina teragih tulen dengan kebolehskalaan yang baik , menyokong fleksibel pengembangan dan pengecutan
Menyokong SQL, mendedahkan protokol rangkaian MySQL kepada dunia luar, dan serasi dengan kebanyakan sintaks MySQL, dan boleh secara langsung menggantikan MySQL dalam kebanyakan senario
Menyokong ketersediaan tinggi secara lalai , apabila beberapa salinan gagal, pangkalan data itu sendiri boleh melakukan pembaikan dan failover data secara automatik, yang telus kepada perniagaan
Menyokong transaksi ACID dan mesra kepada beberapa senario dengan keperluan konsistensi yang kukuh, seperti pemindahan bank
Mempunyai ekosistem rangkaian alat yang kaya, meliputi pelbagai senario seperti pemindahan data, penyegerakan, sandaran, dll.

Ringkasnya, TiDB sesuai untuk senario dengan ciri berikut：

Jumlah data adalah besar dan tidak boleh disimpan pada satu mesin
Tidak mahu melakukan Sharding atau terlalu malas untuk melakukan Sharding
Tidak ada yang jelas titik panas dalam mod akses
Memerlukan transaksi, perlu Konsistensi yang kukuh, pemulihan bencana diperlukan
Harap HTAP Masa Nyata, kurangkan pautan storan

Lima ciri teras

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.

Empat senario aplikasi teras

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.

2 Bermula dengan pantas

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

Salin selepas log masuk

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
===============================================

Salin selepas log masuk

langkah 2. Isytiharkan pembolehubah persekitaran global. source ${your_shell_profile}
```
source /home/user/.bashrc
```
Salin selepas log masuk
langkah3. Jalankan arahan berikut dalam sesi semasa untuk memulakan kluster.
```
tiup playground
```
Salin selepas log masuk

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。

Salin selepas log masuk

3 >Dari segi reka bentuk teras, pangkalan data yang diedarkan TiDB membahagikan keseluruhan seni bina kepada berbilang modul, dan setiap modul berkomunikasi antara satu sama lain untuk membentuk sistem TiDB yang lengkap. Gambar rajah seni bina yang sepadan adalah seperti berikut:

Adakah tidb bahasa pergi?

Tutorial video Pergi
]
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.

Adakah tidb bahasa pergi?

1. Storan pangkalan data TiDB - Pelayan TiKVStoran TiDB model, struktur hierarki enjin KV teragih dengan urus niaga

[

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.

TiKVMenyimpan data perlu memastikan: tiada kehilangan data, data yang baik → Protokol rakit. Di samping itu, isu berikut perlu dipertimbangkan:

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

Bagaimana untuk melaksanakan Peta yang besar (teredar) dengan prestasi tinggi dan kebolehpercayaan tinggi seperti TiKV?

TiKV ialah Peta yang besar, yang menyimpan pasangan Nilai-Kekunci.
Pasangan Nilai-Kekunci dalam Peta ini disusun mengikut susunan binari Kunci, iaitu, kita boleh Cari ke lokasi Kunci tertentu, dan kemudian terus memanggil kaedah Seterusnya untuk mendapatkan kunci yang lebih besar daripada Kunci ini dalam susunan yang semakin meningkat.

Raft dan RocksDB

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 . 】

Adakah tidb bahasa pergi?

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.

Konsep wilayah

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.

Adakah tidb bahasa pergi?

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:

Adakah tidb bahasa pergi?

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.

MVCC

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 的位置。

#简单来说，没有 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
……

Salin selepas log masuk

GC

TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。Garbage Collection (GC) 的任务便是清理不再需要的旧数据。

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” 【删除区间】阶段快速地删除由于 DROP TABLE/DROP INDEX 等操作产生的整区间的废弃数据。

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)。

2、TiDB数据库的计算——TiDB Server

从 SQL 的角度了解了数据是如何存储，以及如何用于计算。

TiDB 在 TiKV 提供的分布式存储能力基础上，构建了兼具优异的交易处理能力与良好的数据分析能力的计算引擎。

TiDB Server：SQL 解析层，对外暴露 MySQL 协议的连接 endpoint，负责接受客户端的连接，执行 SQL 解析和优化，最终生成分布式执行计划。TiDB 层本身是无状态的，实践中可以启动多个 TiDB 实例，通过负载均衡组件（如 LVS、HAProxy 或 F5）对外提供统一的接入地址，客户端的连接可以均匀地分摊在多个 TiDB 实例上以达到负载均衡的效果。TiDB Server 本身并不存储数据，只是解析 SQL，将实际的数据读取请求转发给底层的存储节点 TiKV（或 TiFlash）。

SQL映射KV

可以将关系模型简单理解为 Table 和 SQL 语句，那么问题变为如何在 KV 结构上保存 Table 以及如何在 KV 结构上运行 SQL 语句。 SQL 和 KV 结构之间存在巨大的区别，那么如何能够方便高效地进行映射，就成为一个很重要的问题。一个好的映射方案必须有利于对数据操作的需求。

Adakah tidb bahasa pergi?

分布式SQL运算

首先我们需要将计算尽量靠近存储节点，以避免大量的 RPC 调用。其次，我们需要将 Filter 也下推到存储节点进行计算，这样只需要返回有效的行，避免无意义的网络传输。最后，我们可以将聚合函数、GroupBy 也下推【计算下推】到存储节点，进行预聚合，每个节点只需要返回一个 Count 值即可，再由 tidb-server 将 Count 值 Sum 起来【并行算子】。这里有一个数据逐层返回的示意图：

Adakah tidb bahasa pergi?

实际上 TiDB 的 SQL 层要复杂的多，模块以及层次非常多，下面这个图【SQL引擎架构】列出了重要的模块以及调用关系：

Adakah tidb bahasa pergi?

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.

Proses pelaksanaan SQL

Dalam TiDB, proses daripada teks pertanyaan input kepada keputusan pelaksanaan pelan pelaksanaan akhir boleh dilihat dalam rajah di bawah:

Melalui perubahan yang setara ini, pertanyaan ini boleh menjadi lebih mudah dikendalikan dalam pelan pelaksanaan logik. Selepas perubahan setara selesai, TiDB akan memperoleh struktur pelan pertanyaan yang setara dengan pertanyaan asal, dan kemudian mendapatkan pelan pelaksanaan akhir berdasarkan pengedaran data dan kos pelaksanaan khusus pengendali - Adakah tidb bahasa pergi?

Pengoptimuman fizikal pertanyaan .

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.

3. Penjadualan pangkalan data TiDB - PD Server

PD (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.

Keperluan penjadualan

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.

Replika perlu diedarkan pada mesin dengan atribut berbeza mengikut topologi.

Pemulihan bencana boleh dilakukan secara automatik dan munasabah dengan cepat jika nod tidak berfungsi atau tidak normal.

Kategori kedua: Sebagai sistem pengedaran yang baik, perkara yang perlu dipertimbangkan termasuk:

Mengekalkan pengagihan Pemimpin yang sekata di seluruh kluster.

Kekalkan kapasiti storan yang sekata bagi setiap nod.

Kekalkan pengagihan tempat liputan akses yang sekata.

Kawal kelajuan pengimbangan beban untuk mengelak menjejaskan perkhidmatan dalam talian.
Urus status nod, termasuk membawa nod dalam talian/luar talian secara manual.
Untuk memenuhi keperluan ini, maklumat yang mencukupi perlu dikumpul, seperti status setiap nod, maklumat setiap Kumpulan Raft, statistik operasi akses perniagaan, dsb.; kedua, beberapa dasar perlu ditetapkan, dan PD perlu menetapkan dasar ini berdasarkan maklumat dan strategi penjadualan ini untuk membangunkan pelan penjadualan yang memenuhi keperluan yang dinyatakan sebelum ini sebanyak mungkin.

Operasi Penjadualan

Operasi asas penjadualan merujuk kepada dasar untuk memenuhi penjadualan. Keperluan penjadualan di atas boleh disusun dalam tiga operasi berikut: Tambah salinan

Padam salinan

Letakkan peranan Ketua di antara salinan Rakit yang berbeza Pemindahan kumpulan

Protokol Raft boleh menyokong tiga operasi asas di atas melalui tiga arahan
,
.

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

Bilangan salinan sesuatu Wilayah adalah betul.
Berbilang replika dalam Kumpulan Rakit tidak berada di lokasi yang sama.
Replika diagihkan sama rata antara Kedai.
Bilangan Pemimpin diagihkan sama rata antara Kedai.
Bilangan tempat liputan akses diagihkan sama rata antara Kedai.
Ruang storan yang diduduki oleh setiap Kedai adalah lebih kurang sama.
Kawal kelajuan penjadualan untuk mengelak menjejaskan perkhidmatan dalam talian.

Pelaksanaan penjadualan

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.

5 Amalan terbaik TiDB

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

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.

Transaksi Teragih

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 select for update. Tetapi jika senario perniagaan itu sendiri mempunyai konflik yang lebih sedikit, prestasi penguncian optimistik akan menjadi lebih berfaedah.
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)].

Pemecahan data

TiKV membahagikan data asas secara automatik mengikut Julat Kunci. Setiap Rantau ialah julat Kunci, selang kiri tertutup dan kanan buka dari 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

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.

SQL pada KV

TiDB secara automatik memetakan struktur SQL kepada struktur KV. Ringkasnya, TiDB melaksanakan operasi berikut:

Satu baris data dipetakan ke KV, Kunci dibina dengan awalan TableID dan ID baris diakhiri
Indeks dipetakan ke KV, Kunci dibina dengan awalan TableID IndexID, dan nilai indeks ialah Dengan membina akhiran

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.

Indeks Sekunder

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.
Untuk Pertanyaan jenis OLAP, tahap keselarasan yang lebih tinggi selalunya diperlukan.

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]