Scaling usermeta WordPress untuk ribuan pengguna

Saya telah mengembangkan plugin CRM untuk klien yang terintegrasi dengan manajemen pengguna WordPress dan saya menyimpan informasi tambahan untuk setiap pengguna di bawah wp_usermetatabel.

Namun, database pelanggan klien tumbuh secara eksponensial, dan kami sekarang dalam ribuan , yang memberi kami beberapa puluh ribu baris wp_usermeta: pada titik ini saya mulai khawatir tentang skalabilitas arsitektur ini .

Adakah yang punya pengalaman mengelola jumlah pengguna dengan cara WordPress? Haruskah saya menambahkan kolom ke wp_userstabel alih-alih mengandalkan kolom wp_usermeta? Bagaimana saya bisa mendiagnosis / profil WordPress dan kinerja kode saya sendiri pada tahap ini?

Saya tidak pernah bekerja pada jumlah data sebanyak itu dan pada tingkat yang meningkat ini, dan setiap pointer akan berharga.

Ukuran tabel sebenarnya bukan masalah, kueri yang Anda jalankan di meja itu mungkin.

Misalnya, jika Anda memilih pengguna berdasarkan data yang disimpan dalam tabel meta pengguna, maka kueri itu akan sangat tidak dioptimalkan, karena meta_value bukan bidang yang diindeks. Dalam hal ini Anda mungkin perlu menambahkan indeks tambahan atau mempertimbangkan untuk menyimpan data tertentu dengan cara yang berbeda, seperti dengan taksonomi khusus.

Secara umum, hal-hal yang Anda simpan sebagai meta seharusnya tidak pernah menjadi sesuatu yang secara eksklusif akan Anda cari. Ini berlaku di semua tabel meta di WordPress. Meta terutama dirancang untuk ditarik oleh meta_key, bukan oleh meta_value. Taksonomi membatasi nilai yang mungkin untuk satu set dan mengatur informasi secara berbeda, sehingga mereka melakukan lebih baik ketika "nilai" dihitung sebagai apa yang Anda pilih.

Catatan, memilih dengan kedua meta_key dan meta_value secara umum baik-baik saja, karena mySQL akan mengoptimalkan kueri yang didasarkan pada meta_key terlebih dahulu, mengurangi jumlah data untuk mencari ke batas (mudah-mudahan) dikelola. Jika ini menjadi masalah, Anda dapat "memperbaikinya" dengan menambahkan indeks baru ke tabel meta dengan meta_key dan meta_value pada indeks, namun karena meta_value LONGTEXT, Anda perlu membatasi panjang indeks untuk sesuatu yang masuk akal, seperti 20-30 atau sesuatu, tergantung pada data Anda. Perhatikan bahwa indeks ini mungkin jauh, jauh lebih besar dari data aktual Anda dan secara drastis akan menambah ruang penyimpanan yang dibutuhkan. Namun, itu akan jauh lebih cepat di jenis pertanyaan itu. Konsultasikan DBA yang memenuhi syarat jika ini menjadi masalah nyata.

Untuk referensi, di WordPress.org kami memiliki sekitar 11 juta pengguna terdaftar. Jumlah meta bervariasi per pengguna, dengan mungkin minimal 8 baris per, dan mungkin maks sekitar 250-ish. Tabel pengguna sekitar 2,5 GB, tabel usermeta sekitar 4 GB. Tampaknya berjalan baik-baik saja, sebagian besar, tetapi sesekali kami menemukan beberapa permintaan aneh yang harus kami optimalkan.

Kecuali jika Anda menjalankan kueri Anda sendiri daripada menggunakan API, ukuran tabel tidak terlalu menjadi masalah karena wordpress menjalankan kueri dengan indeks tabel dan MYSQL seharusnya mengoptimalkan kueri jenis ini. Setiap kueri juga mengambil semua informasi meta dalam satu kueri.

Jika Anda bersikeras Anda dapat membagi tabel meta pengguna menjadi beberapa tabel menggunakan hash pada ID pengguna sebagai nama tabel, tetapi Anda mungkin harus menulis pengganti ke kelas wp_db untuk mengakses tabel kanan berdasarkan permintaan. Jika Anda tertarik mengikuti jalur ini, maka cari solusi untuk menangani pemasangan jaringan besar dengan banyak blog.

Tetapi jika Anda tidak memiliki masalah kinerja sekarang maka Anda dapat tumbuh lebih jauh tanpa melakukan penyesuaian yang signifikan. Ketika Anda mulai mendapatkan masalah kinerja hanya memindahkan DB ke server yang lebih cepat, itu akan lebih hemat biaya daripada manipulasi yang dapat Anda lakukan dengan cara WP mengakses info itu.