Bila hendak membahagikan jadual dalam mysql

Situasi yang sesuai untuk pemisahan jadual dalam mysql: 1. Apabila jumlah data terlalu besar dan operasi dan penyelenggaraan biasa menjejaskan akses perniagaan, contohnya, membuat sandaran pangkalan data memerlukan sejumlah besar IO cakera dan IO rangkaian , dan pengubahsuaian DDL jadual akan menyebabkan Mengunci keseluruhan jadual, mengakses dan mengemas kini jadual besar akan menyebabkan terkunci menunggu 2. Semasa perniagaan berkembang, beberapa medan perlu dipecah secara menegak 3. Jumlah data dalam satu jadual meningkat Apabila prestasi hampir kepada kesesakan, penghirisan mendatar perlu dipertimbangkan.

Persekitaran pengendalian tutorial ini: sistem windows7, versi mysql8, komputer Dell G3.

Tidak semua jadual perlu dibahagikan, ia bergantung terutamanya pada kadar pertumbuhan data. Segmentasi akan meningkatkan kerumitan perniagaan pada tahap tertentu Selain membawa penyimpanan data dan pertanyaan, pangkalan data juga merupakan salah satu tugas pentingnya untuk membantu perniagaan dalam merealisasikan keperluannya dengan lebih baik.

Jangan gunakan helah memecah pangkalan data dan jadual melainkan benar-benar perlu untuk mengelakkan "reka bentuk berlebihan" dan "pengoptimuman pramatang". Sebelum membelah pangkalan data dan jadual, jangan pecahkan hanya untuk pemisahan Cuba yang terbaik untuk melakukan apa yang anda boleh dahulu, seperti menaik taraf perkakasan, menaik taraf rangkaian, memisahkan baca dan tulis, pengoptimuman indeks, dsb. Apabila jumlah data mencapai kesesakan satu jadual, pertimbangkan untuk memecah pangkalan data dan jadual.

Jadi bilakah sub-jadual perlu dipertimbangkan dalam MySQL

1 dan penyelenggaraan menjejaskan akses perniagaan

Pengendalian dan penyelenggaraan yang disebut di sini merujuk kepada:

• Untuk sandaran pangkalan data, jika satu jadual terlalu besar, jumlah yang besar cakera IO dan rangkaian IO diperlukan semasa sandaran. Sebagai contoh, jika 1T data dihantar melalui rangkaian dan menduduki 50MB, ia akan mengambil masa 20,000 saat untuk menyelesaikan penghantaran Risiko keseluruhan proses adalah agak tinggi

• Apabila membuat DDL. pengubahsuaian kepada jadual besar, MySQL akan mengunci keseluruhan jadual untuk masa yang lama Dalam tempoh ini, perniagaan tidak dapat mengakses jadual, yang mempunyai kesan yang besar. Jika anda menggunakan pt-online-schema-change, pencetus dan jadual bayangan akan dibuat semasa penggunaan, yang juga mengambil masa yang lama. Semasa operasi ini, ia dikira sebagai masa berisiko. Membahagikan jadual data dan mengurangkan jumlah keseluruhan boleh membantu mengurangkan risiko ini.

• Meja besar akan diakses dan dikemas kini dengan kerap, jadi penantian kunci lebih berkemungkinan berlaku. Pisahkan data, tukar ruang untuk masa, dan kurangkan tekanan akses berselindung

2. Semasa perniagaan berkembang, beberapa bidang perlu dipecah secara menegak

Sebagai contoh, jika jadual pengguna yang direka pada permulaan projek adalah seperti berikut:

Pada peringkat awal projek, reka bentuk ini memenuhi keperluan perniagaan yang mudah dan mudah dibangunkan. Apabila perniagaan berkembang pesat, bilangan pengguna melonjak daripada 100,000 kepada 1 bilion, dan pengguna sangat aktif Medan last_login_name dikemas kini setiap kali mereka log masuk, menyebabkan jadual pengguna sentiasa dikemas kini, yang sangat menekan. Medan lain: id, nama, maklumat_peribadi tidak berubah atau jarang dikemas kini Dari perspektif perniagaan, adalah perlu untuk memisahkan last_login_time dan membuat jadual pengguna_masa baharu.

Atribut personal_info dikemas kini dan kurang kerap ditanya, dan medan teks mengambil terlalu banyak ruang. Pada masa ini, adalah perlu untuk membahagikan jadual user_ext secara menegak.

3. Jumlah data berkembang pesat

Dengan perkembangan pesat perniagaan, jumlah data dalam satu jadual akan terus berkembang apabila prestasinya hampir dengan kesesakan, anda perlu mempertimbangkan Segmen mendatar dilakukan untuk mencipta pangkalan data dan jadual yang berasingan. Pada masa ini, anda mesti memilih peraturan pembahagian yang sesuai dan menganggarkan kapasiti data terlebih dahulu

Analisis kes perniagaan

1 Senario perniagaan pusat

Pusat pengguna ialah perniagaan yang sangat biasa, yang terutamanya menyediakan pendaftaran pengguna, log masuk, pertanyaan/pengubahsuaian dan fungsi lain ialah:

Log masuk pengguna: pertanyaan maklumat pengguna melalui nama_log masuk/telefon/e-mel, 1% permintaan dimiliki kepada jenis ini

• Pertanyaan maklumat pengguna: Selepas log masuk, tanya maklumat pengguna melalui uid, 99% permintaan adalah daripada jenis ini
  Sebelah operasi: Akses bahagian belakang, menyokong keperluan operasi dan melakukan pertanyaan halaman berdasarkan umur, jantina, masa log masuk, masa pendaftaran, dsb. Ia adalah sistem dalaman dengan volum capaian rendah dan keperluan rendah pada ketersediaan dan konsistensi.

• 2. Kaedah segmentasi mendatar

Apabila jumlah data menjadi lebih besar dan lebih besar, pangkalan data perlu dibahagikan secara mendatar, seperti yang diterangkan di atas Kaedah pembahagian termasuk "berdasarkan julat berangka" dan "berdasarkan modulo berangka".

"Berdasarkan julat nilai": Berdasarkan uid kunci primer, data dibahagikan secara mendatar kepada berbilang pangkalan data mengikut julat uid. Contohnya: user-db1 menyimpan data dengan julat uid dari 0 hingga 1000w, dan user-db2 menyimpan data dengan julat uid dari 1000w hingga 2000wuid.

• Kelebihannya ialah: pengembangan adalah mudah Jika kapasiti tidak mencukupi, tambahkan db baru.

• Kelemahannya ialah volum permintaan tidak sekata Secara amnya, pengguna yang baru didaftarkan akan menjadi lebih aktif, jadi pengguna-db2 baharu akan mempunyai muatan yang lebih tinggi daripada pengguna-db1, yang mengakibatkan. penggunaan pelayan yang rendah.

"Modul berdasarkan nilai berangka": Ia juga menggunakan uid kunci utama sebagai asas untuk pembahagian dan membahagikan data secara mendatar berbilang pangkalan data berdasarkan nilai modulo uid . Contohnya: user-db1 menyimpan uid data modulo 1, user-db2 menyimpan uid data modulo 0.

• Kelebihannya ialah: volum data dan volum permintaan diagihkan sama rata

• Kelemahannya ialah: pengembangan menyusahkan, apabila kapasiti tidak cukup, tambah db baru, Memerlukan rehash. Penghijrahan data yang lancar perlu dipertimbangkan.

Kaedah pertanyaan bukan uid

Selepas pembahagian mendatar, permintaan untuk pertanyaan mengikut uid boleh menjadi sangat baik Jika berpuas hati, ia boleh dihalakan terus ke pangkalan data tertentu. Untuk pertanyaan berdasarkan bukan-uid, seperti login_name, tidak diketahui perpustakaan mana yang harus diakses Dalam kes ini, semua perpustakaan perlu dilalui, dan prestasi akan dikurangkan dengan banyak.

Untuk bahagian pengguna, penyelesaian "mewujudkan hubungan pemetaan daripada atribut bukan uid kepada uid" boleh diterima pakai untuk bahagian operasi, penyelesaian "memisahkan bahagian hadapan dan bahagian belakang"; boleh diterima pakai.

1. Wujudkan hubungan pemetaan daripada atribut bukan uid kepada uid

• Perhubungan pemetaan

Sebagai contoh: nama_log masuk tidak boleh ditempatkan secara langsung dalam pangkalan data Hubungan pemetaan nama_log masuk → uid boleh diwujudkan dan disimpan dalam jadual indeks atau cache. Apabila mengakses login_name, mula-mula tanya uid yang sepadan dengan login_name melalui jadual pemetaan, dan kemudian cari pustaka tertentu melalui uid.

Jadual pemetaan hanya mempunyai dua lajur dan boleh membawa banyak data Apabila jumlah data terlalu besar, jadual pemetaan juga boleh dibahagikan secara mendatar. Jenis struktur indeks format kv ini boleh menggunakan cache untuk mengoptimumkan prestasi pertanyaan, dan hubungan pemetaan tidak akan kerap berubah, dan kadar hit cache akan menjadi sangat tinggi.

• Kaedah gen

Gen pemecah: Jika anda membahagikan perpustakaan melalui uid, ia dibahagikan kepada 8 perpustakaan dan dihalakan menggunakan uid%8 , pada masa ini, 3 bit terakhir uid yang menentukan pustaka mana barisan data Pengguna ini. Kemudian 3 bit ini boleh dianggap sebagai gen sub-perpustakaan.

2. Pemisahan bahagian hadapan dan bahagian belakang

Bagi pihak pengguna, keperluan utama ialah memfokus pada pertanyaan satu baris dan hubungan pemetaan antara login_name/telefon/e-mel dan uid perlu diwujudkan Boleh menyelesaikan masalah pertanyaan medan ini.

Bagi bahagian operasi, terdapat banyak pertanyaan dengan paging kelompok dan pelbagai syarat pertanyaan sedemikian memerlukan jumlah pengiraan yang banyak, mengembalikan sejumlah besar data dan menggunakan pangkalan data berprestasi tinggi. Pada masa ini, jika kumpulan perkhidmatan atau pangkalan data yang sama dikongsi dengan pihak pengguna, sebilangan kecil permintaan latar belakang mungkin menduduki sejumlah besar sumber pangkalan data, mengakibatkan kemerosotan prestasi akses sebelah pengguna atau tamat masa.

Untuk perniagaan jenis ini, sebaiknya gunakan penyelesaian "pemisahan bahagian hadapan dan bahagian belakang" Perniagaan bahagian belakang di bahagian operasi mengekstrak perkhidmatan bebas dan DB untuk menyelesaikan gandingan sistem perniagaan hadapan. Oleh kerana bahagian operasi tidak mempunyai keperluan yang tinggi untuk ketersediaan dan ketekalan, ia tidak perlu untuk mengakses perpustakaan masa nyata Sebaliknya, ia boleh menyegerakkan data ke perpustakaan operasi melalui binlog untuk akses. Apabila jumlah data adalah besar, anda juga boleh menggunakan enjin carian ES atau Hive untuk memenuhi kaedah pertanyaan kompleks di latar belakang.

[Cadangan berkaitan: tutorial video mysql]

Atas ialah kandungan terperinci Bila hendak membahagikan jadual dalam mysql. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!