WordPress-Usermeta-Skalierung für Tausende von Benutzern

Ich habe ein CRM-Plugin für einen in die WordPress-Benutzerverwaltung integrierten Client entwickelt und zusätzliche Informationen für jeden Benutzer unter der wp_usermetaTabelle gespeichert .

Die Kundendatenbank des Kunden wächst jedoch exponentiell, und wir sind jetzt zu Tausenden , was uns mehrere Zehntausend Zeilen einbringt wp_usermeta: An diesem Punkt mache ich mir langsam Sorgen um die Skalierbarkeit dieser Architektur .

Hat jemand Erfahrung mit der Verwaltung einer solchen Anzahl von Benutzern auf WordPress-Weise? Sollte ich der wp_usersTabelle Spalten hinzufügen, anstatt mich auf die wp_usermetaeine zu verlassen? Wie kann ich in dieser Phase WordPress und meine eigene Codeleistung diagnostizieren / profilieren?

Ich habe noch nie mit einer solchen Datenmenge und mit dieser zunehmenden Geschwindigkeit gearbeitet, und jeder Zeiger wäre wertvoll.

Die Größe der Tabelle ist nicht wirklich das Problem, die Abfragen, die Sie für diese Tabelle ausführen, sind möglicherweise.

Wenn Sie beispielsweise Benutzer basierend auf Daten auswählen, die in der Benutzer-Metatabelle gespeichert sind, wird diese Abfrage stark unoptimiert, da meta_value kein indiziertes Feld ist. In diesem Fall müssen Sie möglicherweise zusätzliche Indizes hinzufügen oder diese bestimmten Daten auf andere Weise speichern, z. B. mit einer benutzerdefinierten Taxonomie.

Im Allgemeinen sollten Dinge, die Sie als Meta speichern, niemals etwas sein, nach dem Sie ausschließlich suchen. Dies gilt für alle Metatabellen in WordPress. Meta wurde hauptsächlich entwickelt, um vom meta_key und nicht vom meta_value herausgezogen zu werden. Taxonomien beschränken die möglichen Werte auf einen Satz und organisieren die Informationen unterschiedlich, sodass sie besser funktionieren, wenn der "Wert" als das zählt, worauf Sie auswählen.

Beachten Sie, dass die Auswahl sowohl nach meta_key als auch nach meta_value im Allgemeinen in Ordnung ist, da mySQL die Abfrage so optimiert, dass sie zuerst auf dem meta_key basiert, und die zu suchende Datenmenge auf ein (hoffentlich) überschaubares Limit reduziert. Wenn selbst dies zu einem Problem wird, können Sie es "beheben", indem Sie der Metatabelle einen neuen Index mit meta_key und meta_value im Index hinzufügen. Da meta_value jedoch LONGTEXT ist, müssen Sie die Länge dieses Index auf einen vernünftigen Wert beschränken. wie 20-30 oder so, abhängig von Ihren Daten. Beachten Sie, dass dieser Index möglicherweise sehr viel größer als Ihre tatsächlichen Daten ist und den benötigten Speicherplatz drastisch erhöht. Bei solchen Abfragen ist es jedoch viel schneller. Wenden Sie sich an einen qualifizierten DBA, falls dies jemals zu einem echten Problem wird.

Als Referenz haben wir auf WordPress.org ungefähr 11 Millionen Benutzer registriert. Die Anzahl der Metas variiert pro Benutzer, mit wahrscheinlich mindestens 8 Zeilen pro und möglicherweise maximal 250 Zeilen. Die Benutzertabelle ist ungefähr 2,5 GB groß, die Usermeta-Tabelle ungefähr 4 GB. Scheint größtenteils in Ordnung zu sein, aber hin und wieder finden wir eine merkwürdige Abfrage, die wir optimieren müssen.

Sofern Sie keine eigenen Abfragen ausführen, anstatt die API zu verwenden, spielt die Größe der Tabelle keine Rolle, da WordPress Abfragen anhand der Indizes der Tabelle ausführt und MYSQL diese Art von Abfragen optimieren soll. Jede Abfrage ruft auch alle Metainformationen in einer Abfrage ab.

Wenn Sie darauf bestehen, dass Sie die Benutzer-Metatabelle mit einem Hash auf der Benutzer-ID als Tabellennamen in mehrere Tabellen aufteilen können, müssen Sie wahrscheinlich einen Ersatz für die Klasse wp_db schreiben, um auf der Grundlage der Abfrage auf die richtige Tabelle zuzugreifen. Wenn Sie diesem Pfad folgen möchten, suchen Sie nach Lösungen für die Verwaltung großer Netzwerkinstallationen mit vielen Blogs.

Wenn Sie jetzt keine Leistungsprobleme haben, können Sie viel weiter wachsen, ohne wesentliche Anpassungen vorzunehmen. Wenn Sie Leistungsprobleme bekommen, verschieben Sie die Datenbank einfach auf einen schnelleren Server. Dies ist kostengünstiger als jede Manipulation, die Sie an der Art und Weise vornehmen können, wie WP auf diese Informationen zugreift.