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 universal, perkara bergantung pada faktor seperti

• Saiz baris
• Jenis data (rentetan, gumpalan, dll.)
• Bilangan pertanyaan aktif
• Apa jenis pertanyaan
• Indeks
• Baca/Tulis Semula
• Jangkaan kelewatan

Tapi bila ada yang tanya soalan ni

• Apakah yang akan anda lakukan jika 1 bilion keping data dan berjuta-juta baris ditambahkan setiap hari? Untuk pangkalan data yang begitu besar, kependaman untuk 4 pertanyaan baca, 1 tulis dan 2 kemas kini perlu kurang daripada 5 milisaat.
• Jika anda hanya mempunyai 10 juta baris tetapi kemas kini tinggi dan volum bacaan, apakah yang akan anda pilih? Bilangan baris baharu yang ditambah tidak penting. Konsistensi tinggi dan kependaman rendah adalah keperluan.

Jika bilangan baris kurang daripada sejuta dan saiz baris bertambah ribuan, pilihannya mudah sahaja. Tetapi keadaan menjadi lebih rumit apabila pemilihan melibatkan berjuta-juta atau berbilion-bilion baris.

Nota: Saya tidak menyebut nombor kelewatan dalam soalan. tolonglah Jawab berdasarkan bilangan kelewatan yang anda selesa. Juga, kita bercakap tentang data berstruktur.

Saya tidak pasti, tetapi saya boleh menambah 3 soalan khusus:

• Andaikan anda memilih pangkalan data SQL untuk Amazon atau mana-mana sistem pengurusan pesanan e-dagang. Bilangan pesanan meningkat berjuta-juta setiap hari. Sudah ada 1 bilion rekod. Sekarang, anggap tiada arkib data. Pertanyaan bacaan tinggi dengan lebih seribu pertanyaan sesaat. Dan juga ditulis. Nisbah Baca:tulis ialah 100:1
• Mari kita ambil contoh nombor yang kini lebih kecil. Katakan anda memilih pangkalan data SQL untuk abc atau mana-mana sistem pengurusan pesanan e-dagang. Bilangan pesanan meningkat ribuan setiap hari. Sudah ada 10 juta rekod. Sekarang, anggap tiada arkib data. Pertanyaan bacaan tinggi dengan lebih sepuluh ribu pertanyaan sesaat. Dan juga ditulis. Nisbah membaca dan menulis ialah 10:1
• Contoh ketiga: Pengedaran percuma. Kami ada 10 juta barang untuk dihadiahkan. 1 goody setiap pengguna. Konsistensi tinggi dan kependaman rendah adalah matlamatnya. Dengan mengandaikan sudah ada 20 juta pengguna menunggu pengedaran percuma, sebaik sahaja masa bermula, mereka semua akan cuba mendapatkan barangan percuma itu.

Nota: Sepanjang soalan ini, diandaikan bahawa kita akan memilih penyelesaian SQL. Selain itu, jika kes penggunaan yang disediakan tidak masuk akal, abaikan ia. Matlamatnya adalah untuk memperoleh pengetahuan berangka.

Bolehkah sesiapa membantu saya memahami apakah penanda aras itu? Sebarang nombor nyata daripada projek yang sedang anda kerjakan akan menunjukkan bahawa ini ialah kependaman yang diperhatikan untuk pangkalan data yang besar dengan begitu banyak pertanyaan. Apa-apa sahaja yang boleh membantu saya mewajarkan bilangan jadual pilihan untuk bilangan pertanyaan tertentu untuk kependaman tertentu.

Answer 1

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