code

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

codestyles 2020. 10. 17. 10:32
반응형

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


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

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

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

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

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

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


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


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


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

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

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

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

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

반응형