데이터 구조 - mysql 데이터베이스 탐색에 대한 PHP의 문제

에이전트 분배 시스템에 관한 알고리즘 최적화 문제

예를 들어 에이전트 레벨은 골드, 실버, 브론즈의 세 가지 레벨로 나뉩니다. 저는 이제 골드 에이전트 A이고 동시에 실버 에이전트 B, C, D를 개발했습니다. 실버 에이전트 b는 브론즈를 개발했습니다. 그림과 같이 에이전트 E 및 F:
A의 하위 프록시 목록
╦=======
║
╠= b
║ ╠== e
║ ╠== f
╠= c
╠= d
위의 예시 그림을 만들기 위해 사용하는 방법은 다음과 같습니다. (PHP+MYSQL)
우선 에이전트가 다음과 같은 모든 에이전트를 검색합니다. A.
예를 들어 B 상담원을 찾은 후, B 상담원이 우월한 상담원을 모두 검색하면 검색이 완료됩니다.
C요원을 다시 검색해 보세요...
등등.

질문:

이제 에이전트 데이터베이스에는 300,000개의 레코드가 있습니다. 각 에이전트는 에이전트 배포 시스템에서 자신의 하위 에이전트 트리를 볼 수 있습니다.
에이전트의 경우 각 검색에 시간이 오래 걸립니다. 하위 상담원이 1,000명인 경우 전혀 표시되지 않습니다.

---

제가 생각해낸 해결책은 배열을 사용하여 모든 사용자 관계를 저장한 다음 이 배열을 파일로 저장하는 것입니다. 사용자가 추가되거나 삭제될 때마다 배열이 동시에 업데이트됩니다. 원하는 데이터를 배열에서 순회한 다음 데이터베이스로 직접 이동하여 선택을 실행합니다. . 이 접근 방식이 가능합니까?

---

트래버스

상위 멤버 중에서 하위 멤버를 찾으려면 순회를 사용합니다. 이는 삼항 트리의 레벨 순회입니다. 이 알고리즘은 데이터베이스를 시각적으로 여러 번 쿼리합니다. . . 리소스를 너무 많이 소모합니다. 대안이 있나요? 은닉처? 레디스?

답글 내용:

에이전트 분배 시스템에 관한 알고리즘 최적화 문제

예를 들어 에이전트 레벨은 골드, 실버, 브론즈의 세 가지 레벨로 나뉩니다. 저는 이제 골드 에이전트 A입니다. 동시에 실버 에이전트 B, C, D를 개발했습니다. 실버 에이전트 b는 브론즈를 개발했습니다. 그림과 같이 에이전트 E 및 F:
A의 하위 프록시 목록
╦=======
║
╠= b
║ ╠== e
║ ╠== f
╠= c
╠= d
위의 예시 그림을 만들기 위해 사용하는 방법은 다음과 같습니다. (PHP+MYSQL)
우선 에이전트가 다음과 같은 모든 에이전트를 검색합니다. A.
예를 들어 B 상담원을 찾은 후, B 상담원이 우월한 상담원을 모두 검색하면 검색이 완료됩니다.
C 요원을 다시 검색해 보세요………
등등.

질문:

이제 에이전트 데이터베이스에는 300,000개의 레코드가 있습니다. 각 에이전트는 에이전트 배포 시스템에서 자신의 하위 에이전트 트리를 볼 수 있습니다.
에이전트의 경우 각 검색에 시간이 오래 걸립니다. 하위 상담원이 1,000명인 경우 전혀 표시되지 않습니다.

---

제가 생각해낸 해결책은 배열을 사용하여 모든 사용자 관계를 저장한 다음 이 배열을 파일로 저장하는 것입니다. 사용자가 추가되거나 삭제될 때마다 배열이 동시에 업데이트됩니다. 원하는 데이터를 배열에서 순회한 다음 데이터베이스로 직접 이동하여 선택을 실행합니다. . 이 접근 방식이 가능합니까?

---

트래버스

상위 멤버 중에서 하위 멤버를 찾으려면 순회를 사용합니다. 이는 삼항 트리의 레벨 순회입니다. 이 알고리즘은 데이터베이스를 시각적으로 여러 번 쿼리합니다. . . 리소스를 너무 많이 소모합니다. 대안이 있나요? 은닉처? 레디스?

계층적으로 쿼리하고 요청 시 데이터를 쿼리하는 것이 좋습니다. 관계 트리를 한 번에 표시하려면 많은 쿼리가 필요하고 리소스를 소비합니다.
이러한 구현에서는 무한한 분류 수준을 볼 수 있으며 왼쪽-오른쪽 값 원칙을 사용합니다. 그리고 트리구조를 순서대로 순회하는데, 쇼핑몰 분류도 같은 원리에 기초하고 있습니다

먼저 인덱스가 프록시 수준에서 생성되었는지 확인하세요.

트리 전체를 한 페이지에 표시하는 것은 적절하지 않습니다. 주문형 쿼리로 만들 수 있습니다.
골드 요원은 부하의 모든 실버 요원을 표시하는 페이지를 엽니다. 실버 요원 사용자를 클릭하면 부하의 브론즈 요원을 볼 수 있습니다

초대해 주셔서 감사합니다. 제 아이디어를 몇 가지 공유해 보겠습니다.

1. 업데이트가 자주 발생하지 않는 경우에는 매번 SQL 쿼리를 사용하는 대신 缓存(데이터 용량은 30만개, 캐시 레벨 1~2까지만 가능한 것으로 추정)을 사용하세요.

2. 은 위에서 언급한 대로 N级를 먼저 로드한 다음 ajax를 클릭한 후 N+1级을 요청합니다.

트리 구조 무한대 분류

구체적인 답변은 직접 찾아보셔요. 대략적인 원리를 말씀드리죠.
부하가 누구인지 최대한 빨리 알 수 있는 방법은 무엇인가요? 모두가 줄을 서게 되면 두 가지 조건만 충족하면 됩니다. 1- 누가 첫 번째인지 알고, 2- 자신이 마지막인지 확인합니다(물론 누가 마지막인지 알 수 있고 첫 번째인지 확인할 수도 있습니다).
이 추론을 바탕으로 indexNumber >= search.node.min && indexNumber < search.node.indexNumber

인 트리에서 *를 선택하는 등 빠른 검색을 달성하기 위해 각 노드에 적절한 일련 번호를 할당합니다.

최종 테이블 구조는
id, parent_id(부모 노드), top_id(트리가 여러 개인 경우 루트 노드), indexNumber(트리의 인덱스 번호, top_id+indexNumber는 고유함), min( 나는 이 브랜치 아래의 첫 번째 벤치마크입니다. 레벨(트리 높이)

예를 들어 비슷해야 합니다(괄호 안의 첫 번째 숫자는 인덱스 번호, 두 번째는 최소, 세 번째는 트리 높이)

<code>            a(6,1,0)
     b(3,1,1)      c(4,4,1)      d(5,5,1)
e(1,1,2) f(2,2,2)</code>

이 구조는 노드를 운영할 때 더 복잡하지만(예를 들어 f 뒤에 g를 추가하거나 f를 삭제하면 abcd가 시퀀스 번호를 다시 계산해야 함) 검색 속도는 일반적으로 매우 빠릅니다. 한 번의 검색으로 La.