Oracle AI Database 소개

이 장에서는 Oracle AI Database에 대한 개요를 제공합니다.

이 장은 다음 항목으로 구성됩니다.

정보 시스템 정보

모든 조직은 요구 사항을 충족하기 위해 저장하고 관리해야 하는 정보를 가지고 있습니다. 예를 들어, 기업은 사원에 대한 HR 레코드를 수집하고 유지 관리해야 합니다. 이 정보는 필요한 사람들에게 제공되어야 합니다.

정보 시스템은 정보를 저장하고 처리하기 위한 공식 시스템입니다. 데이터베이스는 하나의 단위로 취급되는 체계적인 정보 모음입니다. 데이터베이스의 목적은 데이터베이스 응용 프로그램에서 사용할 수 있도록 관련 정보를 수집, 저장 및 검색하는 것입니다.

데이터베이스 시스템이 처음 발명되었을 때 특정 작업 로드를 위해 설계되었습니다. 수년에 걸쳐 단일 용도 데이터베이스가 더 이상 모든 요구 사항을 충족하지 않는다는 것이 분명해졌습니다. 관계형 워크로드 외에도 개발자는 데이터를 XML, 공간, 그래프, JSON 및 가장 최근에는 AI 시대의 벡터 데이터와 같은 다른 형식으로 저장해야 했습니다.

Oracle AI Database는 관계형 데이터베이스 엔진에서 컨버지드 엔진으로 개발하여 개발자가 거의 모든 유형의 데이터를 애플리케이션에 필요한 형식으로 저장하고 엔터프라이즈급 아키텍처에 완전히 통합할 수 있도록 합니다.

DBMS(Database Management System)

데이터베이스 관리 시스템(DBMS)은 데이터의 저장, 구성 및 검색을 제어하는 소프트웨어입니다.

일반적으로 DBMS에는 다음 요소가 포함됩니다.

데이터베이스 애플리케이션은 데이터 액세스 및 조작을 위해 데이터베이스와 상호 작용하는 소프트웨어 프로그램입니다. Oracle AI Database는 관계형 모델을 지원하는 최초의 데이터베이스 엔진 중 하나입니다. 처음부터 거의 모든 데이터 유형과 다양한 워크로드를 지원하는 컨버지드 데이터베이스 엔진으로 발전했습니다.

관계형 모델

그의 1970 년 논문 "대형 공유 데이터 은행을위한 데이터의 관계형 모델"에서 E. F. Codd는 수학적 세트 이론을 기반으로 관계형 모델을 정의했습니다. 오늘날 가장 널리 인정받는 데이터베이스 모델은 관계형 모델입니다.

관계형 데이터베이스는 관계형 모델을 준수하는 데이터베이스입니다. 관계형 모델에는 다음과 같은 주요 측면이 있습니다.

관계형 데이터베이스는 데이터를 단순 관계 집합에 저장합니다. 관계는 튜플 세트입니다. 튜플은 정렬되지 않은 속성 값 세트입니다.

테이블은 행(튜플) 및 열(속성) 형식의 관계에 대한 2차원 표현입니다. 테이블의 각 행에는 동일한 열 집합이 있습니다. 관계형 데이터베이스는 데이터를 관계식(테이블)에 저장하는 데이터베이스입니다. 예를 들어, 관계형 데이터베이스는 회사 사원에 대한 정보를 사원 테이블, 부서 테이블 및 급여 테이블에 저장할 수 있습니다.

관련 항목

RDBMS(Relational Database Management System)

관계형 모델은 관계형 데이터베이스 관리 시스템(RDBMS)의 기초입니다. RDBMS는 응용 프로그램이 데이터를 조작할 수 있도록 데이터를 데이터베이스로 이동하고 저장한 다음 검색합니다.

RDBMS는 다음과 같은 유형의 작업을 구분합니다.

Oracle AI Database는 RDBMS의 핵심입니다. 유저 정의 유형, 상속 및 다형성과 같은 객체 지향 기능을 구현하는 RDBMS를 ORDBMS(객체 관계형 데이터베이스 관리 시스템)라고 합니다. Oracle AI Database는 관계형 모델을 객체 관계형 모델로 확장하여 복잡한 비즈니스 모델을 관계형 데이터베이스에 저장할 수 있도록 합니다. 시간이 지남에 따라 Oracle의 핵심 데이터 엔진은 이제 컨버지드 데이터베이스라고 하는 훨씬 더 강력한 모델로 발전했습니다.

통합 데이터베이스 구조

Oracle AI Database는 단일 데이터베이스 엔진에서 여러 데이터 모델 및 워크로드를 지원하는 컨버지드 데이터베이스입니다. 관계형 데이터 외에도 JSON 문서, 그래프 데이터, 공간 데이터, 텍스트, 벡터 및 기타 특수 데이터 유형을 관리할 수 있습니다.

이러한 기능은 트랜잭션, 보안, 백업 및 복구, 고가용성, 감사 및 쿼리 최적화를 포함한 공통 데이터베이스 서비스를 공유합니다. 따라서 애플리케이션은 각각 별도의 데이터베이스 없이도 서로 다른 데이터 모델을 사용할 수 있습니다.

예를 들어, 애플리케이션은 고객 및 트랜잭션 데이터를 관계형 테이블에 저장하고, JSON 문서의 유연한 속성, 공간 데이터로서의 지리적 정보, 의미 검색용 벡터 임베딩 등을 저장할 수 있습니다. SQL은 이러한 데이터 형식을 단일 작업으로 query하고 결합하는 데 사용할 수 있습니다. 문서 스타일 API는 이 NoSQL 스타일을 선호하는 개발자가 사용할 수 있습니다.

컨버지드 데이터베이스는 다음과 같은 이점을 제공합니다.

Convergence에서 모든 작업 부하가 모든 기능을 사용하거나 하나의 물리적 데이터베이스에 상주할 필요는 없습니다. 응용 프로그램은 필요한 기능만 사용할 수 있습니다. Oracle의 유연한 아키텍처를 통해 개발자는 플러그 가능한 여러 데이터베이스에 애플리케이션을 분산시킬 수 있습니다.

Oracle Database의 핵심은 관계형입니다. 컨버지드 아키텍처는 이러한 기반을 확장하여 애플리케이션이 여러 데이터 모델을 사용할 수 있도록 하는 동시에 거의 모든 워크로드에 대해 공통된 데이터베이스 서비스 세트를 사용합니다.

스키마 객체

RDBMS의 한 가지 특징은 물리적 데이터 저장 영역과 논리적 데이터 구조의 독립성입니다.

Oracle AI Database에서 데이터베이스 스키마는 논리적 데이터 구조 또는 스키마 객체의 모음입니다. 데이터베이스 사용자는 사용자 이름과 동일한 이름을 가진 데이터베이스 스키마를 소유합니다.

스키마 객체는 데이터베이스의 데이터를 직접 참조하는 유저 생성 구조입니다. 데이터베이스는 많은 유형의 스키마 객체를 지원하며 그 중 가장 중요한 것은 테이블 및 인덱스입니다. 데이터 액세스를 위해 문서 스타일 API를 선호하는 사용자는 (JSON) 컬렉션 또는 JSON 관계형 이중성 뷰를 생성할 수 있습니다.

스키마 객체는 데이터베이스 객체의 한 유형입니다. 프로파일 및 롤과 같은 일부 데이터베이스 객체는 스키마에 상주하지 않습니다.

관련 항목

테이블

표에서는 직원과 같은 엔티티를 설명합니다.

테이블 이름(예: employees) 및 열 집합으로 테이블을 정의합니다. 일반적으로 테이블을 만들 때 각 열에 이름, 데이터 유형 및 너비를 지정합니다.

테이블은 행 집합입니다. 열은 테이블에서 설명하는 엔티티의 속성을 식별하는 반면, 행은 엔티티의 인스턴스를 식별합니다. 예를 들어, employees 엔티티의 속성은 사원 ID 및 성에 대한 열에 해당합니다. 행은 특정 사원을 식별합니다.

선택적으로 열에 대해 무결성 제약 조건이라는 규칙을 지정할 수 있습니다. 한 가지 예는 NOT NULL 무결성 제약 조건입니다. 이 제약 조건은 열이 모든 행에 값을 포함하도록 합니다. 여러 테이블에 걸친 제약 조건은 SQL 검증으로 정의할 수 있습니다. Oracle AI Database 26ai 이전에는 데이터베이스 트리거를 사용하여 비즈니스 로직을 트랜잭션의 일부로 적용할 수 있었습니다.

관련 항목

인덱스

인덱스는 테이블의 하나 이상의 열에 생성할 수 있는 선택적 데이터 구조입니다. 인덱스를 사용하면 데이터 검색 성능을 향상시킬 수 있습니다.

요청을 처리할 때 데이터베이스는 사용 가능한 인덱스를 사용하여 요청된 행을 효율적으로 찾을 수 있습니다. 인덱스는 응용 프로그램에서 종종 특정 행 또는 행 범위를 query할 때 유용합니다.

인덱스는 논리적으로나 물리적으로 데이터에 독립적입니다. 따라서 테이블이나 다른 인덱스에 영향을 주지 않고 인덱스를 삭제하고 생성할 수 있습니다. 인덱스를 삭제한 후에도 모든 응용 프로그램이 계속 작동합니다.

관련 항목

데이터 액세스

DBMS의 일반적인 요구 사항은 데이터 액세스 언어에 대해 허용되는 업계 표준을 준수하는 것입니다. 주: JavaScript를 사용하려면 Linux x86-64 또는 Linux aarch64에서 실행되는 Oracle 26ai가 필요합니다.

SQL(구조적 질의 언어)

SQL은 Oracle AI Database와 같은 RDBMS에 인터페이스를 제공하는 세트 기반 선언 언어입니다.

C와 같은 절차 언어는 수행해야 하는 방법을 설명합니다. SQL은 비절차적이며 수행해야 하는 작업에 대해 설명합니다.

SQL은 관계형 데이터베이스를 위한 ANSI 표준 언어입니다. Oracle 데이터베이스의 데이터에 대한 모든 작업은 SQL 문을 사용하여 수행됩니다. 예를 들어, SQL을 사용하여 테이블을 생성하고 테이블의 데이터를 query 및 수정합니다.

SQL 문은 매우 간단하지만 강력한 컴퓨터 프로그램 또는 명령으로 생각할 수 있습니다. 유저는 원하는 결과(예: 사원 이름)를 파생하는 방법이 아니라 지정합니다. SQL 문은 다음과 같은 SQL 텍스트 문자열입니다.

SELECT first_name, last_name FROM employees;

SQL 문을 사용하면 다음 작업을 수행할 수 있습니다:

SQL은 선행 작업을 하나의 일관된 언어로 통합합니다. Oracle SQL은 ANSI 표준의 구현입니다. Oracle SQL은 표준 SQL 이상으로 확장되는 다양한 기능을 지원합니다.

관련 항목

PL/SQL, Java 및 JavaScript

PL/SQL은 Oracle SQL의 절차적 확장입니다. Java 및 JavaScript는 비즈니스 로직을 데이터베이스에 저장하는 데 사용할 수 있는 추가 옵션입니다.

PL/SQL은 Oracle AI Database와 통합되어 모든 Oracle AI Database SQL 문, 함수 및 데이터 유형을 사용할 수 있습니다. PL/SQL을 사용하여 SQL 프로그램의 흐름을 제어하고, 변수를 사용하고, 오류 처리 프로시저를 작성할 수 있습니다.

PL/SQL의 주요 이점은 응용 프로그램 논리를 데이터베이스 자체에 저장하는 기능입니다. PL/SQL 프로시저 또는 함수는 SQL 문 및 기타 PL/SQL 생성자 집합으로 구성되며 함께 그룹화되어 데이터베이스에 저장되고 하나의 단위로 실행하여 특정 문제를 해결하거나 일련의 관련 작업을 수행하는 스키마 객체입니다. 서버측 프로그래밍의 주요 이점은 내장된 기능을 어디서나 배포할 수 있다는 것입니다.

또한 Oracle AI Database는 Java 및 JavaScript로 작성된 프로그램 유닛을 저장할 수 있습니다. Java 내장 프로시저는 SQL에 게시되고 일반적으로 사용할 수 있도록 데이터베이스에 저장되는 Java 메소드입니다. Java 및 JavaScript에서 기존 PL/SQL 프로그램을 호출할 수 있고, PL/SQL에서 Java 및 JavaScript 프로그램을 호출할 수 있습니다.

MLE(Multilingual Engine)는 JavaScript에서 비즈니스 로직을 작성하고 데이터베이스의 코드를 MLE 모듈로 저장하는 기능을 제공합니다. MLE 모듈로 익스포트된 함수는 호출 사양을 통해 SQL 및 PL/SQL에 노출될 수 있습니다. 이러한 호출 사양은 PL/SQL 단위(함수, 프로시저 및 패키지)이며 PL/SQL이 호출되는 모든 위치에서 호출될 수 있습니다.

관련 항목

NoSQL 문서 액세스를 위한 API

Simple Oracle Document Access(SODA)는 Oracle AI Database에서 문서 모음, 특히 JSON 문서를 관리하기 위한 NoSQL 스타일의 API 세트입니다. 응용 프로그램은 SQL 또는 기본 데이터베이스 스키마에 대한 지식 없이도 모음을 생성하고 문서를 삽입, 검색, 갱신, 삭제 및 query할 수 있습니다.

SODA는 컬렉션, 문서 및 예제별 쿼리 필터를 기반으로 문서 중심 프로그래밍 모델을 제공합니다. 이는 관계형 데이터를 query 및 수정하기 위한 선언적 집합 지향 인터페이스를 제공하고 여러 데이터 유형에 걸쳐 조인, 집계 및 작업을 표현할 수 있는 SQL과는 반대입니다.

SODA는 애플리케이션이 주로 JSON 문서에서 작동하고 간단한 문서 API가 필요한 경우 유용하며, NoSQL API를 사용하려는 개발자를 위한 대안이 될 수 있습니다.

타사 단일 용도 데이터 저장소에서 Oracle AI 데이터베이스로 문서 워크로드를 포팅하는 개발자는 SODA와 유사하지만 마이그레이션을 더 쉽게 만드는 것을 목표로 하는 Oracle AI Database용 Mongo DB API를 사용할 수 있습니다. 가장 간단한 경우, 애플리케이션의 연결 문자열을 단일 목적의 데이터 저장소에서 Oracle AI Database로 변경하는 것만으로도 충분합니다.

트랜잭션 관리

Oracle AI Database는 다중 사용자 데이터베이스로 설계되었습니다. 데이터베이스는 여러 유저가 서로의 데이터를 손상시키지 않고 동시에 작업할 수 있도록 해야 합니다.

트랜잭션

트랜잭션은 하나 이상의 SQL 문을 포함하는 논리적 최소 작업 단위입니다.

RDBMS는 SQL 문이 모두 커밋되도록(즉, 데이터베이스에 적용됨) SQL 문을 그룹화하거나 모두 롤백하여 실행 취소되도록 해야 합니다.

트랜잭션의 필요성에 대한 그림은 저축 계정에서 당좌 예금 계정으로의 자금 이체입니다. 전송은 다음과 같은 개별 작업으로 구성됩니다.

  1. 저축 계좌를 줄이십시오.

  2. 당좌 예금 계좌를 늘리십시오.

  3. 트랜잭션 분개에 트랜잭션을 기록합니다.

Oracle AI Database는 세 가지 작업이 모두 하나의 단위로 성공하거나 실패하도록 보장합니다. 예를 들어, 하드웨어 Failure로 인해 트랜잭션의 명령문이 실행되지 않는 경우 다른 명령문은 롤백되어야 합니다.

트랜잭션은 파일 시스템과는 별도로 Oracle AI Database를 설정하는 한 가지 기능입니다. 여러 파일을 업데이트하는 기본 작업을 수행하고 시스템의 중간에 오류가 발생할 경우 파일이 일관되지 않습니다. 반대로 트랜잭션은 Oracle 데이터베이스를 일관성 있는 상태 간에 이동합니다. 트랜잭션의 기본 원리는 "all or nothing"입니다. 즉, 원자 작업이 전체적으로 성공하거나 실패합니다.

관련 항목

데이터 동시성

다중 사용자 RDBMS의 요구 사항은 여러 사용자가 동일한 데이터에 동시에 액세스하는 데이터 동시성의 제어입니다.

동시성 제어를 사용하지 않으면 사용자가 데이터를 잘못 변경하여 데이터 무결성을 저해할 수 있습니다. 예를 들어, 한 유저가 한 행을 갱신하고 다른 유저가 동시에 갱신할 수 있습니다.

여러 유저가 동일한 데이터에 액세스하는 경우 동시성을 관리하는 한 가지 방법은 유저를 대기시키는 것입니다. 그러나 DBMS의 목표는 대기 시간을 줄여서 존재하지 않거나 무시할 수 있도록 하는 것입니다. 데이터를 수정하는 모든 SQL 문은 가능한 한 간섭이 적게 발생해야 합니다. 데이터를 잘못 업데이트하거나 기본 데이터 구조를 변경하는 상호 작용인 파괴적 상호 작용은 피해야 합니다.

Oracle AI Database는 잠금을 사용하여 데이터에 대한 동시 액세스를 제어합니다. 잠금은 공유 리소스에 액세스하는 트랜잭션 간의 파괴적인 상호 작용을 방지하는 방식입니다. 잠금을 사용하면 데이터 무결성을 보장하면서 동시에 데이터에 액세스할 수 있습니다.

관련 항목

데이터 일관성

Oracle AI Database에서 각 사용자는 사용자 고유의 트랜잭션 및 다른 사용자의 커밋된 트랜잭션에 의해 표시된 변경 사항을 포함하여 일관된 데이터 뷰를 확인해야 합니다.

예를 들어, 데이터베이스는 한 트랜잭션이 다른 동시 트랜잭션에 의해 수행된 커밋되지 않은 변경 사항을 볼 때 발생하는 더티 읽기 문제를 방지해야 합니다.

Oracle AI Database는 항상 명령문 레벨의 읽기 일관성을 적용합니다. 이를 통해 단일 쿼리가 반환하는 데이터가 단일 시점에 커밋되고 일관성을 유지할 수 있습니다. 트랜잭션 격리 수준에 따라 이 시점은 명령문이 열린 시간 또는 트랜잭션이 시작된 시간입니다. Oracle Flashback Query 기능을 사용하면 이 시점을 명시적으로 지정할 수 있습니다.

또한 데이터베이스는 트랜잭션 레벨 읽기 일관성이라고 하는 트랜잭션의 모든 질의에 읽기 일관성을 제공할 수 있습니다. 이 경우 트랜잭션의 각 명령문은 동일한 Point-in-time(트랜잭션이 시작된 시간)의 데이터를 봅니다.

관련 항목

Oracle AI Database 구조

데이터베이스 서버는 정보 관리의 핵심입니다.

일반적으로 서버는 사용자가 동일한 데이터에 동시에 액세스할 수 있도록 다중 유저 환경에서 대량의 데이터를 안정적으로 관리합니다. 또한 데이터베이스 서버는 무단 액세스를 방지하고 Failure Recovery에 대한 효율적인 솔루션을 제공합니다.

데이터베이스 및 인스턴스

Oracle 데이터베이스 서버는 데이터베이스와 데이터베이스 인스턴스(일반적으로 단순히 인스턴스라고 함)로 구성됩니다.

인스턴스와 데이터베이스가 너무 밀접하게 연결되어 있기 때문에 Oracle 데이터베이스라는 용어는 인스턴스와 데이터베이스를 모두 지칭하기도 합니다. 가장 엄격한 의미에서 용어에는 다음과 같은 의미가 있습니다.

다중 테넌트 구조

멀티테넌트 아키텍처는 Oracle AI Database가 CDB가 될 수 있게 해줍니다.

모든 Oracle AI Database는 다른 데이터베이스를 포함하거나 포함할 수 있어야 합니다. 예를 들어, CDB는 PDB를 포함하고 애플리케이션 컨테이너는 애플리케이션 PDB를 포함합니다. PDB는 CDB 또는 애플리케이션 컨테이너에 포함되어 있으며, 애플리케이션 컨테이너는 CDB에 포함되어 있습니다.

Oracle Database 21c부터는 다중 테넌트 컨테이너 데이터베이스가 유일하게 지원되는 아키텍처입니다. 이전 릴리스에서는 Oracle이 비CDB(비컨테이너 데이터베이스)를 지원했습니다.

컨테이너 데이터베이스

CDB에는 사용자 생성 PDB와 애플리케이션 컨테이너가 하나 이상 포함되어 있습니다.

물리적 레벨에서 CDB는 콘트롤 파일, 온라인 리두 로그 파일 및 데이터 파일의 파일 집합입니다. 데이터베이스 Instance는 CDB를 구성하는 파일을 관리합니다.

다음 그림은 CDB 및 연관된 데이터베이스 인스턴스를 보여줍니다.

그림 1: 데이터베이스 인스턴스 및 CDB

그림 cncpt233.png에 대한 설명

플러그인할 수 있는 데이터베이스

PDB는 응용 프로그램에 별도의 데이터베이스로 나타나는 스키마, 스키마 객체 및 비스키마 객체의 이식 가능한 모음입니다.

물리적 레벨에서 각 PDB에는 PDB에 대한 데이터를 저장하는 고유한 데이터 파일 집합이 있습니다. CDB에는 포함된 PDB에 대한 모든 데이터 파일과 CDB 자체에 대한 메타 데이터를 저장하는 시스템 데이터 파일 세트가 포함됩니다.

PDB를 이동하거나 아카이브하려면 PDB를 언플러그합니다. 언플러그된 PDB는 PDB 데이터 파일과 메타 데이터 파일로 구성됩니다. 언플러그된 PDB는 CDB에 플러그인될 때까지 사용할 수 없습니다.

다음 그림은 이름이 MYCDB인 CDB를 보여줍니다.

그림 2: CDB의 PDB

그림 cncpt352.png에 대한 설명

물리적으로 MYCDB는 인스턴스와 연관된 데이터 파일 집합의 의미에서 Oracle AI Database입니다. MYCDB에는 하나의 데이터베이스 인스턴스가 있지만, Oracle Real Application Clusters에서는 여러 인스턴스가 가능하고 데이터베이스 파일 집합이 하나 있습니다.

MYCDB에는 hrpdb 및 salespdb의 두 PDB가 포함됩니다. 그림 1-2에 표시된 것처럼 이러한 PDB는 해당 응용 프로그램에 별도의 독립 데이터베이스로 나타납니다. 응용 프로그램은 CDB 또는 PDB에 연결하는지 여부를 알 수 없습니다.

CDB 자체 또는 CDB 내부의 모든 PDB를 관리하려면 CDB 루트에 연결할 수 있습니다. 루트는 모든 PDB 및 응용 프로그램 컨테이너가 속한 스키마, 스키마 객체 및 비스키마 객체의 모음입니다.

애플리케이션 컨테이너

애플리케이션 컨테이너는 하나 이상의 애플리케이션에 대한 데이터 및 메타데이터를 저장하는 CDB 내에서 사용자가 생성한 선택적 컨테이너입니다.

이 컨텍스트에서 응용 프로그램(마스터 응용 프로그램 정의라고도 함)은 응용 프로그램 루트에 저장된 이름이 지정된 버전의 공통 데이터 및 메타 데이터 세트입니다. 예를 들어, 응용 프로그램에는 일련의 PDB에 공통되는 테이블, 뷰, 유저 계정 및 PL/SQL 패키지 정의가 포함될 수 있습니다.

어떤 면에서 응용 프로그램 컨테이너는 CDB 내에서 응용 프로그램별 CDB로 작동합니다. CDB 자체와 같은 애플리케이션 컨테이너는 여러 애플리케이션 PDB를 포함할 수 있으며, 이러한 PDB가 메타데이터와 데이터를 공유할 수 있도록 합니다. 물리적 레벨에서 응용 프로그램 컨테이너는 PDB와 마찬가지로 고유한 데이터 파일 집합을 가집니다.

예를 들어, SaaS 배치는 각각 애플리케이션 메타데이터와 데이터를 공유하는 개별 고객에 대해 여러 애플리케이션 PDB를 사용할 수 있습니다. 예를 들어, 다음 그림에서 sales_app는 응용 프로그램 루트의 응용 프로그램 모델입니다. 이름이 cust1_pdb인 애플리케이션 PDB에는 고객 1에 대한 판매 데이터만 포함되고, 이름이 cust2_pdb인 애플리케이션 PDB에는 고객 2에 대한 판매 데이터만 포함됩니다. 개별 고객 PDB에 대해 플러그, 언플러그, 복제 및 기타 PDB 레벨 작업을 사용할 수 있습니다.

그림 3: SaaS 사용 사례

그림 cncpt389.png에 대한 설명

Global 분산 데이터베이스 구조

Oracle Globally Distributed Database(이전의 Oracle Sharding)는 여러 PDB에서 데이터의 수평 분할을 기반으로 하는 데이터베이스 확장 기술입니다. 애플리케이션은 PDB 풀을 단일 논리적 데이터베이스로 인식합니다. 각 분할 영역을 샤드라고 합니다.

애플리케이션용 샤딩의 주요 이점으로는 선형 확장성, 장애 억제, 지리적 데이터 배포 등이 있습니다. Globally Distributed Database는 Oracle Cloud에 배포하기에 적합합니다. 샤딩을 구현하는 NoSQL 데이터 저장소와 달리 Globally Distributed Database는 엔터프라이즈 RDBMS의 기능을 희생하지 않고 샤딩의 이점을 제공합니다.

샤딩 구조에서 각 CDB는 CPU, 메모리, 플래시 또는 디스크와 같은 고유한 로컬 리소스가 있는 전용 서버에서 호스팅됩니다. PDB를 샤드로 지정할 수 있습니다. 서로 다른 CDB의 PDB 샤드는 샤딩된 데이터베이스라고 하는 단일 논리적 데이터베이스를 구성합니다. 동일한 CDB에 있는 두 개의 샤드는 동일한 샤딩된 데이터베이스의 멤버일 수 없습니다. 그러나 동일한 CDB 내에서 하나의 PDB는 하나의 샤딩된 데이터베이스에 있을 수 있고, 다른 PDB는 별도의 샤딩된 데이터베이스에 있을 수 있습니다.

수평 분할에는 각 샤드가 동일한 열을 가진 테이블을 포함하지만 행의 하위 집합이 다르도록 데이터베이스 테이블을 샤드 간에 분할하는 작업이 포함됩니다. 이러한 방식으로 분할된 테이블을 샤딩된 테이블이라고도 합니다. 다음 그림은 세 개의 샤드에서 수평으로 분할된 샤딩된 테이블을 보여 주며, 각 샤드는 별도의 CDB에 있는 PDB입니다.

그림 4: 샤드 간 테이블 수평 분할

그림 admin_3v_134a.png에 대한 설명

사용 사례는 고객 계정 데이터를 여러 CDB에 분산하는 것입니다. 예를 들어, ID가 28459361인 고객은 자신의 레코드를 조회할 수 있습니다. 다음 그림은 가능한 아키텍처를 보여줍니다. 고객 요청은 샤딩 디렉터(네트워크 리스너)가 요청을 모든 고객 행을 포함하는 적절한 PDB 샤드로 전달하는 연결 풀을 통해 라우팅됩니다.

그림 5: Oracle Globally Distributed Database 아키텍처

그림 admin_3v_143d.png에 대한 설명

관련 항목

데이터베이스 저장 영역 구조

데이터베이스는 물리적 관점과 논리적 관점 모두에서 고려할 수 있습니다.

물리적 데이터는 운영 체제 레벨에서 볼 수 있습니다. 예를 들어, Linux ls 및 ps와 같은 운영 체제 유틸리티는 데이터베이스 파일 및 프로세스를 나열할 수 있습니다. 테이블과 같은 논리적 데이터는 데이터베이스에 대해서만 의미가 있습니다. SQL 문은 Oracle 데이터베이스의 테이블을 나열할 수 있지만 운영 체제 유틸리티는 나열할 수 없습니다.

데이터베이스에는 물리적 구조와 논리적 구조가 있습니다. 물리적 구조 및 논리적 구조는 서로 별개의 구조이기 때문에 논리 저장 영역 구조에 대한 액세스에 영향을 주지 않고 데이터의 물리적 저장을 관리할 수 없습니다. 예를 들어, 물리적 데이터베이스 파일의 이름을 바꾸어도 이 파일에 데이터가 저장된 테이블의 이름은 바뀌지 않습니다.

물리적 저장 영역 구조

물리적 데이터베이스 구조는 데이터를 저장하는 파일입니다.

CREATE DATABASE 명령을 실행할 때 CDB를 만듭니다. 다음 파일이 생성됩니다.

CDB 내에서 CREATE PLUGGABLE DATABASE 명령을 실행하는 경우 PDB를 생성합니다. PDB에는 CDB 내의 전용 데이터 파일 집합이 포함되어 있습니다. PDB에는 별도의 전용 콘트롤 파일과 온라인 리두 로그가 없습니다. 이러한 파일은 PDB에서 공유됩니다.

다른 많은 파일은 CDB의 작동에 중요합니다. 여기에는 매개변수 파일 및 네트워킹 파일이 포함됩니다. 백업 파일과 아카이브된 리두 로그 파일은 백업과 recovery에 중요한 오프라인 파일입니다.

관련 항목

참조: "물리적 저장 영역 구조"

논리적 저장 영역 구조

논리적 저장 영역 구조를 통해 Oracle AI Database는 디스크 공간 사용을 세부적으로 제어할 수 있습니다.

이 항목에서는 논리적 저장 영역 구조에 대해 설명합니다.

관련 항목

데이터베이스 Instance 구조

Oracle 데이터베이스는 메모리 구조 및 프로세스를 사용하여 CDB를 관리하고 액세스합니다. 모든 메모리 구조는 RDBMS를 구성하는 컴퓨터의 기본 메모리에 존재합니다.

애플리케이션이 CDB 또는 PDB에 접속할 때 데이터베이스 인스턴스에 접속합니다. Instance는 SGA 외에도 다른 메모리 영역을 할당하고 백그라운드 프로세스 외에도 다른 프로세스를 시작하여 응용 프로그램에 서비스를 제공합니다.

Oracle AI Database 프로세스

프로세스는 운영 체제에서 일련의 단계를 실행할 수 있는 메커니즘입니다. 일부 운영 체제에서는 작업, 작업 또는 스레드라는 용어를 사용합니다.

이 항목의 목적에 따라 스레드는 프로세스와 동일합니다. Oracle 데이터베이스 Instance에는 다음과 같은 유형의 프로세스가 있습니다.

Oracle 프로세스는 서버 프로세스와 백그라운드 프로세스를 포함합니다. 대부분의 환경에서 Oracle 프로세스 및 클라이언트 프로세스는 별도의 컴퓨터에서 실행됩니다.

관련 항목

인스턴스 메모리 구조

Oracle AI Database는 프로그램 코드에 대한 메모리 구조, 사용자 간에 공유되는 데이터, 연결된 각 사용자에 대한 전용 데이터 영역을 생성 및 사용합니다.

다음 메모리 구조는 데이터베이스 Instance와 연관되어 있습니다.

관련 항목

애플리케이션 및 네트워킹 구조

주어진 컴퓨터 시스템 또는 네트워크를 최대한 활용하기 위해 Oracle AI Database를 사용하면 데이터베이스 서버와 클라이언트 프로그램 간에 처리를 분할할 수 있습니다. RDBMS를 실행하는 컴퓨터는 데이터베이스 서버의 책임을 처리하고 응용 프로그램을 실행하는 컴퓨터는 데이터의 해석과 표시를 처리합니다.

애플리케이션 구조

응용 프로그램 구조는 데이터베이스 응용 프로그램이 Oracle 데이터베이스에 연결하는 컴퓨팅 환경입니다. 가장 일반적인 두 가지 데이터베이스 구조는 클라이언트/서버 및 다중 계층입니다.

클라이언트/서버 아키텍처

클라이언트/서버 구조에서 클라이언트 응용 프로그램은 데이터베이스 서버에서 수행할 작업에 대한 요청을 시작합니다. 서버는 Oracle AI Database 소프트웨어를 실행하며 동시 공유 데이터 액세스에 필요한 기능을 처리합니다. 서버는 클라이언트에서 생성되는 요청을 수신 및 처리합니다.

다계층 구조

다계층 구조에서 하나 이상의 응용 프로그램 서버가 작업의 일부를 수행합니다. 응용 프로그램 서버는 응용 프로그램 논리의 많은 부분을 포함하고, 클라이언트에 대한 데이터 액세스를 제공하며, 일부 Query 처리를 수행합니다. 이러한 방식으로 데이터베이스에 대한 로드가 감소합니다. Application Server는 클라이언트와 다중 데이터베이스 간의 인터페이스 역할을 할 수 있으며 추가 보안 레벨을 제공할 수 없습니다.

SOA(서비스 지향 구조)는 응용 프로그램 기능이 서비스에서 캡슐화되는 다계층 구조입니다. SOA 서비스는 일반적으로 웹 서비스로 구현됩니다. 웹 서비스는 HTTP를 통해 액세스할 수 있으며 WSDL(Web Services Description Language) 및 SOAP와 같은 XML 기반 표준을 기반으로 합니다. Oracle AI Database는 기존의 다계층 또는 SOA 환경에서 웹 서비스 제공업체 역할을 할 수 있습니다.

마이크로서비스 아키텍처는 애플리케이션을 독립적으로 개발 및 배포된 소규모 서비스로 나눕니다. 각 서비스는 비즈니스 로직을 소유하며, 이상적으로는 데이터를 소유하므로 커플링을 줄이고 팀이 독립적으로 서비스를 확장, 업데이트 및 운영할 수 있습니다.

Oracle 멀티테넌트 아키텍처는 서비스별 데이터베이스 패턴에 자연스럽게 매핑됩니다. 각 마이크로서비스는 별도의 데이터, 보안 및 관리 경계를 제공하는 자체 플러거블 데이터베이스(PDB)를 사용할 수 있으며, 여러 PDB가 공통 컨테이너 데이터베이스(CDB)의 리소스를 공유합니다.

이 접근 방식은 서비스 격리와 효율적인 통합을 결합합니다. PDB는 개별적으로 프로비저닝, 복제, 패치, 백업, 재배치 및 확장할 수 있으며 관리자는 기본 데이터베이스 인프라에 대한 중앙 집중식 제어를 유지합니다.

관련 항목

Oracle Net Services 구조

Oracle Net Services는 분산 처리 및 분산 데이터베이스를 용이하게 하는 데이터베이스와 네트워크 통신 프로토콜 간의 인터페이스입니다.

통신 프로토콜은 네트워크에서 데이터를 송수신하는 방법을 정의합니다. Oracle Net Services는 TCP/IP, HTTP, FTP 및 WebDAV를 비롯한 모든 주요 네트워크 프로토콜에서의 통신을 지원합니다. Oracle Net Services의 구성 요소인 Oracle Net은 클라이언트 응용 프로그램에서 데이터베이스 서버로의 네트워크 세션을 설정하고 유지 관리합니다. 네트워크 세션이 설정되면 Oracle Net는 클라이언트 응용프로그램과 데이터베이스 서버 모두에 대해 데이터 배달 수단으로 작동하여 이들 간에 메시지를 교환합니다. Oracle Net는 네트워크의 각 컴퓨터에 위치해 있기 때문에 이러한 작업을 수행할 있습니다.

Net 서비스의 중요한 구성 요소는 데이터베이스 또는 네트워크의 다른 곳에서 실행되는 프로세스인 Oracle Net Listener(리스너라고 함)입니다. 클라이언트 응용 프로그램은 리스너로 연결 요청을 보내 이러한 요청의 데이터베이스 트래픽을 관리합니다. 연결이 설정되면 클라이언트와 데이터베이스가 직접 통신합니다.

Oracle REST Data Services

ORDS(Oracle REST Data Services)는 Oracle AI Database에 대한 HTTPS 게이트웨이를 제공합니다. 이를 통해 애플리케이션은 별도의 애플리케이션 서버나 광범위한 미들웨어 코드 없이도 PL/SQL, JavaScript 및 Java로 작성된 테이블, 뷰, 내장 프로시저 및 사용자 정의 데이터베이스 작업을 보안 REST API로 노출할 수 있습니다.

ORDS는 또한 Oracle Database API for MongoDB를 지원하므로 애플리케이션은 호환되는 MongoDB 드라이버, 도구 및 명령을 사용하여 Oracle Database에 저장된 JSON 문서 컬렉션에 액세스할 수 있습니다. MongoDB 전송 프로토콜은 ORDS를 통해 데이터베이스 작업으로 변환되어 REST, MongoDB 및 SQL 애플리케이션이 동일한 컨버지드 데이터베이스에서 관리되는 데이터로 작업할 수 있도록 합니다.

관련 항목