Google App Engine에서 가장 효과적인 다 대다 조인 모델은 무엇입니까?

빅 테이블 디자인은 명시 적으로 작은 테이블의 큰 호스트에 비정규을 선호 표준 관계형 모델의 철학의 많은 거부합니다.

이것이 문제가되는 더 큰 영역 중 하나는 많은 조인을 모델링하는 것입니다.

이러한 조인을 모델링하는 한 가지 방법은 첫 번째 정규 형식을 위반하고 모든 흥미로운 데이터를 db.ListProperty ()에 넣는 것입니다. 이것은 쿼리에서 검색 할 수있는 기능을 가지고 있지만 아직 다른 테이블을 가져 오는 것보다 목록을 검색하는 성능의 영향을 탐색하지 않았습니다.

불가능 조인, 그것은 이다 RelationshipProperties을 통해 링크 테이블에 가능. 따라서 충분한 노력을 기울이면 표준 교차 테이블 (상위 테이블을 모두 참조하는 결합 기본 키가있는 테이블)을 작성할 수 있습니다. 누구나 다양한 구현의 성능 적중을 탐색 했습니까?

-편집하다-

문서에서 제안 된 키 목록이 실제로 수행하는 한 가지 방법이지만 그 구현 및 기타 구현의 성능 및 이상률에 관심이 있습니다. 상호 키 목록을 작성하는 데 유틸리티가 있습니까? 반복되는 노력과 관련한 노력이 가치가 있습니까? 더 좋은 방법이 있습니까?

나는 또한 GAE 데이터 저장소와 함께 일하고 있습니다. 이 기사 를 아직 확인하지 않았다면 확인해야합니다 . 유용한 정보를 찾았다면 질문을 업데이트하십시오.

편집하다:

내가 발견 이 그것을 확인, 오늘.

GAE에 대한 경험에서는 테이블 쿼리를 조금만 사용해야합니다. "join"테이블을 추가하면 작업 속도가 훨씬 느려집니다. 예를 들어, 다 대다 관계를 공유하는 테이블 A와 B가 있고 A와 B 모두에 RelationshipProperty 필드가있는 "join"테이블 J를 작성하는 경우, 찾을 때마다 J를 조회해야합니다. 관련 기록 (엔티티).

레코드 / 엔티티를 가져올 때 포함되기 때문에 A 또는 B (또는 필요한 경우 둘 다)의 키 목록을 갖는 것이 훨씬 빠릅니다. 목록에 키가 너무 많지 않은 경우 (즉, 엔터티가 너무 크지 않은 경우)이 방법입니다.

내 응용 프로그램에서 ndb를 사용하기 시작했으며 엔터티를 가져올 때 키를 사용하면 몇 가지 중요한 이점이 있습니다. 엔티티가 이미 캐시 된 경우 먼저 메모리 또는 memcache에서 엔티티를 가져옵니다. 따라서 키 목록에 상당한 겹치는 부분이 있으면 이미 가져온 엔티티에 대해 페치가 훨씬 빠릅니다.