Bagaimana Partisi Tabel Membantu?

Saya mengalami kesulitan untuk mengambil ide pro dan kontra dari partisi tabel. Saya akan mulai bekerja pada sebuah proyek yang akan memiliki 8 tabel dan salah satunya akan menjadi tabel data utama yang akan menampung 180-260 juta catatan. Karena tabel ini akan diindeks dengan benar, jadi saya berpikir untuk membatasi catatan tabel hingga 20 juta dengan cara ini saya harus membuat 9-13 tabel.

Tetapi saya tidak begitu yakin tentang bagaimana ini akan meningkatkan kinerja karena mereka akan duduk di mesin yang sama (RAM 32GB)?

Saya menggunakan MySQL dan tabel adalah MyISAM dan tabel besar akan memiliki indeks pada bidang id dan tidak ada kerumitan lebih lanjut seperti pencarian teks lengkap dll.

Tolong juga menjelaskan partisi tabel vs partisi database.

Berikut ini hanya mengoceh gila dan mengoceh ...

Jika Anda meninggalkan semua data dalam satu tabel (tanpa partisi), Anda akan memiliki O (log n) kali pencarian menggunakan kunci. Mari kita ambil indeks terburuk di dunia, pohon biner. Setiap simpul pohon memiliki tepat satu kunci. Pohon biner seimbang sempurna dengan 268.435.455 (2 ^ 28 - 1) node pohon akan menjadi tinggi 28. Jika Anda membagi pohon biner ini menjadi 16 pohon yang terpisah, Anda mendapatkan 16 pohon biner masing-masing dengan 16.777.215 (2 ^ 24 - 1) simpul pohon untuk ketinggian 24. Jalur pencarian dikurangi 4 simpul, pengurangan ketinggian 14,287%. Jika waktu pencarian dalam mikrodetik, pengurangan 14,2857% dalam waktu pencarian adalah nihil-untuk-diabaikan.

Sekarang di dunia nyata, indeks BTREE akan memiliki treenodes dengan beberapa kunci. Setiap pencarian BTREE akan melakukan pencarian biner di dalam halaman dengan kemungkinan yang layak ke halaman lain. Sebagai contoh, jika setiap halaman BTREE berisi 1024 kunci, tinggi pohon 3 atau 4 akan menjadi norma, ketinggian pohon pendek memang.

Perhatikan bahwa pembagian tabel tidak mengurangi ketinggian BTREE yang sudah kecil. Diberi partisi 260 juta baris, bahkan ada kemungkinan kuat memiliki beberapa BTREE dengan ketinggian yang sama. Mencari kunci dapat melewati semua halaman BTREE root setiap waktu. Hanya satu yang akan memenuhi jalur rentang pencarian yang dibutuhkan.

Sekarang perluas ini. Semua partisi ada di mesin yang sama. Jika Anda tidak memiliki disk terpisah untuk setiap partisi, Anda akan memiliki rotasi I / O disk dan spindle sebagai penghambat otomatis di luar kinerja pencarian partisi.

Dalam hal ini, mem-partisi-by-database tidak akan membelikan Anda apa pun jika id adalah satu-satunya kunci pencarian yang digunakan.

Partisi data harus berfungsi untuk mengelompokkan data yang secara logis dan kohesif di kelas yang sama. Kinerja pencarian setiap partisi tidak perlu menjadi pertimbangan utama selama data dikelompokkan dengan benar. Setelah Anda mencapai partisi logis, kemudian berkonsentrasi pada waktu pencarian. Jika Anda hanya memisahkan data dengan id saja, mungkin banyak baris data tidak akan pernah diakses untuk dibaca atau ditulis. Sekarang, itu harus menjadi pertimbangan utama: Cari semua id yang paling sering diakses dan dipartisi dengan itu . Semua id yang lebih jarang diakses harus berada di satu tabel arsip besar yang masih dapat diakses dengan pencarian indeks untuk permintaan 'sekali dalam bulan biru'.

Dampak keseluruhan harus memiliki setidaknya dua partisi: Satu untuk id yang sering diakses, dan parisi lain untuk id lainnya. Jika id yang sering diakses cukup besar, Anda dapat mempartisi itu secara opsional.

200 juta baris sudah pasti dalam kisaran di mana Anda bisa mendapat manfaat dari tabel partisi. Bergantung pada aplikasi Anda, Anda dapat bertaruh beberapa manfaat yang tercantum di bawah ini:

• Kemudahan membersihkan data lama Jika Anda perlu menghapus catatan lebih dari (katakanlah) 6 bulan, Anda bisa mempartisi tabel pada tanggal dan kemudian menukar partisi yang lebih lama. Ini jauh lebih cepat daripada menghapus data dari sebuah tabel dan seringkali dapat dilakukan pada sistem live. Dalam kasus OP, ini mungkin berguna untuk pemeliharaan sistem.

• Beberapa volume disk Mempartisi memungkinkan Anda untuk membagi data untuk mendistribusikan lalu lintas disk ke beberapa volume disk untuk kecepatan. Dengan pengontrol RAID modern, ini tidak akan menjadi masalah bagi OP.

• Pemindaian tabel dan rentang yang lebih cepat Sungguh, sistem operasional seharusnya tidak melakukan hal semacam ini, tetapi gudang data atau sistem serupa akan melakukan kueri semacam ini secara kuantitas. Pindaian tabel terutama menggunakan lalu lintas disk berurutan, sehingga biasanya merupakan cara paling efisien untuk memproses kueri yang mengembalikan lebih dari beberapa persen dari baris dalam tabel.
  
  Partisi dengan filter umum (biasanya berdasarkan waktu atau periode) memungkinkan potongan besar tabel dihilangkan dari pertanyaan seperti itu jika predikat dapat diselesaikan terhadap kunci partisi. Ini juga memungkinkan tabel untuk dipecah menjadi beberapa volume, yang dapat memberikan keuntungan kinerja yang signifikan untuk set data yang besar. Biasanya, ini bukan masalah untuk sistem operasional.

Untuk tujuan OP, partisi kemungkinan tidak akan mencapai banyak manfaat kinerja untuk pertanyaan operasional, tetapi mungkin berguna untuk manajemen sistem. Jika ada persyaratan signifikan untuk melaporkan agregat di volume besar data maka skema partisi yang tepat dapat membantu dengan itu.

Partisi memungkinkan reorg bersamaan dengan partisi, jika semua indeks Anda dipartisi. Jika tidak, partisi masih jauh lebih kecil dan menggunakan ruang kerja lebih sedikit untuk memaafkan. Dan, secara internal, setiap DBMS "baik" dapat melakukan hal-hal secara paralel dengan tabel dipartisi. Kemungkinan itu TIDAK termasuk MySQL atau MyISAM, ....