Had sebelum jadual boleh dipecahkan atau dipisahkan

Question

Saya baru dalam reka bentuk sistem pangkalan data. Selepas membaca banyak artikel, saya benar-benar keliru apakah had yang sepatutnya kita ada 1 meja tanpa sharding atau partitioning. Saya tahu sangat sukar untuk memberikan jawapan umum, perkara bergantung pada faktor seperti saiz baris, jenis data (rentetan, gumpalan, dll.) bilangan pertanyaan aktif, jenis indeks pertanyaan yang dibaca semula/tulis semula kependaman yang dijangkakan, tetapi apabila seseorang bertanya ini soalan jika Dengan 1 bilion keping data dan berjuta-juta baris ditambah setiap hari, apa yang anda lakukan? Untuk pangkalan data yang begitu besar, kependaman 4 pertanyaan baca, 1 tulis dan 2 kemas kini perlu kurang daripada 5 milisaat. Jika anda hanya mempunyai 10

P粉401901266 · Answer

Beberapa jawapan untuk MySQL. Memandangkan semua pangkalan data tertakluk kepada ruang cakera, kependaman rangkaian, dsb. enjin lain mungkin serupa.

Tidak kira berapa banyak baris, "pertanyaan mata" (mendapatkan baris menggunakan indeks yang sesuai) mengambil masa milisaat.
Boleh menulis satu SELECT yang mengambil masa berjam-jam atau bahkan berhari-hari untuk dijalankan. Oleh itu, anda perlu memahami jika pertanyaan adalah patologi seperti ini. (Saya rasa ini adalah contoh "latensi" tinggi.)
"Sharding" diperlukan apabila anda tidak dapat mengekalkan bilangan penulisan yang diperlukan pada satu pelayan.
Bacaan besar boleh diskalakan "tak terhingga" dengan menggunakan replikasi dan menghantar bacaan ke replika.
PARTITIONing (terutama dalam MySQL) mempunyai kegunaan yang sangat sedikit. Butiran lanjut: Partition
INDEX Sangat penting untuk prestasi.
Untuk aplikasi gudang data, membina dan menyelenggara "jadual ringkasan" adalah penting untuk prestasi berskala besar. (Sesetengah enjin lain mempunyai beberapa alatan terbina dalam.)
每天插入Satu juta baris tidak menjadi masalah. (Sudah tentu, beberapa reka bentuk skema mungkin menyebabkan masalah ini.) Peraturan praktikal: 100/saat mungkin tidak menjadi masalah; Lebih lanjut mengenai High Speed Inest
Latensi rangkaian bergantung terutamanya pada jarak antara pelanggan dan pelayan. Ia mengambil masa lebih daripada 200 milisaat untuk sampai ke bahagian lain Bumi. Sebaliknya, jika pelanggan dan pelayan berada dalam bangunan yang sama, kependaman akan menjadi kurang daripada 1 milisaat. Jika sebaliknya anda merujuk kepada tempoh masa yang diperlukan untuk menjalankan pertanyaan, maka berikut adalah beberapa peraturan: 10ms untuk pertanyaan mudah yang perlu menekan cakera HDD 1ms untuk SSD.
UUID dan cincang sangat memudaratkan prestasi jika data terlalu besar untuk dicache dalam RAM.
Saya tidak menyebut nisbah baca/tulis kerana saya lebih suka menilai membaca dan menulis secara bebas.
"Sepuluh ribu bacaan sesaat" sukar dicapai; Atau mereka boleh mencari cara yang lebih baik untuk mencapai matlamat yang sama. Seberapa cepat pengguna boleh mengeluarkan pertanyaan? Mungkin satu sesaat? Berapa ramai pengguna boleh disambungkan dan aktif pada masa yang sama? Beratus-ratus.
(Pendapat saya) Kebanyakan penanda aras tidak berguna. Sesetengah penanda aras boleh menunjukkan bahawa satu sistem adalah dua kali lebih pantas daripada yang lain. jadi apa? Sesetengah penanda aras menunjukkan bahawa apabila anda mempunyai lebih daripada beberapa ratus aktifsambungan, gerai pemprosesan dan kependaman cenderung kepada infiniti. jadi apa. Menangkap pertanyaan sebenar setelah aplikasi berjalan untuk sementara waktu mungkin merupakan penanda aras terbaik. Tetapi penggunaannya masih terhad.
Sebuah meja tunggal hampir selalu lebih baik daripada meja belah (berbilang jadual; sekatan; serpihan). Jika anda mempunyai contoh khusus, kita boleh membincangkan kebaikan dan keburukan reka bentuk meja.
Saiz baris dan jenis data - Lajur besar (TEXT/BLOB/JSON) disimpan "tidak dilog", dengan itu [berkemungkinan] menyebabkan klik cakera tambahan. Hit cakera adalah bahagian paling mahal dalam sebarang pertanyaan.
Pertanyaan Aktif – Selepas beberapa dozen kali, pertanyaan akan bercanggah antara satu sama lain. (Bayangkan kedai runcit dengan ramai pembeli menolak troli beli-belah – pembeli “terlalu ramai” dan semua orang mengambil masa yang lama untuk selesai.)

Apabila anda masuk ke pangkalan data yang besar, ia datang dalam beberapa jenis yang berbeza; setiap satu mempunyai beberapa ciri yang berbeza.

Gudang data (sensor, log, dll.) - dilampirkan pada "hujung" jadual untuk "pelaporan" yang cekap (dengan beberapa "jadual dimensi";
Cari (produk, halaman web, dll.) - EAV bermasalah; teks penuh selalunya berguna.
Perbankan, Pemprosesan Pesanan - Ini sangat penting untuk fungsi ACID dan keperluan untuk memproses transaksi.
Media (Imej dan Video) - Cara menyimpan objek besar sambil membuat carian (dsb.) dengan pantas.
'Cari terdekat' - memerlukan indeks 2D, SPATIAL atau beberapa teknik di sini