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와 함께 사용되는 용어
위 다이어그램에 사용된 다양한 용어에 대해 자세히 알아봅니다.
- 소스: 이전을 위해 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) 용도 지원되는 값 sourcetypeY 데이터를 마이그레이션할 원본을 나타냅니다.Represents the source from which to migrate the data. 소스는 마이그레이션을 위한 데이터 및 메타데이터(있는 경우)를 제공합니다. 각 소스에 대한 type값을 확인하려면 Supported Sources and Sinks를 참조하십시오.source유형에 대한 소스 구성 Y 소스에 대한 구성을 정의합니다. 이러한 구성 매개변수는 위에서 선택한 소스 유형에 따라 다릅니다. 각 소스 유형에 대한 전체 구성 매개변수 목록은 소스 구성 템플리트를 참조하십시오. sinktypeY 데이터를 마이그레이션할 싱크를 나타냅니다.Represents the sink to which to migrate the data. 싱크는 마이그레이션의 대상 또는 대상입니다. 각 소스에 대한 type값을 확인하려면 Supported Sources and Sinks를 참조하십시오.sink유형에 대한 sink-configuration Y 싱크에 대한 구성을 정의합니다. 이러한 구성 매개변수는 위에서 선택한 싱크 유형에 따라 다릅니다. 각 싱크 유형에 대한 전체 구성 매개변수 목록은 Sink Configuration Templates를 참조하십시오. transforms변환 구성 N 마이그레이션 파이프의 데이터에 적용할 변환을 정의합니다. NoSQL 데이터 마이그레이터에서 지원하는 전체 변환 목록은 변환 구성 템플리트를 참조하십시오. - migratorVersionN NoSQL 데이터 마이그레이터 버전 - - abortOnErrorN 오류 발생 시 마이그레이션 작업을 중지할지 여부를 지정합니다.
기본값은 true이며 마이그레이션 오류가 발생할 때마다 마이그레이션이 중지됨을 나타냅니다.
이 값을 false로 설정하면 실패한 레코드나 기타 마이그레이션 오류가 있는 경우에도 마이그레이션이 계속됩니다. 실패한 레코드 및 마이그레이션 오류는 CLI 터미널에 WARNING으로 기록됩니다.
true, false 주:
JSON 파일은 대소문자를 구분하므로 별도로 지정하지 않는 한 구성 파일에 정의된 모든 매개변수는 대소문자를 구분합니다.
지원되는 소스 및 싱크
이 항목에서는 Oracle NoSQL Database Migrator가 지원하는 소스 및 싱크 목록을 제공합니다.
이 테이블에서 마이그레이션 작업에 적합한 소스와 싱크의 조합을 사용할 수 있습니다. 그러나 끝, 즉 소스 또는 싱크 중 하나 이상이 Oracle NoSQL 제품인지 확인해야 합니다. NoSQL 데이터베이스 마이그레이터를 사용하여 NoSQL 테이블 데이터를 한 파일에서 다른 파일로 이동할 수 없습니다.
|
유형 |
형식 |
적합한 소스 | 유효 싱크 |
|---|---|---|---|
|
Oracle NoSQL Database |
NA | Y | Y |
|
Oracle NoSQL Database Cloud Service |
NA | Y | Y |
|
파일 시스템 |
JSON |
Y | Y |
|
MongoDB JSON |
Y | N | |
|
DynamoDB JSON |
Y | N | |
|
연회( |
N | Y | |
|
CSV |
Y | N | |
|
OCI Object Storage |
JSON |
Y | Y |
|
MongoDB JSON |
Y | N | |
|
연회( |
N | Y | |
|
CSV |
Y | N | |
| AWS S3 |
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.jar을 lib 디렉토리에 복사합니다.
kvstore-ee.jar 파일을 <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 사용과 관련된 작업의 상위 레벨 플로우는 아래 그림에 나와 있습니다.
NoSQL Data Migrator 유틸리티 다운로드
runMigrator 명령에 액세스할 수 있습니다.
주:
Oracle NoSQL Database Migrator 유틸리티를 실행하려면 Java 11 이상의 버전이 필요합니다.소스 및 싱크 식별
- 싱크 테이블 스키마 식별: 싱크가 온프레미스 또는 클라우드에서 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 데이터베이스 마이그레이터는 테이블에 대한 스키마를 미리 정의할 필요 없이 기본 스키마로 테이블을 생성하는 옵션을 제공합니다. 이 기능은 주로 JSON 소스 파일을 Oracle NoSQL Database로 로드할 때 유용합니다.
- 테이블 스키마 제공: NoSQL 데이터베이스 마이그레이터를 사용하면 소스가 schemaInfo 속성을 사용하여 테이블 데이터에 대한 스키마 정의를 제공할 수 있습니다. schemaInfo 속성은 이미 정의된 암시적 스키마가 없는 모든 데이터 소스에서 사용할 수 있습니다. 싱크 데이터 저장소는 다음 옵션 중 하나를 선택할 수 있습니다.
- NoSQL Database Migrator로 정의된 기본 스키마를 사용합니다.
- 소스 제공 스키마를 사용합니다.
- 자체 스키마를 정의하여 소스 제공 스키마를 무효화합니다. 예를 들어, 소스 스키마에서 다른 스키마로 데이터를 변환하려면 소스 제공 스키마를 무효화하고 NoSQL Database Migrator 툴의 변환 기능을 사용해야 합니다.
테이블 스키마 파일(예: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 메타데이터 마이그레이션에 대한 지원은 Oracle NoSQL Database 및 Oracle NoSQL Database Cloud Service에만 제공됩니다.TTL 메타데이터 익스포트 중
_metadata JSON 객체에 포함됩니다. 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 메타데이터를 임포트할 수 있습니다. 임포트 작업은 TTL 메타데이터를 포함하는 테이블 행을 이전할 때 다음과 같은 사용 사례를 처리합니다. 이러한 사용 사례는 includeTTL 구성 매개변수가 지정된 경우에만 적용됩니다.
- 사용 사례 1: 임포트 테이블 행에 TTL 메타데이터 정보가 없습니다.
외부 소스에서 생성되거나 이전 버전의 마이그레이션기를 사용하여 익스포트된 JSON 소스 파일을 임포트하는 경우 임포트 행에 TTL 정보가 없습니다. 그러나 includeTTL 구성 매개변수가
true와 같으므로 마이그레이터는 테이블 행에 대해 TTL=0을 설정합니다. 즉, 임포트 테이블 행이 만료되지 않습니다. - 사용 사례 2: 소스 테이블 행의 TTL 값이 테이블 행이 임포트될 때 참조 시간을 기준으로 만료됩니다.
테이블 행을 파일로 엑스포트하고 테이블 행의 만료 시간 후에 임포트하려고 하면 테이블 행이 무시되고 저장소에 기록되지 않습니다.
- 사용 사례 3: 소스 테이블 행의 TTL 값이 테이블 행이 임포트될 때 참조 시간을 기준으로 만료되지 않습니다.
테이블 행을 파일로 엑스포트하고 테이블 행의 만료 시간 전에 임포트하려고 하면 테이블 행이 TTL 값으로 임포트됩니다. 그러나 TimeToLive 클래스의 정수 시간 및 일 창 제약 조건으로 인해 테이블 행의 새 TTL 값이 익스포트된 TTL 값과 같지 않을 수 있습니다. 예를 들어 다음과 같습니다.
익스포트된 테이블 행{ "id" : 8, "name" : "xyz", "_metadata" : { "expiration" : 1629709200000 //Monday, August 23, 2021 9:00:00 AM in UTC } }가져오는 동안의 참조 시간은 1629707962582(2021년 8월 23일 월요일 오전 8:39:22.582)입니다.
임포트된 테이블 행{ "id" : 8, "name" : "xyz", "_metadata" : { "ttl" : 1629712800000 //Monday, August 23, 2021 10:00:00 AM UTC } }
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))| 소스 조건 | 사용자 작업 | 마이그레이션 결과 |
|---|---|---|
|
사례 1: 소스 데이터는 싱크 테이블의 IDENTITY 필드에 대한 값을 제공하지 않습니다. 예: JSON 소스 파일 |
구성 파일을 생성/생성합니다. |
데이터 마이그레이션에 성공했습니다. IDENTITY 열 값은 자동 생성됩니다. Oracle NoSQL Database 싱크 테이블 |
|
사례 2: 소스 데이터는 싱크 테이블의 IDENTITY 필드에 대한 값을 제공합니다. 예: JSON 소스 파일 |
구성 파일을 생성/생성합니다. 싱크 구성 템플리트의 ID 열에 대해 ignoreFields 변환을 제공합니다.
|
데이터 마이그레이션에 성공했습니다. 제공된 ID 값은 건너뛰고 IDENTITY 열 값은 자동 생성됩니다. Oracle NoSQL Database 싱크 테이블
migrateID에서 마이그레이션된 데이터: |
|
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))| 소스 조건 | 사용자 작업 | 마이그레이션 결과 |
|---|---|---|
|
사례 1: 소스 데이터는 싱크 테이블의 IDENTITY 필드에 대한 값을 제공하지 않습니다. 예: JSON 소스 파일 |
구성 파일을 생성/생성합니다. |
데이터 마이그레이션에 성공했습니다. IDENTITY 열 값은 자동 생성됩니다. Oracle NoSQL Database 싱크 테이블
migrateID에서 마이그레이션된 데이터: |
|
사례 2: 소스 데이터는 싱크 테이블의 IDENTITY 필드에 대한 값을 제공하며 기본 키 필드입니다. 예: JSON 소스 파일 |
구성 파일을 생성/생성합니다. 싱크 구성 템플리트(권장)에서 ID 열에 대해 ignoreFields 변환을 제공합니다.
|
데이터 마이그레이션에 성공했습니다. 제공된 ID 값은 건너뛰고 IDENTITY 열 값은 자동 생성됩니다. Oracle NoSQL Database 싱크 테이블
migrateID에서 마이그레이션된 데이터: |
|
IDENTITY 열에 대해 ignoreFields 변환 없이 구성 파일을 생성/생성합니다. |
데이터 마이그레이션에 성공했습니다. 소스에서 제공된 ID 값을 제공하지 않고 테이블에 추가 행을 삽입하려고 하면 시퀀스 생성기는 ID 값을 자동으로 생성하려고 시도합니다. 시퀀스 생성기의 시작 값은 1입니다. 따라서 생성된 ID 값은 싱크 테이블의 기존 ID 값 중 하나를 복제할 수 있습니다. 이것은 Primary Key 제약 조건을 위반하므로 오류가 반환되고 행이 삽입되지 않습니다. 자세한 내용은 순서 생성기를 참조하십시오. 기본 키 제약 조건 위반을 방지하려면 시퀀스 생성기가 싱크 테이블의 기존 ID 값과 충돌하지 않는 값으로 시퀀스를 시작해야 합니다. START WITH 속성을 사용하여 수정하려면 아래 예를 참조하십시오. 예: Oracle NoSQL Database 싱크 테이블의 마이그레이션된 데이터
migrateID:ID 열에 삽입할 시퀀스 생성기에 적합한 값을 찾으려면 다음 질의를 사용하여
ID 필드의 최대값을 인출합니다.출력:
싱크 테이블에 있는
ID 열의 최대값은 3입니다. 중복을 피하기 위해 시퀀스 생성기에서 ID 값을 3 이상으로 생성하려고 합니다. 다음 명령문을 사용하여 시퀀스 생성기의 START WITH 속성을 4로 갱신합니다.그러면 시퀀스가 4에서 시작됩니다. 이제 ID 값을 제공하지 않고 싱크 테이블에 행을 삽입하면 시퀀스 생성기는 ID 중복을 뒤집어 4부터 ID 값을 자동으로 생성합니다. |
변환 구성 매개변수에 대한 자세한 내용은 변환 구성 템플리트 항목을 참조하십시오.
runMigrator 명령을 실행합니다.
runMigrator 실행 파일은 추출된 NoSQL Database Migrator 파일에서 사용할 수 있습니다. runMigrator 명령을 성공적으로 실행하려면 Java 11 이상 버전 및 bash를 시스템에 설치해야 합니다.
runMigrator 명령은 다음 두 가지 방법으로 실행할 수 있습니다.
- 아래와 같이
runMigrator명령의 런타임 옵션을 사용하여 구성 파일을 생성합니다.[~]$ ./runMigrator configuration file is not provided. Do you want to generate configuration? (y/n) [n]: y ... ...runMigrator유틸리티를 호출하면 일련의 런타임 옵션이 제공되며 각 옵션에 대한 선택사항에 따라 구성 파일이 생성됩니다.- 유틸리티가 구성 파일을 만든 후 동일한 실행에서 마이그레이션 작업을 계속하거나 이후 마이그레이션을 위해 구성 파일을 저장할 수 있습니다.
- 생성된 구성 파일을 사용하여 마이그레이션 작업을 진행하거나 지연하기로 결정했는지에 관계없이 이후 요구 사항에 맞게 파일을 편집 또는 사용자 정의할 수 있습니다. 나중에 마이그레이션을 위해 사용자 정의된 구성 파일을 사용할 수 있습니다.
-c또는--config옵션을 사용하여 수동으로 생성된 구성 파일(JSON 형식)을 런타임 매개변수로 전달합니다.-c또는--config옵션을 사용하여runMigrator명령을 실행하기 전에 구성 파일을 수동으로 생성해야 합니다. 소스 및 싱크 구성 매개변수에 대한 도움말은 Oracle NoSQL Database Migrator Reference를 참조하십시오.[~]$ ./runMigrator -c </path/to/the/configuration/json/file>
로깅 마이그레이터 진행률
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 파일로 마이그레이션하려면 다음을 수행합니다.
마이그레이션을 검증하려면 JSON 싱크 파일을 열고 스키마 및 데이터를 볼 수 있습니다.
-- Exported myTable Data
[~/nosqlMigrator]$cat myTableJSON
{
"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
- storeName:
myTable의 데이터 및 스키마 정의를 NoSQL Database KVStore에서 NDCS로 이전하려면 다음을 수행합니다.
마이그레이션을 검증하기 위해 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.
- 출처: JSON 출처 파일.
- 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>.
-
SampleData.json에서 Oracle NoSQL Database Cloud Service로 마이그레이션하려면 다음을 수행합니다.
Migrate_JSON 테이블이 생성되었는지 확인할 수 있습니다. 콘솔에 액세스하는 절차는 Oracle NoSQL Database Cloud Service 문서의 Infrastructure 콘솔에서 서비스 액세스 문서를 참조하십시오.
그림 - 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 데이터가 포함된 파일 또는 디렉토리를 복사할 수 있습니다.
{"_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 Database Migrator가 기본 스키마 구조로 테이블을 생성하도록 지시할 수 있습니다.주:
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로 마이그레이션하려면 다음을 수행합니다.
마이그레이션을 검증하기 위해 NDCS 콘솔에 로그인하여 소스 데이터로 myTable가 생성되었는지 확인할 수 있습니다.
DynamoDB JSON 파일에서 Oracle NoSQL Database로 마이그레이션
이 예에서는 Oracle NoSQL Database Migrator를 사용하여 DynamoDB JSON 파일을 Oracle NoSQL Database로 복사하는 방법을 보여 줍니다.
사용 사례:
여러 옵션을 평가한 후 조직은 DynamoDB 데이터베이스를 통해 Oracle NoSQL Database를 완성합니다. 조직에서는 테이블 및 데이터를 DynamoDB에서 Oracle NoSQL Database(온프레미스)로 마이그레이션하려고 합니다.
자세한 내용은 DynamoDB 테이블을 Oracle NoSQL 테이블에 매핑을 참조하십시오.
소스 구성 템플리트에 경로를 지정하여 파일 시스템에서 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 테이블 데이터를 AWS S3 스토리지에서 로컬 마운트된 파일 시스템으로 복사합니다.
예제:
이 데모에서는 DynamoDB JSON 파일을 Oracle NoSQL Database(온프레미스)로 마이그레이션하는 방법을 알아봅니다. 이 예에서는 수동으로 만든 구성 파일을 사용합니다.
필요 조건
- 마이그레이션에 대한 소스 및 싱크를 식별합니다.
- 출처: DynamoDB JSON 파일
- 싱크: Oracle NoSQL Database(온프레미스)
- DynamoDB 테이블 데이터를 Oracle NoSQL Database로 임포트하려면 먼저 DynamoDB 테이블을 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에서 파일을 다운로드해야 합니다. 다운로드 후 파일의 구조는 아래와 같습니다.
download-dir/01639372501551-bb4dd8c3 |----data |------sxz3hjr3re2dzn2ymgd2gi4iku.json.gz ==>table data |----manifest-files.json |----manifest-files.md5 |----manifest-summary.json |----manifest-summary.md5 |----_started
절차
- 식별된 소스 및 싱크 details.See 소스 구성 템플리트 및 싱크 구성 템플리트를 사용하여 구성 파일(JSON 형식)을 준비합니다.
다음 두 가지 옵션 중 하나를 선택할 수 있습니다.
- 옵션 1: 기본 스키마 구성을 사용하여 DynamoDB 테이블을 JSON 문서로 임포트합니다.
여기서
defaultSchema는TRUE이므로 마이그레이터는 싱크대에 기본 스키마를 만듭니다.DDBPartitionKey및 해당하는 NoSQL 열 유형을 지정해야 합니다. 그렇지 않으면 오류가 발생합니다.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] "schemaInfo" : { "defaultSchema" : true, "DDBPartitionKey" : "<PrimaryKey:Datatype>", }, }, "abortOnError" : true, "migratorVersion" : "1.0.0" }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 = 구성의 partiiton 키에 대해 제공된 값
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이 삽입됩니다.{ "source" : { "type" : "file", "format" : "dynamodb_json", "dataPath" : "<complete/path/to/the/DynamoDB/Formatted/JSON/file>" }, "sink" : { "type" : "nosqldb", "table" : "<table_name>", "schemaInfo" : { "defaultSchema" : false, "readUnits" : 100, "writeUnits" : 60, "schemaPath" : "<full path of the schema file with the DDL statement>", "storageSize" : 1 }, "storeName" : "kvstore", "helperHosts" : ["<hostname>:5000"] }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- 옵션 1: 기본 스키마 구성을 사용하여 DynamoDB 테이블을 JSON 문서로 임포트합니다.
- 명령 프롬프트를 열고 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
--config또는-c옵션을 사용하여 구성 파일을 전달하여runMigrator명령을 실행합니다.[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>- 이 유틸리티는 아래와 같이 데이터 마이그레이션을 진행합니다.
Records provided by source=7.., Records written to sink=7, Records failed=0, Records skipped=0. Elapsed time: 0 min 2sec 50ms Migration completed.
검증
java -jar lib/sql.jar -helper-hosts localhost:5000 -store kvstoredesc <table_name>
SELECT * from <table_name>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 데이터를 포함하는 파일을 이전할 수 있습니다.
{"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
- 구획: 개발자
절차
- 식별된 소스 및 싱크 세부정보로 구성 파일(JSON 형식)을 준비합니다. 소스 구성 템플리트 및 싱크 구성 템플리트를 참조하십시오.
다음 두 가지 옵션 중 하나를 선택할 수 있습니다.
- 옵션 1: 기본 스키마 구성을 사용하여 DynamoDB 테이블을 JSON 문서로 임포트합니다.
여기서
defaultSchema는TRUE이므로 마이그레이터는 싱크대에 기본 스키마를 만듭니다.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.0.0" }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 = 구성의 partiiton 키에 대해 제공된 값
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이 삽입됩니다.{ "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 }, "abortOnError" : true, "migratorVersion" : "1.0.0" }
- 옵션 1: 기본 스키마 구성을 사용하여 DynamoDB 테이블을 JSON 문서로 임포트합니다.
- 명령 프롬프트를 열고 NoSQL Database Migrator 유틸리티를 추출한 디렉토리로 이동합니다.
--config또는-c옵션을 사용하여 구성 파일을 전달하여runMigrator명령을 실행합니다.[~/nosqlMigrator/nosql-migrator-1.0.0]$./runMigrator --config <complete/path/to/the/JSON/config/file>- 이 유틸리티는 아래와 같이 데이터 마이그레이션을 진행합니다.
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=23456user_data 테이블을 애슈번 영역에서 피닉스 영역으로 마이그레이션하려면 다음을 수행합니다.
마이그레이션을 검증하려면 피닉스 지역의 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 파일로 백업하려면 다음을 수행합니다.
데이터 백업을 검증하려면 Oracle NoSQL Database Cloud Service 콘솔에 로그인합니다. Storage > Object Storage & Archive Storage > Buckets 메뉴를 탐색합니다. Migrate_oci 버킷의 NDCSupload/Delegation 디렉토리에서 파일에 액세스합니다. 콘솔에 액세스하는 절차는 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 파일
- 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));
course.csv에서 Oracle NoSQL Database Service로 마이그레이션하려면 다음 단계를 수행합니다.
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