더 빠른 db_query, db_select 또는 EntityFieldQuery

그래서 더 빠른 db_query, db_select 또는 EntityFieldQuery가 무엇인지 찾으려고합니다. 현재 EntityFieldQuery를 사용하고 있습니다. 약 1600 개의 노드 항목을 잡고 있습니다.

나는 이것이 시스템에 부담을 줄 수 있다는 것을 알고 있으므로 1600 노드를 얻는 가장 좋은 옵션을 알아 내고 싶습니다. 몇 초 또는 밀리 초를 줄이면 내가 구축하는 응용 프로그램에 많은 문제가 있습니다.

답변 해 주셔서 감사합니다.

database

— 호르헤 칼데론
소스

프로필을 작성 했습니까?

— mpdonadio

당신이 무슨 뜻인지 확실하지. 좀 더 자세히 설명해 주시겠습니까?

— Jorge Calderon

사용해야 할 것은 정확히하려는 일에 달려 있습니까? 더 자세한 내용을 알려 주시면 도와 드리겠습니다. 많은 쿼리를 실행하는 경우 db_query ()가 가장 빠릅니다. 그러나 1600 개 이상의 엔터티를로드 할 때 entity_load가 느리기 때문에 엔터티 (entity_load)를 사용하여 엔터티를로드하는 경우 (entity_load) 중요하지 않을 수 있습니다.

— donutdan4114

쿼리 코드 / 쿼리 속도보다 더 많은 것이 있습니다. 예를 들어 노드 액세스가 필요합니까?

— 루비

@ 루비-그래. EntityFieldQuery를 계속 사용했지만 필요에 따라 노드에서 세 개의 사용자 정의 필드에 액세스해야합니다. 그러나 raf가 꽤 좋은 조언과 숫자를 제공했기 때문에 아래의 대답은 여전히 가장 좋은 대답입니다. 정확히 내가 찾던 것이 었습니다.

— Jorge Calderon

답변:

간단히 말해서 db_query가 가장 빠릅니다! 다음은 여러 가지 질문, 출처에서 수집 한 몇 가지 이유, 사실 및 그림입니다.

이 질문에 대한 간단한 인터넷 검색 결과는 다음과 같습니다.

For simple queries, db_query() is 22% faster than db_select()
For simple queries, db_query() is 124% faster than EFQ
For queries with two joins, db_query() is 29% faster than db_select()

이

db_query():

Total Incl. Wall Time (microsec):   796 microsecs
Total Incl. CPU (microsecs):    0 microsecs
Total Incl. MemUse (bytes): 123,352 bytes
Total Incl. PeakMemUse (bytes): 124,248 bytes
Number of Function Calls:   38

db_select()

Total Incl. Wall Time (microsec):   1,118 microsecs
Total Incl. CPU (microsecs):    0 microsecs
Total Incl. MemUse (bytes): 425,216 bytes
Total Incl. PeakMemUse (bytes): 436,392 bytes
Number of Function Calls:   88

위에서 알 수 있듯이 db_select는 db_query보다 많은 함수를 호출하고 더 많은 메모리를 사용합니다.

db_select를 사용해야하는 이유는 여기 를 참조 하십시오.
db_select에서 EntityFieldQuery를 사용하는 이유에 대한 이유는 여기 를 참조 하십시오.
db_query와 db_select의 성능 비교는 여기 를 참조 하십시오

선택은 전적으로 귀하의 요구 사항을 기반으로해야한다고 생각합니다. EntityFieldQuery는 느릴 수 있지만 간단한 구문, 필드 스토리지의 플러그 가능, 느슨한 결합 등 많은 장점을 제공합니다.

— 라프
소스

이것이 바로 내가 찾던 것입니다. 고마워요 Raf.

— Jorge Calderon

1600 노드의 경우 API를 둘러 보지 않고 EntityFieldQuery를 사용하는 것은 매우 나쁜 생각입니다. 당신은 잘못된 것을 최적화하고 있습니다.

안녕하세요 Chx, 좀 더 자세히 설명해주세요. 결론적으로 1600 개의 노드를 뽑아야합니다. 이미 EntityFieldQuery를 사용하고 있으므로 나쁜 아이디어가 무엇인지 이해하려고합니다. 내가 찾은 것은 EntityFieldQuery가 일부 영역에서 제한적이라는 것입니다. 지금까지 그것은 나에게 영향을 미치지 않습니다. 어쨌든, 당신의 생각을 기다리겠습니다.

— Jorge Calderon

모든 1600 노드의 필드 데이터 만 원하면 EFQE 가 도움이 될 수 있습니다. 이미 EFQ를 가지고 있다면 샌드 박스 페이지를보고 필요한 것을 파악할 수 있어야합니다.

— mikeytown2
소스