11월로 돌아갑니다, 라주 수라바르잘라(Couchbase QE 및 성능 부문 선임 이사)와 함께 "개발자를 위한 마인드맵: 개발자를 위한 오라클에서 카우치베이스까지"를 발표했습니다. 슬라이드 데크는 여기에서 확인할 수 있습니다: http://bit.ly/2mPdJfo. 시리즈에 대한 개요 기사는 다음 링크에서 확인할 수 있습니다. https://www.couchbase.com/blog/couchbase-oracle-developers-part-2-architecture/. 이 시리즈는 Raju와 공동으로 작성되었습니다.
이 블로그는 개발자의 관점에서 두 데이터베이스의 상위 수준 아키텍처를 설명하는 '오라클 개발자를 위한 카우치베이스' 시리즈의 두 번째 파트입니다. 이 블로그에서는 오라클에 대한 지식이 있다고 가정하고 비교 및 대조를 위한 경우를 제외하고는 오라클 기능을 설명하지 않습니다. 이 비교 및 대조는 단지 이를 위한 것입니다. 기능이나 성능을 다른 데이터베이스와 비교하여 평가하기 위한 것이 아닙니다.
오라클과 카우치베이스는 모두 특정 엔터프라이즈 애플리케이션 작업을 처리하기 위해 개발되었습니다. 둘 다 확장되어 왔고 확장 중입니다. 두 제품은 기업에서 공존하고 있습니다. 이러한 감성을 바탕으로 오라클 개발자가 Couchbase를 이해하는 데 도움이 되도록 두 제품을 비교하여 설명합니다.
이제 아키텍처에 대해 알아보겠습니다.
| 주제 | Oracle | 카우치베이스 |
| 단일 노드 배포 | Oracle은 단일 모놀리식 단일 인스턴스 데이터베이스입니다(그림 1에 표시된 배포에서). 실제로 원래 단일 시스템에서 실행되도록 개발되었으며 SMP(멀티 소켓, 멀티 코어) 시스템에서 잘 작동합니다. 데이터베이스의 모든 계층(논리적, 물리적 공간 관리, 잠금, 로깅)은 모두 단일 시스템에서 관리됩니다. 코드는 단일 머신을 위해 설계된 리소스 잠금을 통해 단일 스레드(또는 협력 스레드)에서 실행됩니다.
이 구성은 개발 및 프로덕션 배포의 대부분을 차지합니다. 디스크 용량이 부족하면 용량을 추가합니다. CPU 용량이 부족하면 더 많은 소켓과 코어를 갖춘 더 큰 머신으로 워크로드를 마이그레이션합니다. 또는 요즘에는 더 큰 가상 머신이나 컨테이너로 마이그레이션합니다. 서버 통신용 앱은 독점적인 오라클 프로토콜을 사용합니다. 상위 수준의 SDK가 이를 기반으로 작동합니다. |
카우치베이스 서버는 단일 서버에 설치할 수 있으며 일반적으로 개발을 위해 단일 노드(MacOS, Linux 또는 Windows)에 설치됩니다. 모든 데이터베이스 기능은 서비스(데이터 레이어, 인덱스, 쿼리, 직접 또는 쿼리를 통해 데이터에 액세스하는 API 포함)로 추상화되어 있습니다. 이러한 서비스는 REST API를 통해 서비스를 노출하도록 조정됩니다. 애플리케이션은 다음을 사용합니다. 데이터 가져오기, 인덱스 생성, N1QL 쿼리 실행을 위한 Couchbase SDK(모든 인기 언어 사용 가능).
이 구성은 주로 노트북, 가상 머신 또는 컨테이너에서 개발하는 데 사용됩니다. 배포에는 거의 사용되지 않습니다. 실제로 단일 노드에 배포할 때 데이터 복사본이 하나만 있으면 Couchbase에서 경고를 표시합니다! 서버 통신을 위한 API는 REST API와 멤캐시드 바이너리 프로토콜을 통해 이루어집니다. 다른 모든 상위 SDK는 그 아래에서 REST 또는 멤캐시드 프로토콜을 사용합니다. |
| 언어 | SQL, PL/SQL, XQuery, SES(보안 엔터프라이즈 검색) | N1QL(JSON용 SQL), 직접 데이터 액세스, FTS(전체 텍스트 검색). |
| 연결 | 사용자 프로세스와 클라이언트 애플리케이션을 대신하여 실행되는 데이터베이스 프로세스/스레드 간의 영구 연결입니다. | TCP/IP를 통한 HTTP 연결. 멤캐시드 연결데이터 가져오기/수정, 쿼리를 위한 각 요청은 별개의 요청입니다. 연결 요청을 효율적으로 처리하기 위해 TCP와 HTTP 킵얼라이브를 사용합니다. |
| 세션 | 세션은 CONNECT에서 QUIT까지 시작됩니다. 각 애플리케이션 '세션'에는 오라클 서버에 해당하는 세션이 있습니다. 세션 내에서 쿼리 1개 또는 여러 트랜잭션에 걸친 쿼리 백만 개를 실행할 수 있습니다. | 연결과 마찬가지로, 카우치베이스에서는 각 요청이 별개의 요청으로 이루어집니다. 각 요청에는 바인드 매개변수와 컨텍스트 매개변수(예: 시간 초과)가 모두 포함되어야 합니다. 요청이 처리되면 세션 컨텍스트는 서버에서 사라집니다.
그러나 SDK가 컨텍스트와 파라미터를 기억하고 애플리케이션의 개입 없이 후속 요청에서 이를 전달할 수 있으므로 코딩이 쉽습니다. |
| 사용자, 인증 | OS 사용자, 데이터베이스 사용자를 지원합니다. 인증은 OS, 데이터베이스, 타사(예: LDAP, kerberos)를 통해 수행할 수 있습니다. | OS 사용자, 데이터베이스 사용자를 지원합니다. 인증은 OS, 데이터베이스, 타사(예: LDAP, kerberos)를 통해 수행할 수 있습니다. |
| 데이터베이스 | 인스턴스보다 낮은 단위인 데이터베이스는 사용자 및 애플리케이션에 대한 데이터 관리 및 최상위 액세스 제어의 단위입니다.
하나의 Oracle 인스턴스에 여러 개의 데이터베이스를 가질 수 있습니다. |
하나의 카우치베이스 인스턴스는 최대 10개의 버킷을 가질 수 있습니다. 각 버킷에는 고정된 양의 메모리가 할당됩니다(각 노드에서). 이는 데이터 노드에서 데이터를 캐시하는 데 사용됩니다. Oracle의 데이터 버퍼 풀이라고 생각하시면 됩니다.
각 버킷에는 JSON 문서가 저장됩니다. 단일 버킷의 각 JSON 문서에는 고유 키(테이블의 기본 키 라인에 따라)가 있어야 합니다. 각 버킷에는 표나 컬렉션과 같은 여러 유형의 문서가 있을 수 있습니다. 고유성을 허용하고 키만 보고도 문서 유형을 식별할 수 있도록 문서 키 앞에 문서 유형을 접두사로 붙입니다. 예: "cust.x817.022.4u2" { "type": "cust,":"lname":"Smith"} |
| 표 | 표 | 버킷 내 문서 유형. 고객 문서(cust 접두사가 붙은)는 논리적으로 하나의 그룹이 되고 부품 문서도 하나의 그룹이 됩니다. 인덱스와 쿼리의 컨텍스트를 제외하고는 물리적으로 분리되지 않습니다. |
| 칼럼 | 칼럼 | Couchbase의 모든 문서는 http://json.org/ 을 준수하는 JSON 문서여야 합니다. 간단한 1레벨 JSON 문서를 생각해 보세요. 문서 키: "cust:2984" Doc: {"a":1, "b": True, "c": "Hello"} 마인드맵에서 이 문서는 행, 개별 속성, "a", "b", "c"는 열, 문서 키는 기본 키로 생각할 수 있습니다. 이 문서에는 간단한 스칼라 값이 포함되어 있습니다.JSON에는 배열과 객체, 객체의 배열, 배열을 포함하는 객체가 포함될 수 있습니다. 속성 이름은 위에서 아래로 참조됩니다(오라클의 객체를 생각하면 됩니다. 이에 대해서는 '데이터베이스 유형' 섹션에서 자세히 설명합니다). |
| 논리적 및 물리적 스키마 구조. | ||
| SDK | http://bit.ly/20TCGn0 | https://www.couchbase.com/downloads (SDK까지 아래로 스크롤) |
| 멀티 노드 아키텍처 (동종 배포). |
||
| 다차원 배포 | 사용할 수 없습니다. Oracle RAC의 각 노드에는 트랜잭션 및 관리 기능을 포함한 전체 Oracle SQL 기능이 있습니다. |
클러스터의 각 노드에는 하나 이상의 서비스 조합이 있을 수 있습니다: 데이터, 쿼리, 색인, 분석 검색. 클러스터 관리자(코디네이터)는 서비스의 배포 및 가용성을 알고 있으며 서로에 대한 정보를 서비스에게 알립니다. SDK는 데이터 배포, 쿼리 및 FTS 노드도 인식합니다. SDK는 쿼리 워크로드의 경우 쿼리 노드, 데이터/KV 워크로드의 경우 데이터 노드, 검색 워크로드의 경우 FTS 노드 간에 워크로드의 균형을 맞추려고 노력합니다. |
| 시스템 아키텍처 | 단일 노드 배포는 SMP에 적합합니다. 멀티노드 배포는 동일한 디스크/스토리지 공유. 따라서 공유 디스크 시스템입니다. 컴퓨팅을 더 추가하고 동일한 디스크를 공유하여 어느 지점까지 확장할 수 있습니다. 결국, 공유 디스크와 IO 처리량이 병목 현상이 됩니다. 개발자는 인스턴스 유형(단일 노드 또는 다중 노드 RAC)에 대해 (대부분) 잘 모릅니다. 지원되는 SQL은 동일하며 트랜잭션은 멀티노드 환경에서 원활하게 작동합니다.오라클은 이를 위해 정교한 분산 잠금 관리자, 버퍼 풀 동기화 등을 개발했습니다. 하지만 성능에 미치는 부정적인 영향을 줄이기 위해 고가의 인피니밴드가 필요합니다. 그럼에도 불구하고 잠금 등의 충돌을 최소화하기 위해 여러 RAC 노드 간에 워크로드를 분할하는 경우가 종종 있습니다. |
단일 노드를 확장하여 단일 시스템에서 실행되는 여러 서비스의 공동 운영으로 구현할 수 있습니다. 단일 시스템에서도 메시지 전달을 통해 조정이 이루어집니다.
느슨하게 결합된 이 서비스 세트는 원활하게 확장할 수 있습니다. 각 노드에 모든 서비스를 보유하고 동일한 서비스를 사용하는 새 노드를 추가하기만 하면 됩니다. 모든 서비스는 멀티노드 토폴로지를 이해합니다. 이를 스케일아웃이라고 합니다. 애플리케이션이 모든 서비스를 균일하게 사용하지는 않습니다. 병목 현상은 데이터, 쿼리의 인덱서에서 발생할 수 있습니다. 따라서 카우치베이스에서는 병목 현상이 발생하는 서비스를 실행하기 위해 단순히 노드의 크기를 조정하고 새 노드를 추가합니다. 이렇게 하면 동종 배포에 비해 최적의 리소스 사용률과 더 나은 성능을 제공합니다. 또한 비용도 절감할 수 있습니다. 다차원 확장은 다른 구성과 관리 용이성이 동일하게 유지되므로 배포가 쉽습니다. |
| 쿼리 | 오라클은 본격적인 SQL을 지원합니다. SQL 확장 기능에는 JSON 및 텍스트 검색 지원이 포함됩니다. Oracle은 XML, XQuery, SQL/XML 등을 지원하는 XML DB도 보유하고 있습니다. |
카우치베이스는 바이너리 및 JSON을 저장할 수 있습니다. 개발자 API는 문서, 하위 문서를 직접 GET 및 SET할 수 있습니다. N1QL(JSON용 SQL)은 선언적 언어를 제공합니다. 쿼리를 효율적으로 실행하기 위한 인덱스와 본격적인 쿼리 엔진이 함께 제공됩니다. 자세한 내용은 query.couchbase.com에서 확인하세요. Couchbase FTS(전체 텍스트 검색)를 사용하면 텍스트 색인을 생성하고 검색할 수 있습니다. http://bit.ly/2vbcbOF |
| 고가용성 | 오라클의 MAA(최대 가용성 아키텍처)는 다음과 같이 권장합니다: "클러스터 구성 화면의 디스크 그룹 세부 정보 섹션에서 MAA는 최상의 보호와 최고의 운영 간소화를 위해 모든(DATA 및 RECO) 디스크 그룹에 대해 Oracle ASM(자동 스토리지 관리) HIGH 중복성을 선택할 것을 권장합니다."
오라클은 핫 스탠바이 서버, 스키마 기반 복제, 변경 캡처 등을 생성할 수 있는 기능을 제공합니다. |
단일 클러스터 내에서 원하는 사본 수를 지정하기만 하면 데이터와 인덱스의 사본을 여러 개 가질 수 있습니다. 데이터 사본은 최대 3개까지, 인덱스 사본은 원하는 수만큼 가질 수 있습니다.
여러 클러스터에 걸쳐 내장된 XDCR(데이터 센터 간 복제)을 사용하여 데이터를 복제할 수 있습니다. |
| 거래 | ACID
다중 진술 |
단일 문서 원자성 데이터 서비스 일관성, 인덱스 - 최종 일관성 낙관적 잠금(CAS) 내구성에 대한 추가 확인 |
| 드라이버 | JDBC, ODBC, .NET, LINQ 등 | Couchbase SDK(Java, .NET, LINQ, PHP, Python, Go), Simba JDBC/ODBC |
| 데이터 모델 | 정규화된 데이터 모델과 비정규화된 데이터 모델을 모두 지원합니다. | 비정규화된(집계된) JSON 모델. 여러 유형의 문서(예: 주문과 고객) 간의 관계를 표현하고 처리할 수 있습니다. 하위 문서(주문) 또는 상위 문서(고객)는 관련 문서의 기본 키를 저장한 다음 조인할 수 있습니다. 이 관계는 암시적이며, Couchbase에서 제약 조건(예: 외래 키 제약 조건)으로 코드화되지 않습니다. 이것이 바로 Couchbase가 더 유연한 이유입니다. |
