Kami telah berhasil merancang struktur database PostgreSQL kami untuk menyimpan korespondensi, setahun telah berlalu, pengguna secara aktif mengisinya, sekarang memiliki
jutaan catatan , dan ... sesuatu mulai melambat.
Faktanya adalah bahwa
ketika tabel bertambah besar, “kedalaman” indeks juga tumbuh - meskipun secara logaritma. Namun seiring waktu, ini memaksa server untuk
memproses banyak halaman data untuk melakukan tugas baca / tulis yang sama daripada di awal.
Di sinilah
partisi datang untuk menyelamatkan.
Saya perhatikan bahwa ini bukan tentang sharding, yaitu distribusi data antara database atau server yang berbeda. Karena, bahkan membagi data menjadi
beberapa server, Anda tidak dapat menyingkirkan masalah "pembengkakan" indeks dari waktu ke waktu. Jelas bahwa jika Anda mampu membuat komisi server baru setiap hari, maka masalah Anda tidak lagi terletak pada bidang database tertentu.
Kami akan mempertimbangkan bukan skrip khusus untuk mengimplementasikan partisi "dalam perangkat keras", tetapi pendekatan itu sendiri - apa dan bagaimana "memotong-motong," dan apa yang menjadi tujuan dari keinginan tersebut.
Konsep
Sekali lagi, kami menetapkan tujuan kami: kami ingin memastikan bahwa hari ini, besok, dan setelah satu tahun, jumlah data PostgreSQL yang dibaca selama operasi baca / tulis tetap kurang lebih sama.
Untuk
data yang terakumulasi secara kronologis (pesan, dokumen, log, arsip, ...), pilihan alami sebagai kunci partisi adalah
tanggal / waktu acara . Dalam kasus kami, peristiwa seperti itu adalah
saat pesan dikirim .
Perhatikan bahwa pengguna hampir selalu
hanya bekerja dengan data "terbaru" seperti itu - mereka membaca pesan terbaru, menganalisis log terbaru ... Tidak, tentu saja, mereka dapat menggulir lebih jauh ke masa lalu, hanya melakukan ini sangat jarang.
Dari batasan-batasan ini, menjadi jelas bahwa bagian
"harian" akan menjadi solusi terbaik untuk pesan - setelah semua, pengguna kami akan hampir selalu membaca apa yang datang kepadanya "hari ini" atau "kemarin".
Jika kita menulis dan membaca hampir hanya satu bagian di siang hari, ini memberi kita
penggunaan memori dan disk yang lebih efisien - karena semua indeks bagian mudah masuk ke dalam RAM, tidak seperti bagian "besar dan tebal" dari seluruh tabel.
selangkah demi selangkah
Secara umum, semua hal di atas terdengar seperti satu keuntungan yang solid. Dan itu dapat dicapai, tetapi untuk ini kita harus berusaha keras - karena
keputusan untuk mempartisi salah satu entitas mengarah pada kebutuhan untuk "memotong" dan berhubungan dengannya .
Pesan, propertinya dan proyeksi
Karena kami memutuskan untuk memotong pesan berdasarkan tanggal, masuk akal juga untuk membagi entitas-properti (file yang dilampirkan, milis), dan
juga berdasarkan tanggal pesan , tergantung pada mereka.
Karena salah satu tugas khas kami hanya melihat register pesan (belum dibaca, masuk, semuanya), masuk akal juga untuk "menariknya" ke dalam partisi berdasarkan tanggal pesan.
Tambahkan kunci partisi (tanggal pesan) ke semua tabel: penerima, file, pendaftar. Anda tidak dapat menambahkan ke pesan itu sendiri, tetapi gunakan DateTime yang ada.
Tema
Karena topiknya adalah satu ke beberapa pesan, tidak akan mungkin untuk "memotongnya" dalam model yang sama, seseorang harus mengandalkan sesuatu yang lain. Dalam kasus kami,
tanggal pesan pertama dalam korespondensi adalah ideal - yaitu, saat penciptaan topik itu sendiri.
Tambahkan kunci partisi (tanggal topik) ke semua tabel: topik, peserta.
Tetapi sekarang kami memiliki dua masalah sekaligus:
- di bagian mana untuk mencari posting tentang topik?
- di bagian mana untuk mencari topik dari pesan?
Anda dapat, tentu saja, terus mencari di semua bagian, tetapi itu akan sangat menyedihkan, dan akan meniadakan semua kemenangan kami. Oleh karena itu, untuk mengetahui di mana tepatnya mencari, kami akan membuat tautan / petunjuk logis ke bagian:
- dalam pesan, tambahkan bidang dengan tanggal topik
- tambahkan ke topik serangkaian tanggal pesan untuk korespondensi ini (Anda dapat menggunakan tabel terpisah, atau Anda dapat menggunakan array tanggal)
Karena akan ada beberapa modifikasi pada daftar tanggal pesan untuk setiap korespondensi individu (setelah semua, hampir semua pesan jatuh ke 1-2 hari ke depan), saya akan memikirkan opsi ini.
Total, struktur basis kami mengambil bentuk berikut, dengan mempertimbangkan partisi:
Tabel: RU, jika Anda tidak menyukai Cyrillic, lebih baik untuk tidak melihat nama-nama tabel / bidang Simpan satu sen yang cukup
Nah, jika kita tidak menggunakan
opsi partisi klasik berdasarkan distribusi nilai bidang (melalui pemicu dan pewarisan atau PARTISI OLEH), tetapi "secara manual" di tingkat aplikasi, kita dapat melihat bahwa nilai kunci partisi sudah disimpan dalam nama tabel itu sendiri.
Oleh karena itu, jika Anda begitu
khawatir tentang jumlah data yang disimpan , maka Anda dapat menyingkirkan bidang "ekstra" ini dan merujuk ke tabel tertentu. Benar, semua sampel dari beberapa bagian dalam kasus ini harus diserahkan ke sisi aplikasi.