CRUD 시나리오를위한 NoSql 업데이트 메커니즘

Question

Orm Frameworks에 대한 경험이 있으며 NoSql 데이터베이스 솔루션의 구조를 이해하기 시작합니다. 개체 모델을 기반으로 한 몇 가지 샘플을 계속 사용하겠습니다.

나는 아래의 문서 모델을 가지고 있으며 시나리오를 다루는 방법을 생각하고 싶지 않습니다. 태그

---

public class Post 
{ 
    public string Title { get; set; } 
    public List<Tag> Tags { get; set; } 
} 

public class Tag 
{ 
    public string Name { get; set; } 
} 

그리고 몇 가지 질문이 내 시나리오에 대한 내 마음에 표시

업데이트 게시물 개수와 몇 가지 태그

1. 저장 후
2. 표시 태그 목록입니다.

   포스트 클래스는 태그와 함께 저장되는 문서입니다. RDBMS에서 Tag와 Post는 many-to-many 릴레이션을 가지고 있지만 NoSql에서 관계가 없으므로 post 객체가 전체 멤버와 함께 저장된다는 것을 알았습니다. 게시물 수 시나리오가있는 태그 목록을 표시하면 전체 게시물 항목에서 무거운 쿼리가 발생합니다 모든 쿼리에서 약간의 노력으로이 시나리오에서 NoSql의 모든 이점을 잃지 않습니까?

   태그 이름을 업데이트해도 복잡한 작업이 발생하지 않습니까? 나는 전체 게시물 항목을 쿼리하고 그 태그 이름을 가지고 찾아 그것을 업데이 트해야합니다. 그런데 다중 문서 트랜잭션과 긴 프로세스가 필요하므로 NoSQL의 다중 문서 트랜잭션에 대한 지원이 없기 때문에 실패 할 경우 db에서 불일치가 발생합니다. 어떻게 처리 할 수 ​​있습니까?

   RDBMS (Sql) 시스템에 대해 NoSen의 단점을 표시하려고하지 않습니다. 나는 단지 내 생각이이 상황에 대해 정확하다는 것을 이해하려고 노력하고있다. 내가 놓친 것이나 나쁜 것들이 나쁘다고 생각하지는 않는다. 확장 성이 필요하므로 NoSQL 솔루션에 관심이 있습니다.

Answer 1

처음에는 NoSQL이 키 - 값 저장소, 문서 저장소, 그래프 데이터베이스 등 다양한 데이터베이스 유형을 다루는 전문 용어입니다 ... 다른 유형 및 구현 목록은 http://nosql-database.org/을 참조하십시오. 이러한 시스템 중 일부는 트랜잭션 보증도 제공합니다. Post가 데이터베이스에 완전히 쓰여지는 경우.

키 - 값 저장소는 매우 눈에 띄는 NoSQL 인스턴스 인 것처럼 보입니다. 첫 번째 질문에 대해서는

:

| pid | title | tags 
| 1 | foo | sql, rdbms 
| 2 | bar | sql, acid 
... 

: 당신은, 하나는 RDBMS에서 외래 키와 같은 엄격한 관계를 사용하지,하지만 당신은 그냥 게시물 인스턴스와 연관된 태그 목록을 유지하는 것이 옳다

| tag | pids 
| sql | 1, 2 
| rdbms | 1 
| acid | 2 

이 꽤 쉽게 게시물 개수를 할 수 있습니다 : 태그에서 질의를 들어 하나 개의 태그에 당신에게 모든 문서 ID를 제공하는 소위 역 색인 (http://en.wikipedia.org/wiki/Inverted_index)가 있습니다.

태그 이름을 업데이트하면 데이터에 대한지도 기반 액세스 권한이있는 경우 실제로는 그렇게 복잡하지 않습니다. 태그 이름을 변경하는 것은 할 수있는 일반적인 일이다,

map: IF post.tag contains('Sql') THEN emit(post) 

reduce: in post.tag: replace('Sql' by 'SQL') 
     write(post) 

그러나 나는 생각하지 않는다 : 간단한 작업 (의사 코드)와 'SQL'에 대한 태그 'SQL을'업데이트합니다.긴 프로세스 시간과 불일치 문제는 브루어 (Brewer)가 CAP 이론 (http://en.wikipedia.org/wiki/CAP_theorem)에서 말한 것으로 기본적으로 일관성, 가용성 및 파티션 허용 오차를 동시에 가질 수 없다고 말합니다. 다른 두. 귀하의 경우 : 태그의 일관된 업데이트 ('Sql'태그가 있고 다른 하나가 이미 'SQL'인 곳에 두 개의 문서를 읽을 수 없도록)를 유지하려면 다른 테이블을 잠글 수밖에 없습니다 독자가 없으므로 가용성을 확보 할 수 없습니다.

최종 생각 : 고 가용성, 우수한 확장 플랫폼을 구축하려는 경우 관계형 방식으로 너무 많이 생각하고 싶지는 않습니다.