필드 확장 성과 관련하여 필드 재사용과 새로운 필드 생성 간의 적절한 균형은 무엇입니까?

웹 사이트에서 다음 문구를 읽었습니다.

컨텐츠 유형에 새 필드를 추가하는 대신 기존 필드를 추가하는 것이 시스템의 복잡성을 줄이고 확장 성을 향상시키는 더 좋은 옵션입니다.

그리고 약간의 의심이 생깁니다.

우리가 개발중인 시스템에서 우리는 3 ~ 4 가지 컨텐츠 유형에서 필드를 재사용 할 수 있지만 인용 문구가 말한 것처럼 확장 성을 향상시키는 대신 필드의 테이블이 더 빨리 병목 현상이 생길 것이기 때문에 그것이 줄어들 것이라고 두려워합니다. (적어도이 경우에는 해당 필드의 모든 값이 함께 매년 수백만 개에 이르므로 테이블이 너무 커지기 때문에 이것이 내 추론입니다.) 동의하십니까?

설계 할 때 목표로 할 수있는 최대 행 수는 몇 개입니까? 그렇게하면 필드를 재사용 할시기와 새로운 것을 생성 할시기를 결정할 수 있습니다 (재사용 기회가 있더라도).

필드의 데이터 양은 일반적으로 문제가되지 않습니다. 걱정되는 경우 대체 필드 스토리지 플러그인을 살펴 보거나 직접 작성하십시오. 예를 들어 MongoDB 는 당신이 넣은 모든 것을 다룰 수 있습니다. 예를 들어 http://examiner.com에서 사용됩니다 .

진짜 문제는 그러나 당신이 가지고있는 필드의 수입니다. 현재 Drupal 7에서 모든 필드 의 전체 필드 구성은로드 여부에 관계없이 모든 단일 요청에 대해 캐시에서 가져옵니다.

필드 구성을로드 및 직렬화 해제하는 데 13MB 이상의 메모리가 필요한 250 개 이상의 필드가있는 사이트를 보았습니다.

편집 : Drupal 7.22에서 필드 정보 캐시가 개선되었으며 (자세한 내용은 http://drupal.org/node/1040790 참조) 특정 페이지에 표시된 번들 필드 만 캐시에서로드되며 별도의 캐시 항목. 여러 번들에서 인스턴스를 요청하는 잘못된 API 호출이없는 경우에만 작동합니다.

나는 berdir에 전적으로 동의합니다. 다음은 일부 노드 유형에서 수백만 개의 행과 30-40 개의 필드가있는 프로젝트에 대한 경험입니다.

1. 모든 필드가 기본 키로 페치되므로 필드 테이블의 행 수는 읽기 성능에 큰 문제가되지 않습니다.
2. 노드 유형 당 필드 수는 새 노드를 작성할 때 큰 성능 문제로 빠르게 증가 할 수 있습니다. 한 노드 유형에 30 개 이상의 필드가 있으면 새 노드를 작성할 때 60 개 이상의 INSERT 문이 발생합니다. 완료하는 데 몇 초가 걸립니다. 많은 양의 데이터를 생성하는 사용자는 성능에 영향을 미칩니다. 1000 개 노드의 대량 삽입에는 거의 1 시간이 걸립니다. 100'000 개의 노드를 업데이트해야하는 경우 이는 큰 문제입니다.
3. 필드 수에 문제가 있다고 생각되면 자신 만의 필드 스토리지를 작성하거나 필드를 사용하지 않는 것을 진지하게 고려해야합니다. (여전히 추가 노력으로 노드를 뷰로 작업 할 수 있습니다.)
4. MongoDB에 대한 단어. 매우 흥미로운 프로젝트이며 큰 DB의 올림픽으로 만들기를 바랍니다. 불행히도 MySql 또는 PgSql의 성숙도와 비교하면 아기입니다. 아주 어린 제품을 다룰 준비를하십시오.

무슨 일이 일어날 지 정말로 걱정한다면 시뮬레이션이 제대로 된 것 같습니다.

Rackspace Cloud, Amazon, Linode 또는 VPS를 쉽게 시작할 수있는 곳에서 계정을 만드십시오. 두 개의 동일한 인스턴스를 만듭니다. 각각 Drupal을 설치하십시오. 더미 컨텐츠 유형을 작성하고 한 시스템에서 다른 방법으로 필드를 설정하십시오. devel 모듈을 사용하여 콘텐츠의 보트로드를 만듭니다. Drupal이 필요에 따라 캐싱되도록 성능 설정을 조정하십시오. mysqltuner를 실행하고 각 추천마다 MySQL을 조정하십시오. 스왑이 발생하지 않고 APC 캐시가 변경되지 않도록 PHP 및 APC 설정을 다시 확인하십시오.

각각에 대해 적절한 기본 구성을 얻은 후에는 wget 및 drush를 사용하여 트래픽 (일반 방문자 및 관리자 업데이트 모두)을 시뮬레이션 한 다음 프로파일 링을 시작하십시오.

시뮬레이션은 완벽하지는 않지만 올바른 방향으로 갈 수 있습니다.

생성 된 테이블의 각 필드에있는 모든 단일 테이블 필드에서 인덱스를 사용할 때 필드 확장성에 관한 한 가지 문제. 기본 키 클러스터형 인덱스는 대부분의 필드를 합성 한 다음 각 필드에 대해 별도의 인덱스를 생성했습니다. 인덱스는 데이터베이스에 대한 많은 오버 헤드 쓰기를 생성하며 대부분의 경우 사용되지 않습니다.

또 다른 팁 : 많은 필드를 갖는 것은 많은 다른 모듈에서도 문제를 일으킬 것입니다. 예를 들어, 토큰 GUI는 URL 별칭을 편집하려고 할 때 몇 분 동안 브라우저를 지연시킵니다. 이 동작은 토큰이로드되고 표시 될 모든 페이지에서 볼 수 있습니다 (devel-dpm () 등 포함).

InnoDB를 사용할 때이 데이터를 여러 테이블로 분할하면 성능상의 이점이 없습니다 (MyISAM은 테이블 잠금으로 인해 다릅니다). 따라서 유사한 필드를 가진 유사한 콘텐츠 유형이 많을 경우 (구성이 동일 할 수 있으며 레이블 만 다를 수 있음) 필드를 재사용하십시오!

유사한 노드 속성으로 인해 템플리트 작성이 쉬워 질 수도 있습니다.

내 이야기를 공유하기 위해 Drupal Commerce를 사용하고 있으며 제품 변형 (Sku)에는 약 40 개의 필드가 있고 제품 ​​디스플레이에는 또 다른 460 (예, 미친 것)이 있습니다. 우리는이 모든 분야를 살펴볼 제품 비교 견해를 가지고있었습니다. 캐싱하지 않으면 일부 페이지로드에 최대 1 분이 걸릴 수 있습니다!

그러나 작동했습니다. 캐싱 및 니스를 사용한 경우 사용자 대기 시간이 그리 나쁘지 않았습니다.

우리가 너무 많은 분야에서 겪었던 주요 문제는 Display Suite를 사용하는 것입니다. 디스플레이 스위트를 사용하면 필드를 다시 정렬하거나 움직일 때 매우 느려집니다 (때로는 무응답).

운 좋게도 가장 복잡한 제품의 경우 최대 필드 수를 200-250 범위로 줄일 수 있도록 제품을 약간 리팩토링하기로 결정했습니다 (우리는 과학적인 계측을 수행하므로 복잡한 측정 및 사양이 필요함). .

흥미로운 질문입니다. 나는 전에 이것에 대해 생각했지만 때로는 필드를 재사용하는 것이 비슷한 필드를로드하지 않는 것이 편리 할 수 ​​있지만 우리가 많은 양의 데이터에서 선택 해야하는 특정 컨텐츠 유형을 갖는 것은 어리석은 것처럼 보입니다. 알고 결과에 반환되지 않습니다.

확장에 대한 모범 사례를 조언하기 위해 프로젝트에 대한 정보가 조금 더 필요합니다. 예상되는 트래픽은 몇 명입니까? 예를 들어 관리자의 트래픽을 제외한 모든 트래픽이 인증되지 않고 익명으로 캐시 된 경우

나는 지금까지 항상 필드를 재사용했지만 지금은 새 프로젝트에 노드 유형마다 고유 필드를 사용하는 것을 고려하고 있습니다. 실제로 각 엔터티 번들에 대해 모든 항목 (필드, 뷰, 규칙, 컨텍스트 등)을 멋지게 분리하고 싶습니다. 그래서 확장성에 대한 의문이 제기되어 나를 이끌어 냈습니다. Drupal 7.22에서 Berdir의 편집 (필드 정보 캐시가 개선되었습니다 (자세한 내용은 http://drupal.org/node/1040790 참조)에 만족합니다. 특정 페이지에 표시된 번들 필드 만로드됩니다 캐시와 개별 캐시 항목으로, 여러 번들에서 인스턴스를 요청하는 잘못된 API 호출이없는 경우에만 작동합니다.

여러 복잡한 사이트에서 몇 달 동안 사용해온 매우 흥미로운 모듈이 있음을 지적하고 싶습니다 . : https://www.drupal.org/project/render_cache 내 의견으로는 그 숨겨진 보석 중 하나입니다.

프로젝트 페이지에 표시된 것처럼 주석 부분은 실제로 DO 자체에서 사용되고 있습니다.

그렇다면 모든 것을 염두에두고 별도의 분야에 찬성하여 합의를 돌리겠습니까? 그러나 DS에 대해 언급 된 경고는 여전히 큰 문제입니다. 예를 들어 코어 블록 관리 인터페이스가 재정렬을 처리하는 방법 대신 아약스를 통해 저장하는 방식이 매우 귀찮습니다. 그래도 ds 문제라고 생각합니다 ...

내 제안에 따라 별도의 콘텐츠 유형으로 동일한 필드를 사용하는 것이 좋습니다. 사이트 성능이 향상되기 때문입니다. Drupal 7에서는 해당 시간에 선택 조작을 사용하는 경우 컨텐츠 유형에 동일한 필드를 사용하는 것이 Drupal7 사이트에 실제로 유용합니다.