Skalowanie usermeta WordPress dla tysięcy użytkowników

Opracowałem wtyczkę CRM dla klienta zintegrowanego z zarządzaniem użytkownikami WordPress i zapisałem dodatkowe informacje dla każdego użytkownika pod wp_usermetatabelą.

Jednak baza klientów klienta rośnie wykładniczo, a teraz jesteśmy w tysiącach , co daje nam kilkadziesiąt tysięcy rzędów wp_usermeta: w tym momencie zaczynam się martwić skalowalnością tej architektury .

Czy ktoś ma jakieś doświadczenie w zarządzaniu taką liczbą użytkowników na WordPress? Czy powinienem dodawać kolumny do wp_userstabeli zamiast polegać na wp_usermetajednej? Jak mogę zdiagnozować / profilować WordPress i mój własny kod na tym etapie?

Nigdy nie pracowałem nad taką ilością danych i przy tak rosnącej szybkości, a każdy wskaźnik byłby cenny.

Rozmiar tabeli nie jest tak naprawdę problemem, mogą to być zapytania uruchamiane na tej tabeli.

Na przykład, jeśli wybierasz użytkowników na podstawie danych przechowywanych w tabeli meta użytkowników, to zapytanie będzie wysoce niezoptymalizowane, ponieważ wartość meta nie jest polem indeksowanym. W takim przypadku może być konieczne dodanie dodatkowych indeksów lub rozważenie przechowywania tych konkretnych danych w inny sposób, na przykład z niestandardową taksonomią.

Ogólnie rzecz biorąc, rzeczy, które przechowujesz jako meta, nigdy nie powinny być czymś, na podstawie czego będziesz szukać wyłącznie. Dotyczy to wszystkich meta tabel w WordPress. Meta jest zaprojektowana głównie do wyciągania przez meta_key, a nie przez meta_value. Taksonomie ograniczają możliwe wartości do zestawu i inaczej organizują informacje, więc działają lepiej, gdy „wartość” liczy się jako wybrana.

Zauważ, że wybranie zarówno meta_key, jak i meta_value jest na ogół w porządku, ponieważ mySQL zoptymalizuje najpierw zapytanie w oparciu o meta_key, zmniejszając ilość danych do wyszukiwania do (miejmy nadzieję) możliwego do zarządzania limitu. Jeśli nawet stanie się to problemem, możesz go „naprawić”, dodając nowy indeks do meta-tabeli z zarówno meta_key, jak i meta_value w indeksie, jednak ponieważ wartość meta_value to LONGTEXT, musisz ograniczyć długość tego indeksu do czegoś rozsądnego, jak 20-30 czy coś, w zależności od twoich danych. Pamiętaj, że ten indeks może być znacznie, znacznie większy niż rzeczywiste dane i drastycznie zwiększy potrzebne miejsce do przechowywania. Będzie to jednak znacznie szybsze przy tego rodzaju zapytaniach. Skonsultuj się z wykwalifikowanym DBA, jeśli kiedykolwiek stanie się to poważnym problemem.

Dla porównania, na WordPress.org mamy zarejestrowanych około 11 milionów użytkowników. Ilość meta różni się w zależności od użytkownika, prawdopodobnie z minimum 8 wierszami na, a może maksymalnie z około 250-miesięcznym. Tabela użytkowników wynosi około 2,5 GB, a tabela usermeta około 4 GB. Wygląda na to, że działa dobrze, ale co jakiś czas znajdujemy jakieś dziwne zapytanie, które musimy zoptymalizować.

O ile nie uruchamiasz własnych zapytań zamiast interfejsu API, rozmiar tabeli nie ma większego znaczenia, ponieważ wordpress uruchamia zapytania według indeksów tabeli, a MYSQL powinien zoptymalizować tego rodzaju zapytania. Każde zapytanie pobiera również wszystkie meta informacje w jednym zapytaniu.

Jeśli nalegasz, możesz podzielić meta tabelę użytkownika na kilka tabel, używając skrótu ID użytkownika jako nazwy tabeli, ale prawdopodobnie będziesz musiał napisać zamiennik do klasy wp_db, aby uzyskać dostęp do odpowiedniej tabeli na podstawie zapytania. Jeśli chcesz podążać tą ścieżką, poszukaj rozwiązań do obsługi dużych instalacji sieciowych z wieloma blogami.

Ale jeśli nie masz teraz żadnych problemów z wydajnością, możesz znacznie dalej rosnąć bez dokonywania znaczących zmian. Kiedy zaczniesz mieć problemy z wydajnością, po prostu przenieś bazę danych na szybszy serwer, będzie to bardziej opłacalne niż jakakolwiek manipulacja sposobem, w jaki WP może uzyskać dostęp do tych informacji.