데이터 스토리지가 필요한 플러그인을 개발할 때 한 가지 방법을 사용하는 장단점이 무엇입니까?
분과에 주어진 설명이 자세히 설명되지 않습니다
그러나 완전히 새로운 테이블로 뛰어 들기 전에 WordPress의 Post Meta (일명 Custom Fields)에 플러그인 데이터를 저장할 수 있는지 고려하십시오. 메타 후가 선호되는 방법입니다. 가능하면 실용적으로 사용하십시오.
답변:
글쎄, 내가 WP 스크립트 아동의 모자를 취한다면, 내 대답은 항상 post_meta를 사용하는 것입니다.
그러나 데이터베이스에 대해 한두 가지 사실을 알고 있으므로 제 대답은 결코 EAV (일명 post_meta 테이블)를 사용하여 쿼리해야 할 수도있는 데이터를 저장하지 않는 것입니다.
인덱스 프론트에는 기본적으로 메타 테이블에서 사용할 가치가 없습니다. 따라서 데이터 유형 XYZ를 저장하고 있고 XYZ가있는 모든 게시물에 대해 값이 'abc'... 인 행운을 빕니다. (WP trac의 모든 사용자 / 역할 / 캡 관련 티켓을 참조하여 어떻게 얻을 수 있는지에 대한 아이디어를 얻으십시오.)
조인 프론트에서는 옵티마이 저가 조인 기준이 여러 개인 경우 쿼리를 분석하는 대신 일반 알고리즘을 사용하기로 결정하는 한계에 빠르게 충돌합니다.
따라서, 아니요, 아니요, 아니요. 지금, 지금,하지 마십시오 적 메타를 사용합니다. 저장하는 것이 외형 적이 지 않고 쿼리 기준의 일부가되지 않는 한.
앱으로 분류됩니다. 예를 들어 영화 감독의 생년월일을 저장하는 경우보다 큽니다. 원하는 모든 메타를 사용하십시오. 그러나 영화의 출시 날짜를 저장하는 경우 별도의 테이블을 사용하지 않거나 게시물 테이블에 열을 추가하지 않고 해당 열에 색인을 추가해야합니다.
플러그인에 많은 양의 데이터가있는 경우 다음을 사용하는 wp_postmeta것이 좋지 않습니다.
WooCommerce를 예로 들어 ~ 30,000 개의 제품을 보유한 매장에서는 제품 당 평균 ~ 40 개의 게시물 메타 (속성 및 모든 항목), 제품 당 5 개의 제품 이미지가 표시됩니다. 이는 ~ 4 개의 이미지 메타가 있음을 의미합니다. 각 이미지마다 :
30,000 개 제품 x 40 개 메타 = 1,200,000 개 행 wp_postmeta
+
30,000 개 제품 x 5 개 이미지 x 4 개 이미지 메타 당 = 600,000 개 행 wp_postmeta
따라서 30,000 개의 제품 만 있으면 1,800,000 개의 행을 볼 수 wp_postmeta있습니다.
제품 또는 제품 이미지에 더 많은 속성을 추가하면이 수가 증가합니다.
그 문제는 두 가지입니다.
wp_postmeta이후의 mysql 버전을 사용하지 않으면 테이블이 색인화되지 않습니다 (예 :에 대한 FULLTEXT 색인 없음 meta_value).실제 사례에서 예를 제공하려면 다음을 수행하십시오.
SELECT meta_value FROM wp_postmeta WHERE meta_key LIKE '_shipping_city'이것은 5 ~ 10 주문이 있더라도 엔트리 레벨 전용 서버에서 ~ 3 초에 모든 주문 세부 사항에서 운송 도시를 선택합니다 . 이는 wp_postmeta라이브 설치에서 약 3 백만 행이 있는 테이블 에서 쿼리가 실행되기 때문 입니다.
테마는 wp_postmeta슬라이더, 리뷰 삽입, 기타 메타 에서 다양한 요소를 가져 오기 때문에 홈페이지조차 매우 느립니다 . 일반적으로 제품 목록이 매우 느리고 제품을 나열 할 때 검색 속도가 느려집니다.
일반적인 방법으로는이 문제를 해결할 수 없습니다. 서버에 Elastic Search를 넣고 Wordpress에서 Elastic Search 플러그인을 사용할 수 있으며, redis / memcached를 사용할 수 있고, 좋은 페이지 캐시 플러그인을 사용할 수 있지만, 결국 근본적인 문제는 남아 있습니다. wp_postmeta완료 될 때마다 테이블이 느려집니다. 아래에서 구현 한 솔루션을 테스트 한 서버 에서이 모든 것이 올바르게 설치 및 구성되었으며 최적화되었으며 캐싱 플러그인이 시작된 후 로그인하지 않은 사용자 또는 일반적으로 수행되는 쿼리에 대해 사이트가 정상적으로 작동했습니다.
그러나 로그인 한 사용자가 일반적으로 수행하지 않은 작업이나 크론, 캐싱 플러그인 또는 기타 유틸리티가 DB에서 실제 데이터를 가져와 캐시하거나 다른 작업을 수행하려고하는 순간 돼지가 느려졌습니다.
그래서 나는 다른 것을 시도했다 :
모든 제품 메타 (post type product for post type product )를 코드로 생성 된 사용자 정의 테이블 로 가져 가기 위해 작은 플러그인을 코딩했습니다 . 이 플러그인은 각 게시물의 모든 메타를 가져 와서 각 메타를 열로 추가하고 각 행에 값을 삽입하여 테이블을 만들었습니다. EAV 형식을 평평한 수평 관계형 형식으로 바꿨습니다. 또한 wp_postmeta테이블 에서 이동 된 모든 제품에서 postmeta를 삭제하는 플러그인이 있습니다.
내가 그 동안 첨부 파일 postmeta 및 다른 모든 게시물 유형의 메타를 자체 테이블 로 옮겼 습니다.
그런 다음 get_(post_type)_meta필터에 연결하여 메타 데이터 검색을 재정 의하여 새 사용자 정의 테이블에서 메타 데이터를 제공합니다.
이제 이전과 동일한 쿼리로 ~ 3 초가 wp_postmeta걸리고 ~ 0.006 초가 걸립니다. 사이트는 이제 새로운 WP 설치 인 것처럼 작동합니다.
....................
당연히 워드 프레스 방식으로 작업하는 것이 좋습니다. 실제로는 표준입니다.
그러나 EAV 테이블이 스케일링에서 매우 비효율적이라는 것도 명백한 지식입니다. 유연성이 뛰어나고 모든 데이터를 저장할 수 있지만 비용은 성능입니다. 기본적인 트레이드 오프입니다.
이러한 맥락에서, 많은 양의 데이터를 원하고 있고 그 데이터를 쿼리 / 검색하여 wp_postmeta테이블을 확실히 사용하려는 사람에게 알리기가 어렵습니다 . 성능이 크게 향상됩니다.
사용자 정의 테이블을 사용하면 데이터가 쌓여도 여전히 빠르게 유지됩니다.
Easy Digital Downloads 플러그인의 제작자 인 Pippin Williams는 플러그인을 코딩하기 시작했을 때 사용자 정의 테이블을 사용한다고 언급했듯이, 오랫동안 사용하거나 많은 데이터를 쌓을 계획이라면, 잘 디자인하면 사용자 정의 테이블을 사용하는 것이 더 효율적입니다.
데이터를 검색하기 전후에 다른 플러그인 / 애드온 개발자가 플러그인에 연결하여 데이터를 조작 할 수있는 수단이 있는지 확인해야합니다. 그렇게하면 꽤 견실합니다.
그것은 당신이하는 일에 달려 있습니다. WP 방법은 기존 테이블이 충분히 유연하게 설계 되었기 때문에 기존 테이블을 사용하는 것이지만 때로는 메타 데이터 카테고리를 원하는 경우 기존 테이블에 배치 할 수없는 새로운 데이터 클래스에 도달 할 수 있습니다. wp_termsmeta 테이블을 작성하도록 선택할 수 있습니다.
그러나 일반적으로 존재하는 다른 테이블에 데이터를 매우 편안하게 저장할 수 있으며 데이터 저장 위치는 플러그인의 기능에 따라 다릅니다.
캐싱은 WordPress 내에 구현되어 응답 시간도 단축됩니다.
100 % 거부에 동의했습니다. 그러나 그 주위에 방법이 있습니다.
쿼리 할 값에 포스트 메타를 사용할 때의 문제는 값이 배열 등일 때입니다.
array(
'key1' => 'val 1',
'key2' => 'val 2'
);
이것은 직렬화 된 문자열로 db에 저장되며 다음과 같습니다.
{array["key1"]...{}...}따라서 모든 게시물을 쿼리하려면 array['key2'] = 'val 2'wp가 array라는 모든 메타 항목을 가져 와서 압축을 푼 다음 테스트 한 다음 다음으로 이동해야합니다. 사이트가 성공적이고 게시물, 페이지, 사용자 정의 게시물 등이 많은 경우 서버가 확실하게 중단됩니다.
솔루션은 프로젝트에 따라 다르며 그 이유를 알 수 있습니다. 데이터를 var = val다음 과 같이 저장하면 wp는 모든 단일 테스트의 압축을 풀기 위해 PHP를 사용하지 않고도 검색 할 수 있습니다. 위 시나리오에서이를 수행하려면 일부 네임 스페이스를 사용하고 메타 키를 저장하십시오.
_array_key1 = 'val 1';
_array_key2 = 'val 2';
그러면 wp 2와 키 2를 찾으면 바로 잡아 당길 수 있습니다. 이것은 프로젝트에 따라 다릅니다. 현재 프로젝트는 약 20 개의 서로 다른 dataTypes을 각 사용자 정의 게시물과 함께 저장해야하므로 위의 내용은 검색 할 거대한 테이블을 생성하여 수만 개의 게시물을 어떻게 기대하는지 알 수 있습니다. 따라서이 시나리오에서는 사용자 정의 테이블이 유일한 방법입니다.
이것이 누군가를 돕기를 바랍니다.
내 FarmVille 사이트의 경우 :) 두 가지를 모두 수행했지만 판매했기 때문에 완료하지 않았습니다.
나는 한 편으로 사용자가 새로운 팜빌 데이터를 입력하여 워드 프레스 사이트를 편집하기를 원했기 때문에이 작업을 수행했다. (프론트 엔드 편집 플러그인을 통해) 그 뒤에 옵션으로 제공됩니다. 따라서 XML 또는 사용자가 옳았습니다 (위키 시스템의 일종).
두 가지를 모두 사용할 때의 예입니다.