Java - Google App Engine - Google Datastore에서 그래프 구조 모델링

Question

Google Apps Engine은 Google Datastore를 유일한 NoSQL 데이터베이스로 제공합니다 (BigTable을 기반으로 생각합니다).

저는 사회적인 데이터 구조를 가지고 있으며 그래프 데이터베이스에서와 같이 모델링하고 싶습니다. 내 응용 프로그램은 이기종 객체 (사용자, 파일, ...) 및 이들 사이의 관계 (예 : user1 OWNS file2, user2 FOLLOWS user3 등)를 저장해야합니다.

나는이 일반적인 상황을 모델링 할 수있는 좋은 방법을 찾고 있어요, 내가 솔루션의 두 가족으로 생각 :

1. 목록 기반 솔루션 : 모든 객체는 다른 관련 객체와의 목록이 포함되어 있습니다 목록에있는 객체의 존재 자체는 관계입니다 (Google에서 JDO 부분에 말한대로 https://developers.google.com/appengine/docs/java/datastore/jdo/relationships).

2. 그래프 기반 솔루션 : 노드와 관계는 모두 개체입니다. 객체는 관계와는 독립적으로 존재하지만 각 관계에는 두 개 (또는 그 이상) 연결된 객체에 대한 참조가 포함됩니다.

이 두 가지 접근 방법의 강점과 약점은 무엇입니까? 접근 방식에 대해서 1

:이 사람이 생각할 수있는 간단한 방법이며, 그것은 또한 공식 문서에 제시되어 있지만 :

• 각 감독 관계가 오브젝트 기록이 성장합니다 제한 사항이에있다 예를 들어 객체 차원 제한에 의해 주어진 가능한 관계의 수?
• JDO 기능이 있습니까? 아니면 데이터 저장소 구조로 인해 자연스럽게 구현 될 수 있습니까?
• 관계 검색 시간이 목록과 함께 증가합니다.이 솔루션이 많은 관계에 적합합니까?

접근법 2 : 각 관계는 더 높은 수준의 특성을 가질 수 있습니다 (이는 개체이며 속성을 가질 수 있습니다). 그리고 메모리 크기는 Google 문제가 아니라고 생각합니다.

• 각 관계에는 자체 레코드가 필요하므로 관계의 총 수가 증가하면 각 관련 커플의 검색 시간이 늘어납니다. 이것은 많은 양의 관계 (수백만, 수십억)에 적합한가? 나는. Google은 잘 구조화되어있는 레코드를 검색하는 좋은 방법이 있습니까? 아니면 곧 User4라는 User1이라는 친구를 검색하고 싶다면 몇 초 기다려야 할 상황에 처할 것입니까?
• 다른 측면에서는 새로운 관계가 추가 될 때 각 개체의 차원이 증가하지 않습니다.

두 가지 접근법에서 다른 중요한 점을 찾아서 최고의 모델을 선택하도록 도와 주시겠습니까?

Answer 1

먼저 Datastore의 검색 시간은 검색하는 엔티티 수에만 저장하는 엔티티 수에 따라 달라지지 않습니다. 따라서 10 억 개 중 하나의 관계 개체를 찾아야하는 경우 하나의 개체 만있는 것처럼 동일한 시간이 걸립니다.

둘째, 목록 접근 방식에는 "폭발 색인"이라는 심각한 제한이 있습니다.검색 가능한 목록을 포함하는 속성을 색인화해야합니다. 이 속성 이외의 다른 참조를 사용하는 쿼리를 사용하는 경우이 문제와 관련이 있습니다. Google의 의미를 이해해야합니다.

셋째, 목록 접근 방식은 훨씬 더 비쌉니다. 새로운 관계를 추가 할 때마다 상당한 비용으로 전체 엔터티를 다시 작성합니다. 키 전용 쿼리를 사용할 수 없으면 읽기 비용도 높아집니다. 객체 접근 방식을 사용하면 키 전용 쿼리를 사용하여 관계를 찾을 수 있으며 이러한 쿼리는 이제 무료입니다.

UPDATE :

의 관계가 지시하는 경우 사용자 단체의 관계 기관의 아이들을,뿐만 아니라 관계 엔티티의 ID와 같은 개체 ID를 사용하여 고려할 수 있습니다. 그런 다음 Relationship 엔티티에는 전혀 특성이 없으므로 가장 비용 효율적인 솔루션입니다. 키 전용 ancestor queries을 사용하여 사용자가 소유 한 모든 객체를 검색 할 수 있습니다.

Answer 2

질문이 너무 복잡하지만 최선의 해결책을 설명하려고합니다 (파이썬에서는 대답하지만 자바에서는 동일하게 대답 할 것입니다).

class User(db.User): 
    followers = db.StringListProperty() 

단순 추가 팔로어.

user = User.get(key) 
user.followers.append(str(followerKey)) 

이 빨리 다음에 쿼리 및 추종자

User.all().filter('followers', followerKey) # -> followed 

당신이 내가있는이 빠르지 만 더 복잡하고 비용이 많이 드는 할 수 있도록 I/O는 비용이 많이 드는 기록 O /이 쿼리를 허용 :

class User(db.User): 
    followers = db.StringListProperty() 
    follows = db.StringListProperty() 

사용자 삭제가 필요하므로 변경 사항이 복잡하기 때문에 다음과 같이 2 번 작성해야합니다.

관계를 저장할 수도 있지만 추종자와 함께 두 번째 예제보다 복잡하기 때문에 상황이 악화됩니다 ... - 엔터티가 1Mb를 가질 수 있다는 것을 명심하십시오. 제한이 없지만 될 수 있습니다.

Answer 3

저는 AppEngine 응용 프로그램을 가지고 있으며 두 가지 접근 방법을 사용합니다. 어떤 것이 더 좋은가는 두 가지에 달려 있습니다. 얼마나 많은 관계가있을 수 있는지, 얼마나 자주 관계가 바뀌는 지에 대한 실질적인 한계입니다.

참고 1 : 내 답변은 Objectify 사용 경험과 캐싱 사용량을 기반으로합니다. 마일리지는 다른 접근 방식에 따라 달라질 수 있습니다.

참고 2 : 올바른 데이터 저장소 용어 '이름'대신 여기에 'id'라는 용어를 사용했습니다. 이름은 혼란 스러웠을 것이고 id는 객체화 된 용어와 더 잘 어울립니다.

참석 한 학교와 연결된 사용자를 고려하고 그 반대의 경우도 고려하십시오. 이 경우 두 가지를 모두 수행합니다. '목록'방법의 변형과 함께 사용자를 학교에 연결하십시오. 사용자가 참석 한 학교 ID 목록을 다른 유형/종류이지만 사용자와 동일한 ID를 가진 UserSchoolLinks 항목으로 저장합니다. 예를 들어, 사용자의 id = '6h30n'은 ID가 '6h30n'인 UserSchoolLinks 객체를 저장합니다. 사용자의 학교 목록을 가져와야 할 때마다 키 조회로이 단일 항목을로드하십시오.

그러나 학교에 다니는 사용자의 경우 반대로하지 마십시오. 그 관계에 대해 링크 엔티티를 삽입하십시오. 링크 엔티티의 ID에는 학교의 ID와 사용자의 ID를 조합하여 사용하십시오. 두 ID를 별도의 속성으로 엔티티에 저장하십시오.예를 들어 학교 'g3g0a3'에 다니는 사용자 '6h30n'의 SchoolUserLink는 'g3g0a3 ~ 6h30n'이라는 ID를 가져 오며 school = g3g0a3 및 user = 6h30n 필드를 포함합니다. 학교 속성에 대한 쿼리를 사용하여 학교에 대한 모든 SchoolUserLinks를 가져옵니다.

1. 사용자가 자주 학교를 볼 수 있지만 거의 변경할 것 :

   는 그 이유는. 이 접근 방식을 사용하면 사용자의 학교는 캐싱되며 프로필을 공격 할 때마다 가져올 필요가 없습니다.

2. 키 조회를 통해 사용자의 학교가 나올 예정이므로 검색어를 사용하지 않습니다. 따라서 사용자 학교의 최종 일관성을 처리 할 필요가 없습니다.

3. 학교에는 여러 사용자가 참석할 수 있습니다. 이 관계를 링크 엔티티로 저장하면 거대한 단일 객체를 만들지 않아도됩니다.

4. 학교에 다니는 사용자가 많이 바뀔 것입니다. 이렇게하면 우리는 하나의 큰 개체를 자주 작성할 필요가 없습니다.

5. 사용자 엔티티의 ID를 UserSchoolLinks 엔티티의 ID로 사용하면 사용자의 ID 만 알 수있는 링크를 가져올 수 있습니다.

6. 학교 ID와 사용자 ID를 SchoolUser 링크의 ID로 결합합니다. 주요 조회를 통해 사용자와 학교가 연결되어 있는지 확인할 수 있습니다. 다시 한 번, 결과 일관성에 대해 걱정할 필요가 없습니다.

7. 사용자 ID를 SchoolUserLink의 속성으로 포함시킴으로써 사용자의 ID를 얻기 위해 SchoolUserLink 객체를 구문 분석 할 필요가 없습니다. 또한이 필드를 사용하여 양방향 간의 일관성을 확인하고 사람들이 수백 개의 학교에 다니는 경우에 대비하여 폴백을 사용할 수 있습니다.

하향 : 1.이 접근법은 DRY 원칙을 위반합니다. 최소한의 악마처럼 보입니다. 2. 우리는 여전히 학교에 다녔던 사용자를 얻기 위해 쿼리를 사용해야합니다. 그것은 결국 일관성을 유지한다는 것을 의미합니다.

UserSchoolLinks 엔터티를 업데이트하고 트랜잭션에서 SchoolUserLink 엔터티를 추가/제거하십시오.