WordPress 사용자 관리와 통합 된 클라이언트 용 CRM 플러그인을 개발했으며 wp_usermeta표 아래에 각 사용자에 대한 추가 정보를 저장했습니다 .
그러나 클라이언트의 고객 데이터베이스는 기하 급수적으로 증가하고 있으며 현재 수천 명 에 이르러 수만 행을 제공합니다 wp_usermeta.이 시점에서 저는 이 아키텍처의 확장성에 대해 걱정하기 시작했습니다 .
WordPress 방식으로 그러한 양의 사용자를 관리 한 경험이 있습니까? 열에 wp_users의존하지 않고 테이블 에 열을 추가해야합니까 wp_usermeta? 이 단계에서 WordPress 및 자체 코드 성능을 진단 / 프로파일하는 방법은 무엇입니까?
나는 그런 양의 데이터 와이 증가하는 속도로 일한 적이 없으며 모든 포인터가 중요합니다.
답변:
테이블의 크기는 실제로 문제가 아니며 해당 테이블에서 실행중인 쿼리는 문제가 될 수 있습니다.
예를 들어, user-meta 테이블에 저장된 데이터를 기반으로 사용자를 선택하는 경우 meta_value가 색인화 된 필드가 아니기 때문에 해당 쿼리가 최적화되지 않습니다. 이 경우 추가 색인을 추가하거나 사용자 지정 분류법과 같은 다른 방식으로 특정 데이터를 저장하는 것이 좋습니다.
일반적으로 메타로 저장하는 콘텐츠는 독점적으로 검색하는 콘텐츠가되어서는 안됩니다. 이것은 WordPress의 모든 메타 테이블에 적용됩니다. 메타는 주로 meta_value가 아니라 meta_key에 의해 추출되도록 설계되었습니다. 분류법은 가능한 값을 세트로 제한하고 정보를 다르게 구성하므로 "값"이 선택한 항목으로 계산 될 때 더 잘 수행됩니다.
mySQL은 먼저 meta_key를 기반으로 쿼리를 최적화하여 검색 할 데이터의 양을 (관리 가능하게) 관리 가능한 한계로 줄이므로 meta_key와 meta_value로 선택하는 것이 일반적으로 좋습니다. 이것이 문제가 되더라도 meta_key와 meta_value를 인덱스에 추가하여 메타 테이블에 새 인덱스를 추가하여이를 "수정"할 수 있지만 meta_value가 LONGTEXT이므로 해당 인덱스의 길이를 적절한 것으로 제한해야합니다. 데이터에 따라 20-30 개 정도 이 색인은 실제 데이터보다 훨씬 클 수 있으며 필요한 저장 공간을 크게 증가시킵니다. 그러나 이러한 유형의 쿼리에서는 훨씬 빠릅니다. 이것이 실제 문제가되는 경우 자격을 갖춘 DBA에 문의하십시오.
참고로 WordPress.org에는 약 1,100 만 명의 사용자가 등록되어 있습니다. 메타의 양은 사용자마다 다르며, 아마도 최소 8 행, 최대 약 250-ish입니다. users 테이블은 약 2.5GB, usermeta 테이블은 약 4GB입니다. 대부분 정상적으로 작동하는 것 같지만 가끔씩 최적화해야 할 이상한 쿼리가 있습니다.
(object_type,meta_key,meta_value(50))
API를 사용하는 대신 자체 쿼리를 실행하지 않는 한, 테이블 크기는 중요하지 않습니다. 워드 프레스가 테이블의 인덱스에 의해 쿼리를 실행하고 MYSQL이 이러한 종류의 쿼리를 최적화해야합니다. 각 쿼리는 모든 메타 정보를 하나의 쿼리로 가져옵니다.
주장하면 사용자 ID의 해시를 테이블 이름으로 사용하여 사용자 메타 테이블을 여러 테이블로 분할 할 수 있지만 쿼리를 기반으로 올바른 테이블에 액세스하려면 wp_db 클래스를 대체해야합니다. 이 경로를 따르는 데 관심이있는 경우 많은 블로그에서 대규모 네트워크 설치를 처리하기위한 솔루션을 찾으십시오.
그러나 지금 성능 문제가 없다면 상당한 조정을하지 않고도 훨씬 더 발전 할 수 있습니다. 성능 문제가 발생하기 시작하면 DB를 더 빠른 서버로 옮기기 만하면 WP가 해당 정보에 액세스하는 방식을 수행하는 것보다 훨씬 비용 효율적입니다.