문서 기반 NoSQL 옵션을 사용하면 KV 스토어를 통해 무엇을 구입하고 그 반대의 경우도 마찬가지입니까?
답변
키 – 값 저장소는 가장 간단한 데이터 모델을 제공하고, 이름에서 알 수 정확히 무엇을 : 그것은 저장 값이 키에 의해 색인하는 스토리지 시스템입니다. 키에 의한 쿼리로 제한되고 값은 불투명 하며 상점은 이에 대해 아무것도 알지 못합니다 . 이것은 매우 빠른 읽기 및 쓰기 작업 (간단한 디스크 액세스)을 허용하고이 모델은 일종의 비 휘발성 캐시 (즉, 수명이 긴 데이터에 대한 키로 빠른 액세스가 필요한 경우 적합 함)라고 생각합니다.
문서 지향 데이터베이스는 이전 모델을 확장하고 값이 저장되어 구조화 된 데이터베이스가 이해할 수있는 (따라서 이름, 문서) 형식입니다. 예를 들어 문서 는 비정규 화 된 방식으로 저장된 블로그 게시물 과 댓글 및 태그 일 수 있습니다. 데이터가 투명 하기 때문에 저장소는 문서의 색인 필드와 같은 더 많은 작업을 수행 할 수 있으며 키별 쿼리에 국한되지 않습니다. 내가 암시했듯이 이러한 데이터베이스는 단일 쿼리로 전체 페이지의 데이터를 가져올 수 있으며 콘텐츠 지향 응용 프로그램에 적합합니다 (이것이 Facebook이나 Amazon과 같은 큰 사이트가 좋아하는 이유입니다).
다른 종류의 NoSQL 데이터베이스에는 열 지향 저장소 , 그래프 데이터베이스 및 개체 데이터베이스가 포함 됩니다. 그러나 이것은 질문을 넘어선 다.
또한보십시오
답변
글쎄요, 저는 지난 한 달 동안 직접 NoSQL을 조사했습니다. 일반적으로 다음과 같이 말할 수 있다고 생각합니다.
- KV 저장소는 키에 대해 실제로 저장된 값 콘텐츠를 알지 못합니다.
- 문서 기반을 사용하면 db가 문서 구조 (예 : 블로그 게시물의 태그)를 알고 있으므로 값 콘텐츠 내에서 보조 색인을 정의 할 수 있습니다.
- NoSQL 솔루션에는 각각 다음과 같은 특정 기능을 고려해야합니다.
- KV 저장소의 특수 데이터 유형 (예 : redis에서와 같이 왼쪽 / 오른쪽 팝 / 푸시가있는 세트)
- riak이 말했듯이 쉽게 확장 / 축소 클러스터 (아직 시도하지 않았습니다 …)
- Voldemort에서와 같은 플러그 형 데이터 저장소
- CouchDB / couchapp와 같은 내장 웹 구성 및 웹 앱 지원
답변
문서 지향 데이터베이스 또는 문서 저장소는 반 구조화 된 데이터 인 문서 지향 정보를 저장, 검색 및 관리하기위한 것입니다. 키-값 저장소는 문서 지향 데이터베이스를 상속합니다. 차이점은 데이터가 처리되는 방식에 있습니다. 키-값 저장소에서 데이터는 본질적으로 데이터베이스에 대해 불투명 한 것으로 간주되는 반면 문서 지향 시스템은 데이터베이스 엔진이 추가 최적화를 위해 사용하는 메타 데이터를 추출하기 위해 문서의 내부 구조에 의존합니다.
MOngoDb와 Cassandra의 차이점을 다룬다면. MongoDB는 관계형 데이터베이스처럼 작동합니다. 데이터 모델은 최상위 수준의 데이터베이스, MySQL의 테이블과 같은 컬렉션 (예 : MySQL)과 컬렉션 내에 포함 된 문서로 구성됩니다. 각 문서에는 MySQL의 열 및 값과 유사한 필드와 값이 있습니다. 필드는 간단한 키 / 값 (예 : { ‘name’: ‘David Mytton’}) 일 수 있지만 { ‘name’: { ‘first’: David, ‘last’: ‘Mytton’}}과 같은 다른 문서도 포함 할 수 있습니다. Cassandra에서 문서는 실제로 단일 키와 값인 “열”로 알려져 있습니다. 예 : { ‘key’: ‘name’, ‘value’: ‘David Mytton’}. 내부 복제 및 일관성을위한 타임 스탬프 필드도 있습니다. 값은 단일 값일 수 있지만 다른 “열”을 포함 할 수도 있습니다. 그런 다음 이러한 열은 키로 참조되는 열의 특정 값을 기준으로 데이터를 정렬하는 column family 내에 존재합니다.
그러나 최상위 수준에는 MongoDB 데이터베이스와 유사한 키 스페이스가 있습니다.
