Oracle NoSQL Database Cloud Service에서 테이블 설계

Oracle NoSQL Database Cloud Service에서 테이블을 설계하고 구성하는 방법을 알아봅니다.

이 문서에는 다음 항목이 있습니다.

테이블 필드

테이블 필드를 사용하여 데이터를 설계 및 구성하는 방법을 알아봅니다.

애플리케이션은 행이 키 필드와 단일 JSON 데이터 필드로 구성되는 스키마 없는 테이블을 사용하도록 선택할 수 있습니다. 스키마 없는 테이블은 행에 저장할 수 있는 융통성을 제공합니다.

또는 모든 테이블 필드가 특정 유형으로 정의되는 고정 스키마 테이블을 사용하도록 선택할 수도 있습니다.

입력된 데이터가 있는 고정 스키마 테이블은 적용 및 스토리지 효율성 측면에서 사용하는 것이 더 안전합니다. 고정 스키마 테이블의 스키마를 수정할 수 있지만 테이블 구조는 쉽게 변경할 수 없습니다. 스키마리스 테이블은 유연하며 테이블 구조는 쉽게 수정할 수 있습니다.

마지막으로, 애플리케이션은 테이블이 데이터 및 JSON 데이터 필드를 입력할 수 있는 하이브리드 데이터 모델 접근 방식을 사용할 수도 있습니다.

다음 예에서는 세 가지 접근 방식 모두에 대해 데이터를 설계하고 구성하는 방법을 보여줍니다.

예제 1: 스키마 없는 테이블 설계

테이블에 찾아보기 패턴에 대한 정보를 저장할 수 있는 여러 옵션이 있습니다. 한 가지 옵션은 쿠키 ID를 키로 사용하고 대상자 세분화 데이터를 단일 JSON 필드로 유지하는 테이블을 정의하는 것입니다.

// schema less, data is stored in a JSON field
CREATE TABLE audience_info (
       cookie_id LONG,
       audience_data JSON,
       PRIMARY KEY(cookie_id))

이 경우 audience_info 테이블은 다음과 같은 JSON 객체를 보유할 수 있습니다.

{
  "cookie_id": "",
  "audience_data": {
    "ipaddr" : "10.0.00.xxx",
    "audience_segment: {
       "sports_lover" : "2018-11-30",
       "book_reader" :  "2018-12-01"
    }
  }
}

애플리케이션에는 이 테이블에 대한 키 필드와 데이터 필드가 있습니다. audience_data 필드에 정보로 저장하도록 선택한 항목에 유연성이 있습니다. 따라서 사용 가능한 정보의 유형을 쉽게 변경할 수 있습니다.

예제 2: 고정 스키마 테이블 설계

보다 명시적으로 선언된 필드가 있는 테이블을 생성하여 찾아보기 패턴에 대한 정보를 저장할 수 있습니다.

// fixed schema, data is stored in typed fields.
CREATE TABLE audience_info(
       cookie_id LONG,
       ipaddr STRING,
       audience_segment RECORD(sports_lover TIMESTAMP(9),
                               book_reader TIMESTAMP(9)),
       PRIMARY KEY(cookie_id))

이 예에서는 테이블에 키 필드와 두 개의 데이터 필드가 있습니다. 데이터는 더 컴팩트하며 모든 데이터 필드가 정확한지 확인할 수 있습니다.

예제 3: 하이브리드 테이블 설계

테이블에 입력된 데이터 필드와 JSON 데이터 필드를 모두 사용하여 찾아보기 패턴에 대한 정보를 저장할 수 있습니다.

// mixed, data is stored in both typed and JSON fields.
CREATE TABLE audience_info (
       cookie_id LONG,
       ipaddr STRING,
       audience_segment JSON,
       PRIMARY KEY(cookie_id))

기본 키 및 샤드 키

애플리케이션을 설계하는 동안 기본 키 및 샤드 키의 용도를 알아봅니다.

기본 키와 샤드 키는 스키마의 중요한 요소이며 데이터를 효율적으로 액세스하고 배포하는 데 도움이 됩니다. 테이블을 생성하는 경우에만 기본 키와 샤드 키를 생성합니다. 테이블 수명 동안 유지되며 변경하거나 삭제할 수 없습니다.

기본 키

테이블을 생성할 때 하나 이상의 Primary Key 열을 지정해야 합니다. 기본 키는 테이블에서 모든 행을 식별합니다. 간단한 CRUD 작업의 경우 Oracle NoSQL Database Cloud Service는 기본 키를 사용하여 읽거나 수정할 특정 행을 검색합니다. 예를 들어, 테이블에 다음 필드가 있다고 가정합니다.

• productName

• productType

• productLine

제품 이름은 중요하고 각 행에 고유하므로 productName를 primary key로 설정합니다. 그런 다음 productName을 기반으로 원하는 행을 검색합니다. 이 경우 이와 같은 명령문을 사용하여 테이블을 정의합니다.

/* Create a new table called users. */
CREATE TABLE if not exists myProducts 
(
  productName STRING,
  productType STRING,
  productLine INTEGER,
  PRIMARY KEY (productName)
)"

샤드 키

샤드 키의 주요 목적은 효율성을 높이기 위해 Oracle NoSQL Database Cloud Service 클러스터에 데이터를 배포하고 간편한 참조와 액세스를 위해 샤드 키를 공유하는 레코드를 로컬에 배치하는 것입니다. 샤드 키를 공유하는 레코드는 동일한 물리적 위치에 저장되며 원자적이고 효율적으로 액세스할 수 있습니다.

기본 및 샤드 키 설계는 프로비저닝된 처리량을 확장하고 달성하는 데 영향을 줍니다. 예를 들어, 레코드가 샤드 키를 공유하는 경우 원자 작업에서 여러 테이블 행을 삭제하거나 단일 원자 작업에서 테이블의 하위 행 집합을 검색할 수 있습니다. 확장성을 지원하는 것 외에도 잘 설계된 샤드 키는 단일 샤드에 데이터를 넣거나 데이터를 가져오는 데 필요한 주기를 줄여 성능을 향상시킬 수 있습니다.

예를 들어, 다음과 같은 세 가지 기본 키 필드를 지정한다고 가정합니다.

PRIMARY KEY (productName, productType, productLine)

응용 프로그램에서 productName 및 productType 열을 사용하여 자주 query하는 것을 알고 있기 때문에 이러한 필드를 샤드 키로 지정하는 것이 좋습니다. 샤드 키 지정은 이 두 열에 대한 모든 행이 동일한 샤드에 저장되도록 보장합니다. 이러한 두 필드가 샤드 키가 아닌 경우 가장 자주 질의되는 열은 모든 샤드에 저장될 수 있습니다. 그런 다음 두 필드의 모든 행을 찾으려면 하나의 샤드가 아닌 모든 데이터 스토리지를 스캔해야 합니다.

샤드 키는 키 값에 대한 효율적인 쿼리를 용이하게 하기 위해 동일한 샤드에 스토리지를 지정합니다. 그러나 최상의 성능을 위해 데이터를 샤드 간에 분산하려면 고유한 값이 거의 없는 샤드 키를 사용하지 않아야 합니다.

주:

테이블을 생성할 때 샤드 키를 지정하지 않으면 Oracle NoSQL Database Cloud Service에서 샤드 조직에 기본 키를 사용합니다.

샤드 키 선택 시 고려해야 할 중요한 요소

• 기수: 사용자 본국과 같은 낮은 기수 필드는 몇 개의 샤드에서 레코드를 함께 그룹화합니다. 결과적으로 이러한 샤드는 빈번한 데이터 리밸런싱이 필요하므로 핫 샤드 문제가 발생할 가능성이 높아집니다. 대신 각 샤드 키에는 높은 기수가 있어야 합니다. 여기서 샤드 키는 데이터 세트에 있는 레코드의 짝수 조각을 표현할 수 있습니다. 예를 들어, ID 번호(예: customerID, userID 또는 productID)는 샤드 키에 적합한 후보입니다.

• 원자성: 샤드 키를 공유하는 객체만 트랜잭션에 참여할 수 있습니다. 여러 레코드에 걸쳐 있는 ACID 트랜잭션이 필요한 경우 해당 요구 사항을 충족할 수 있는 샤드 키를 선택합니다.

따라야 할 모범 사례는 무엇입니까?

• 샤드 키 균일 배포: 샤드 키가 균일하게 분산된 경우 단일 샤드가 시스템 용량을 제한하지 않습니다.

• 질의 격리: 질의는 효율성과 성능을 극대화하기 위해 특정 샤드를 대상으로 해야 합니다. 질의가 단일 샤드로 격리되지 않으면 모든 샤드에 질의가 적용되어 효율성이 떨어지고 질의 대기 시간이 증가합니다.

TableRequest 객체를 사용하여 기본 및 샤드 키를 지정하는 방법을 알아보려면 테이블 생성을 참조하십시오.

보관 시간

TTL(Time-to-Live) 기능을 사용하여 테이블 및 행에 대한 만료 시간을 지정하는 방법을 배웁니다.

많은 응용 프로그램이 유효 수명이 제한된 데이터를 처리합니다. TTL(Time-to-Live)은 테이블 행의 시간대를 설정할 수 있는 메커니즘으로, 이 시간대가 지나면 행이 자동으로 만료되어 더 이상 사용할 수 없습니다. Oracle NoSQL Database Cloud Service에 데이터를 유지할 수 있는 시간입니다. 만료 시간에 도달한 데이터는 더 이상 검색할 수 없으며 저장 영역 통계에 나타나지 않습니다.

기본적으로 생성하는 모든 테이블의 TTL 값은 만료 시간이 없음을 나타내는 0입니다. 테이블을 생성할 때 TTL 값을 선언하고 숫자로 TTL을 지정한 후 HOURS 또는 DAYS를 지정할 수 있습니다. 테이블 행에 대해 TTL 값을 명시적으로 설정하지 않은 경우 테이블 행이 상주하는 테이블의 TTL 값을 상속합니다. 행의 TTL 값을 설정하면 테이블의 TTL 값이 무효화됩니다. 행에 TTL 값이 있는 후 테이블의 TTL 값을 변경하면 행의 TTL 값이 유지됩니다.

행이 만료 시간에 도달하기 전에 언제든지 테이블 행의 TTL 값을 갱신할 수 있습니다. 만료된 데이터는 더 이상 액세스할 수 없습니다. 따라서 데이터 삭제를 위해 데이터베이스 로그 항목을 기록하는 오버헤드를 방지하기 때문에 TTL 값을 사용하면 행을 수동으로 삭제하는 것보다 효율적입니다. 만료된 데이터는 만료 날짜 이후에 디스크에서 제거됩니다.

테이블 상태 및 수명 주기

다양한 테이블 상태 및 중요도(테이블 수명 주기 프로세스)에 대해 알아봅니다.

각 테이블은 테이블 생성에서 삭제(삭제)까지의 여러 가지 상태를 통과합니다. 예를 들어, DROPPING 상태의 테이블은 ACTIVE 상태로 진행할 수 없고 ACTIVE 상태의 테이블은 UPDATING 상태로 변경될 수 있습니다. 테이블 수명 주기를 모니터하여 여러 테이블 상태를 추적할 수 있습니다. 이 절에서는 다양한 테이블 상태에 대해 설명합니다.

그림 테이블 설명 - state.png

테이블 상태	설명
CREATING	테이블을 생성하는 중입니다. 사용할 준비가 되지 않았습니다.
UPDATING	테이블 업데이트가 진행 중입니다. 테이블이 이 상태인 동안에는 테이블을 추가로 수정할 수 없습니다. 테이블은 다음과 같은 경우 UPDATING 상태입니다. 테이블 제한 변경 테이블 스키마 변경 중 테이블 인덱스 추가 또는 삭제
ACTIVE	테이블은 현재 상태에서 사용할 수 있습니다. 테이블이 최근에 생성되었거나 수정되었을 수 있지만 테이블 상태는 이제 안정적입니다.
DROPPING	테이블이 삭제되고 있으므로 어떠한 목적으로도 액세스할 수 없습니다.
DROPPED	테이블이 삭제되었으며 읽기, 쓰기 또는 질의 작업에 대해 더 이상 존재하지 않습니다. 주: 삭제한 후에는 동일한 이름을 가진 테이블을 다시 생성할 수 있습니다.

테이블 계층

Oracle NoSQL Database를 사용하면 테이블이 상위-하위 관계에 존재할 수 있습니다. 이를 테이블 계층이라고 합니다.

create table 문을 사용하면 다른 테이블의 하위 테이블로 테이블을 생성하여 새 테이블의 상위 테이블이 됩니다. 이 작업은 하위 테이블에 대한 조합 이름(name_path)을 사용하여 수행됩니다. 조합 이름은 점으로 구분된 식별자의 숫자 N(N > 1)으로 구성됩니다. 마지막 식별자는 하위 테이블의 로컬 이름이고 첫번째 N-1 식별자는 상위 테이블의 이름을 가리킵니다.

상위-하위 테이블의 특성:

• 하위 테이블은 상위 테이블의 기본 키 열을 상속합니다.
• 계층의 모든 테이블에는 루트 테이블의 create table 문에 지정된 동일한 샤드 키 열이 있습니다.
• 상위 테이블은 하위 테이블이 삭제되기 전에 삭제할 수 없습니다.
• 참조 무결성 제약 조건은 상위-하위 테이블에 적용되지 않습니다.

일부 형식의 데이터 정규화가 필요한 경우 하위 테이블 사용을 고려해야 합니다. 1-N 관계를 모델링할 때 하위 테이블도 좋은 선택이 될 수 있으며 상위-하위 계층에서 여러 레코드를 작성할 때 ACID 트랜잭션 의미를 제공합니다.

---

제목 및 저작권 정보

Oracle NoSQL Database Cloud Service에서 테이블 설계

Copyright ©2022,2024,

Oracle and/or its affiliates.