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


89

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

키-값은 매우 간단합니다. 단순한 값을 가진 키입니다.

키-값처럼 설명 된 문서 지향 데이터베이스를 보았지만 값은 JSON 개체와 같은 구조 일 수 있습니다. 각 "문서"는 다른 키와 동일한 키를 모두, 일부 또는 전혀 가질 수 없습니다.

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

그렇다면이 둘의 차이점은 무엇이며 왜 다른 하나를 사용합니까?

특별히 MongoDB와 Cassandra를 살펴 보았습니다. 기본적으로 변경 가능한 동적 구조가 필요하지만 다른 값에는 영향을주지 않습니다. 동시에 특정 키를 검색 / 필터링하고 보고서를 실행할 수 있어야합니다. CAP를 사용하면 AP가 가장 중요합니다. 데이터 충돌이나 손실이없는 한 데이터는 "결국"노드간에 동기화 될 수 있습니다. 각 사용자는 자신의 "테이블"을 갖게됩니다.

답변:


41

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를 기본 문서 저장소로 사용할 수 있지만 실제 문서 지향 저장소의 모든 기능을 얻을 수는 없습니다.


5
column family는 테이블과 같습니다. 행은 테이블 행과 같습니다. 열은 즉석에서 정의 할 수 있다는 점을 제외하면 데이터베이스 열과 비슷합니다. 따라서 경우에 따라 매우 드물게 채워진 테이블이 있거나 각 행에 다른 열이 채워질 수 있습니다.
DNA

1
데이터베이스에 따라 다릅니다. MongoDB (문서 지향)에서는 모든 단일 키를 업데이트 할 수도 있습니다.
David Raab 2011 년

1
그것이 사실이라면 MongoDB는 어떻게 문서 지향 데이터베이스를 정의하고 Cassandra는 열 지향적입니다. 어떻게 다릅니 까?
Luke

3
@Luke Column-oriented는 스키마가없는 RDBMS와 거의 비슷하게 보이지만 느슨한 구조 외에도 주요 차이점은 관계형이 아니라는 것입니다.
user327961

1
@ user327961 그러나 MongoDB는 스키마가없는 RDBMS 와도 같으며 관계형도 아닙니다.
huggie

54

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


이 경우 mongo (document)는 cassendra (Column)이 할 수있는 일을 할 수 있습니다. 그렇다면 칼럼이 필요한 이유는 무엇입니까?
sanjay patel

1
컬럼 지향 설계를 사용하면 문서 지향 스토리지 엔진보다 훨씬 더 효율적일 수 있습니다. MongoDB는 더 커지면 전체 문서를 디스크에 다시 작성해야하지만 Cassandra는 그럴 필요가 없습니다 (물론 단순화 된 것입니다. 여기에는 많은 세부 정보가 있습니다). 이것은 글을 쓸 때 카산드라를 훨씬 더 빠르게 만듭니다.
Theo

29

"삽입"에서 rdbms 단어를 사용하려면 문서 기반이보다 일관되고 직관적입니다. 카산드라를 사용하면 쿼럼 개념과 일관성을 유지할 수 있지만 모든 열 기반 시스템에 적용되지 않으며 가용성이 떨어집니다. 한 번 쓰기 / 자주 읽기가 많은 시스템에서는 MongoDB로 이동하십시오. 또한 항상 개체의 전체 구조를 읽을 계획이라면 고려하십시오. 문서 기반 시스템은 문서를받을 때 전체 문서를 반환하도록 설계되었으며 전체 행의 일부를 반환하는 데는 그다지 강력하지 않습니다.

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

또한 Mongo DB는 C ++로 작성되었으며 두 번째 주요 릴리스에있는 반면 Cassandra는 JVM에서 실행되어야하며 첫 번째 주요 릴리스는 어제 이후로만 릴리스 후보에 있습니다 (그러나 0.X 릴리스는 이미 대기업).

반면에 Cassandra의 설계는 부분적으로 Amazon Dynamo를 기반으로했으며 고 가용성 솔루션이되도록 핵심적으로 구축되었지만 열 기반 형식과는 관련이 없습니다. MongoDB도 확장되지만 Cassandra만큼 우아하지는 않습니다.


1
C ++와 Java로 작성된 소프트웨어의 문제점은 무엇입니까?
Nayuki

@Nayuki 이제 Java의 메모리 관리 모델의 지연 가비지 수집이 이론상 C ++의 "수동"관리 모델보다 성능이 뛰어나지 만 일반적으로 동등한 것을 작성하여 Java를 능가하는 것이 일반적으로 어렵지 않은 경쟁이 심한 워크로드가 있다는 것을 알고 있습니다. 최소한 예외 및 RTTI를 비활성화하는 한 C ++ 프로그램. 스택리스 코 루틴과 재개 가능한 함수를 잘 활용한다면 개인적으로 아직 Java가 제 C ++를 능가하는 것을 보지 못했습니다.
patrickjp93

0

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

혼란스러운 부분은 넓은 열의 "행"이 문서로 쉽게 표현 될 수 있다는 것입니다. 그러나 언급했듯이 서로 다르게 저장되고 서로 다른 목적에 맞게 최적화됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.