시리즈 홈페이지는 다음과 같습니다: https://www.couchbase.com/blog/couchbase-oracle-developers-part-2-architecture/
Oracle DBA는 클러스터, 머신, 스토리지 시스템, 디스크 등으로 작업합니다. 오라클 개발자와 애플리케이션은 오라클 데이터베이스 시스템 내의 데이터베이스, 테이블, 행, 열, 파티션, 사용자, 데이터 유형으로 작업합니다. Couchbase에서 이러한 작업이 어떻게 수행되는지 비교하고 대조해 보겠습니다.
| 주제 | Oracle | 카우치베이스 | ||||
| 데이터베이스 | 데이터베이스 | 카우치베이스 인스턴스(단일 노드 또는 멀티노드 클러스터) 내에서 하나 이상의 버킷을 만들 수 있습니다. 개발자 관점에서 버킷을 생성하고 다양한 유형의 JSON을 버킷에 삽입하기 시작합니다.
CREATE: 버킷은 Couchbase 웹 콘솔 또는 REST API를 통해 만들 수 있습니다. 웹 콘솔에서 아래 정보를 입력합니다.
사용자는 다음을 제공합니다: 버킷의 이름입니다. 기존 데이터 스토리지의 위치. 카우치베이스는 지정된 직접 아래에 버킷 이름을 가진 디렉터리를 생성합니다. 이 경우, 고객 디렉터리는 : /my/data 아래에 생성됩니다. 이 디렉터리 /my/data는 데이터(키-값) 서비스가 있는 Couchbase 클러스터의 모든 노드에 존재해야 합니다. 이 디렉토리는 고정되어 있으며 변경할 수 없습니다. 사용된 메모리(메가바이트). 데이터를 삽입/로드할 때 데이터를 캐시하는 데 사용되는 고정된 메모리 양입니다. 메모리의 실제 데이터는 애플리케이션 액세스 패턴에 따라 달라집니다. 일반적인 LRU, MRU 알고리즘은 메모리에 보관할 문서와 퇴거할 문서를 결정하는 데 사용됩니다. 키 퇴거에 대한 자세한 내용은 링크를 참조하세요: 버킷 유형 카우치베이스: JSON 데이터베이스 멤캐시드: 멤캐시 임시모든 데이터, 인덱스가 메모리에만 있다는 점을 제외하면 Couchbase 버킷과 동일합니다. 복제본: 기본적으로 클러스터에는 데이터 사본이 하나 있습니다. 클러스터 내에 데이터 사본을 최대 3개까지 만들 수 있습니다. 클러스터의 CAP 정리 규칙. CAP 정리와 그 적용에 대한 많은 논문과 강연이 공개 도메인에 있습니다.Couchbase Bucket은 CP 시스템입니다. 즉, Couchbase는 가용성보다 일관성을 선택합니다(A보다 C). 파티션 허용 오차를 지원하는 것은 이러한 멀티노드 스케일 아웃 시스템의 필수 요건입니다. 모든 매개변수와 예제에 대한 자세한 내용은 Couchbase 설명서를 참조하세요. http://bit.ly/2GrbMOw |
||||
| 표 | 표 | 현재 카우치베이스 버킷은 두 가지 서비스를 제공합니다. 목적.
앞서 설명한 것처럼 Couchbase 시스템에는 최대 10개의 버킷이 있을 수 있습니다. RDBMS에서는 도메인에 속하는 행을 단일 테이블에 저장합니다. Couchbase에서는 개체에 대한 데이터를 최대한 많이 포함하도록 문서를 모델링합니다. 예를 들어, 고객 객체에는 기본 고객 정보뿐만 아니라 고객 주문도 포함할 수 있으므로 한 번의 GET 작업으로 전체 고객 정보를 빠르게 가져올 수 있습니다. N1QL을 통한 문서 삽입 예시:
CUSTOMER에 대한 CREATE TABLE이 없다는 점에 유의하세요. 버킷에 JSON 문서를 직접 삽입하면 됩니다. 버킷 고유 문서가 필요합니다. 이 고유 문서는 테이블의 기본 키로 모델링됩니다. 여러 부분이 있는 경우 하이픈, 밑줄 또는 마침표와 같은 구분 기호로 구분하세요. 이제 이커머스라는 이름의 버킷에 고객 문서가 생겼습니다. 이제 파트너와 같은 다른 유형의 문서가 필요하다고 가정해 보겠습니다. PARTNER라는 별도의 버킷을 만들면 됩니다. 또는 파트너 문서를 같은 버킷에 삽입할 수도 있습니다. 별도의 버킷에 삽입하는 것은 간단합니다. 카우치베이스에서는 애플리케이션에 대해 여러 유형의 문서를 저장할 때 동일한 버킷을 사용하는 것이 일반적이며 권장되는 방식입니다. 여기에는 두 가지 장점이 있습니다.
|
||||
| 행 | 행 | JSON 문서와 문서키를 사용합니다.
문서 키 디자인 시 고려 사항: http://bit.ly/2GnRwwV |
||||
| 칼럼 | 칼럼 | JSON은 키-값 쌍으로 구성됩니다.
예시 {"fullname": "Joe Smith"} {"name: {"fname":"Joe","lname":"Smith"} {"hobbies": ["레고","로봇공학","스키"]} 이 문서에서 '이름'은 속성이라고도 하는 키입니다. 그 값은 스칼라(전체 이름), 객체(이름) 또는 배열(취미)일 수 있습니다. Oracle에서는 테이블을 만들 때 열 이름과 해당 데이터 유형을 지정합니다. Couchbase에서는 JSON 문서를 삽입하기만 하면 됩니다. 각 문서는 속성(열)을 자체적으로 설명합니다. 이름. 이렇게 하면 테이블을 잠그지 않고도 스키마를 유연하게 발전시킬 수 있습니다. 데이터 유형은 값 자체에서 간단히 해석됩니다: 문자열, 숫자, null, 참, 거짓, 객체 또는 배열입니다. |
||||
| 조회수 | 뷰는 CREATE VIEW 문으로 만들 수 있습니다. 일단 생성되면 테이블(관계 집합)을 사용할 수 있는 모든 곳에서 사용할 수 있는 단순한 관계입니다. 뷰에 대한 업데이트에는 몇 가지 추가 요구 사항이 있습니다(예: 삽입 트리거 대신 복잡한 뷰에 대한 업데이트). | 카우치베이스에는 오라클과 같은 동적 SQL 기반 뷰가 없습니다. 하지만 카우치베이스에는 맵 축소 프레임워크에 기반한 '카우치베이스 뷰'라는 기술이 있습니다. 이는 SQL 보기가 아닌 구체화된 보기와 유사하며 N1QL과 함께 사용할 수 없습니다. | ||||
| 구체화된 뷰(일명 구체화된 쿼리 테이블) | 구체화된 뷰 | 카우치베이스 뷰는 사전 집계, 인덱스 등 사용자가 원하는 모든 것을 만들 수 있는 유연한 맵 축소 프레임워크를 제공합니다. 자세한 내용은 http://bit.ly/2EhIFfF 참조 | ||||
| 시퀀스 | 시퀀스 | 사용 불가 | ||||
| 트리거 | 트리거 | 트리거를 사용할 수 없습니다.
만료(TTL: 기한) 설정을 통해 일정 기간이 지나면 문서가 자동으로 삭제되도록 설정할 수 있습니다. http://bit.ly/2DFe7U2 |
||||
| 제약 조건 | 제약 조건: 기본 키, 고유, 확인, 참조, 널이 아닌 참조, | 카우치베이스는 버킷 내의 문서 키에 대해 고유한 제약 조건을 요구하고 이를 강제합니다. 문서는 다른 문서의 키를 참조할 수 있습니다. 이는 단순히 데이터를 저장하는 것일 뿐이며 조인 작업에 사용될 수 있습니다. 참조 자체는 확인되거나 강제 적용되지 않습니다. | ||||
| 색인 | 색인 | 색인. 자세한 내용은 색인 섹션에서 확인하세요. 현재로서는 자세한 블로그(http://bit.ly/2DI1nAa)를 참조하세요. |
