WordPress usermeta mở rộng cho hàng ngàn người dùng


11

Tôi đã phát triển một plugin CRM cho một khách hàng được tích hợp với quản lý người dùng WordPress và tôi đã lưu trữ thông tin bổ sung cho mỗi người dùng dưới wp_usermetabảng.

Tuy nhiên, cơ sở dữ liệu khách hàng của khách hàng đang tăng theo cấp số nhân và hiện chúng tôi có hàng ngàn , điều này mang lại cho chúng tôi vài chục nghìn hàng wp_usermeta: tại thời điểm này tôi bắt đầu lo lắng về khả năng mở rộng của kiến trúc này .

Có ai có bất kỳ kinh nghiệm nào trong việc quản lý một lượng người dùng như vậy theo cách của WordPress không? Tôi có nên thêm các cột vào wp_usersbảng thay vì dựa vào wp_usermetamột cột không? Làm cách nào tôi có thể chẩn đoán / hồ sơ WordPress và hiệu suất mã của riêng tôi ở giai đoạn này?

Tôi chưa bao giờ làm việc với số lượng dữ liệu như vậy và với tốc độ ngày càng tăng này, và bất kỳ con trỏ nào cũng sẽ có giá trị.

Câu trả lời:


15

Kích thước của bảng không thực sự là vấn đề, các truy vấn bạn đang chạy trên bảng đó có thể là.

Ví dụ: nếu bạn đang chọn người dùng dựa trên dữ liệu được lưu trữ trong bảng meta người dùng, thì truy vấn đó sẽ không được tối ưu hóa cao, vì meta_value không phải là trường được lập chỉ mục. Trong trường hợp đó, bạn có thể cần thêm các chỉ mục bổ sung hoặc xem xét việc lưu trữ dữ liệu cụ thể đó theo một cách khác, chẳng hạn như với phân loại tùy chỉnh.

Nói chung, những thứ mà bạn lưu trữ dưới dạng meta không bao giờ nên là thứ mà bạn sẽ độc quyền tìm kiếm dựa trên. Điều này áp dụng trên tất cả các bảng meta trong WordPress. Meta được thiết kế chủ yếu để được kéo ra bởi meta_key, không phải bởi meta_value. Phân loại giới hạn các giá trị có thể trong một tập hợp và sắp xếp thông tin khác nhau, vì vậy chúng làm tốt hơn khi "giá trị" được tính như những gì bạn đang chọn.

Lưu ý, việc chọn bởi cả meta_key và meta_value thường ổn, bởi vì myQuery sẽ tối ưu hóa truy vấn dựa trên meta_key trước, giảm lượng dữ liệu để tìm kiếm đến giới hạn có thể quản lý (hy vọng). Nếu ngay cả điều này trở thành vấn đề, bạn có thể "khắc phục" bằng cách thêm chỉ mục mới vào bảng meta với cả meta_key và meta_value trên chỉ mục, tuy nhiên vì meta_value là LONGTEXT, bạn cần giới hạn độ dài của chỉ mục đó ở mức hợp lý, như 20-30 hoặc một cái gì đó, tùy thuộc vào dữ liệu của bạn. Lưu ý rằng chỉ mục này có thể lớn hơn nhiều so với dữ liệu thực tế của bạn và sẽ tăng đáng kể dung lượng lưu trữ cần thiết. Tuy nhiên, nó sẽ nhanh hơn nhiều ở các loại truy vấn đó. Tham khảo ý kiến ​​một DBA đủ điều kiện nếu điều này trở thành một vấn đề thực sự.

Để tham khảo, trên WordPress.org, chúng tôi có khoảng 11 triệu người dùng đã đăng ký. Số lượng meta khác nhau cho mỗi người dùng, có thể tối thiểu 8 hàng mỗi lần và có thể tối đa khoảng 250-ish. Bảng người dùng khoảng 2,5 GB, bảng usermeta khoảng 4 GB. Có vẻ như để chạy ổn, đối với hầu hết các phần, nhưng thỉnh thoảng chúng tôi tìm thấy một số truy vấn kỳ quặc mà chúng tôi phải đi tối ưu hóa.


1
wordpress.org có lập chỉ mục bảng meta không? và nếu vậy, bạn có thể đưa ra ví dụ về cách nó được cấu hình?
dwenaus

1
Bảng usermeta không có nhiều chỉ mục hơn mặc định trên WordPress.org. Có một bảng meta được sử dụng trong bbPress nơi chúng tôi đã thêm một KEY bổ sung, có dạng(object_type,meta_key,meta_value(50))
Otto

Cảm ơn Otto. Bạn có bất cứ mẹo cụ thể nào để định hình / chẩn đoán hiệu năng truy vấn Wordpress của tôi không?
Sunyatasattva

2
Không thực sự là một câu hỏi liên quan đến WordPress ở đó, hãy tìm hiểu thêm về hồ sơ MySQL và như vậy. Bạn có thể sử dụng một số công cụ đơn giản như plugin Debug Bar để xem các truy vấn mà WordPress thực hiện và thời gian của chúng, nhưng các công cụ này còn thô sơ và một cơ chế cấu hình MySQL thực sự sẽ tốt hơn. Bạn cần xác định các tắc nghẽn thực sự trước khi thực hiện tối ưu hóa.
Otto

5

Trừ khi bạn đang chạy các truy vấn của riêng mình thay vì sử dụng API, kích thước của bảng không quan trọng bằng wordpress chạy các truy vấn theo các chỉ mục của bảng và MYSQL được cho là để tối ưu hóa loại truy vấn này. Mỗi truy vấn cũng lấy tất cả thông tin meta trong một truy vấn.

Nếu bạn khăng khăng bạn có thể chia bảng meta người dùng thành nhiều bảng bằng cách sử dụng hàm băm trên ID người dùng làm tên bảng, nhưng sau đó bạn có thể sẽ phải viết một thay thế cho lớp wp_db để truy cập vào bảng bên phải dựa trên truy vấn. Nếu bạn quan tâm đến việc đi theo con đường này thì hãy tìm giải pháp để xử lý các cài đặt mạng lớn với nhiều blog.

Nhưng nếu bây giờ bạn không có bất kỳ vấn đề nào về hiệu suất thì bạn có thể phát triển hơn nữa mà không cần thực hiện bất kỳ điều chỉnh đáng kể nào. Khi bạn bắt đầu gặp vấn đề về hiệu năng, chỉ cần chuyển DB sang máy chủ nhanh hơn, sẽ hiệu quả hơn về mặt chi phí so với mọi thao tác bạn có thể làm đối với cách WP truy cập thông tin đó.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.