열 지향 NoSQL은 문서 지향과 어떻게 다릅니까?

열 지향 NoSQL은 문서 지향과 어떻게 다릅니까?

제가 읽은 NoSQL 데이터베이스의 세 가지 유형은 키-값, 열 지향 및 문서 지향입니다.

Key-Value는 매우 간단합니다.일반적인 값을 가진 키입니다.

키-값과 유사한 문서 지향 데이터베이스를 본 적이 있지만, 값은 JSON 개체와 같은 구조일 수 있습니다.각 "문서"는 다른 문서와 동일한 키를 모두, 일부 또는 모두 가질 수 있습니다.

열 방향은 구조를 지정하지 않는다는 점에서 문서 방향과 매우 유사합니다.

그럼 이 두 가지 차이는 무엇이며, 왜 하나를 다른 하나와 함께 사용합니까?

MongoDB와 Cassandra에 대해 자세히 알아봤습니다.기본적으로는 다른 가치관에 영향을 주지 않으면서 변화할 수 있는 역동적인 구조가 필요합니다.동시에 특정 키를 검색/필터링하고 보고서를 실행할 수 있어야 합니다.CAP에서는 AP가 가장 중요합니다.데이터의 경합이나 손실이 없는 한, 데이터는 「결국」노드간에 동기화할 수 있습니다.각 사용자는 자신의 "테이블"을 갖게 됩니다.

주요 차이점은 문서 저장소(예: MongoDB 및 CouchDB)는 하위 문서 내의 하위 문서, 문서가 포함된 목록 등 임의로 복잡한 문서를 허용하는 반면 열 저장소(예: Cassandra 및 HBase)는 고정된 형식(예: 엄격한 1단계 또는 2단계 사전)만 허용한다는 것이다.

Cassandra에서 각 행(키에 의해 주소 지정)에는 하나 이상의 "열"이 포함됩니다.열은 그 자체로 키-값 쌍입니다.열 이름을 미리 정의할 필요가 없습니다. 즉, 구조가 고정되어 있지 않습니다.행의 열은 키(이름)에 따라 정렬된 순서로 저장됩니다.

경우에 따라서는 행에 매우 많은 수의 열이 있을 수 있습니다(예: 특정 종류의 쿼리를 활성화하기 위한 색인 역할을 함).Cassandra는 이러한 큰 구조물을 효율적으로 처리할 수 있으며 특정 범위의 기둥을 검색할 수 있습니다.

슈퍼 컬럼이라고 불리는 추가 레벨의 구조(일반적으로 사용되지 않음)가 있습니다.여기서 컬럼에는 네스트된(하위) 컬럼이 포함됩니다.

전체 구조는 2 또는 3레벨의 키를 가진 네스트된 해시 테이블/사전으로 간주할 수 있습니다.

일반 열 패밀리:

row
    col  col  col ...
    val  val  val ...

슈퍼 컬럼 패밀리:

row
      supercol                      supercol                     ...
          (sub)col  (sub)col  ...       (sub)col  (sub)col  ...
           val       val      ...        val       val      ...

데이터를 분할하거나 그룹화하는 데 사용할 수 있는 상위 수준의 구조(열 패밀리와 키 스페이스)도 있습니다.

다음 질문도 참조: Cassandra: 서브컬럼이란

또는 http://wiki.apache.org/cassandra/ArticlesAndPresentations의 데이터 모델링 링크

참조: 문서 지향 데이터베이스와의 비교 - 보통 문서 전체를 삽입합니다(일반적으로 JSON). 반면 Cassandra에서는 개별 컬럼 또는 슈퍼 컬럼에 주소를 지정하여 개별적으로 업데이트할 수 있습니다. 즉, 서로 다른 세분화 수준에서 작동합니다.각 열에는 고유한 타임스탬프/버전(분산 클러스터 전체에서 업데이트를 조정하는 데 사용됨)이 있습니다.

Cassandra 컬럼 값은 바이트에 불과하지만 ASCII, UTF8 텍스트, 숫자, 날짜 등으로 입력할 수 있습니다.

물론 JSON을 포함한 컬럼을 삽입함으로써 Cassandra를 원시 문서 저장소로 사용할 수 있지만, 실제 문서 중심의 저장소의 모든 기능을 얻을 수는 없습니다.

"insert"에서 rdbms 단어를 사용하려면 Document-based가 더 일관되고 직선적입니다.cassandra를 참고하면 쿼럼 개념과 일관성을 확보할 수 있지만 모든 컬럼 기반 시스템에 적용되는 것은 아니며 가용성을 떨어뜨릴 수 있습니다.한번 쓰기/읽기가 많은 시스템에서는 MongoDB를 선택합니다.또한 객체의 전체 구조를 항상 읽을 계획인 경우에도 고려하십시오.문서 기반 시스템은 문서를 받았을 때 전체 문서를 반환하도록 설계되어 전체 행의 일부를 반환하는 데 그다지 강하지 않습니다.

Cassandra와 같은 컬럼 기반 시스템은 문서 기반 "업데이트"보다 훨씬 우수합니다.열이 포함된 행을 읽지 않고도 열의 값을 변경할 수 있습니다.쓰기는 실제로 같은 서버에서 수행할 필요가 없습니다.행은 여러 서버의 여러 파일에 포함될 수 있습니다.빠르게 진화하는 거대한 데이터 시스템에 대해 Cassandra를 선택하십시오.또한 키당 매우 큰 데이터 청크를 가질 계획이며 각 쿼리에서 모든 데이터 청크를 로드할 필요가 없는 경우에도 고려하십시오."select"에서 Cassandra는 필요한 열만 로드할 수 있습니다.

또, Mongo DB는 C++로 써져 있어 2번째 메이저 릴리스에 있는 반면, Cassandra는 JVM 상에서 가동할 필요가 있어, 첫 번째 메이저 릴리스는 어제부터 릴리스 후보입니다(단, 0.X 릴리스는 이미 메이저 기업의 프로덕션을 제출했습니다).

한편, Cassandra의 설계는 부분적으로 Amazon Dynamo에 근거해, 그 핵심을 하이 어베이러빌리티 솔루션으로서 구축되고 있습니다만, 그것은 칼럼 베이스의 형식과는 관계가 없습니다.MongoDB도 스케일아웃이 가능하지만 Cassandra만큼 우아하지는 않습니다.

주요 차이점은 각각의 DB 유형이 데이터를 물리적으로 저장하는 방식이라고 할 수 있습니다.
컬럼 타입의 경우 데이터는 컬럼별로 저장되므로 특정 컬럼에 대한 효율적인 집계 작업/쿼리가 가능합니다.
문서 유형을 사용하면 전체 문서가 논리적으로 한 곳에 저장되고 일반적으로 전체적으로 검색됩니다("열" / "필드"에서는 효율적인 집계가 불가능합니다).

혼란스러운 점은 넓은 열의 "행"은 문서로서 쉽게 나타낼 수 있지만 앞서 언급한 바와 같이 저장 및 용도가 다르다는 것입니다.

언급URL : https://stackoverflow.com/questions/7565012/how-does-column-oriented-nosql-differ-from-document-oriented