NoSQL에서 레코드 관계를 어떻게 추적합니까?

NoSQL에서 레코드 관계를 어떻게 추적합니까?

---

NoSQL KVP 또는 Document 데이터베이스에서 외래 키와 인덱스에 해당하는 것을 파악하려고합니다. 피벗 테이블이 없기 때문에 (두 객체 사이의 관계를 표시하는 키를 추가하기 위해) 일반 웹 페이지에 유용한 방식으로 데이터를 검색하는 방법에 대해 정말 충격을 받았습니다.

사용자가 있다고 가정하면이 사용자는 사이트 전체에 많은 의견을 남깁니다. 사용자 의견을 추적 할 수있는 유일한 방법은

1. 사용자 객체에 포함시킵니다 (매우 쓸모없는 것 같습니다)
2. 필요한 user_id:comments경우 주석을 가져올 수 있도록 각 주석의 키 [comment : 34, comment : 197 등 ...] 목록이 포함 된 값을 작성하고 유지하십시오 .

그러나 두 번째 예를 들어, "active_comments"라는 키와 같은 다른 것들을 추적하는 데 사용하면 벽돌 벽에 부딪 칠 것입니다. 여기에는 3 천만 개의 ID가 포함되어있을 수 있습니다. 최근에 알기 위해 각 페이지를 쿼리 하는 데 TON이 필요 했습니다. 적극적인 의견. 또한 많은 페이지가 동시에 업데이트를 시도 할 수 있으므로 경쟁 조건이 발생하기 쉽습니다 .

NoSQL 데이터베이스에서 다음과 같은 관계를 어떻게 추적 할 수 있습니까?

• 모든 사용자 의견
• 모든 활성 댓글
• 모든 게시물에 [keyword] 태그로 설정 됨
• 클럽의 모든 학생 또는 학생이있는 모든 클럽

아니면 내가 잘못 생각하고 있습니까?

---

다 대다 연관을 "NoSQL 방식"으로 저장하는 방법에 대한 모든 대답은 데이터를 중복 저장 하는 것과 같은 것으로 줄어 듭니다 .

NoSQL에서는 데이터 엔터티 간의 관계를 기반으로 데이터베이스를 설계하지 않습니다. 실행할 쿼리를 기반으로 데이터베이스를 설계합니다. 관계형 데이터베이스를 비정규 화하는 데 사용하는 것과 동일한 기준을 사용하십시오. 데이터가 응집력을 갖는 것이 더 중요한 경우 (정규화 된 테이블 대신 쉼표로 구분 된 목록의 값을 생각하면) 그렇게하십시오.

그러나 이것은 불가피하게 한 유형의 쿼리 (예 : 특정 기사에 대한 사용자의 주석)를 다른 유형의 쿼리 (주어진 사용자의 기사에 대한 주석)를 희생하면서 최적화합니다. 응용 프로그램에서 두 유형의 쿼리를 동일하게 최적화해야하는 경우 비정규 화하면 안됩니다. 마찬가지로 관계형 방식으로 데이터를 사용해야하는 경우 NoSQL 솔루션을 사용하지 않아야합니다.

중복되지 않은 데이터 세트가 서로 동기화되지 않을 경우 비정규 화 및 중복성이 발생할 위험이 있습니다. 이를 이상 현상 이라고합니다 . 정규화 된 관계형 데이터베이스를 사용하면 RDBMS가 이상을 방지 할 수 있습니다. 비정규 화 된 데이터베이스 또는 NoSQL에서는 이상을 방지하기 위해 응용 프로그램 코드를 작성해야합니다.

NoSQL 데이터베이스가 이상을 방지하기 위해 열심히 노력하는 것이 좋을 것이라고 생각할 수도 있습니다. 이를 수행 할 수있는 패러다임, 즉 관계형 패러다임이 있습니다.

---

1. user : userid : comments는 합리적인 접근법입니다. 인덱싱되지 않은 열에 대해 쿼리 할 수 ​​없다는 추가 요구 사항이있는 SQL의 열 인덱스와 동등한 것으로 생각하십시오.

2. 여기에서 요구 사항을 고려해야합니다. 3 천만 개의 항목이있는 목록은 속도가 느리기 때문에 불합리하지는 않지만, 아무 것도하지 않는 것은 비현실적입니다. 실제 요구 사항에 최근 주석이 표시되는 경우 주석을 추가 할 때마다 업데이트되는 매우 짧은 목록을 유지하는 것이 좋습니다. NoSQL에는 정규화 요구 사항이 없습니다. 경쟁 조건은 기본 키 값 저장소의 목록과 관련된 문제이지만 일반적으로 플랫폼에서 목록을 올바르게 지원하거나 잠금으로 무언가를 수행하거나 실제로 업데이트 실패에 대해 신경 쓰지 않습니다.

3. 사용자 의견과 동일-색인 키워드를 만듭니다.

4. 더 똑같이-아마도 학생의 재산으로서의 클럽 목록과 그 분야의 색인으로 클럽의 모든 회원을 얻을 수 있습니다.

---

couchDB 접근 방식은 맵 단계에서 적절한 클래스의 항목을 생성하고 축소하여 요약 할 것을 제안합니다. 따라서 모든 사용자를 맵핑 1하고 주어진 사용자에 대해 방출 하고 나중에 하나만 인쇄 할 수 있습니다. 그러나 couchDB에서 모든 추적 가능한 데이터의 영구적 인 뷰를 구축하려면 많은 디스크 스토리지가 필요합니다. 그러나 관계에 대한이 위키 페이지도 있습니다 : http://wiki.apache.org/couchdb/EntityRelationship .

반면에 Riak에는 관계를 구축 할 수있는 도구가 있습니다. 링크입니다. 링크 된 (여기 주석) 문서의 주소를 '루트'문서 (여기서는 사용자 문서)에 입력 할 수 있습니다. 하나의 트릭이 있습니다. 배포 된 경우 여러 위치에서 한 번에 수정 될 수 있습니다. 충돌을 일으켜 결과적으로 큰 벡터 클럭 트리가 발생합니다.

Riak은 또 다른 '메커니즘'을 가지고 있습니다. 버킷과 키라는 2 계층 키 네임 스페이스가 있습니다. 따라서 학생 예를 들어, 클럽 A, B 및 C와 학생 StudentX, StudentY가 있다면 StudentY를 다음과 같이 유지할 수 있습니다.

{ Key = {ClubA, StudentX}, Value = true }, 
{ Key = {ClubB, StudentX}, Value = true }, 
{ Key = {ClubA, StudentY}, Value = true }

주어진 버킷의 관계 키 목록 만 읽으십시오. 그게 뭐가 문제 야? 느려요. 버킷 버킷 나열은 결코 우선 순위였습니다. 점점 더 좋아지고 있습니다. btw. 이 예제 {true}는 StudentX 또는 Y의 단일 전체 프로파일에 연결될 수 있으므로 메모리를 낭비하지 않습니다 (여기서는 충돌이 불가능합니다).

보시다시피 NoSQL! = NoSQL. 특정 구현을 살펴보고 직접 테스트해야합니다.

컬럼 상점이 관계에 적합한 것처럼 보이기 전에 언급되어 있습니다. 그러나 A와 C 및 P 요구에 따라 달라집니다.) A가 필요하지 않고 Peta 바이트보다 작 으면 그대로두고 MySql 또는 Postgres로 이동하십시오.

행운을 빕니다

---

당신은

"user": {
    "userid": "unique value",
    "category": "student",
    "metainfo": "yada yada yada",
    "clubs": ["archery", "kendo"]
}

"comments": {
    "commentid": "unique value",
    "pageid": "unique value",
    "post-time": "ISO Date",
    "userid": "OP id -> THIS IS IMPORTANT"
}

"page": {
    "pageid": "unique value",
    "post-time": "ISO Date",
    "op-id": "user id",
    "tag": ["abc", "zxcv", "qwer"]
}

관계형 데이터베이스에서 일대 다 관계는 데이터를 정규화하는 것입니다. 이는 NoSQL 데이터베이스에서도 마찬가지입니다. 정보를 가져올 필드를 간단히 색인화하십시오.

예를 들어 중요한 인덱스는

• Comment.UserID
• Comment.PageID
• Comment.PostTime
• Page.Tag []

당신이 사용하는 경우 NosDB (SQL 지원하는 .NET 기반 형 NoSQL 데이터베이스) 쿼리처럼 될 것입니다

 SELECT * FROM Comments WHERE userid = ‘That user’;

 SELECT * FROM Comments WHERE pageid = ‘That user’;

 SELECT * FROM Comments WHERE post-time > DateTime('2016, 1, 1');

 SELECT * FROM Page WHERE tag = 'kendo'

SQL 치트 시트 또는 문서 에서 지원되는 모든 쿼리 유형을 확인하십시오 .

참고URL : https://stackoverflow.com/questions/4126811/how-do-you-track-record-relations-in-nosql