문서 기반 데이터베이스와 관계형 데이터베이스의 장단점
문서 기반 데이터베이스 (이 경우 CouchDB)로 몇 가지 요구 사항을 수행 할 수 있는지 확인하려고했습니다. 두 가지 일반적인 요구 사항 :
- 고유 색인이있는 일부 필드가있는 항목의 CRUD
- eBay와 같은 전자 상거래 웹 앱 ( 여기에 더 자세한 설명 ).
그리고 저는 문서 기반 데이터베이스가 이러한 요구 사항을 해결하기위한 최선의 선택이 아니라고 생각하기 시작했습니다. 또한 문서 기반 데이터베이스의 사용을 상상할 수 없습니다 (제 상상력이 너무 제한적일 수 있음).
이러한 요구 사항에 대해 문서 지향 데이터베이스를 사용하려고 할 때 느릅 나무에게 배를 묻는 다면 설명해 주 시겠습니까?
문서 지향 방식으로 애플리케이션에 접근하는 방법을 생각해야합니다. RDBMS에서 문제를 모델링하는 방법을 복제하려고하면 실패합니다. 당신이 만들고 싶을 수있는 다른 절충점도 있습니다. ([ed : 이것이 인수와 어떻게 연결되는지 확실하지 않지만 :] CouchDB의 설계는 언제든지 실패 할 수있는 많은 노드의 활성 클러스터가 있다고 가정합니다. 앱이 데이터베이스 노드 중 하나가 사라지는 것을 어떻게 처리 할 것인가? 그 아래?)
그것에 대해 생각하는 한 가지 방법은 컴퓨터가없고 종이 문서 만 가지고 있다고 상상하는 것입니다. 전달되는 종이 조각을 사용하여 효율적인 비즈니스 프로세스를 어떻게 만들 수 있습니까? 병목 현상을 어떻게 피할 수 있습니까? 문제가 발생하면 어떻게합니까?
고려해야 할 또 다른 각도는 최종 일관성으로, 결국에는 일관성있는 상태에 도달하지만 일정 기간 동안 일관성이 없을 수 있습니다. 이것은 RDBMS 땅에서 혐오감이지만 실제 세계에서는 매우 흔합니다. 표준 거래의 예는 은행 계좌에서 돈을 이체하는 것입니다. 실제 세계에서는 단일 원자 거래를 통해 또는 서로 신용 및 직불 통지를 발행하는 다른 은행을 통해 실제로 어떻게 발생합니까? 수표를 쓰면 어떻게 되나요?
따라서 예를 살펴 보겠습니다.
- 고유 색인이있는 일부 필드가있는 항목의 CRUD입니다.
CouchDB 용어로 이것을 올바르게 이해한다면, 명명 된 값이 모든 문서에서 고유 한 것으로 보장되는 문서 모음을 원하십니까? 문서가 서로 다른 복제본에 생성 될 수 있으므로이 경우는 일반적으로 지원되지 않습니다.
따라서 우리는 실제 문제를보고 그것을 모델링 할 수 있는지 확인해야합니다. 정말 독특해야합니까? 애플리케이션이 동일한 값을 가진 여러 문서를 처리 할 수 있습니까? 고유 한 식별자를 할당해야합니까? 결정 론적으로 할 수 있습니까? 이것이 필요한 일반적인 시나리오는 고유 한 순차 식별자가 필요한 경우입니다. 이것은 복제 된 환경에서 해결하기 어렵습니다. 실제로 고유 ID가 생성 된 시간과 관련하여 엄격하게 순차적이어야하는 경우 ID가 즉시 필요하면 불가능 합니다 . 이러한 제약 중 하나 이상을 완화해야합니다.
- eBay와 같은 전자 상거래 웹 앱
해당 게시물에 마지막으로 작성한 댓글이 "매우 유용합니다! 감사합니다"라는 말을했기 때문에 여기에 무엇을 추가해야할지 모르겠습니다. 거기에 설명 된 접근 방식에서 누락되어 여전히 문제를 일으키는 것이 있습니까? 나는 MrKurt의 대답이 꽤 꽉 차 있다고 생각하고 경합을 줄이는 약간의 향상을 추가했습니다.
데이터를 정규화 할 필요가 있습니까?
- 예 : 관계형을 사용합니다.
- 아니오 : 문서를 사용합니다.
나는 같은 배에 있고, 지금은 couchdb를 좋아하고, 전체적인 기능적 스타일이 훌륭하다고 생각합니다. 그러나 정확히 언제 응용 프로그램에 사용하기 시작합니다. 제 말은, 예, 우리 모두는 스키마를 사용하지 않고 정상적인 형태가 길가에 남아있는 것에 대한 모든 불쾌한 끊김없이 매우 빠르게 애플리케이션 개발을 시작할 수 있습니다. 그러나 "우리는 거인의 어깨 위에 서있다"라는 문구를 만들어내는 것입니다. RDBMS를 사용하고 스키마를 정규화하고 사용하는 데에는 좋은 이유가 있습니다. 나의 오래된 오라클 헤드는 형태가없는 데이터에 대해 생각하고 있습니다.
couchdb에 대한 나의 주요 와우 요소는 복제 작업과 함께 작동하는 버전 관리 시스템입니다.
나는 지난 달에 couchdb의 저장 메커니즘을 파악하려고 노력해 왔는데, 분명히 B 트리를 사용하지만 정상적인 형식에 기반한 데이터를 저장하지 않습니다. 이것은 정말 똑똑하고 데이터 비트가 복제된다는 것을 깨닫고이 B 트리 항목에 대한 포인터를 만들 수 있다는 것을 의미합니까?
지금까지 base64 문자열로 스트리밍되는 xml 문서, 구성 파일, 리소스 파일을 생각하고 있습니다.
그러나 구조 데이터에 couchdb를 사용할 것입니다. 잘 모르겠습니다. 어떤 도움을 주셔서 대단히 감사합니다.
RDF 데이터 또는 자유 형식 텍스트를 저장하는 데 유용 할 수 있습니다.
ID로 검색 할 수있는 항목의 정의를 저장하는 기본 관계형 데이터베이스와 해당 항목의 설명 및 / 또는 사양에 대한 문서 데이터베이스를 가질 수 있습니다. 예를 들어 다음 필드가있는 Products 테이블이있는 관계형 데이터베이스가있을 수 있습니다.
- 제품 ID
- 기술
- 단가
- LotSize
- 명세서
그리고 해당 사양 필드에는 실제로 제품의 기술 사양이 포함 된 문서에 대한 참조가 포함됩니다. 이렇게하면 두 세계의 장점을 모두 얻을 수 있습니다.
문서 기반 DB는 문서 저장에 가장 적합합니다. Lotus Notes는 일반적인 구현이며 Notes 이메일이 그 예입니다. 설명하는 내용, 전자 상거래, CRUD 등의 경우 실제 DB는 인덱싱 된 데이터 항목 / 요소 (문서와 달리)의 저장 및 검색을 위해 더 잘 설계되었습니다.
Re CRUD : 전체 REST 패러다임이 CRUD에 직접 매핑됩니다 (또는 그 반대로). 따라서 리소스 (URI를 통해 식별 가능) 및 기본 작업 집합 (즉, CRUD)을 사용하여 요구 사항을 모델링 할 수 있다는 것을 알고 있다면 상당수의 문서 지향 시스템이 제공하는 REST 기반 시스템에 매우 근접 할 수 있습니다. 상자의.
'IT TIP' 카테고리의 다른 글
| C ++ 11 auto : 상수 참조를 얻는다면 어떨까요? (0) | 2020.11.05 |
|---|---|
| data.table로 할 수없는 data.frame으로 무엇을 할 수 있습니까? (0) | 2020.11.05 |
| Vim에서 부드럽게 스크롤하는 가장 좋은 방법은 무엇입니까? (0) | 2020.11.05 |
| WebSocket 요청-응답 서브 프로토콜 (0) | 2020.11.05 |
| Hibernate 주석을 사용하여 외래 키 제약을 어떻게 표시 할 수 있습니까? (0) | 2020.11.05 |