Oracle NoSQL Database Migrator 사용

Oracle NoSQL Database Migrator 및 데이터 마이그레이션에 사용할 수 있는 방법을 확인해 보세요.

Oracle NoSQL Database Migrator는 Oracle NoSQL 테이블을 한 데이터 소스에서 다른 데이터 소스로 마이그레이션할 수 있게 해주는 도구입니다. 이 툴은 온프레미스 및 AWS S3에서 Oracle NoSQL Database Cloud Service, Oracle NoSQL Database의 테이블에 대해 작동할 수 있습니다. Migrator 도구는 다양한 데이터 형식과 물리적 미디어 유형을 지원합니다. 지원되는 데이터 형식은 JSON, Parquet, MongoDB 형식이 지정된 JSON, DynamoDB 형식이 지정된 JSON 및 CSV 파일입니다. 지원되는 물리적 미디어 유형은 파일, OCI Object Storage, 온프레미스 Oracle NoSQL Database, Oracle NoSQL Database Cloud Service 및 AWS S3입니다.

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

관련 항목

개요

Oracle NoSQL Database Migrator를 사용하면 Oracle NoSQL Database 온프레미스, 클라우드, 심지어 단순한 JSON 파일 등 Oracle NoSQL 테이블을 한 데이터 소스에서 다른 데이터 소스로 이동할 수 있습니다.

NoSQL 테이블을 from 또는 to Oracle NoSQL Database로 마이그레이션해야 하는 상황이 많을 수 있습니다. 예를 들어, NoSQL Database 애플리케이션을 향상시키는 개발자 팀은 cloudsim을 사용하여 로컬 Oracle NoSQL Database Cloud Service(NDCS) 인스턴스에서 업데이트된 코드를 테스트할 수 있습니다. 가능한 모든 테스트 사례를 확인하려면 실제 데이터와 유사한 테스트 데이터를 설정해야 합니다. 이렇게 하려면 운영 환경에서 cloudsim 환경의 로컬 NDCS 인스턴스로 NoSQL 테이블을 복사해야 합니다. 다른 상황에서는 NoSQL 개발자가 개발 또는 테스트를 위해 애플리케이션 데이터를 온프레미스에서 클라우드로 또는 그 반대로 이동해야 할 수 있습니다.

Oracle NoSQL Database Migrator를 사용해 Oracle NoSQL Database 온프레미스, 클라우드, 단순한 JSON 파일 등 데이터 소스 간에 NoSQL 테이블을 이동할 수 있습니다. 또한 NoSQL 테이블을 MongoDB 형식 JSON 입력 파일, DynamoDB 형식 JSON 입력 파일(AWS S3 소스 또는 파일에서 저장됨) 또는 CSV 파일에서 온프레미스 또는 클라우드 NoSQL 데이터베이스로 복사할 수 있습니다.

다음 그림에 표시된 것처럼 NoSQL Database Migrator 유틸리티는 데이터 소스와 대상(싱크라고 함) 사이의 커넥터 또는 파이프 역할을 합니다. 본질적으로 이 유틸리티는 선택한 소스에서 데이터를 내보내고 해당 데이터를 싱크로 가져옵니다. 이 도구는 테이블 지향적입니다. 즉, 테이블 레벨에서만 데이터를 이동할 수 있습니다. 단일 마이그레이션 작업은 단일 테이블에서 작동하며 다양한 데이터 형식으로 소스 간에 테이블 데이터를 마이그레이션할 수 있도록 지원합니다.

Oracle NoSQL Database Migrator는 향후 추가 소스 및 싱크를 지원할 수 있도록 설계되었습니다. 현재 릴리스부터 Oracle NoSQL Database Migrator가 지원하는 소스 및 싱크 목록은 Supported Sources and Sinks를 참고하세요.

다음은 migrator_overview.eps에 대한 설명입니다.
그림 migrator_overview.eps에 대한 설명

Oracle NoSQL Database Migrator와 함께 사용되는 용어

위 다이어그램에 사용된 다양한 용어에 대해 자세히 알아봅니다.

  • 소스: 이전을 위해 NoSQL 테이블을 익스포트하는 엔티티입니다. Oracle NoSQL Database 온프레미스 또는 클라우드, JSON 파일, MongoDB 형식의 JSON 파일, DynamoDB 형식의 JSON 파일, CSV 파일 등이 있습니다.
  • 싱크: NoSQL Database Migrator에서 NoSQL 테이블을 가져오는 엔티티입니다. 싱크의 예로는 Oracle NoSQL Database 온프레미스 또는 클라우드와 JSON 파일이 있습니다.

NoSQL Database Migrator 도구는 다양한 소스 및 싱크 유형(물리적 매체 또는 데이터 저장소), 데이터 형식(데이터가 소스 또는 싱크에 표시되는 방식)을 지원합니다. 지원되는 데이터 형식은 JSON, Parquet, MongoDB 형식이 지정된 JSON, DynamoDB 형식이 지정된 JSON 및 CSV 파일입니다. 지원되는 소스 및 싱크 유형은 파일, OCI Object Storage, 온프레미스 Oracle NoSQL Database, Oracle NoSQL Database Cloud Service입니다.

  • 마이그레이션 파이프: NoSQL Database Migrator를 통해 소스의 데이터가 싱크로 전송됩니다. 마이그레이션 파이프로 시각화할 수 있습니다.
  • 변환: 규칙을 추가하여 이전 파이프에서 NoSQL 테이블 데이터를 수정할 수 있습니다. 이러한 규칙을 변환이라고 합니다. Oracle NoSQL Database Migrator는 최상위 필드 또는 열에서만 데이터 변환을 허용합니다. 중첩 필드의 데이터를 변환할 수는 없습니다. 허용되는 변환의 몇 가지 예는 다음과 같습니다.
    • 하나 이상의 열을 삭제하거나 무시합니다.
    • 하나 이상의 열 이름 바꾸기
    • 여러 열을 단일 필드(일반적으로 JSON 필드)로 집계합니다.
  • 구성 파일: 구성 파일에서 마이그레이션 작업에 필요한 모든 매개변수를 JSON 형식으로 정의합니다. 나중에 이 구성 파일을 CLI에서 runMigrator 명령에 단일 매개변수로 전달합니다. 일반적인 구성 파일 형식은 아래와 같습니다.
    {
 "source": {
   "type" : <source type>,
   //source-configuration for type. See Source Configuration Templates  .
 },
 "sink": {
   "type" : <sink type>,
   //sink-configuration for type. See Sink Configuration Templates  .
 },
 "transforms" : {
   //transforms configuration. See Transformation Configuration Templates  .
 },
 "migratorVersion" : "<migrator version>",
 "abortOnError" : <true|false>
}
    그룹화 매개변수 필수(Y/N) 용도 지원되는 값
    source type Y 데이터를 마이그레이션할 원본을 나타냅니다.Represents the source from which to migrate the data. 소스는 마이그레이션을 위한 데이터 및 메타데이터(있는 경우)를 제공합니다. 각 소스에 대한 type 값을 확인하려면 Supported Sources and Sinks를 참조하십시오.
    source 유형에 대한 소스 구성 Y 소스에 대한 구성을 정의합니다. 이러한 구성 매개변수는 위에서 선택한 소스 유형에 따라 다릅니다. 각 소스 유형에 대한 전체 구성 매개변수 목록은 소스 구성 템플리트를 참조하십시오.
    sink type Y 데이터를 마이그레이션할 싱크를 나타냅니다.Represents the sink to which to migrate the data. 싱크는 마이그레이션의 대상 또는 대상입니다. 각 소스에 대한 type 값을 확인하려면 Supported Sources and Sinks를 참조하십시오.
    sink 유형에 대한 sink-configuration Y 싱크에 대한 구성을 정의합니다. 이러한 구성 매개변수는 위에서 선택한 싱크 유형에 따라 다릅니다. 각 싱크 유형에 대한 전체 구성 매개변수 목록은 Sink Configuration Templates를 참조하십시오.
    transforms 변환 구성 N 마이그레이션 파이프의 데이터에 적용할 변환을 정의합니다. NoSQL 데이터 마이그레이터에서 지원하는 전체 변환 목록은 변환 구성 템플리트를 참조하십시오.
    - migratorVersion N NoSQL 데이터 마이그레이터 버전 -
    - abortOnError N

    오류 발생 시 마이그레이션 작업을 중지할지 여부를 지정합니다.

    기본값은 true이며 마이그레이션 오류가 발생할 때마다 마이그레이션이 중지됨을 나타냅니다.

    이 값을 false로 설정하면 실패한 레코드나 기타 마이그레이션 오류가 있는 경우에도 마이그레이션이 계속됩니다. 실패한 레코드 및 마이그레이션 오류는 CLI 터미널에 WARNING으로 기록됩니다.

    		true, false

    주:

    JSON 파일은 대소문자를 구분하므로 별도로 지정하지 않는 한 구성 파일에 정의된 모든 매개변수는 대소문자를 구분합니다.

지원되는 소스 및 싱크

이 항목에서는 Oracle NoSQL Database Migrator가 지원하는 소스 및 싱크 목록을 제공합니다.

이 테이블에서 마이그레이션 작업에 적합한 소스와 싱크의 조합을 사용할 수 있습니다. 그러나 끝, 즉 소스 또는 싱크 중 하나 이상이 Oracle NoSQL 제품인지 확인해야 합니다. NoSQL 데이터베이스 마이그레이터를 사용하여 NoSQL 테이블 데이터를 한 파일에서 다른 파일로 이동할 수 없습니다.

유형
(값)

형식
(값)

적합한 소스 유효 싱크

Oracle NoSQL Database
(nosqldb)

NA Y Y

Oracle NoSQL Database Cloud Service
(nosqldb_cloud)

NA Y Y

파일 시스템
(file)

JSON
(json)

Y Y

MongoDB JSON
(mongodb_json)

Y N

DynamoDB JSON
(dynamodb_json)

Y N

연회(parquet)

N Y

CSV
(csv)

Y N

OCI Object Storage
(object_storage_oci)

JSON
(json)

Y Y

MongoDB JSON
(mongodb_json)

Y N

연회(parquet)

N Y

CSV
(csv)

Y N
AWS S3

DynamoDB JSON
(dynamodb_json)

Y N

주:

많은 구성 매개변수가 소스 및 싱크 구성에서 일반적입니다. 참조하기 쉽도록 설명서 섹션의 각 소스 및 싱크에 대해 이러한 매개변수에 대한 설명이 반복되어 다양한 유형의 소스 및 싱크에 대한 구성 파일 형식을 설명합니다. 모든 경우에 동일한 이름을 가진 파라미터의 구문과 의미는 동일합니다.

소스 및 싱크 보안

일부 소스 및 싱크 유형에는 인증 목적으로 선택적 또는 필수 보안 정보가 있습니다.

Oracle Cloud Infrastructure(OCI)의 서비스를 사용하는 모든 소스 및 싱크는 특정 매개변수를 사용하여 선택적 보안 정보를 제공할 수 있습니다. 이 정보는 OCI 구성 파일 또는 인스턴스 주체를 사용하여 제공할 수 있습니다.

Oracle NoSQL Database 소스 및 싱크에는 설치가 보안이고 Oracle Wallet 기반 인증을 사용하는 경우 필수 보안 정보가 필요합니다. 이 정보는 jar 파일을 <MIGRATOR_HOME>/lib 디렉토리에 추가하여 제공할 수 있습니다.

전자 지갑 기반 인증

Oracle NoSQL Database 설치에서 Oracle Wallet 기반 인증을 사용하는 경우 EE 설치의 일부인 추가 jar 파일을 포함해야 합니다. 자세한 내용은 Oracle Wallet을 참조하십시오.

jar 파일이 없으면 다음과 같은 오류 메시지가 표시됩니다.

lib 디렉토리에서 kvstore-ee.jar 및 kvstore-ee-<version>.jar를 찾을 수 없습니다. kvstore-ee.jar 및 kvstore-ee-<version>.jar를 lib 디렉토리에 복사합니다.

위에 표시된 예외를 방지하려면 kvstore-ee.jar 및 kvstore-ee-<version>.jar 파일을 EE 서버 패키지에서 <MIGRATOR_HOME>/lib 디렉토리로 복사해야 합니다. <MIGRATOR_HOME>은 Oracle NoSQL Database Migrator 패키지를 추출하여 생성된 nosql-migrator-M.N.O/ 디렉토리이고 M.N.O는 소프트웨어 release.major.minor 번호를 나타냅니다. 예: nosql-migrator-1.1.0/lib.

주:

전자 지갑 기반 인증은 Oracle NoSQL Database의 EE(Enterprise Edition)에서만 지원됩니다.

Instance Principals를 사용하여 인증

인스턴스 주체는 인스턴스에서 서비스 리소스에 대한 작업을 수행할 수 있는 권한이 부여된 작업자(또는 주체)가 될 수 있는 IAM 서비스 기능입니다. 각 컴퓨팅 인스턴스는 고유한 ID를 가지며 여기에 추가된 인증서를 사용하여 인증합니다.

Oracle NoSQL Database Migrator는 인스턴스 주체 인증을 사용하여 NoSQL 클라우드 및 OCI Object Storage 소스 및 싱크에 연결할 수 있는 옵션을 제공합니다. NoSQL Database Migrator 도구가 OCI 컴퓨트 인스턴스 내에서 사용되는 경우에만 지원됩니다(예: OCI에서 호스팅되는 VM에서 실행되는 NoSQL Database Migrator 도구). 이 기능을 사용으로 설정하려면 NoSQL 클라우드 소스 및 싱크 구성 파일의 useInstancePrincipal 속성을 사용합니다. 다양한 유형의 소스 및 싱크에 대한 구성 매개변수에 대한 자세한 내용은 소스 구성 템플리트 및 싱크 구성 템플리트를 참조하십시오.

인스턴스 주체에 대한 자세한 내용은 인스턴스에서 서비스 호출을 참조하십시오.

Oracle NoSQL Database Migrator용 워크플로우

NoSQL 데이터 마이그레이션을 위해 Oracle NoSQL Database Migrator 유틸리티를 사용하는 것과 관련된 다양한 단계에 대해 알아봅니다.

NoSQL Database Migrator 사용과 관련된 작업의 상위 레벨 플로우는 아래 그림에 나와 있습니다.


다음은 migrator_flow.eps에 대한 설명입니다.
그림 migrator_flow.eps에 대한 설명

NoSQL Data Migrator 유틸리티 다운로드

Oracle NoSQL Database Migrator 유틸리티는 Oracle NoSQL 다운로드 페이지에서 다운로드할 수 있습니다. 시스템에서 압축을 다운로드하고 압축을 풀면 명령줄 인터페이스에서 runMigrator 명령에 액세스할 수 있습니다.

주:

Oracle NoSQL Database Migrator 유틸리티를 실행하려면 Java 11 이상의 버전이 필요합니다.

소스 및 싱크 식별

마이그레이터를 사용하기 전에 데이터 소스와 싱크를 식별해야 합니다. 예를 들어 NoSQL 테이블을 온프레미스의 Oracle NoSQL Database에서 JSON 형식의 파일로 마이그레이션하려는 경우 소스는 Oracle NoSQL Database이고 싱크는 JSON 파일이 됩니다. 지원되는 소스 및 싱크를 참조하여 식별된 소스 및 싱크가 Oracle NoSQL Database Migrator에서 지원되는지 확인합니다. 또한 대상 또는 싱크에서 NoSQL 테이블의 스키마를 결정하고 생성하는 데 적합한 단계입니다.
  • 싱크 테이블 스키마 식별: 싱크가 온프레미스 또는 클라우드에서 Oracle NoSQL Database인 경우 싱크 테이블에 대한 스키마를 식별하고 소스 데이터가 대상 스키마와 일치하는지 확인해야 합니다. 필요한 경우 변환을 사용하여 소스 데이터를 싱크 테이블에 매핑합니다.
    • 기본 스키마: NoSQL 데이터베이스 마이그레이터는 테이블에 대한 스키마를 미리 정의할 필요 없이 기본 스키마로 테이블을 생성하는 옵션을 제공합니다. 이 기능은 주로 JSON 소스 파일을 Oracle NoSQL Database로 로드할 때 유용합니다.
      소스가 MongoDB 형식 JSON 파일인 경우 테이블의 기본 스키마는 다음과 같습니다.
      CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))

      설명:

      - tablename = 구성의 테이블 속성에 대해 제공된 값입니다.

      - ID = mongoDB 익스포트된 JSON 소스 파일의 각 문서에서 _id 값입니다.

      - DOCUMENT = mongoDB 내보낸 파일의 각 문서에 대해 _id 필드를 제외한 내용이 DOCUMENT 열로 집계됩니다.

      소스가 DynamoDB 형식 JSON 파일인 경우 테이블의 기본 스키마는 다음과 같습니다.
      CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, 
[DDBSortKey_name DDBSortKey_type],DOCUMENT JSON,
PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))

      설명:

      - TABLE_NAME = 구성의 싱크 테이블에 대해 제공된 값

      - DDBPartitionKey_name = 구성의 분할 영역 키에 대해 제공된 값

      - DDBPartitionKey_type = 구성에서 분할 영역 키의 데이터 유형에 대해 제공된 값

      - DDBSortKey_name = 구성의 정렬 키에 대해 제공된 값(있는 경우)

      - DDBSortKey_type = 구성에서 정렬 키의 데이터 유형에 대해 제공된 값(있는 경우)

      - DOCUMENT = NoSQL JSON 열로 집계된 Dynamo DB 테이블 항목의 분할 영역 및 정렬 키를 제외한 모든 속성

      소스 형식이 CSV 파일인 경우 대상 테이블에 대해 기본 스키마가 지원되지 않습니다. 소스 CSV 파일과 동일한 수의 열 및 데이터 유형을 포함하는 테이블 정의로 스키마 파일을 생성할 수 있습니다. 스키마 파일 생성에 대한 자세한 내용은 테이블 스키마 제공을 참조하십시오.

      다른 모든 소스의 경우 기본 스키마는 다음과 같습니다.
      CREATE TABLE IF NOT EXISTS <tablename> (ID LONG GENERATED ALWAYS AS IDENTITY, DOCUMENT JSON, PRIMARY KEY(ID))

      설명:

      - tablename = 구성의 테이블 속성에 대해 제공된 값입니다.

      - ID = 자동 생성된 LONG 값입니다.

      - DOCUMENT = 소스에서 제공하는 JSON 레코드가 DOCUMENT 열로 집계됩니다.

      주:

      _id 값이 MongoDB 형식 JSON 파일에서 문자열로 제공되지 않은 경우 NoSQL Database Migrator는 기본 스키마에 삽입하기 전에 문자열로 변환합니다.
  • 테이블 스키마 제공: NoSQL 데이터베이스 마이그레이터를 사용하면 소스가 schemaInfo 속성을 사용하여 테이블 데이터에 대한 스키마 정의를 제공할 수 있습니다. schemaInfo 속성은 이미 정의된 암시적 스키마가 없는 모든 데이터 소스에서 사용할 수 있습니다. 싱크 데이터 저장소는 다음 옵션 중 하나를 선택할 수 있습니다.
    • NoSQL Database Migrator로 정의된 기본 스키마를 사용합니다.
    • 소스 제공 스키마를 사용합니다.
    • 자체 스키마를 정의하여 소스 제공 스키마를 무효화합니다. 예를 들어, 소스 스키마에서 다른 스키마로 데이터를 변환하려면 소스 제공 스키마를 무효화하고 NoSQL Database Migrator 툴의 변환 기능을 사용해야 합니다.

    다음은 source_sink_schema_example.png에 대한 설명입니다.
    그림 source_sink_schema_example.png에 대한 설명

    테이블 스키마 파일(예: mytable_schema.ddl)에는 테이블 DDL 문이 포함될 수 있습니다. NoSQL Database Migrator 도구는 마이그레이션을 시작하기 전에 이 테이블 스키마 파일을 실행합니다. migrator 툴은 스키마 파일에서 한 행에 하나만 DDL 문을 지원합니다. 예를 들어 다음과 같습니다.
    CREATE TABLE IF NOT EXISTS(id INTEGER, name STRING, age INTEGER, PRIMARY KEY(SHARD(ID)))

    주:

    테이블이 싱크대에 있고 schemaPath의 DDL이 테이블과 다를 경우 이전이 실패합니다.
  • 싱크 테이블 만들기: 싱크 테이블 스키마를 식별하면 Admin CLI 또는 sink 구성 파일의 schemaInfo 속성을 사용하여 싱크 테이블을 만듭니다. Sink Configuration Templates을 참조하십시오.

    주:

    소스가 CSV 파일인 경우 대상 테이블의 스키마에 대해 DDL 명령을 사용하여 파일을 생성합니다. 싱크 구성 파일의 schemaInfo.schemaPath 매개변수에 파일 경로를 제공합니다.

테이블 행의 TTL 메타 데이터 이전

TTL(Time to Live)은 테이블 행을 자동으로 만료시키는 메커니즘입니다. TTL은 매장에서 데이터를 보관할 수 있는 시간으로 표현됩니다. 만료 시간 초과 값에 도달한 데이터는 더 이상 검색할 수 없으며 상점 통계에 나타나지 않습니다.

Oracle NoSQL Database 테이블 마이그레이션을 수행할 때 테이블 행에 대한 TTL 메타데이터를 실제 데이터와 함께 포함하도록 선택할 수 있습니다. NoSQL Database Migrator는 다음 소스 유형에 대해 테이블 행 TTL 메타데이터의 익스포트 및 임포트를 지원하는 구성 매개변수를 제공합니다.

테이블 - TTL 메타데이터 이전 중

소스 유형 소스 구성 매개변수 싱크 구성 매개변수
Oracle NoSQL Database includeTTL includeTTL
Oracle NoSQL Database Cloud Service includeTTL includeTTL
DynamoDB 형식의 JSON 파일 ttlAttributeName includeTTL
AWS에 저장된 DynamoDB 형식의 JSON 파일 S3 ttlAttributeName includeTTL

Oracle NoSQL Database 및 Oracle NoSQL Database Cloud Service에서 TTL 메타데이터 익스포트

NoSQL Database Migrator는 테이블 행의 TTL 메타데이터 익스포트를 지원하는 includeTTL 구성 매개변수를 제공합니다.

테이블이 엑스포트되면 유효한 만료 시간이 있는 테이블 행에 대한 TTL 데이터가 엑스포트됩니다. 행이 만료되지 않으면 _metadata JSON 객체는 만료 값이 항상 0이므로 익스포트된 데이터에 명시적으로 포함되지 않습니다. NoSQL Database Migrator는 UNIX 시대(1970년 1월 1일) 이후 각 행의 만료 시간을 밀리초 수로 내보냅니다. 예제
//Row 1
{
    "id" : 1,
    "name" : "xyz",
    "age" : 45,
    "_metadata" : {
        "expiration" : 1629709200000   //Row Expiration time in milliseconds
    }
}

//Row 2
{
    "id" : 2,
    "name" : "abc",
    "age" : 52,
    "_metadata" : {
        "expiration" : 1629709400000   //Row Expiration time in milliseconds
    }
}

//Row 3 No Metadata for below row as it will not expire
{
    "id" : 3,
    "name" : "def",
    "age" : 15
}

TTL 메타데이터 임포트 중

싱크 구성 템플리트에서 includeTTL 구성 매개변수를 사용하여 선택적으로 TTL 메타데이터를 가져올 수 있습니다.

가져오기 작업의 기본 참조 시간은 NoSQL Database Migrator 도구가 실행 중인 시스템의 System.currentTimeMillis()에서 가져온 현재 시간(밀리초)입니다. 그러나 만료 시간을 연장하고 즉시 만료되는 행을 임포트하려면 ttlRelativeDate 구성 매개변수를 사용하여 사용자정의 참조 시간을 설정할 수도 있습니다. 확장은 다음과 같이 계산되고 만료 시간에 추가됩니다. 

Extended time = expiration time - reference time

임포트 작업은 TTL 메타데이터가 포함된 테이블 행을 이전할 때 다음과 같은 사용 사례를 처리합니다. 이러한 사용 사례는 includeTTL 구성 매개변수가 true로 설정된 경우에만 적용할 수 있습니다.

  • 사용 사례 1: 임포트 테이블 행에 TTL 메타데이터 정보가 없습니다.

    임포트할 행에 TTL 정보가 포함되지 않은 경우 NoSQL Database Migrator는 행에 대해 TTL=0을 설정합니다.

  • 사용 사례 2: 테이블 행이 임포트되는 참조 시간을 기준으로 소스 테이블 행의 TTL 값이 만료됩니다.

    만료된 테이블 행은 무시되고 저장소에 기록되지 않습니다.

  • 사용 사례 3: 테이블 행이 임포트되는 참조 시간을 기준으로 소스 테이블 행의 TTL 값이 만료되지 않습니다.

    테이블 행이 TTL 값으로 임포트됩니다. 그러나 TimeToLive 클래스의 정수 시간 및 일 기간 제약 조건으로 인해 가져온 TTL 값이 원래 내보낸 TTL 값과 일치하지 않을 수 있습니다. 예제

    엑스포트된 테이블 행을 살펴보십시오.
    {
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
  "expiration" : 1734566400000 //Thursday, December 19, 2024 12:00:00 AM in UTC
  }
}

    가져오는 동안의 참조 시간은 1734480000000이며, 이는 2024년 12월 18일 수요일 오전 12:00:00입니다.

    임포트된 테이블 행
    {
  "id" : 8,
  "name" : "xyz",
  "_metadata" : {
    "ttl" :  1734739200000 //Saturday, December 21, 2024 12:00:00 AM
  }
}

AWS에 저장된 DynamoDB 형식의 JSON 파일 및 DynamoDB 형식의 JSON 파일에서 TTL 메타데이터 임포트 S3

NoSQL Database Migrator는 DynamoDB 형식의 JSON 파일 항목에서 TTL 메타데이터 임포트를 지원하는 추가 구성 매개변수 ttlAttributeName을 제공합니다.

DynamoDB 익스포트된 JSON 파일에는 TTL 만료 시간기록을 저장할 각 항목의 특정 속성이 포함됩니다. To optionally import the TTL values from DynamoDB exported JSON files, you must supply the specific attribute's name as a value to the ttlAttributeName configuration parameter in the DynamoDB-Formatted JSON File or DynamoDB-Formatted JSON File stored in AWS S3 source configuration files. 또한 싱크 구성 템플리트에서 includeTTL 구성 매개변수를 설정해야 합니다. 유효한 싱크는 Oracle NoSQL Database 및 Oracle NoSQL Database Cloud Service입니다. NoSQL 데이터베이스 마이그레이터는 임포트된 항목에 대한 TTL 정보를 _metadata JSON 객체에 저장합니다.

임포트 작업은 DynamoDB 익스포트된 JSON 파일의 테이블 항목을 이전할 때 다음과 같은 사용 사례를 관리합니다.

  • 사용 사례 1: ttlAttributeName 구성 매개변수 값이 DynamoDB 익스포트된 JSON 파일에 지정된 TTL 속성 이름으로 설정됩니다.

    NoSQL Database Migrator는 UNIX 시대(1970년 1월 1일) 이후 이 항목의 만료 시간을 밀리초 수로 가져옵니다.

    예를 들어, DynamoDB 익스포트된 JSON 파일의 항목을 고려해 보십시오.
    {
    "Item": {
        "DeptId": {
            "N": "1"
        },
        "DeptName": {
            "S": "Engineering"
        },
        "ttl": {
            "N": "1734616800"
        }
    }
}
    여기서 ttl 속성은 항목에 대한 TTL 값을 지정합니다. DynamoDB 형식의 JSON 파일에서 ttlAttributeName 구성 매개변수를 ttl로 설정하거나 AWS S3 소스 구성 파일에 저장된 DynamoDB 형식의 JSON 파일을 설정하면 NoSQL Database Migrator는 항목에 대한 만료 시간을 다음과 같이 가져옵니다.
    {
  "DeptId": 1,
  "document": {
      "DeptName": "Engineering"
    }  
  "_metadata": {
    "expiration": 1734616800000
  }
}

    주:

    만료 시간을 계산하기 위한 참조 시간으로 싱크 구성 템플리트의 ttlRelativeDate 구성 매개변수를 제공할 수 있습니다.
  • 사용 사례 2: ttlAttributeName 구성 매개변수 값이 설정되었지만, 값이 DynamoDB 익스포트된 JSON 파일의 항목에 속성으로 존재하지 않습니다.

    NoSQL Database Migrator는 제공된 항목에 대한 TTL 메타데이터 정보를 가져오지 않습니다.

  • 사용 사례 3: ttlAttributeName 구성 매개변수 값이 DynamoDB 익스포트된 JSON 파일의 항목에 있는 속성 이름과 일치하지 않습니다.
    NoSQL Database Migrator는 싱크 구성에 따라 다음 방법 중 하나로 임포트를 처리합니다.
    • 기본 스키마를 사용하여 임포트하도록 구성된 경우 속성을 일반 필드로 복사합니다.
    • 사용자 정의 스키마를 사용하여 임포트하도록 구성된 경우 속성을 건너뜁니다.

IDENTITY 열이 있는 싱크로 데이터 가져오기

적합한 소스에서 IDENTITY 열이 있는 싱크 테이블(온프레미스/클라우드 서비스)로 데이터를 임포트할 수 있습니다. IDENTITY 열을 GENERATED ALWAYS AS IDENTITY 또는 GENERATED BY DEFAULT AS IDENTITY로 생성합니다. IDENTITY 열로 테이블을 생성하는 방법에 대한 자세한 내용은 SQL 참조 설명서의 IDENTITY 열로 테이블 생성을 참조하십시오.

데이터를 임포트하기 전에 싱크에 있는 Oracle NoSQL Database 테이블이 있는지 확인합니다(있는 경우). 싱크 테이블에 기존 데이터가 있는 경우 마이그레이션으로 인해 싱크 테이블의 기존 데이터를 덮어쓰거나 가져오는 동안 소스 데이터를 건너뛰는 등의 문제가 발생할 수 있습니다.

IDENTITY 열이 GENERATED ALWAYS AS IDENTITY인 싱크 테이블

IDENTITY 열이 GENERATED ALWAYS AS IDENTITY로 생성된 싱크 테이블을 고려해 보십시오. 데이터 임포트는 소스가 구성 파일의 IDENTITY 열 및 ignoreFields 변환 매개변수에 값을 제공하는지 여부에 따라 달라집니다.

예를 들어, JSON 파일 소스에서 Oracle NoSQL Database 테이블로 데이터를 싱크로 임포트할 수 있습니다. 싱크 테이블의 스키마는 다음과 같습니다. 

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED ALWAYS AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))
Migrator 유틸리티는 다음과 같은 경우에 설명된 대로 데이터 마이그레이션을 처리합니다.
소스 조건 사용자 작업 마이그레이션 결과

사례 1: 소스 데이터는 싱크 테이블의 IDENTITY 필드에 대한 값을 제공하지 않습니다.

예: JSON 소스 파일 sample_noID.json

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

구성 파일을 생성/생성합니다.

데이터 마이그레이션에 성공했습니다. IDENTITY 열 값은 자동 생성됩니다. Oracle NoSQL Database 싱크 테이블 migrateID에서 마이그레이션된 데이터: 

{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"John","course":"Computer Science"}
{"ID":1002,"name":"Tony","course":"Electronics"}

사례 2: 소스 데이터는 싱크 테이블의 IDENTITY 필드에 대한 값을 제공합니다.

예: JSON 소스 파일 sampleID.json

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

구성 파일을 생성/생성합니다. 싱크 구성 템플리트의 ID 열에 대해 ignoreFields 변환을 제공합니다.

"transforms" : { "ignoreFields" : ["ID"] }

데이터 마이그레이션에 성공했습니다. 제공된 ID 값은 건너뛰고 IDENTITY 열 값은 자동 생성됩니다.

Oracle NoSQL Database 싱크 테이블 migrateID에서 마이그레이션된 데이터:
{"ID":2003,"name":"John","course":"Computer Science"}
{"ID":2002,"name":"Tony","course":"Electronics"}
{"ID":2001,"name":"Jane","course":"BioTechnology"}

IDENTITY 열에 대해 ignoreFields 변환 없이 구성 파일을 생성/생성합니다.

데이터 마이그레이션이 실패하고 다음 오류 메시지가 표시됩니다.

"Cannot set value for a generated always identity column".

변환 구성 매개변수에 대한 자세한 내용은 변환 구성 템플리트 항목을 참조하십시오.

IDENTITY 열이 GENERATED BY DEFAULT AS IDENTITY인 싱크 테이블

IDENTITY 열이 GENERATED BY DEFAULT AS IDENTITY로 생성된 싱크 테이블을 고려해 보십시오. 데이터 임포트는 소스가 IDENTITY 열 및 ignoreFields 변환 매개변수에 값을 제공하는지 여부에 따라 달라집니다.

예를 들어, JSON 파일 소스에서 Oracle NoSQL Database 테이블로 데이터를 싱크로 임포트할 수 있습니다. 싱크 테이블의 스키마는 다음과 같습니다. 

CREATE TABLE IF NOT EXISTS migrateID(ID INTEGER GENERATED BY DEFAULT AS IDENTITY, name STRING, course STRING, PRIMARY KEY
      (ID))
Migrator 유틸리티는 다음과 같은 경우에 설명된 대로 데이터 마이그레이션을 처리합니다.
소스 조건 사용자 작업 마이그레이션 결과

사례 1: 소스 데이터는 싱크 테이블의 IDENTITY 필드에 대한 값을 제공하지 않습니다.

예: JSON 소스 파일 sample_noID.json

{"name":"John", "course":"Computer Science"}
{"name":"Jane", "course":"BioTechnology"}
{"name":"Tony", "course":"Electronics"}

구성 파일을 생성/생성합니다.
데이터 마이그레이션에 성공했습니다. IDENTITY 열 값은 자동 생성됩니다. Oracle NoSQL Database 싱크 테이블 migrateID에서 마이그레이션된 데이터:
{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}

사례 2: 소스 데이터는 싱크 테이블의 IDENTITY 필드에 대한 값을 제공하며 기본 키 필드입니다.

예: JSON 소스 파일 sampleID.json

{"ID":1, "name":"John", "course":"Computer Science"}
{"ID":2, "name":"Jane", "course":"BioTechnology"}
{"ID":3, "name":"Tony", "course":"Electronics"}

구성 파일을 생성/생성합니다. 싱크 구성 템플리트(권장)에서 ID 열에 대해 ignoreFields 변환을 제공합니다.

"transforms" : { "ignoreFields" : ["ID"] }

데이터 마이그레이션에 성공했습니다. 제공된 ID 값은 건너뛰고 IDENTITY 열 값은 자동 생성됩니다.

Oracle NoSQL Database 싱크 테이블 migrateID에서 마이그레이션된 데이터:
{"ID":1002,"name":"John","course":"Computer Science"}
{"ID":1001,"name":"Jane","course":"BioTechnology"}
{"ID":1003,"name":"Tony","course":"Electronics"}

IDENTITY 열에 대해 ignoreFields 변환 없이 구성 파일을 생성/생성합니다.

데이터 마이그레이션에 성공했습니다. 소스에서 제공된 ID 값은 싱크 테이블의 ID 열로 복사됩니다.

ID 값을 제공하지 않고 테이블에 추가 행을 삽입하려고 하면 시퀀스 생성기는 ID 값을 자동으로 생성하려고 시도합니다. 시퀀스 생성기의 시작 값은 1입니다. 따라서 생성된 ID 값은 싱크 테이블의 기존 ID 값 중 하나를 복제할 수 있습니다. 이것은 Primary Key 제약 조건을 위반하므로 오류가 반환되고 행이 삽입되지 않습니다.

자세한 내용은 순서 생성기를 참조하십시오.

기본 키 제약 조건 위반을 방지하려면 시퀀스 생성기가 싱크 테이블의 기존 ID 값과 충돌하지 않는 값으로 시퀀스를 시작해야 합니다. START WITH 속성을 사용하여 수정하려면 아래 예를 참조하십시오.

예: Oracle NoSQL Database 싱크 테이블의 마이그레이션된 데이터 migrateID:
{"ID":1,"name":"John","course":"Computer Science"}
{"ID":2,"name":"Jane","course":"BioTechnology"}
{"ID":3,"name":"Tony","course":"Electronics"}
ID 열에 삽입할 시퀀스 생성기에 적합한 값을 찾으려면 다음 질의를 사용하여 ID 필드의 최대값을 인출합니다.
SELECT max(ID) FROM migrateID
출력: 
{"Column_1":3}
싱크 테이블에 있는 ID 열의 최대값은 3입니다. 중복을 피하기 위해 시퀀스 생성기에서 ID 값을 3 이상으로 생성하려고 합니다. 다음 명령문을 사용하여 시퀀스 생성기의 START WITH 속성을 4로 갱신합니다.
ALTER Table migrateID (MODIFY ID GENERATED BY DEFAULT AS IDENTITY (START WITH 4))

그러면 시퀀스가 4에서 시작됩니다.

이제 ID 값을 제공하지 않고 싱크 테이블에 행을 삽입하면 시퀀스 생성기는 ID 중복을 뒤집어 4부터 ID 값을 자동으로 생성합니다.

변환 구성 매개변수에 대한 자세한 내용은 변환 구성 템플리트 항목을 참조하십시오.

runMigrator 명령을 실행합니다.

runMigrator 실행 파일은 추출된 NoSQL Database Migrator 파일에서 사용할 수 있습니다. runMigrator 명령을 성공적으로 실행하려면 Java 11 이상 버전 및 bash를 시스템에 설치해야 합니다.

runMigrator 명령은 다음 두 가지 방법으로 실행할 수 있습니다.
  1. 아래와 같이 runMigrator 명령의 런타임 옵션을 사용하여 구성 파일을 생성합니다. 
    [~]$ ./runMigrator
configuration file is not provided. Do you want to generate configuration? (y/n)                                                                              
 
[n]: y
...
...
    • runMigrator 유틸리티를 호출하면 일련의 런타임 옵션이 제공되며 각 옵션에 대한 선택사항에 따라 구성 파일이 생성됩니다.
    • 유틸리티가 구성 파일을 만든 후 동일한 실행에서 마이그레이션 작업을 계속하거나 이후 마이그레이션을 위해 구성 파일을 저장할 수 있습니다.
    • 생성된 구성 파일을 사용하여 마이그레이션 작업을 진행하거나 지연하기로 결정했는지에 관계없이 이후 요구 사항에 맞게 파일을 편집 또는 사용자 정의할 수 있습니다. 나중에 마이그레이션을 위해 사용자 정의된 구성 파일을 사용할 수 있습니다.
  2. -c 또는 --config 옵션을 사용하여 수동으로 생성된 구성 파일(JSON 형식)을 런타임 매개변수로 전달합니다. -c 또는 --config 옵션을 사용하여 runMigrator 명령을 실행하기 전에 구성 파일을 수동으로 생성해야 합니다. 소스 및 싱크 구성 매개변수에 대한 도움말은 Oracle NoSQL Database Migrator Reference를 참조하십시오.
    [~]$ ./runMigrator -c </path/to/the/configuration/json/file>

주:

NoSQL Database Migrator는 Oracle NoSQL Cloud Service 테이블에서 유효한 싱크로 데이터를 내보내는 동안 읽기 단위를 사용합니다.

로깅 마이그레이터 진행률

NoSQL 데이터베이스 마이그레이터 툴은 추적, 디버깅 및 진행률 메시지를 표준 출력 또는 파일에 인쇄할 수 있는 옵션을 제공합니다. 이 옵션은 특히 매우 큰 테이블이나 데이터 집합의 이전 작업 진행 상황을 추적하는 데 유용할 수 있습니다.

  • 로그 레벨

    NoSQL Database Migrator 도구를 통해 로깅 동작을 제어하려면 --log-level 또는 -l 런타임 매개변수를 runMigrator 명령에 전달합니다. 적절한 로그 레벨 값을 전달하여 기록할 로그 정보의 양을 지정할 수 있습니다. 

    $./runMigrator --log-level <loglevel>
    예제:
    $./runMigrator --log-level debug

    표 - NoSQL Database Migrator에 대해 지원되는 로그 레벨

    로그 레벨 설명
    경고 오류 및 경고를 인쇄합니다.
    정보(default) 소스 검증, 싱크 검증, 테이블 생성, 이전된 데이터 레코드 수와 같은 데이터 이전 진행 상태를 인쇄합니다.
    debug 추가 디버그 정보를 인쇄합니다.
    모두 모든 것을 인쇄합니다. 이 레벨은 모든 로깅 레벨을 설정합니다.
  • 로그 파일:
    --log-file 또는 -f 매개변수를 사용하여 로그 파일의 이름을 지정할 수 있습니다. --log-file가 runMigrator 명령에 런타임 매개변수로 전달되면 NoSQL Database Migrator는 모든 로그 메시지를 표준 출력에 기록합니다.
    $./runMigrator --log-file <log file name>
    예제:
    $./runMigrator --log-file nosql_migrator.log

Oracle NoSQL Database Migrator를 위한 사용 사례 데모

특정 사용 사례에 대해 Oracle NoSQL Database Migrator를 사용하여 데이터 마이그레이션을 수행하는 방법을 알아봅니다. 각 사용 사례에서 마이그레이션을 수행하기 위한 코드 예제가 포함된 자세한 체계적인 지침을 찾을 수 있습니다.

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

Oracle NoSQL Database Cloud Service에서 JSON 파일로 마이그레이션

이 예에서는 Oracle NoSQL Database Migrator를 사용하여 Oracle NoSQL Database Cloud Service(NDCS)에서 JSON 파일로 NoSQL 테이블의 데이터 및 스키마 정의를 복사하는 방법을 보여 줍니다.

사용 사례

조직은 Oracle NoSQL Database Cloud Service(NDCS) 데이터를 사용하여 향후 행동을 예측하고 개인화된 권장사항을 제공하는 모델을 교육하기로 결정합니다. NDCS 테이블 데이터의 정기적 복사본을 JSON 파일로 가져와서 분석 엔진에 적용하여 모델을 분석하고 교육할 수 있습니다. 이렇게 하면 분석 쿼리를 지연 시간이 짧은 중요 경로와 분리하는 데 도움이 됩니다.

예

데모에서는 myTable라는 NoSQL 테이블의 데이터 및 스키마 정의를 NDCS에서 JSON 파일로 마이그레이션하는 방법을 살펴보겠습니다.
필요 조건
  • 마이그레이션에 대한 소스 및 싱크를 식별합니다.
    • 출처: Oracle NoSQL Database Cloud Service
    • 싱크: JSON 파일
  • OCI 클라우드 인증서를 식별하고 OCI 구성 파일에서 캡처합니다. /home/.oci/config에 구성 파일을 저장합니다. 인증서 취득을 참조하십시오.
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Service의 리전 엔드포인트 및 구획 이름을 식별합니다.
    • 끝점: us-phoenix-1
    • 구획: developers
절차
myTable의 데이터 및 스키마 정의를 Oracle NoSQL Database Cloud Service에서 JSON 파일로 마이그레이션하려면 다음을 수행합니다.
  1. 명령 프롬프트를 열고 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  2. NoSQL 데이터베이스 마이그레이터를 사용하여 구성 파일을 생성하려면 런타임 매개변수 없이 runMigrator 명령을 실행하십시오.
    [~/nosqlMigrator]$./runMigrator
  3. 구성 파일을 런타임 매개변수로 제공하지 않았으므로 지금 구성을 생성할지 묻는 메시지가 표시됩니다. y를 입력합니다.
    Configuration file is not provided. Do you want to generate
configuration? (y/n) [n]: y

Generating a configuration file interactively.
  4. 유틸리티의 프롬프트에 따라 소스 구성에 대한 옵션을 선택합니다.
    Enter a location for your config [./migrator-config.json]: /home/<user>/nosqlMigrator/NDCS2JSON
Select the source: 
1) nosqldb
2) nosqldb_cloud
3) file
4) object_storage_oci
5) aws_s3
#? 2

Configuration for source type=nosqldb_cloud
Enter endpoint URL or region ID of the Oracle NoSQL Database Cloud: us-phoenix-1
Select the authentication type: 
1) credentials_file
2) instance_principal
3) delegation_token
#? 1
Enter path to the file containing OCI credentials [/home/<user>/.oci/config]:
Enter the profile name in OCI credentials file [DEFAULT]: 
Enter the compartment name or id of the table []: developers
Enter table name: myTable
Include TTL data? If you select 'yes' TTL of rows will also 
be included in the exported data.(y/n) [n]: 
Enter percentage of table read units to be used for migration operation. (1-100) [90]:
Enter store operation timeout in milliseconds. (1-30000) [5000]:
  5. 유틸리티의 프롬프트에 따라 Sink 구성에 대한 옵션을 선택합니다. 
    Select the sink:
1) nosqldb
2) nosqldb_cloud
3) file
#? 3
Configuration for sink type=file
Enter path to a directory to store JSON data: /home/<user>/nosqlMigrator
would you like to export data to multiple files for each source?(y/n) [y]: n
Would you like to store JSON in pretty format? (y/n) [n]: y
Would you like to migrate the table schema also? (y/n) [y]: y
Enter path to a file to store table schema: /home/<user>/nosqlMigrator/myTableSchema
  6. 유틸리티의 프롬프트에 따라 소스 데이터 변환 옵션을 선택합니다. 기본값은 n입니다.
    Would you like to add transformations to source data? (y/n) [n]:
  7. 레코드 마이그레이션에 실패한 경우 마이그레이션을 계속할지 여부를 결정하려면 선택 항목을 입력합니다.
    Would you like to continue migration in case of any record/row is failed to migrate?: (y/n) [n]:
  8. 유틸리티가 생성된 구성을 화면에 표시합니다. 
    generated configuration is:
{
  "source": {
    "type": "nosqldb_cloud",
    "endpoint": "us-phoenix-1",
    "table": "myTable",
    "compartment": "developers",
    "credentials": "/home/<user>/.oci/config",
    "credentialsProfile": "DEFAULT",
    "readUnitsPercent": 90,
    "requestTimeoutMs": 5000
  },
  "sink": {
    "type": "file",
    "format": "json",
    "useMultiFiles" : false,
    "schemaPath": "/home/<user>/nosqlMigrator/myTableSchema",
    "pretty": true,
    "dataPath": "/home/<user>/nosqlMigrator"
  },
  "abortOnError": true,
  "migratorVersion": "1.6.5"
}
  9. 마지막으로 유틸리티는 생성된 구성 파일을 사용하여 마이그레이션을 계속할지 여부를 결정하라는 메시지를 표시합니다. 기본 옵션은 y입니다.

    주:

    n을 선택하는 경우 생성된 구성 파일을 사용하여 ./runMigrator -c 또는 ./runMigrator --config 옵션을 사용하여 마이그레이션을 실행할 수 있습니다. 
    would you like to run the migration with above configuration?
If you select no, you can use the generated configuration file to run the migration using
./runMigrator --config /home/<user>/nosqlMigrator/NDCS2JSON
(y/n) [y]:
  10. NoSQL 데이터베이스 마이그레이터는 NDCS에서 JSON 파일로 데이터 및 스키마를 이전합니다.
    Records provided by source=10,Records written to sink=10,Records failed=0,Records skipped=0.
Elapsed time: 0min 1sec 277ms
Migration completed.
검증

마이그레이션을 검증하기 위해 지정된 싱크 디렉토리로 이동하여 스키마 및 데이터를 볼 수 있습니다. 

-- Exported myTable Data. JSON files are created in the supplied data path
 
[~/nosqlMigrator]$cat myTable_1_5.json
{
  "id" : 10,
  "document" : {
    "course" : "Computer Science",
    "name" : "Neena",
    "studentid" : 105
  }
}
{
  "id" : 3,
  "document" : {
  "course" : "Computer Science",
    "name" : "John",
    "studentid" : 107
  }
}
{
  "id" : 4,
  "document" : {
    "course" : "Computer Science",
    "name" : "Ruby",
    "studentid" : 100
  }
}
{
  "id" : 6,
  "document" : {
    "course" : "Bio-Technology",
    "name" : "Rekha",
    "studentid" : 104
  }
}
{
  "id" : 7,
  "document" : {
    "course" : "Computer Science",
    "name" : "Ruby",
    "studentid" : 100
  }
}
{
  "id" : 5,
  "document" : {
    "course" : "Journalism",
    "name" : "Rani",
    "studentid" : 106
  }
}
{
  "id" : 8,
  "document" : {
    "course" : "Computer Science",
    "name" : "Tom",
    "studentid" : 103
  }
}
{
  "id" : 9,
  "document" : {
    "course" : "Computer Science",
    "name" : "Peter",
    "studentid" : 109
  }
}
{
  "id" : 1,
  "document" : {
    "course" : "Journalism",
    "name" : "Tracy",
    "studentid" : 110
  }
}
{
  "id" : 2,
  "document" : {
    "course" : "Bio-Technology",
    "name" : "Raja",
    "studentid" : 108
  }
}
-- Exported myTable Schema
 
[~/nosqlMigrator]$cat myTableSchema
CREATE TABLE IF NOT EXISTS myTable (id INTEGER, document JSON, PRIMARY KEY(SHARD(id)))

Oracle NoSQL Database 온프레미스에서 Oracle NoSQL Database Cloud Service로 마이그레이션

이 예에서는 Oracle NoSQL Database Migrator를 사용하여 Oracle NoSQL Database에서 Oracle NoSQL Database Cloud Service(NDCS)로 NoSQL 테이블의 데이터 및 스키마 정의를 복사하는 방법을 보여 줍니다.

사용 사례

개발자는 기존 NoSQL 데이터베이스 KVStore 작업 로드에 대한 리소스, 클러스터 및 가비지 수집 관리 오버헤드를 방지하기 위한 옵션을 살펴봅니다. NDCS는 기존 온프레미스 KVStore 워크로드를 자동으로 관리하므로 솔루션을 통해 기존 온프레미스 KVStore 워크로드를 Oracle NoSQL Database Cloud Service로 마이그레이션하려고 합니다.

예

데모를 위해 NoSQL Database KVStore에서 NDCS로 myTable라는 NoSQL 테이블의 데이터 및 스키마 정의를 마이그레이션하는 방법을 살펴보겠습니다. 또한 이 사용 사례를 사용하여 미리 생성된 구성 파일을 전달하여 runMigrator 유틸리티를 실행하는 방법을 보여 줍니다.
필요 조건
  • 마이그레이션에 대한 소스 및 싱크를 식별합니다.
    • 소스: Oracle NoSQL Database
    • 싱크: Oracle NoSQL Database Cloud Service
  • OCI 클라우드 인증서를 식별하고 OCI 구성 파일에서 캡처합니다. /home/.oci/config에 구성 파일을 저장합니다. Oracle NoSQL Database Cloud Service 사용의 인증서 취득을 참조하십시오.
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Service의 리전 엔드포인트 및 구획 이름을 식별합니다.
    • 끝점: us-phoenix-1
    • 구획: developers
  • 온프레미스 KVStore에 대해 다음 세부정보를 식별합니다.
    • storeName: kvstore
    • helperHosts: <hostname>:5000
    • 테이블: myTable
절차
myTable의 데이터 및 스키마 정의를 NoSQL Database KVStore에서 NDCS로 이전하려면 다음을 수행합니다.
  1. 구성 파일(JSON 형식)을 식별된 소스 및 싱크 세부 정보로 준비합니다. Source Configuration Templates 및 Sink Configuration Templates를 참조하십시오.
    {
  "source" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "myTable",
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "myTable",
    "compartment" : "developers",
    "schemaInfo" : {
      "schemaPath" : "<complete/path/to/the/JSON/file/with/DDL/commands/for/the/schema/definition>",
      "readUnits" : 100,
      "writeUnits" : 100,
      "storageSize" : 1
    },
    "credentials" : "<complete/path/to/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.0.0"
}
  2. 명령 프롬프트를 열고 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  3. --config 또는 -c 옵션을 사용하여 구성 파일을 전달하여 runMigrator 명령을 실행합니다.
    [~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. 이 유틸리티는 아래와 같이 데이터 마이그레이션을 진행합니다.
    Records provided by source=10, Records written to sink=10, Records failed=0.
Elapsed time: 0min 10sec 426ms
Migration completed.
검증

마이그레이션을 검증하기 위해 NDCS 콘솔에 로그인하여 소스 데이터로 myTable가 생성되었는지 확인할 수 있습니다.

JSON 파일 소스에서 Oracle NoSQL Database Cloud Service로 마이그레이션

이 예에서는 Oracle NoSQL Database Migrator를 사용하여 JSON 파일 소스의 데이터를 Oracle NoSQL Database Cloud Service로 복사하는 방법을 보여줍니다.

여러 옵션을 평가한 후 조직은 Oracle NoSQL Database Cloud Service를 NoSQL 데이터베이스 플랫폼으로 완성합니다. 소스 콘텐츠는 JSON 파일 형식이므로 Oracle NoSQL Database Cloud Service로 마이그레이션할 방법을 찾고 있습니다.

이 예에서는 SampleData.json이라는 JSON 파일에서 데이터를 마이그레이션하는 방법을 알아봅니다. 미리 생성된 구성 파일을 전달하여 runMigrator 유틸리티를 실행합니다. 구성 파일이 런타임 매개변수로 제공되지 않은 경우 runMigrator 유틸리티는 대화식 절차를 통해 구성을 생성하라는 메시지를 표시합니다.

필요 조건
  • 마이그레이션에 대한 소스 및 싱크를 식별합니다.
    • 출처: JSON 출처 파일.
      SampleData.json는 소스 파일입니다. 행당 하나의 문서가 포함된 여러 JSON 문서가 새 행 문자로 구분되어 포함되어 있습니다.
      {"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-03-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-02T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-02T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-02T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":7,"val_json":{"array":["a","b","c"],"date":"2023-02-20T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-01-20T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-01-22T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":4,"val_json":{"array":["j","k","l"],"date":"2023-02-03T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-03T02:38:57.520Z","numfield":28,"strfield":"foo"},{"datefield":"2023-02-03T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
    • 싱크: Oracle NoSQL Database Cloud Service.
  • OCI 클라우드 인증서를 식별하고 구성 파일에서 캡처합니다. /home/user/.oci/config에 구성 파일을 저장합니다. 자세한 내용은 Oracle NoSQL Database Cloud Service 사용의 인증서 취득을 참조하십시오.
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Service의 리전 엔드포인트 및 구획 이름을 식별합니다.
    • 끝점: us-ashburn-1
    • 구획: Training-NoSQL
  • JSON 소스 파일에 대해 다음 세부정보를 식별합니다.

    • schemaPath: <absolute path to the schema definition file containing DDL statements for the NoSQL table at the sink>.

      이 예제에서 DDL 파일은 schema_json.ddl입니다.
      create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY
    KEY(id));

      Oracle NoSQL Database Migrator는 schemaPath가 제공되지 않은 경우 기본 스키마로 테이블을 생성하는 옵션을 제공합니다. 자세한 내용은 Oracle NoSQL Database Migrator 워크플로의 소스 및 싱크 식별 항목을 참고하세요.

    • 데이터 경로: <absolute path to a file or directory containing the JSON data for migration>.
절차
JSON 소스 파일을 SampleData.json에서 Oracle NoSQL Database Cloud Service로 마이그레이션하려면 다음을 수행합니다.
  1. 구성 파일(JSON 형식)을 식별된 소스 및 싱크 세부정보로 준비합니다. 소스 구성 템플리트 및 싱크 구성 템플리트를 참조하십시오.
    {
  "source" : {
    "type" : "file",
    "format" : "json",
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.5.0]/schema_json.ddl"
    },
    "dataPath" : "[~/nosql-migrator-1.5.0]/SampleData.json"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "Migrate_JSON",
    "compartment" : "Training-NoSQL",
    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "/home/user/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.5.0"
}
  2. 명령 프롬프트를 열고 Oracle NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  3. --config 또는 -c 옵션을 사용하여 구성 파일을 전달하여 runMigrator 명령을 실행합니다.
    [~/nosql-migrator-1.5.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. 이 유틸리티는 아래와 같이 데이터 마이그레이션을 진행합니다. Migrate_JSON 테이블은 schemaPath에 제공된 스키마를 사용하여 싱크에 생성됩니다.
    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: create table Migrate_JSON (id INTEGER, val_json JSON, PRIMARY KEY(id)),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
[cloud sink] : start loading records
[json file source] : start parsing JSON records from file: SampleData.json
[INFO] migration completed.
Records provided by source=4, Records written to sink=4, Records failed=0, Records skipped=0.
Elapsed time: 0min 5sec 778ms
Migration completed.
검증
마이그레이션을 검증하기 위해 Oracle NoSQL Database Cloud Service 콘솔에 로그인하여 소스 데이터로 Migrate_JSON 테이블이 생성되었는지 확인할 수 있습니다. 콘솔에 액세스하는 절차는 Oracle NoSQL Database Cloud Service 문서의 Infrastructure 콘솔에서 서비스 액세스 문서를 참조하십시오.

그림 - Oracle NoSQL Database Cloud Service 콘솔 테이블


다음은 그림 -에 대한 설명입니다.
"그림 - Oracle NoSQL Database Cloud Service 콘솔 테이블"에 대한 설명

그림 - Oracle NoSQL Database Cloud Service 콘솔 테이블 데이터


다음은 그림 -에 대한 설명입니다.
"그림 - Oracle NoSQL Database Cloud Service 콘솔 테이블 데이터"에 대한 설명

MongoDB JSON 파일에서 Oracle NoSQL Database Cloud Service로 마이그레이션

이 예에서는 Oracle NoSQL Database Migrator를 사용하여 Mongo-DB 포맷 데이터를 Oracle NoSQL Database Cloud Service(NDCS)로 복사하는 방법을 보여 줍니다.

사용 사례

여러 옵션을 평가한 후 조직은 Oracle NoSQL Database Cloud Service를 NoSQL 데이터베이스 플랫폼으로 완성합니다. NoSQL 테이블과 데이터는 MongoDB에 있으므로 해당 테이블과 데이터를 Oracle NDCS로 이전하는 방법을 찾고 있습니다.

소스 구성 템플리트에 파일 또는 디렉토리를 지정하여 이전을 위해 MongoDB 익스포트된 JSON 데이터가 포함된 파일 또는 디렉토리를 복사할 수 있습니다.

샘플 MongoDB 형식 JSON 파일은 다음과 같습니다.
{"_id":0,"name":"Aimee Zank","scores":[{"score":1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}

MongoDB는 JSON 파일 형식에 대한 두 가지 유형의 확장인 정식 모드 및 완화 모드를 지원합니다. Canonical 또는 Relaxed 모드에서 mongoexport 도구를 사용하여 생성된 MongoDB 형식 JSON 파일을 제공할 수 있습니다. 두 모드 모두 마이그레이션을 위해 NoSQL Database Migrator에서 지원됩니다.

MongoDB 확장 JSON(v2) 파일에 대한 자세한 내용은 mongoexport_formats을 참조하십시오.

MongoDB 형식 JSON 파일 생성에 대한 자세한 내용은 mongoexport를 참조하십시오.

예

데모를 위해 MongoDB 형식의 JSON 파일을 NDCS로 마이그레이션하는 방법을 살펴보겠습니다. 이 예에서는 수동으로 만든 구성 파일을 사용합니다.
필요 조건
  • 마이그레이션에 대한 소스 및 싱크를 식별합니다.
    • 출처: MongoDB-형식 JSON 파일
    • 싱크: Oracle NoSQL Database Cloud Service
  • mongoexport 유틸리티를 사용하여 Mongo DB에서 데이터를 추출합니다. 자세한 내용은 mongoexport를 참조하십시오.
  • Mongo-DB 형식 JSON 파일의 데이터와 일치하는 테이블 스키마가 있는 싱크대에 NoSQL 테이블을 생성합니다. 또는 defaultSchema 속성을 true로 설정하여 기본 스키마 구조로 테이블을 생성하도록 NoSQL 데이터베이스 이전자에 지시할 수 있습니다.

    주:

    MongoDB 형식이 지정된 JSON 소스의 경우 테이블의 기본 스키마는 다음과 같습니다.
    CREATE TABLE IF NOT EXISTS <tablename>(ID STRING, DOCUMENT JSON,PRIMARY KEY(SHARD(ID))
    설명:
    • tablename = 테이블 구성 값입니다.
    • ID = mongoDB에서 익스포트된 JSON 소스 파일의 _id 값입니다.
    • DOCUMENT = mongoDB 익스포트된 JSON 소스 파일의 전체 콘텐츠가 _id 필드를 제외한 DOCUMENT 열로 집계됩니다.
  • OCI 클라우드 인증서를 식별하고 OCI 구성 파일에서 캡처합니다. 구성 파일을 /home/.oci/config에 저장합니다. Oracle NoSQL Database Cloud Service 사용의 인증서 취득을 참조하십시오.
    [DEFAULT]
tenancy=ocid1.tenancy.oc1....
user=ocid1.user.oc1....
fingerprint= 43:d1:....
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=<passphrase>
  • Oracle NoSQL Database Cloud Service의 리전 엔드포인트 및 구획 이름을 식별합니다.
    • 끝점: us-phoenix-1
    • 구획: developers
절차

MongoDB 형식 JSON 데이터를 Oracle NoSQL Database Cloud Service로 마이그레이션하려면 다음을 수행합니다.

  1. 구성 파일(JSON 형식)을 식별된 소스 및 싱크 세부정보와 함께 준비합니다. 소스 구성 템플리트 및 싱크 구성 템플리트를 참조하십시오.
    {
  "source" : {
    "type" : "file",
    "format" : "mongodb_json",
    "dataPath" : "<complete/path/to/the/MongoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "mongoImport",
    "compartment" : "developers",
    "schemaInfo" : {
      "defaultSchema" : true,
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1
    },
    "credentials" : "<complete/path/to/the/oci/config/file>",
    "credentialsProfile" : "DEFAULT",
    "writeUnitsPercent" : 90,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.0.0"
}
  2. 명령 프롬프트를 열고 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  3. --config 또는 -c 옵션을 사용하여 구성 파일을 전달하여 runMigrator 명령을 실행합니다.
    [~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. 이 유틸리티는 아래와 같이 데이터 마이그레이션을 진행합니다.
    Records provided by source=29,353, Records written to sink=29,353, Records failed=0.
Elapsed time: 9min 9sec 630ms
Migration completed.
검증

마이그레이션을 검증하기 위해 NDCS 콘솔에 로그인하여 소스 데이터로 myTable가 생성되었는지 확인할 수 있습니다.

DynamoDB JSON 파일에서 Oracle NoSQL Database로 마이그레이션

이 예에서는 Oracle NoSQL Database Migrator를 사용하여 DynamoDB JSON 파일을 NoSQL Database로 복사하는 방법을 보여줍니다.

사용 사례:

여러 옵션을 평가한 후 조직은 DynamoDB 데이터베이스를 통해 Oracle NoSQL Database를 완성합니다. 조직은 테이블과 데이터를 DynamoDB에서 Oracle NoSQL Database(온프레미스)로 이전하려고 합니다.

자세한 내용은 DynamoDB 테이블을 Oracle NoSQL 테이블에 매핑을 참조하십시오.

소스 구성 템플리트에 경로를 지정하여 파일 시스템에서 DynamoDB 익스포트된 JSON 데이터를 포함하는 파일 또는 디렉토리를 이전할 수 있습니다.

샘플 DynamoDB 형식 JSON 파일은 다음과 같습니다.
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}

내보낸 DynamoDB 테이블 데이터를 AWS S3 스토리지에서 로컬 마운트된 파일 시스템으로 복사합니다.

예제:

이 데모에서는 DynamoDB JSON 파일을 Oracle NoSQL Database(온프레미스)로 마이그레이션하는 방법을 알아봅니다. 이 예에서는 수동으로 만든 구성 파일을 사용합니다.

필요 조건

  • 마이그레이션에 대한 소스 및 싱크를 식별합니다.
    • 출처: DynamoDB JSON 파일
    • 싱크: Oracle NoSQL Database(온프레미스)
  • DynamoDB 테이블 데이터를 Oracle NoSQL Database로 임포트하려면 먼저 DynamoDB 테이블을 S3로 익스포트해야 합니다. 테이블을 익스포트하려면 Amazon S3에 DynamoDB 테이블 데이터 익스포트에 제공된 단계를 참조하십시오. 익스포트하는 동안 형식을 DynamoDB JSON으로 선택합니다. 익스포트된 데이터는 아래와 같이 여러 gzip 파일에 DynamoDB 테이블 데이터를 포함합니다.
    / 01639372501551-bb4dd8c3 
|-- 01639372501551-bb4dd8c3 ==> exported data prefix
|----data
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data
|----manifest-files.json
|----manifest-files.md5
|----manifest-summary.json
|----manifest-summary.md5
|----_started
  • AWS S3에서 파일을 다운로드해야 합니다. 다운로드 후 파일의 구조는 아래와 같습니다.
    download-dir/01639372501551-bb4dd8c3     
|----data    
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data   
|----manifest-files.json   
|----manifest-files.md5   
|----manifest-summary.json   
|----manifest-summary.md5   
|----_started

절차

DynamoDB JSON 데이터를 Oracle NoSQL Database로 이전하려면 다음과 같이 하십시오.
  1. 식별된 소스 및 싱크 세부정보를 사용하여 구성 파일(JSON 형식)을 준비합니다. 자세한 내용은 Source Configuration Templates 및 Sink Configuration Templates를 참조하십시오.

    주:

    DynamoDB에서 익스포트한 JSON 테이블 항목에 TTL 속성이 포함된 경우 선택적으로 TTL 값을 임포트하려면 소스 구성 템플리트의 ttlAttributeName 구성 매개변수에 속성을 지정하고 싱크 구성 템플리트에서 includeTTL 구성 매개변수를 true로 설정합니다.
    다음 두 가지 옵션 중 하나를 선택할 수 있습니다.
    • 옵션 1: 기본 스키마 구성을 사용하여 DynamoDB 테이블을 JSON 문서로 임포트하는 중입니다.

      여기서 defaultSchema 구성 매개변수를 true로 설정합니다. 따라서 NoSQL Database Migrator는 싱크에 기본 스키마를 만듭니다. DDBPartitionKey 및 해당 NoSQL 열 유형을 지정해야 합니다. 그렇지 않은 경우 오류가 표시됩니다.

      DynamoDB 익스포트된 JSON 소스의 기본 스키마에 대한 자세한 내용은 Oracle NoSQL Database Migrator용 워크플로우의 소스 및 싱크 식별 항목을 참조하십시오. 
      {
  "source" : {
    "type" : "file",
    "format" : "dynamodb_json",
    "ttlAttributeName" : "ttl",
    "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "sampledynDBImp",
    "includeTTL" : true,
    "schemaInfo" : {
      "DDBPartitionKey" : "Id:INTEGER",
      "defaultSchema" : true
    },
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.6.5"
}
      이 예에서는 다음 기본 스키마가 사용됩니다.
      CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
    • 옵션 2: 사용자가 제공한 스키마 파일을 사용하여 DynamoDB 테이블을 고정 열로 임포트합니다.

      여기서 defaultSchema 구성 매개변수를 false로 설정합니다. 따라서 schemaPath 매개변수에 싱크 테이블의 DDL 문을 포함하는 파일을 지정합니다. 자세한 내용은 DynamoDB 유형을 Oracle NoSQL 유형에 매핑을 참조하십시오.

      이 예에서는 다음 사용자 정의 스키마가 사용됩니다.
      CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))

      NoSQL Database Migrator는 스키마 파일을 사용하여 마이그레이션의 일부로 싱크에 테이블을 만듭니다. 기본 키 데이터가 제공된 경우 입력 JSON 레코드가 삽입됩니다. 그렇지 않은 경우 오류가 표시됩니다.

      주:

      • Dynamo DB 테이블에 NoSQL 데이터베이스에서 지원되지 않는 데이터 유형이 있으면 마이그레이션이 실패합니다.
      • 입력 데이터에 기본 키가 아닌 특정 열에 대한 값이 포함되어 있지 않으면 열 기본값이 사용됩니다. 기본값은 테이블을 생성하는 동안 열 정의의 일부여야 합니다. 예: id INTEGER not null default 0. 열에 기본 정의가 없으면 열에 대한 값이 제공되지 않으면 SQL NULL이 삽입됩니다.
      • DynamoDB 테이블을 JSON 문서로 모델링하는 경우 AggregateFields 변환을 사용하여 비기본 키 데이터를 JSON 열로 집계해야 합니다. 자세한 내용은 aggregateFields을 참조하십시오. 
      {
  "source" : {
    "type" : "file",
    "format" : "dynamodb_json",
    "ttlAttributeName" : "ttl",
    "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>"
  },
  "sink" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "sampledynDBImp",
    "includeTTL" : true,
    "schemaInfo" : {
      "schemaPath" : "<full path of the schema file with the DDL statement>"
    },
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "transforms": {
    "aggregateFields" : {
      "fieldName" : "document",
      "skipFields" : ["Id"]
    }
  },
  "abortOnError" : true,
  "migratorVersion" : "1.6.5"
}
  2. 명령 프롬프트를 열고 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  3. 옵션 1 및 2에 대해 별도의 구성 파일을 전달하여 runMigrator 명령을 실행합니다. --config 또는 -c 옵션을 사용합니다.
    ./runMigrator --config <complete/path/to/the/JSON/config/file>
  4. 이 유틸리티는 다음 샘플에 설명된 대로 데이터 마이그레이션을 진행합니다.
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [nosqldb sink] : start loading DDLs
[INFO] [nosqldb sink] : executing DDL: CREATE TABLE IF NOT EXISTS sampledynDBImp (Id INTEGER, document JSON, PRIMARY KEY(SHARD(Id)))
[INFO] [nosqldb sink] : completed loading DDLs
[INFO] migration started
[INFO] Start writing data to OnDB Sink
[INFO] executing for source:DynamoSample
[INFO] [DDB file source] : start parsing JSON records from file: DynamoSample.json.gz
[INFO] Writing data to OnDB Sink completed.
[INFO] migration completed.
Records provided by source=2, Records written to sink=2, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 45ms
Migration completed.

검증

데이터 저장소에서 SQL 프롬프트를 시작합니다.
 java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
새 테이블이 소스 데이터로 생성되었는지 확인합니다.
SELECT * FROM sampledynDBImp

출력

TTL 정보는 가져온 각 항목의 _metadata JSON 객체에 포함됩니다.
{"Id":102,"document":{"Address":{"City":"Wales","DoorNum":1024,"Street":"32 main","Zip":560014},"Age":48,"FavColors":["Blue"],"FavNumbers":[10],"FirstName":"John","LastName":"White","Phones":[["222-222"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}
{"Id":101,"document":{"Address":{"City":"London","DoorNum":201,"Street":"21 main","Zip":570004},"Age":22,"FavColors":["Red","Green"],"FavNumbers":[10],"FirstName":"Fred","LastName":"Smith","Phones":[["555-222","123-567"]],"PremierCustomer":false,"_metadata":{"expiration":1734616196000}}}

AWS S3의 DynamoDB JSON 파일에서 Oracle NoSQL Database Cloud Service로 마이그레이션

이 예에서는 Oracle NoSQL Database Migrator를 사용해 AWS S3 저장소에 저장된 DynamoDB JSON 파일을 Oracle NoSQL Database Cloud Service(NDCS)로 복사하는 방법을 보여줍니다.

사용 사례:

여러 옵션을 평가한 후 조직은 DynamoDB 데이터베이스보다 Oracle NoSQL Database Cloud Service를 완성합니다. 이 조직은 테이블 및 데이터를 DynamoDB에서 Oracle NoSQL Database Cloud Service로 마이그레이션하려고 합니다.

자세한 내용은 DynamoDB 테이블을 Oracle NoSQL 테이블에 매핑을 참조하십시오.

소스 구성 템플리트에 경로를 지정하여 AWS S3 스토리지에서 DynamoDB 익스포트된 JSON 데이터를 포함하는 파일을 이전할 수 있습니다.

샘플 DynamoDB 형식 JSON 파일은 다음과 같습니다.
{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"}}}

DynamoDB 테이블 데이터를 Amazon S3로 익스포트에 지정된 대로 DynamoDB 테이블을 AWS S3 스토리지로 익스포트합니다.

예제:

이 데모에서는 AWS S3 소스의 DynamoDB JSON 파일을 NDCS로 마이그레이션하는 방법을 알아봅니다. 이 예에서는 수동으로 만든 구성 파일을 사용합니다.

필요 조건

  • 마이그레이션에 대한 소스 및 싱크를 식별합니다.
    • 출처: DynamoDB AWS의 JSON 파일 S3
    • 싱크: Oracle NoSQL Database Cloud Service
  • AWS DynamoDB에서 NDCS로 마이그레이션해야 하는 테이블을 식별합니다. 사용자의 인증서를 사용하여 AWS 콘솔에 로그인합니다. DynamoDB으로 이동합니다. 테이블에서 마이그레이션할 테이블을 선택합니다.
  • 객체 버킷을 생성하고 테이블을 S3로 엑스포트합니다. AWS 콘솔에서 S3으로 이동합니다. 버킷에서 새 객체 버킷을 생성합니다. DynamoDB로 돌아가서 S3로 익스포트를 누릅니다. 소스 테이블과 대상 S3 버킷을 제공하고 익스포트를 누릅니다.
    테이블을 익스포트하려면 DynamoDB 테이블 데이터를 Amazon S3로 익스포트에 제공된 단계를 참조하십시오. 익스포트하는 동안 형식을 DynamoDB JSON으로 선택합니다. 익스포트된 데이터는 아래와 같이 여러 gzip 파일에 DynamoDB 테이블 데이터를 포함합니다.
    / 01639372501551-bb4dd8c3 
|-- 01639372501551-bb4dd8c3 ==> exported data prefix
|----data
|------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz  ==>table data
|----manifest-files.json
|----manifest-files.md5
|----manifest-summary.json
|----manifest-summary.md5
|----_started
  • 마이그레이션기에서 AWS S3에 액세스하려면 aws 자격 증명(액세스 키 ID 및 암호 액세스 키 포함) 및 구성 파일(인증서 및 선택적으로 구성)이 필요합니다. 구성 파일에 대한 자세한 내용은 구성 설정 설정 및 보기를 참조하십시오. 액세스 키 생성에 대한 자세한 내용은 키 쌍 생성을 참조하십시오.
  • OCI 클라우드 인증서를 식별하고 OCI 구성 파일에서 캡처합니다. 구성 파일을 홈 디렉토리(~/.oci/config) 아래의 .oci 디렉토리에 저장합니다. 자세한 내용은 인증서 취득을 참조하십시오. 
    [DEFAULT]              
tenancy=ocid1.tenancy.oc1....         
user=ocid1.user.oc1....         
fingerprint= 43:d1:....         
key_file=</fully/qualified/path/to/the/private/key/>              
pass_phrase=<passphrase>
  • Oracle NoSQL Database의 리전 엔드포인트 및 구획 이름을 식별합니다. 예를 들어 다음과 같습니다.
    • 끝점: us-phoenix-1
    • 구획: 개발자

절차

DynamoDB JSON 데이터를 Oracle NoSQL Database로 마이그레이션하려면 다음을 수행합니다.
  1. 식별된 소스 및 싱크 세부정보를 사용하여 구성 파일(JSON 형식)을 준비합니다. 자세한 내용은 Source Configuration Templates 및 Sink Configuration Templates를 참조하십시오.

    주:

    AWS S3의 DynamoDB JSON 파일에 있는 항목에 TTL 속성이 포함된 경우 선택적으로 TTL 값을 임포트하려면 소스 구성 템플리트의 ttlAttributeName 구성 매개변수에 속성을 지정하고 싱크 구성 템플리트에서 includeTTL 구성 매개변수를 true로 설정합니다. 자세한 내용은 테이블 행에 대한 TTL 메타데이터 이전을 참조하십시오.
    다음 두 가지 옵션 중 하나를 선택할 수 있습니다.
    • 옵션 1: 기본 스키마 구성을 사용하여 DynamoDB 테이블을 JSON 문서로 임포트하는 중입니다.
      여기서 defaultSchema는 TRUE이므로 migrator는 싱크대에 기본 스키마를 만듭니다. DDBPartitionKey 및 해당 NoSQL 열 유형을 지정해야 합니다. 그렇지 않은 경우 오류가 발생합니다.
      {
 "source" : {
   "type" : "aws_s3",
   "format" : "dynamodb_json",
   "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>",
   "credentials" : "</path/to/aws/credentials/file>",
   "credentialsProfile" : <"profile name in aws credentials file">
 },
 "sink" : {
   "type" : "nosqldb_cloud",
   "endpoint" : "<region_name>",
   "table" : "<table_name>",
   "compartment" : "<compartment_name>",
   "schemaInfo" : {
      "defaultSchema" : true,
      "readUnits" : 100,
      "writeUnits" : 60,
      "DDBPartitionKey" : "<PrimaryKey:Datatype>",
      "storageSize" : 1
   },
   "credentials" : "<complete/path/to/the/oci/config/file>",
   "credentialsProfile" : "DEFAULT",
   "writeUnitsPercent" : 90,
   "requestTimeoutMs" : 5000
 },
 "abortOnError" : true,
 "migratorVersion" : "1.6.5"
}
      DynamoDB JSON 소스의 경우 테이블의 기본 스키마는 아래와 같습니다.
      CREATE TABLE IF NOT EXISTS <TABLE_NAME>(DDBPartitionKey_name DDBPartitionKey_type, 
[DDBSortKey_name DDBSortKey_type], DOCUMENT JSON, 
PRIMARY KEY(SHARD(DDBPartitionKey_name),[DDBSortKey_name]))

      위치

      TABLE_NAME = 구성의 싱크 'table'에 대해 제공된 값

      DDBPartitionKey_name = 구성에서 분할 영역 키에 대해 제공된 값

      DDBPartitionKey_type = 구성에서 분할 영역 키의 데이터 유형에 대해 제공된 값

      DDBSortKey_name = 구성의 정렬 키에 대해 제공된 값(있는 경우)

      DDBSortKey_type = 구성에서 정렬 키의 데이터 유형에 대해 제공된 값(있는 경우)

      DOCUMENT = NoSQL JSON 열로 집계된 Dynamo DB 테이블 항목의 분할 영역 및 정렬 키를 제외한 모든 속성

    • 옵션 2: 사용자가 제공한 스키마 파일을 사용하여 DynamoDB 테이블을 고정 열로 임포트합니다.
      여기서 defaultSchema는 FALSE이고 schemaPath를 DDL 문을 포함하는 파일로 지정합니다. 자세한 내용은 DynamoDB 유형을 Oracle NoSQL 유형에 매핑을 참조하십시오.

      주:

      Dynamo DB 테이블의 데이터 유형이 NoSQL에서 지원되지 않는 경우 마이그레이션이 실패합니다.
      다음은 예제 스키마 파일입니다.
      CREATE TABLE IF NOT EXISTS sampledynDBImp (AccountId INTEGER,document JSON, 
PRIMARY KEY(SHARD(AccountId)));
      스키마 파일은 이전 과정에서 싱크대에 테이블을 생성하는 데 사용됩니다. 기본 키 데이터가 제공되는 한 입력 JSON 레코드가 삽입되고, 그렇지 않으면 오류가 발생합니다.

      주:

      • 입력 데이터에 Primary Key 이외의 특정 열에 대한 값이 포함되지 않은 경우 열 기본값이 사용됩니다. 테이블 생성 시 기본값은 열 정의의 일부여야 합니다. 예: id INTEGER not null default 0. 열에 기본 정의가 없으면 열에 값이 제공되지 않으면 SQL NULL이 삽입됩니다.
      • DynamoDB 테이블을 JSON 문서로 모델링하는 경우 AggregateFields 변환을 사용하여 비기본 키 데이터를 JSON 열로 집계해야 합니다. 자세한 내용은 aggregateFields을 참조하십시오. 
      {
 "source" : {
   "type" : "aws_s3",
   "format" : "dynamodb_json",
   "s3URL" : "<https://<bucket-name>.<s3_endpoint>/export_path>",
   "credentials" : "</path/to/aws/credentials/file>",
   "credentialsProfile" : <"profile name in aws credentials file">
 },
 "sink" : {
   "type" : "nosqldb_cloud",
   "endpoint" : "<region_name>",
   "table" : "<table_name>",
   "compartment" : "<compartment_name>",
   "schemaInfo" : {
      "defaultSchema" : false,
      "readUnits" : 100,
      "writeUnits" : 60,
      "schemaPath" : "<full path of the schema file with the DDL statement>",
      "storageSize" : 1
   },
   "credentials" : "<complete/path/to/the/oci/config/file>",
   "credentialsProfile" : "DEFAULT",
   "writeUnitsPercent" : 90,
   "requestTimeoutMs" : 5000
 },
  "transforms": {
    "aggregateFields" : {
      "fieldName" : "document",
      "skipFields" : ["AccountId"]
    }
  },
 "abortOnError" : true,
 "migratorVersion" : "1.6.5"
}
  2. 명령 프롬프트를 열고 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  3. --config 또는 -c 옵션을 사용하여 구성 파일을 전달하여 runMigrator 명령을 실행합니다.
    [~/nosqlMigrator]$./runMigrator 
--config <complete/path/to/the/JSON/config/file>
  4. 이 유틸리티는 아래와 같이 데이터 마이그레이션을 진행합니다.
    Records provided by source=7..,
Records written to sink=7,
Records failed=0,
Records skipped=0.
Elapsed time: 0 min 2sec 50ms
Migration completed.

검증

NDCS 콘솔에 로그인하여 새 테이블이 소스 데이터로 생성되었는지 확인할 수 있습니다.

Oracle NoSQL Database Cloud Service 지역 간 마이그레이션

이 예에서는 Oracle NoSQL Database Migrator를 사용하여 영역 간 마이그레이션을 수행하는 방법을 보여 줍니다.

사용 사례

조직은 Oracle NoSQL Database Cloud Service를 사용하여 데이터를 저장하고 관리합니다. 운용 환경에서 새 영역을 실행하기 전에 테스트 목적으로 기존 영역에서 최신 영역으로 데이터를 복제하기로 결정합니다.

이 사용 사례에서는 NoSQL Database Migrator를 사용하여 애슈번 지역의 user_data 테이블에서 피닉스 영역으로 데이터를 복사하는 방법을 알아봅니다.

미리 생성된 구성 파일을 전달하여 runMigrator 유틸리티를 실행합니다. 구성 파일을 런타임 매개변수로 제공하지 않으면 runMigrator 유틸리티가 대화식 절차를 통해 구성을 생성하라는 메시지를 표시합니다.

필요 조건
  • Oracle NoSQL Database Migrator를 Oracle NoSQL Downloads 페이지에서 다운로드하여 컴퓨터로 컨텐츠를 추출합니다. 자세한 내용은 Oracle NoSQL Database Migrator 워크플로를 참고하세요.
  • 마이그레이션에 대한 소스 및 싱크를 식별합니다.
    • 출처: 애슈번 지역의 user_data 테이블입니다.
      user_data 테이블에는 다음 데이터가 포함됩니다. 
      {"id":40,"firstName":"Joanna","lastName":"Smith","otherNames":[{"first":"Joanna","last":"Smart"}],"age":null,"income":75000,"address":{"city":"Houston","number":401,"phones":[{"area":null,"kind":"work","number":1618955},{"area":451,"kind":"home","number":4613341},{"area":481,"kind":"mobile","number":4613382}],"state":"TX","street":"Tex Ave","zip":95085},"connections":[70,30,40],"email":"joanna.smith123@reachmail.com","communityService":"**"}

{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"Good"},{"first":"Johny2","last":"Brave"},{"first":"Johny3","last":"Kind"},{"first":"Johny4","last":"Humble"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"email":"john.smith@reachmail.com","communityService":"****"}

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"BeGood"}],"age":22,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"email":"jane.smith201@reachmail.com","communityService":"*****"}

{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"BeGood"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"email":"adam.smith201reachmail.com","communityService":"***"}
      소스의 영역 끝점 또는 서비스 끝점 및 구획 이름을 식별합니다.
      • 끝점: us-ashburn-1
      • 구획: ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya
    • 싱크: 피닉스 영역의 user_data 테이블입니다.
      싱크의 영역 끝점 또는 서비스 끝점과 구획 이름을 식별합니다.
      • 끝점: us-phoenix-1
      • 구획: ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma

      싱크 테이블 스키마를 식별합니다.

      소스 테이블과 동일한 테이블 이름과 스키마를 사용할 수 있습니다. 기타 스키마 옵션에 대한 자세한 내용은 Oracle NoSQL Database Migrator 워크플로의 소스 및 싱크 식별 항목을 참조하십시오.

  • 두 지역에 대한 OCI 클라우드 인증서를 식별하고 구성 파일에서 캡처합니다. 시스템의 /home/<user>/.oci/config 위치에 구성 파일을 저장합니다. 자세한 내용은 인증서 취득을 참조하십시오.

주:

  • 리전이 서로 다른 테넌시에 속하는 경우 /home/<user>/.oci/config 파일에서 각 테넌시에 적합한 OCI 클라우드 인증서를 사용하여 서로 다른 프로파일을 제공해야 합니다.
  • 영역이 동일한 테넌시에 속하는 경우 /home/<user>/.oci/config 파일에 단일 프로파일을 가질 수 있습니다.

이 예에서는 영역이 서로 다른 테넌시에 속합니다. DEFAULT 프로파일에는 애슈번 지역에 대한 OCI 인증서가 포함되며 DEFAULT2에는 피닉스 지역에 대한 OCI 인증서가 포함됩니다.

마이그레이터 구성 파일 endpoint 매개변수(소스 및 싱크 구성 템플리트)에서 서비스 끝점 URL 또는 영역의 영역 ID를 제공할 수 있습니다. Oracle NoSQL Database Cloud Service에 대해 지원되는 데이터 지역 목록 및 해당 서비스 엔드포인트 URL은 Oracle NoSQL Database Cloud Service 문서의 데이터 지역 및 연관된 서비스 URL을 참조하십시오.
[DEFAULT]
user=ocid1.user.oc1....
fingerprint=fd:96:....
tenancy=ocid1.tenancy.oc1....
region=us-ashburn-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=abcd


[DEFAULT2]
user=ocid1.user.oc1....
fingerprint=1b:68:....
tenancy=ocid1.tenancy.oc1....
region=us-phoenix-1
key_file=</fully/qualified/path/to/the/private/key/>
pass_phrase=23456
절차
user_data 테이블을 애슈번 영역에서 피닉스 영역으로 마이그레이션하려면 다음을 수행합니다.
  1. 구성 파일(JSON 형식)을 식별된 소스 및 싱크 세부정보로 준비합니다. 소스 구성 템플리트 및 싱크 구성 템플리트를 참조하십시오.
    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "user_data",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT",
    "readUnitsPercent" : 100,
    "includeTTL" : false,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-phoenix-1",
    "table" : "user_data",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma",
    "includeTTL" : false,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "credentials" : "/home/<user>/.oci/config",
    "credentialsProfile" : "DEFAULT2",
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.5.0"
}
  2. 시스템에서 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다. 명령줄 인터페이스에서 runMigrator 명령에 액세스할 수 있습니다.
  3. --config 또는 -c 옵션을 사용하여 구성 파일을 전달하여 runMigrator 명령을 실행합니다.
    [~/nosql-migrator-1.5.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. 이 유틸리티는 아래와 같이 데이터 마이그레이션을 진행합니다. user_data 테이블은 싱크 구성 템플리트에서 useSourceSchema 매개변수를 true로 구성한 것과 동일한 스키마를 사용하여 싱크에 생성됩니다. 
    creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[cloud sink] : start loading DDLs
[cloud sink] : executing DDL: CREATE TABLE IF NOT EXISTS user_data (id INTEGER, firstName STRING, lastName STRING, otherNames ARRAY(RECORD(first STRING, last STRING)), age INTEGER, income INTEGER, address JSON, connections ARRAY(INTEGER), email STRING, communityService STRING, PRIMARY KEY(SHARD(id))),limits: [100, 60, 1]
[cloud sink] : completed loading DDLs
[cloud sink] : start loading records
migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
Elapsed time: 0min 5sec 603ms
Migration completed.

    주:

    • 테이블이 소스 테이블과 스키마가 동일한 싱크에 존재하는 경우 구성 템플리트에서 overwrite 매개변수를 true로 제공했으므로 기본 키가 동일한 행을 겹쳐씁니다.
    • 소스 테이블과 스키마가 다른 싱크에 테이블이 이미 있는 경우 마이그레이션이 실패합니다.
검증

마이그레이션을 검증하려면 피닉스 지역의 Oracle NoSQL Database Cloud Service 콘솔에 로그인하면 됩니다. 애슈번 영역에 있는 user_data 테이블의 소스 데이터가 이 영역의 user_data 테이블에 복사되었는지 확인합니다. 콘솔에 액세스하는 절차는 Infrastructure 콘솔에서 서비스 액세스 문서를 참조하십시오.

Oracle NoSQL Database Cloud Service에서 OCI Object Storage로 마이그레이션하기

이 예에서는 Cloud Shell에서 Oracle NoSQL Database Migrator를 사용하는 방법을 보여줍니다.

사용 사례

스타트업 벤처 기업은 Oracle NoSQL Database Cloud Service를 데이터 스토리지 솔루션으로 사용할 계획입니다. 이 회사는 Oracle NoSQL Database Migrator를 사용해 Oracle NoSQL Database Cloud Service의 테이블에서 OCI Object Storage로 데이터를 복사하여 데이터를 정기적으로 백업하고자 합니다. 비용 효율적인 방법으로 모든 OCI 사용자가 액세스할 수 있는 Cloud Shell에서 NoSQL Database Migrator 유틸리티를 실행하려고 합니다.

이 사용 사례에서는 구독된 지역의 Cloud Shell에 NoSQL Database Migrator 유틸리티를 복사하고 데이터 마이그레이션을 수행하는 방법을 알아봅니다. Oracle NoSQL Database Cloud Service 테이블에서 OCI Object Storage의 JSON 파일로 소스 데이터를 마이그레이션합니다.

미리 생성된 구성 파일을 전달하여 runMigrator 유틸리티를 실행합니다. 구성 파일을 런타임 매개변수로 제공하지 않으면 runMigrator 유틸리티가 대화식 절차를 통해 구성을 생성하라는 메시지를 표시합니다.

필요 조건
  • Oracle NoSQL Database Migrator를 Oracle NoSQL Downloads 페이지에서 로컬 시스템으로 다운로드합니다.
  • 클라우드 콘솔의 개발자 툴 메뉴에서 Cloud Shell을 실행합니다. 웹 브라우저가 홈 디렉토리를 엽니다. Cloud Shell 창의 오른쪽 상단에 있는 Cloud Shell 메뉴를 누르고 드롭다운에서 업로드 옵션을 선택합니다. 팝업 창의 로컬 시스템에서 Oracle NoSQL Database Migrator 패키지를 끌어 놓거나, 컴퓨터에서 선택 옵션을 누르고 로컬 시스템에서 패키지를 선택하고 업로드 단추를 누릅니다. 로컬 시스템에서 Cloud Shell의 홈 디렉토리로 직접 Oracle NoSQL Database Migrator 패키지를 끌어 놓을 수도 있습니다. 패키지의 컨텐츠를 추출합니다.
  • 백업의 소스 및 싱크를 식별합니다.

    • 출처: Oracle NoSQL Database Cloud Service 애슈번 지역의 NDCSupload 테이블

      데모의 경우 NDCSupload 테이블에서 다음 데이터를 고려하십시오.
      {"id":1,"name":"Jane Smith","email":"iamjane@somemail.co.us","age":30,"income":30000.0}
{"id":2,"name":"Adam Smith","email":"adam.smith@mymail.com","age":25,"income":25000.0}
{"id":3,"name":"Jennifer Smith","email":"jenny1_smith@mymail.com","age":35,"income":35000.0}
{"id":4,"name":"Noelle Smith","email":"noel21@somemail.co.us","age":40,"income":40000.0}

      소스의 끝점 및 구획 ID를 식별합니다. 끝점에 대해 영역 식별자 또는 서비스 끝점을 제공할 수 있습니다. Oracle NoSQL Database Cloud Service에서 지원되는 데이터 지역 목록은 데이터 지역 및 연관된 서비스 URL을 참조하십시오.

      • 끝점: us-ashburn-1
      • 구획 ID: ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya

    • Sink: OCI Object Storage 버킷의 JSON 파일입니다.

      OCI Object Storage에 대한 리전 엔드포인트, 네임스페이스, 버킷 및 접두어를 식별합니다. 자세한 내용은 Oracle Cloud Object Storage 액세스를 참조하십시오. OCI Object Storage 서비스 엔드포인트 목록은 Object Storage Endpoints를 참조하십시오.

      • 끝점: us-ashburn-1
      • 버킷: Migrate_oci
      • 접두어: Delegation
      • namespace: <> 네임스페이스를 제공하지 않으면 유틸리티에서 테넌시의 기본 네임스페이스를 사용합니다.

      주:

      오브젝트 스토리지 버킷이 다른 컴파트먼트에 있는 경우 버킷에 오브젝트를 쓸 수 있는 권한이 있는지 확인하십시오. 정책 설정에 대한 자세한 내용은 오브젝트 스토리지의 객체 쓰기를 참조하십시오.
절차
NDCSupload 테이블을 Oracle NoSQL Database Cloud Service에서 Cloud Shell을 사용하여 OCI Object Storage 버킷의 JSON 파일로 백업하려면 다음을 수행합니다.
  1. 구성 파일(JSON 형식)을 식별된 소스 및 싱크 세부정보로 준비합니다. 소스 구성 템플리트 및 싱크 구성 템플리트를 참조하십시오. 소스 및 싱크 구성 템플리트에서 useDelegationToken 매개변수를 true로 설정했는지 확인합니다.
    이 사용 사례에서는 다음과 같은 구성 템플리트가 사용됩니다.
    {
  "source" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "NDCSupload",
    "compartment" : "ocid1.compartment.oc1..aaaaaaaahcrgrgptoaq4cgpoymd32ti2ql4sdpu5puroausdf4og55z4tnya",
    "useDelegationToken" : true,
    "readUnitsPercent" : 90,
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "",
    "bucket" : "Migrate_oci",
    "prefix" : "Delegation",
    "chunkSize" : 32,
    "compression" : "",
    "useDelegationToken" : true
  },
  "abortOnError" : true,
  "migratorVersion" : "1.6.0"
}
  2. Cloud Shell에서 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  3. --config 또는 -c 옵션을 사용하여 구성 파일을 전달하여 runMigrator 명령을 실행합니다.
    [~/nosql-migrator-1.6.0]$./runMigrator --config <complete/path/to/the/config/file>
  4. NoSQL Database Migrator 유틸리티는 데이터 마이그레이션을 계속합니다. useDelegationToken 매개변수를 true로 설정했으므로 Cloud Shell은 NoSQL Database Migrator 유틸리티를 실행하는 동안 위임 토큰을 사용하여 자동으로 인증을 수행합니다. NoSQL 데이터베이스 마이그레이터는 NDCSupload 테이블의 데이터를 오브젝트 스토리지 버킷 Migrate_oci의 JSON 파일로 복사합니다. 로그에서 성공적인 데이터 백업을 확인합니다.
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] migration started
[INFO] [OCI OS sink] : writing table schema to Delegation/Schema/schema.ddl
[INFO] [OCI OS sink] : start writing records with prefix Delegation
[INFO] migration completed.
Records provided by source=4,Records written to sink=4,Records failed=0.
Elapsed time: 0min 0sec 486ms
Migration completed.

    주:

    데이터가 파일에 복사됨: Migrate_oci/NDCSupload/Delegation/Data/000000.json

    싱크 구성 템플리트의 chunkSize 매개변수에 따라 소스 데이터를 동일한 디렉토리에 있는 여러 JSON 파일로 분할할 수 있습니다.

    스키마가 Migrate_oci/NDCStable1/Delegation/Schema/schema.ddl 파일로 복사됩니다.

검증

데이터 백업을 검증하려면 Oracle NoSQL Database Cloud Service 콘솔에 로그인합니다. Storage > Object Storage & Archive Storage > Buckets 메뉴를 탐색합니다. Migrate_oci 버킷의 NDCSupload/Delegation 디렉토리에서 파일에 액세스합니다. 콘솔에 액세스하는 절차는 Infrastructure 콘솔에서 서비스 액세스 문서를 참조하십시오.

OKE 인증을 사용하여 OCI Object Storage에서 Oracle NoSQL Database Cloud Service로 마이그레이션

이 예에서는 OKE 워크로드 ID 인증과 함께 Oracle NoSQL Database Migrator를 사용하여 OCI Object Storage의 JSON 파일에서 Oracle NoSQL Database Cloud Service 테이블로 데이터를 복사하는 방법을 보여줍니다.

사용 사례

개발자는 컨테이너화된 애플리케이션에서 NoSQL Database Migrator를 사용하여 OCI OS(OCI Object Storage) 버킷의 JSON 파일에서 Oracle NoSQL Database Cloud Service(NDCS) 테이블로 데이터를 복원하는 옵션을 탐색합니다. 컨테이너화된 애플리케이션은 패키지의 애플리케이션 및 모든 종속성(예: 라이브러리, 바이너리 및 구성 파일)을 번들로 제공하는 가상화된 환경입니다. 이를 통해 기본 인프라에 관계없이 다양한 환경에서 애플리케이션을 일관되게 실행할 수 있습니다.

Oracle Cloud Infrastructure Container Engine for Kubernetes(OKE) Pod 내에서 NoSQL Database Migrator를 실행하려고 합니다. OKE Pod에서 OCI OS 및 NDCS 서비스에 안전하게 액세스하려면 WIA(작업 로드 ID 인증) 방법을 사용합니다.

이 데모에서는 NoSQL Database Migrator용 도커 이미지를 빌드하고, 컨테이너 레지스트리의 저장소에 이미지를 복사하고, OKE 클러스터를 생성하고, OKE 클러스터 포드에 Migrator 이미지를 배치하여 Migrator 유틸리티를 실행합니다. 여기서 Migrator 유틸리티를 컨테이너화된 애플리케이션으로 실행하기 위해 수동으로 생성된 NoSQL Database Migrator 구성 파일을 제공합니다.

필요 조건
  • 마이그레이션에 대한 소스 및 싱크를 식별합니다.
    • 소스: OCI OS 버킷의 JSON 파일 및 스키마 파일입니다.
      소스 JSON 파일 및 스키마를 사용할 수 있는 OCI OS 버킷의 영역 끝점, 네임스페이스, 버킷 및 접두어를 식별합니다. 자세한 내용은 Oracle Cloud Object Storage 액세스를 참조하십시오. OCI OS 서비스 끝점 목록은 오브젝트 스토리지 끝점을 참조하십시오.
      • 엔드포인트: us-ashburn-1
      • 물통: Migrate_oci
      • 접두어: userSession
      • 네임스페이스: idhkv1iewjzj
        버킷의 네임스페이스 이름은 테넌시의 네임스페이스와 동일하며 테넌시가 생성될 때 자동 생성됩니다. 네임스페이스 이름은 다음과 같이 가져올 수 있습니다.
        • Oracle NoSQL Database Cloud Service 콘솔에서 스토리지> 버킷으로 이동합니다.
        • 목록 범위에서 구획을 선택하고 버킷을 선택합니다. 버킷 세부정보 페이지에는 네임스페이스 매개변수에 이름이 표시됩니다.

        OCI OS 네임스페이스 이름을 제공하지 않을 경우 Migrator 유틸리티는 테넌시의 기본 네임스페이스를 사용합니다.

    • 싱크: Oracle NoSQL Database Cloud Service의 users 테이블.

      영역 끝점 또는 서비스 끝점과 싱크의 컴파트먼트 이름을 식별합니다.

      • 엔드포인트: us-ashburn-1
      • 구획: ocid1.compartment.oc1..aaaaaaaaleiwplazhwmicoogv3tf4lum4m4nzbcv5wfjmoxuz3doreagvdma

      싱크 테이블 스키마를 식별합니다.

      OCI OS 버킷에 저장된 테이블 이름 및 스키마를 사용하려면 useSourceSchema 매개변수를 true로 설정합니다. 다른 스키마 옵션에 대한 자세한 내용은 Oracle NoSQL Database Migrator에 대한 워크플로우의 소스 및 싱크 식별 항목을 참조하십시오.

      주:

      NDCS 테이블로 데이터를 복원할 컴파트먼트에 대한 쓰기 권한이 있는지 확인합니다. 자세한 내용은 구획 관리를 참조하십시오..
  • NoSQL Database Migrator에 대한 Docker 이미지를 준비하고 컨테이너 레지스트리로 이동합니다.
    1. OCI 콘솔에서 테넌시 네임스페이스를 가져옵니다.

      Oracle NoSQL Database Cloud Service 콘솔에 로그인합니다. 탐색 표시줄에서 프로파일 메뉴를 선택한 다음 테넌시: <테나니 이름>을 선택합니다.

      테넌시 네임스페이스인 오브젝트 스토리지 네임스페이스 이름을 클립보드에 복사합니다.

    2. Migrator 유틸리티에 대한 Docker 이미지를 빌드합니다.
      NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다. 마이그레이션기 패키지에는 Dockerfile이라는 도커 파일이 포함되어 있습니다. 명령 인터페이스에서 다음 명령을 사용하여 Migrator 유틸리티의 Docker 이미지를 작성합니다. 
      #Command:
docker build -t nosqlmigrator:<tag> .
      #Example:
docker build -t nosqlmigrator:1.0 .
      tag 옵션에서 Docker 이미지에 대한 버전 식별자를 지정할 수 있습니다. 다음 명령을 사용하여 Docker 이미지를 확인합니다.
      #Command:
Docker images
      #Example output
------------------------------------------------------------------------------------------

REPOSITORY                 TAG          IMAGE ID         CREATED         SIZE
localhost/nosqlmigrator    1.0          e1dcec27a5cc     10 seconds ago  487 MB
quay.io/podman/hello       latest       83fc7ce1224f     10 months ago   580 kB
docker.io/library/openjdk  17-jdk-slim  8a3a2ffec52a     2 years ago     406 MB

------------------------------------------------------------------------------------------
    3. 권한 부여 토큰을 생성합니다.

      Migrator Docker 이미지를 저장하려면 컨테이너 레지스트리에 로그인하려면 인증 토큰이 필요합니다. 인증 토큰이 아직 없는 경우 생성해야 합니다. 자세한 내용은 인증 토큰 가져오기를 참조하십시오.

    4. 컨테이너 레지스트리에 마이그레이션자 Docker 이미지를 저장합니다.

      Kubernetes Pod에서 Migrator Docker 이미지에 액세스하려면 이미지를 퍼블릭 또는 프라이빗 레지스트리에 저장해야 합니다. 예를 들어, Docker, Artifact Hub, OCI Container Registry 등은 몇 가지 레지스트리입니다. 이 데모에서는 컨테이너 레지스트리를 사용합니다. 자세한 내용은 컨테이너 레지스트리 개요를 참조하십시오.

      1. OCI 콘솔에서 컨테이너 레지스트리에 저장소를 생성합니다. 자세한 내용은 저장소 생성을(를) 참조하십시오.

        이 데모에서는 okemigrator 저장소를 만듭니다.

        그림 - 컨테이너 레지스트리의 저장소


        다음은 그림 -에 대한 설명입니다.
        "그림 - 컨테이너 레지스트리의 저장소"에 대한 설명

      2. 다음 명령을 사용하여 명령 인터페이스에서 컨테이너 레지스트리에 로그인합니다.
        #Command:
docker login <region-key>.ocir.io -u <tenancy-namespace>/<user name>password: <Auth token>
        #Example:
docker login iad.ocir.io -u idhx..xxwjzj/rx..xxxxh@oracle.com
password: <Auth token>
        #Output:
Login Succeeded!

        위의 명령에서

        region-key: 컨테이너 레지스트리를 사용 중인 영역에 대한 키를 지정합니다. 자세한 내용은 지역별 가용성을 참조하십시오.

        tenancy-namespace: OCI 콘솔에서 복사한 테넌시 네임스페이스를 지정합니다.

        user name: OCI 콘솔 사용자 이름을 지정합니다.

        password: 인증 토큰을 지정합니다.

      3. 다음 명령을 사용하여 Migrator Docker 이미지에 태그를 지정하고 컨테이너 레지스트리로 푸시합니다.
        #Command:
docker tag <Migrator Docker image> <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>
docker push <region-key>.ocir.io/<tenancy-namespace>/<repo>:<tag>
        #Example:
docker tag localhost/nosqlmigrator:1.0 iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
docker push iad.ocir.io/idhx..xxwjzj/okemigrator:1.0

        위의 명령에서

        repo: 컨테이너 레지스트리에서 생성한 저장소의 이름을 지정합니다.

        tag: Docker 이미지에 대한 버전 식별자를 지정합니다. 

        #Output:
Getting image source signatures
Copying blob 0994dbbf9a1b done   | 
Copying blob 37849399aca1 done   | 
Copying blob 5f70bf18a086 done   | 
Copying blob 2f263e87cb11 done   | 
Copying blob f941f90e71a8 done   | 
Copying blob c82e5bf37b8a done   | 
Copying blob 2ad58b3543c5 done   | 
Copying blob 409bec9cdb8b done   | 
Copying config e1dcec27a5 done   | 
Writing manifest to image destination
  • WIA - NDCS 및 OCI OS로 OKE 클러스터를 구성합니다.
    1. OKE를 사용하여 Kubernetes 클러스터를 생성합니다.

      OCI 콘솔에서 OKE를 사용하여 네트워크 리소스의 가용성을 기반으로 Kubernetes 클러스터를 정의하고 생성합니다. Migrator 유틸리티를 컨테이너화된 애플리케이션으로 실행하려면 Kubernetes 클러스터가 필요합니다. 클러스터 생성 세부정보는 콘솔 워크플로우를 사용하여 Kubernetes 클러스터 생성을 참조하십시오.

      이 데모에서는 위 링크에 설명된 빠른 생성 워크플로우를 사용하여 단일 노드 관리 클러스터를 생성할 수 있습니다.

      그림 - 마이그레이션기 컨테이너용 Kubernetes 클러스터


      다음은 그림 -에 대한 설명입니다.
      "그림 - 마이그레이션기 컨테이너용 Kubernetes 클러스터" 설명

    2. OCI 콘솔에서 WIA를 설정하여 Kubernetes 클러스터의 다른 OCI 리소스에 액세스합니다.

      Kubernetes 클러스터 POD에서 실행되는 동안 NDCS 및 OCI OS 버킷에 Migrator 유틸리티 액세스 권한을 부여하려면 WIA를 설정해야 합니다. 다음 단계를 수행합니다.

      1. 클러스터의 kubeconfig 구성 파일을 설정합니다.
        • OCI 콘솔에서 생성한 Kubernetes 클러스터를 열고 클러스터 액세스 버튼을 누릅니다.
        • 클러스터 액세스 대화 상자에서 Cloud Shell 액세스를 누릅니다.
        • Cloud Shell 실행을 눌러 Cloud Shell 창을 표시합니다.
        • Oracle Cloud Infrastructure CLI 명령을 실행하여 kubeconfig 파일을 설정합니다. Access Your Cluster 대화 상자에서 명령을 복사할 수 있습니다. 예상되는 출력은 다음과 같습니다.
          #Example:  
oci ce cluster create-kubeconfig --cluster-id ocid1.cluster.oc1.iad.aaa...muqzq --file $HOME/.kube/config --region us-ashburn-1 --token-version 2.0.0  --kube-endpoint PUBLIC_ENDPOINT
          #Output:
New config written to the Kubeconfig file /home/<user>/.kube/config
      2. 위 명령의 cluster-id 옵션에서 클러스터의 OCID를 복사하고 추가 단계에서 사용할 수 있도록 저장합니다.
        ocid1.cluster.oc1.iad.aaa...muqzq
      3. Cloud Shell 창에서 다음 명령을 사용하여 Kubernetes 서비스 계정에 대한 네임스페이스를 생성합니다.
        #Command:
kubectl create namespace <namespace-name>
        #Example:
kubectl create namespace migrator
        #Output:
namespace/migrator created
      4. Cloud Shell 창에서 다음 명령을 사용하여 네임스페이스에 Migrator 애플리케이션에 대한 Kubernetes 서비스 계정을 생성합니다.
        #Command:
kubectl create serviceaccount <service-account-name> --namespace <namespace-name>
        #Example:
kubectl create serviceaccount migratorsa --namespace migrator
        #Output:
serviceaccount/migratorsa created
      5. OCI 콘솔에서 IAM 정책을 정의하여 워크로드가 Kubernetes 클러스터에서 OCI 리소스에 액세스할 수 있도록 합니다.

        OCI 콘솔에서 ID 및 보안 > ID > 정책 메뉴를 탐색합니다. nosql-family 및 object-family 리소스에 대한 액세스를 허용하려면 다음 정책을 생성합니다. 이전 단계의 클러스터, 네임스페이스 및 서비스 계정 값의 OCID를 사용합니다. 

        #Command:
Allow <subject> to <verb> <resource-type> in <location> where <conditions>
        #Example:
Allow any-user to manage nosql-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}

Allow any-user to manage object-family in compartment Training-NoSQL where all { request.principal.type = 'workload', request.principal.namespace = 'migrator', request.principal.service_account = 'migratorsa', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa2o6h5noeut7i4xr2bp4aohcc2ncozgvn3nny3uqu7cvp2rwmuqzq'}

        정책 생성에 대한 자세한 내용은 콘솔을 사용하여 정책 생성을 참조하십시오.

절차

OCI OS 버킷의 JSON 파일에서 NDCS 테이블로 이전하려면 Cloud Shell 창에서 다음을 수행합니다.

  1. OCI OS 소스 및 NDCS 싱크를 사용하여 Migrator 구성 파일 migrator-config.json을 준비합니다. 템플리트는 Source Configuration Templates 및 Sink Configuration Templates를 참조하십시오.

    OKE WIA를 사용하여 OCI OS 버킷 및 NDCS에 액세스하려면 소스 및 싱크 구성 템플리트 모두에서 useOKEWorkloadIdentity 매개변수를 true로 설정합니다. 여기서는 OCI OS 버킷의 스키마 DDL 파일에서 소스 스키마를 사용합니다. 따라서 싱크 구성 템플리트에서 useSourceSchema 매개변수를 true로 설정합니다.

    주:

    OKE WIA를 사용하는 동안에는 마이그레이션기 구성 파일을 대화식으로 생성할 수 없습니다. 소스 및 싱크 구성 템플리트를 참조하여 구성 파일을 수동으로 준비해야 합니다. 
    {
  "source" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "useOKEWorkloadIdentity" : true
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "compartment" : "Training-NoSQL",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "useOKEWorkloadIdentity" : true,
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
  2. 구성 맵 리소스(구성 맵)를 만들어 Kubernetes POD에서 런타임 시 migrator-config.json 구성 입력 파일을 Migrator 컨테이너로 전달합니다. 구성 맵은 컨테이너의 파일 시스템에 있는 Migrator 구성 파일을 마운트 볼륨으로 마운트합니다.
    #Command:
kubectl create configmap oci-migrator-config --from-file=<Migrator configuration file> -n <namespace-name>
    #Example:
kubectl create configmap oci-migrator-config --from-file=migrator-config.json -n migrator
    #Output:
configmap/oci-migrator-config created
  3. Container Registry에서 Kubernetes Pod로 Migrator Docker 이미지를 가져오는 동안 사용할 OCI 인증서가 포함된 Docker 레지스트리 암호를 생성합니다.
    #Command:
kubectl create secret docker-registry ocirsecret --docker-server=<region-key>.ocir.io --docker-username='tenancy-namespace/username' --docker-password='auth token' --docker-email='<user Email>' -n <namespace-name>
    #Example:
kubectl create secret docker-registry ocirsecret --docker-server=iad.ocir.io --docker-username='idhx..xxwjzj/rx..xxxxh@oracle.com' --docker-password='<Auth token>' --docker-email='rx..xxxxh@oracle.com' -n migrator
    #Output:
secret/ocirsecret created
  4. 마이그레이션자 Docker 이미지를 지정하는 데 사용할 매니페스트 파일을 만듭니다. 네임스페이스, Kubernetes 서비스 계정 이름, Docker 이미지 이름, Docker 레지스트리 보안 정보 및 구성 맵에 대한 이전 단계의 값을 제공해야 합니다. 다음 샘플 매니페스트 파일을 참조할 수 있습니다.
    #migrator-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nosql-migrator
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nosql-migrator
  template:
    metadata:
      labels:
        app: nosql-migrator
    spec:
      serviceAccountName: migratorsa
      automountServiceAccountToken: true
      containers:
        - name: nosqlmigrator
          image: iad.ocir.io/idhx..xxwjzj/okemigrator:1.0
          imagePullPolicy: Always
          args: ["--config", "/config/migrator-config.json", "--log-level", "DEBUG"]
          volumeMounts:
            - name: config-volume
              mountPath: /config  # Mount the file here
      imagePullSecrets:
        - name: ocirsecret
      volumes:
        - name: config-volume
          configMap:
            name: oci-migrator-config
  5. 다음 명령을 사용하여 Kubernetes POD에 Migrator Docker 이미지를 배포합니다. OKE는 Kubernetes 클러스터의 노드 중 하나에 있는 컨테이너에서 Migrator 유틸리티를 실행합니다.
    #Command:
kubectl create -f <manifest file> -n <namespace-name>
    #Example:
kubectl create -f migrator-deployment.yaml -n migrator
    #Output:
deployment.apps/nosql-migrator created
  6. 다음 명령을 사용하여 로그를 확인할 수 있습니다.
    1. Migrator 유틸리티가 실행 중인 Pod의 이름을 인출합니다.
      #Command:
kubectl get pods -n <namespace-name>
      #Example:
kubectl get pods -n migrator
      #Output:
NAME                            READY   STATUS    RESTARTS   AGE
nosql-migrator-ccdbf549-6sjjg   1/1     Running   0          56s
    2. Pod의 이름을 사용하여 Migrator 로그를 인출합니다.
      #Command:
kubectl logs -f <kubernetes cluster pod name> -n <namespace-name>
      #Example:
kubectl logs -f nosql-migrator-ccdbf549-6sjjg -n migrator
      #Output:
SLF4J(I): Connected with provider of type [org.apache.logging.slf4j.SLF4JServiceProvider]
[INFO] Configuration for migration:
{
  "source" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "idhkv1iewjzj",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "useOKEWorkloadIdentity" : true
  },
  "sink" : {
    "type" : "nosqldb_cloud",
    "endpoint" : "us-ashburn-1",
    "table" : "users",
    "compartment" : "Training-NoSQL",
    "includeTTL" : true,
    "schemaInfo" : {
      "readUnits" : 100,
      "writeUnits" : 60,
      "storageSize" : 1,
      "useSourceSchema" : true
    },
    "useOKEWorkloadIdentity" : true,
    "writeUnitsPercent" : 90,
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.7.0"
}
[INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] migration started
[INFO] [cloud sink] : start loading DDLs
[INFO] [cloud sink] : completed loading DDLs
[INFO] [cloud sink] : start loading records
[INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_1_5_0.json
[INFO] [OCI OS source] : start parsing JSON records from object: users/userSession/Data/users_6_10_0.json
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0, Records skipped=0.
Elapsed time: 0min 1sec 15ms
Migration completed.

    주:

    다음과 같이 데이터 이전을 반복적으로 실행할 수 있습니다.

    1. 다음 명령을 사용하여 nosql-migrator 컨테이너를 삭제합니다.
      #Command:
kubectl delete -f <manifest file> -n <namespace-name>
      #Example:
kubectl delete -f migrator-deployment.yaml -n migrator
      #Output:
deployment.apps "nosql-migrator" deleted
    2. migrator-config.json 구성 입력 파일을 업데이트합니다.
    3. 2단계의 명령을 사용하여 구성 맵을 삭제하고 다시 만듭니다.

      Docker 레지스트리 암호와 manifest 파일을 다시 생성할 필요가 없습니다.

    4. 매니페스트 파일을 사용하여 Kubernetes POD에 Migrator Docker 이미지를 배치합니다(5단계).
검증

데이터 복원을 확인하려면 Oracle NoSQL Database Cloud Service 콘솔에 로그인합니다. 탐색 표시줄에서 데이터베이스 > NoSQL 데이터베이스로 이동합니다. 드롭다운에서 컴파트먼트를 선택하여 users 테이블을 확인합니다. 콘솔 액세스 절차는 Infrastructure 콘솔에서 서비스 액세스를 참조하십시오.

세션 토큰 인증을 사용하여 Oracle NoSQL Database에서 OCI Object Storage로 마이그레이션

이 예에서는 세션 토큰 인증과 함께 Oracle NoSQL Database Migrator를 사용하여 Oracle NoSQL Database 테이블에서 OCI Object Storage 버킷의 JSON 파일로 데이터를 복사하는 방법을 보여줍니다.

사용 사례

개발자는 Oracle NoSQL Database 테이블 데이터를 OCI Object Storage(OCI OS)에 백업하는 옵션을 모색하고 있습니다. 세션 토큰 기반 인증을 사용하려고 합니다.

이 데모에서는 OCI CLI(명령행 인터페이스) 명령을 사용하여 세션 토큰을 생성합니다. Migrator 구성 파일을 수동으로 생성하고 데이터 마이그레이션을 수행합니다.

필요 조건
  • 마이그레이션의 소스 및 싱크를 식별합니다.
    • 소스: Oracle NoSQL Database의 users 테이블.
    • 싱크: OCI OS 버킷의 JSON 파일

      OCI OS의 리전 엔드포인트, 네임스페이스, 버킷 및 접두어를 식별합니다. 자세한 내용은 Oracle Cloud Object Storage 액세스를 참조하십시오. OCI OS 서비스 끝점 목록은 오브젝트 스토리지 끝점을 참조하십시오.

      • 엔드포인트: us-ashburn-1
      • 물통: Migrate_oci
      • 접두어: userSession
      • 네임스페이스: idhkv1iewjzj
        버킷의 네임스페이스 이름은 테넌시의 네임스페이스와 동일하며 테넌시가 생성될 때 자동 생성됩니다. 네임스페이스 이름은 다음과 같이 가져올 수 있습니다.
        • Oracle NoSQL Database Cloud Service 콘솔에서 스토리지> 버킷으로 이동합니다.
        • 목록 범위에서 구획을 선택하고 버킷을 선택합니다. 버킷 세부정보 페이지에는 네임스페이스 매개변수에 이름이 표시됩니다.

        OCI OS 네임스페이스 이름을 제공하지 않을 경우 Migrator 유틸리티는 테넌시의 기본 네임스페이스를 사용합니다.

      주:

      OCI OS 버킷에 객체를 쓸 수 있는 권한이 있는지 확인합니다. 정책 설정에 대한 자세한 내용은 오브젝트 스토리지에 쓰기를 참조하십시오.
  • 다음 단계에 따라 세션 토큰을 생성합니다.
    • OCI CLI를 설치하고 구성합니다. Quickstart를 참조하십시오.
    • 다음 OCI CLI 명령 중 하나를 사용하여 세션 토큰을 생성합니다. 사용 가능한 옵션에 대한 자세한 내용은 CLI에 대한 토큰 기반 인증을 참조하십시오.
      #Create a session token using OCI CLI from a web browser:
oci session authenticate --region <region_name> --profile-name <profile_name>
      #Example:
oci session authenticate --region us-ashburn-1 --profile-name SESSIONPROFILE

      또는

      #Create a session token using OCI CLI without a web browser:
oci session authenticate --no-browser --region <region_name> --profile-name <profile_name>
      #Example:
oci session authenticate --no-browser --region us-ashburn-1 --profile-name SESSIONPROFILE

      위의 명령에서

      region_name: OCI OS에 대한 영역 끝점을 지정합니다. Oracle NoSQL Database Cloud Service에서 지원되는 데이터 지역 목록은 데이터 지역 및 연관된 서비스 URL을 참조하십시오.

      profile_name: OCI CLI 명령이 세션 토큰을 생성하는 데 사용하는 프로파일을 지정합니다.

      OCI CLI 명령은 다음 샘플에 표시된 대로 $HOME/.oci/config 경로의 OCI 구성 파일에 항목을 생성합니다.
      [SESSIONPROFILE]
fingerprint=f1:e9:b7:e6:25:ff:fe:05:71:be:e8:aa:cc:3d:0d:23
key_file=$HOME/.oci/sessions/SESSIONPROFILE/oci_api_key.pem
tenancy=ocid1.tenancy.oc1..aaaaa ... d6zjq
region=us-ashburn-1
security_token_file=$HOME/.oci/sessions/SESSIONPROFILE/token

      security_token_file는 위의 OCI CLI 명령을 사용하여 생성한 세션 토큰의 경로를 가리킵니다.

      주:

      • OCI 구성 파일에 프로파일이 이미 있는 경우 OCI CLI 명령은 세션 토큰을 생성하는 동안 해당 프로파일을 세션 토큰 관련 구성으로 덮어씁니다.
      • 싱크 구성 템플릿에서 다음을 지정합니다.
        • credentials 매개변수의 OCI 구성 파일에 대한 경로입니다.
        • credentialsProfile 매개변수에서 세션 토큰을 생성하는 동안 사용되는 프로파일입니다. 
        "credentials" : "$HOME/.oci/config"
"credentialsProfile" : "SESSIONPROFILE"

        Migrator 유틸리티는 위 매개변수를 사용하여 생성된 세션 토큰의 세부정보를 자동으로 인출합니다. credentials 매개변수를 지정하지 않으면 Migrator 유틸리티가 $HOME/.oci 경로에서 인증서 파일을 찾습니다. credentialsProfile 매개변수를 지정하지 않으면 Migrator 유틸리티는 OCI 구성 파일의 기본 프로파일 이름(DEFAULT)을 사용합니다.

      • 세션 토큰은 60분 동안 유효합니다. 세션 기간을 연장하려면 세션을 새로 고칠 수 있습니다. 자세한 내용은 토큰 새로고침을 참조하십시오.
절차

Oracle NoSQL Database 테이블에서 OCI OS 버킷의 JSON 파일로 마이그레이션하려면 다음을 수행합니다.

  1. OCI OS 버킷 싱크에서 Oracle NoSQL Database 소스 및 JSON 파일을 사용하여 구성 파일(JSON 형식)을 준비합니다. 템플리트는 Source Configuration Templates 및 Sink Configuration Templates를 참조하십시오.
    세션 토큰 인증을 사용하여 OCI OS 버킷에 액세스하려면 싱크 구성 템플리트에서 useSessionToken 매개변수를 true로 설정합니다. 이에 따라 credentials 매개변수에 구성 경로를 지정하고 credentialsProfile 매개변수에 프로파일 이름을 지정합니다. 
    {
  "source" : {
    "type" : "nosqldb",
    "storeName" : "kvstore",
    "helperHosts" : ["<hostname>:<port>"],
    "table" : "users",
    "includeTTL" : true,
    "requestTimeoutMs" : 5000
  },
  "sink" : {
    "type" : "object_storage_oci",
    "format" : "json",
    "endpoint" : "us-ashburn-1",
    "namespace" : "idhkv1iewjzj",
    "bucket" : "Migrate_oci",
    "prefix" : "userSession",
    "chunkSize" : 32,
    "compression" : "",
    "useSessionToken" : true,
    "credentials" : "$/home/.oci/config",
    "credentialsProfile" : "SESSIONPROFILE"
  },
  "abortOnError" : true,
  "migratorVersion" : "<latest>"
}
  2. 명령 프롬프트를 열고 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  3. 구성 파일 옵션을 전달하여 runMigrator 명령을 실행합니다. 다음과 같이 구성 파일을 전달하려면 --config 또는 -c 옵션을 사용합니다.
    ./runMigrator --config ./migrator-config.json
  4. Migrator 유틸리티는 데이터 마이그레이션을 계속합니다. 샘플 출력은 다음과 같습니다.
    useSessionToken 매개변수가 true인 경우 Migrator 유틸리티는 세션 토큰을 사용하여 자동으로 인증됩니다. Migrator 유틸리티는 users 테이블의 데이터를 Migrate_oci이라는 OCI OS 버킷의 JSON 파일로 복사합니다. 로그에서 성공적인 데이터 백업을 확인합니다. 
    [INFO] creating source from given configuration:
[INFO] source creation completed
[INFO] creating sink from given configuration:
[INFO] sink creation completed
[INFO] creating migrator pipeline
[INFO] [OCI OS sink] : writing table schema to userSession/Schema/schema.ddl
[INFO] migration started
[INFO] Migration success for source users_6_10. read=2,written=2,failed=0
[INFO] Migration success for source users_1_5. read=3,written=3,failed=0
[INFO] Migration is successful for all the sources.
[INFO] migration completed.
Records provided by source=5, Records written to sink=5, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 982ms
Migration completed.

    주:

    싱크 구성 템플리트의 chunkSize 매개변수에 따라 Migrator 유틸리티는 소스 데이터를 동일한 디렉토리의 여러 JSON 파일로 분할합니다. 이 예에서 Migrator 유틸리티는 Migrate_oci/userSession/Data 디렉토리의 users_1_5_0.json 및 users_6_10_0.json 파일에 데이터를 복사합니다.

    소스 테이블 스키마가 Migrate_oci/userSession/Schema 디렉토리의 schema.ddl 파일로 복사됩니다.

확인

데이터 백업을 확인하려면 Oracle NoSQL Database Cloud Service 콘솔에 로그인합니다. 메뉴 Storage > Object Storage & Archive Storage > Buckets를 탐색합니다. Migrate_oci 버킷의 userSession 디렉토리에서 파일에 액세스합니다. 콘솔 액세스 절차는 Infrastructure 콘솔에서 서비스 액세스를 참조하십시오.

CSV 파일에서 Oracle NoSQL Database로 마이그레이션

이 예에서는 Oracle NoSQL Database Migrator를 사용하여 CSV 파일에서 Oracle NoSQL Database로 데이터를 복사하는 방법을 보여 줍니다.

예

여러 옵션을 평가한 후 조직은 Oracle NoSQL Database를 NoSQL 데이터베이스 플랫폼으로 완성합니다. 소스 콘텐츠는 CSV 파일 형식이므로 Oracle NoSQL Database로 마이그레이션할 방법을 찾고 있습니다.

이 예제에서는 대학에서 제공하는 다양한 과정에 대한 정보를 포함하는 course.csv라는 CSV 파일에서 데이터를 이전하는 방법을 배웁니다. runMigrator 유틸리티에서 구성 파일을 생성합니다.

식별된 소스 및 싱크 세부정보로 구성 파일을 준비할 수도 있습니다. Oracle NoSQL Database Migrator Reference를 참고하세요.

필요 조건
  • 마이그레이션의 소스 및 싱크를 식별합니다.
    • 출처: CSV 파일

      이 예에서 소스 파일은 course.csv입니다.

      
cat [~/nosql-migrator-1.5.0]/course.csv
1,"Computer Science", "San Francisco", "2500"
2,"Bio-Technology", "Los Angeles", "1200"
3,"Journalism", "Las Vegas", "1500"
4,"Telecommunication", "San Francisco", "2500"
    • 싱크: Oracle NoSQL Database
  • CSV 파일은 RFC4180 형식을 따라야 합니다.
  • 대상 테이블 course의 스키마에 대한 DDL 명령을 포함하는 파일을 생성합니다. 테이블 정의는 열 수 및 해당 유형에 관한 CSV 데이터 파일과 일치해야 합니다.

    이 예제에서 DDL 파일은 mytable_schema.ddl입니다.

    
cat [~/nosql-migrator-1.5.0]/mytable_schema.ddl
create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id));
절차
CSV 파일 데이터를 course.csv에서 Oracle NoSQL Database Service로 마이그레이션하려면 다음 단계를 수행합니다.
  1. 명령 프롬프트를 열고 Oracle NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
  2. Oracle NoSQL Database Migrator를 사용하여 구성 파일을 생성하려면 런타임 매개변수 없이 runMigrator 명령을 실행합니다.
    [~/nosql-migrator-1.5.0]$./runMigrator
  3. 구성 파일을 런타임 매개변수로 제공하지 않았으므로 지금 구성을 생성할지 묻는 메시지가 표시됩니다. y를 입력합니다.
    Enter key를 눌러 구성 파일의 위치를 선택하거나 기본 위치를 유지할 수 있습니다. 
    
Configuration file is not provided. Do you want to generate
configuration? (y/n) [n]: y
Generating a configuration file interactively.

Enter a location for your config [./migrator-config.json]: 
./migrator-config.json already exist. Do you want to overwrite?(y/n) [n]: y
  4. 유틸리티의 프롬프트에 따라 소스 구성에 대한 옵션을 선택합니다.
    
Select the source: 
1) nosqldb
2) nosqldb_cloud
3) file
4) object_storage_oci
5) aws_s3
#? 3

Configuration for source type=file
Select the source file format: 
1) json
2) mongodb_json
3) dynamodb_json
4) csv
#? 4
  5. 소스 CSV 파일의 경로를 제공합니다. 또한 유틸리티의 프롬프트에 따라 열 이름을 재정렬하고, 인코딩 방법을 선택하고, 대상 테이블에서 테일링 공백을 정리하도록 선택할 수 있습니다. 
    
Enter path to a file or directory containing csv data: [~/nosql-migrator-1.5.0]/course.csv
Does the CSV file contain a headerLine? (y/n) [n]: n
Do you want to reorder the column names of NoSQL table with respect to
CSV file columns? (y/n) [n]: n
Provide the CSV file encoding. The supported encodings are:
UTF-8,UTF-16,US-ASCII,ISO-8859-1. [UTF-8]: 
Do you want to trim the tailing spaces? (y/n) [n]: n
  6. 유틸리티의 프롬프트에 따라 Sink 구성에 대한 옵션을 선택합니다. 
    
Select the sink:
1) nosqldb
2) nosqldb_cloud
#? 1
Configuration for sink type=nosqldb
Enter store name of the Oracle NoSQL Database: mystore
Enter comma separated list of host:port of Oracle NoSQL Database: <hostname>:5000
  7. 유틸리티의 프롬프트에 따라 대상 테이블의 이름을 제공합니다. 
    
Enter fully qualified table name: course
  8. TTL 값을 설정할 항목을 입력합니다. 기본값은 n입니다. 
    
Include TTL data? If you select 'yes' TTL value provided by the
source will be set on imported rows. (y/n) [n]: n
  9. 유틸리티의 프롬프트를 기반으로 Oracle NoSQL Database Migrator 도구를 통해 대상 테이블을 생성해야 하는지 여부를 지정합니다. 테이블이 이미 생성된 경우 n를 제공하는 것이 좋습니다. 테이블이 생성되지 않은 경우 유틸리티가 대상 테이블의 스키마에 대한 DDL 명령을 포함하는 파일의 경로를 요청합니다. 
    
Would you like to create table as part of migration process?
Use this option if you want to create table through the migration tool.
If you select yes, you will be asked to provide a file that contains
table DDL or to use schema provided by the source or default schema.
(y/n) [n]: y
Enter path to a file containing table DDL: [~/nosql-migrator-1.5.0]/mytable_schema.ddl
Is the store secured? (y/n) [y]: n
would you like to overwrite records which are already present?
If you select 'no' records with same primary key will be skipped [y/n] [y]: y
Enter store operation timeout in milliseconds. [5000]:
Would you like to add transformations to source data? (y/n) [n]: n
  10. 레코드 마이그레이션에 실패한 경우 마이그레이션을 계속할지 여부를 결정하려면 선택 항목을 입력합니다. 
    
Would you like to continue migration if any data fails to be migrated? 
(y/n) [n]: n
  11. 유틸리티가 생성된 구성을 화면에 표시합니다. 
    
Generated configuration is:
{
  "source" : {
    "type" : "file",
    "format" : "csv",
    "dataPath" : "[~/nosql-migrator-1.5.0]/course.csv",
    "hasHeader" : false,
    "csvOptions" : {
      "encoding" : "UTF-8",
      "trim" : false
    }
  },
  "sink" : {
    "type" : "nosqldb",
    "storeName" : "mystore",
    "helperHosts" : ["<hostname>:5000"],
    "table" : "migrated_table",
    "query" : "",
    "includeTTL" : false,
    "schemaInfo" : {
      "schemaPath" : "[~/nosql-migrator-1.5.0]/mytable_schema.ddl"
    },
    "overwrite" : true,
    "requestTimeoutMs" : 5000
  },
  "abortOnError" : true,
  "migratorVersion" : "1.5.0"
}
  12. 마지막으로, 생성된 구성 파일을 사용하여 마이그레이션을 계속할지 여부를 지정하라는 메시지가 표시됩니다. 기본 옵션은 y입니다.
    주: n을 선택하면 생성된 구성 파일을 사용하여 이전을 수행할 수 있습니다. ./runMigrator -c 또는 ./runMigrator --config 옵션을 지정합니다. 
    
Would you like to run the migration with above configuration?
If you select no, you can use the generated configuration file to
run the migration using:
./runMigrator --config ./migrator-config.json
(y/n) [y]: y
  13. NoSQL Database Migrator는 사용자의 데이터를 CSV 파일에서 Oracle NoSQL Database로 복사합니다.
    
creating source from given configuration:
source creation completed
creating sink from given configuration:
sink creation completed
creating migrator pipeline
migration started
[nosqldb sink] : start loading DDLs
[nosqldb sink] : executing DDL: create table course (id INTEGER, name STRING, location STRING, fees INTEGER, PRIMARY KEY(id))
[nosqldb sink] : completed loading DDLs
[nosqldb sink] : start loading records
[csv file source] : start parsing CSV records from file: course.csv
migration completed. Records provided by source=4, Records written to sink=4, Records failed=0,Records skipped=0.
Elapsed time: 0min 0sec 559ms
Migration completed.
검증
KVStore에서 SQL 프롬프트를 시작합니다.
 java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstore
새 테이블이 소스 데이터로 생성되었는지 확인합니다.

sql-> select * from course;
{"id":4,"name":"Telecommunication","location":"San Francisco","fees":2500}
{"id":1,"name":"Computer Science","location":"San Francisco","fees":2500}
{"id":2,"name":"Bio-Technology","location":"Los Angeles","fees":1200}
{"id":3,"name":"Journalism","location":"Las Vegas","fees":1500}
 
4 rows returned