Neo4j에서 Neptune으로 데이터 마이그레이션 - Amazon Neptune

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Neo4j에서 Neptune으로 데이터 마이그레이션

Neo4j에서 Amazon Neptune으로 마이그레이션할 때, 데이터를 마이그레이션하는 것은 프로세스의 주요 단계입니다. 데이터를 마이그레이션하는 방법에는 여러 가지가 있습니다. 올바른 접근 방식은 애플리케이션의 요구 사항, 데이터 크기, 원하는 마이그레이션 유형에 따라 결정됩니다. 그러나 이러한 마이그레이션 중 상당수는 모두 동일한 고려 사항에 대한 평가가 필요하며, 그 중 몇 가지가 아래에 강조 표시되어 있습니다.

참고

오프라인 데이터 마이그레이션을 수행하는 방법에 대한 한 가지 예를 단계별로 자세히 알아보려면 AWS 데이터베이스 블로그완전 자동화된 유틸리티를 사용하여 Neo4j 그래프 데이터베이스를 Neptune으로 마이그레이션을 참조하세요.

Neo4j에서 Neptune으로 데이터 마이그레이션 평가

데이터 마이그레이션을 평가할 때 첫 번째 단계는 데이터를 마이그레이션할 방법을 결정하는 것입니다. 옵션은 마이그레이션되는 애플리케이션의 아키텍처, 데이터 크기, 마이그레이션 중 필요한 가용성에 따라 달라집니다. 일반적으로 마이그레이션은 온라인과 오프라인이라는 두 가지 범주 중 하나로 분류되는 경향이 있습니다.

오프라인 마이그레이션은 마이그레이션 중에 애플리케이션이 읽기 또는 쓰기 트래픽을 허용하지 않기 때문에 가장 간단하게 수행할 수 있는 경향이 있습니다. 애플리케이션이 트래픽 수신을 중지하면 데이터를 내보내고, 최적화하고, 가져오고, 애플리케이션을 다시 활성화하기 전에 애플리케이션을 테스트할 수 있습니다.

데이터를 마이그레이션하는 동안 애플리케이션이 여전히 읽기 및 쓰기 트래픽을 허용해야 하기 때문에 온라인 마이그레이션은 더 복잡합니다. 각 온라인 마이그레이션의 정확한 요구 사항은 다를 수 있지만 일반적인 아키텍처는 일반적으로 다음과 비슷합니다.

Neo4j에서 Neptune으로 마이그레이션하기 위한 데이터 모델 최적화

Neptune과 Neo4j 모두 레이블이 지정된 속성 그래프(LPG)를 지원합니다. 그러나 Neptune에는 성능 최적화에 활용할 수 있는 몇 가지 아키텍처 및 데이터 모델 차이점이 있습니다.

노드 및 엣지 ID 최적화

Neo4j는 숫자로 된 긴 ID를 자동으로 생성합니다. Cypher를 사용하면 ID로 노드를 참조할 수 있지만 인덱싱된 속성으로 노드를 조회할 때는 일반적으로 권장하지 않습니다.

Neptune을 사용하면 정점과 엣지에 고유한 문자열 기반 ID를 제공할 수 있습니다. 자체 ID를 제공하지 않는 경우 Neptune은 새 엣지와 정점에 대해 UUID의 문자열 표현을 자동으로 생성합니다.

Neo4j에서 데이터를 내보낸 다음 Neptune으로 대량으로 가져와서 Neo4j에서 Neptune으로 데이터를 마이그레이션하면 Neo4j의 ID를 보존할 수 있습니다. Neo4j에서 생성된 숫자 값은 Neptune으로 가져올 때 사용자 제공 ID로 작동할 수 있습니다. Neptune에서는 숫자 값이 아닌 문자열로 표시됩니다.

하지만 정점 속성을 정점 ID로 승격시켜야 하는 경우도 있습니다. Neo4j에서 인덱스 속성을 사용하여 노드를 찾는 것이 노드를 찾는 가장 빠른 방법인 것처럼 Neptune에서 정점을 찾는 가장 빠른 방법은 ID로 정점을 찾는 것입니다. 따라서 고유한 값을 포함하는 적절한 정점 속성을 식별할 수 있다면 벌크 로드 CSV 파일에서 정점 ~id를 지정된 속성 값으로 바꾸는 것을 고려해야 합니다. 이렇게 하면 CSV 파일에 해당하는 ~from 및 ~to 엣지 값도 다시 작성해야 합니다.

Neo4j에서 Neptune으로 데이터를 마이그레이션할 때의 스키마 제약 조건

Neptune 내에서 사용할 수 있는 유일한 스키마 제약 조건은 노드 또는 엣지 ID의 고유성입니다. 고유성 제약을 활용해야 하는 애플리케이션은 노드 또는 엣지 ID를 지정하여 고유성 제약을 달성하기 위한 이 접근 방식을 살펴보는 것이 좋습니다. 애플리케이션이 고유성 제약 조건으로 여러 열을 사용한 경우 ID는 이러한 값의 조합으로 설정될 수 있습니다. 예를 들어, 복잡한 고유성 제약 조건을 충족하기 위해 id=123, code='SEA'ID='123_SEA'로 표시할 수 있습니다.

Neo4j에서 Neptune으로 데이터를 마이그레이션할 때의 엣지 방향 최적화

노드, 엣지 또는 속성이 Neptune에 추가되면 세 가지 방식으로 자동으로 인덱싱 되며 네 번째 인덱스도 옵션으로 제공됩니다. Neptune이 인덱스를 빌드하고 사용하는 방식 때문에 송신 엣지를 따르는 쿼리는 들어오는 엣지를 사용하는 쿼리보다 더 효율적입니다. Neptune의 그래프 데이터 스토리지 모델에서는 SPOG 인덱스를 사용하는 주제 기반 검색이라고 할 수 있습니다.

데이터 모델 및 쿼리를 Neptune으로 마이그레이션할 때 가장 중요한 쿼리가 팬 아웃 수준이 높은 수신 엣지를 통과하는 데 의존하는 경우, 특히 통과할 엣지 레이블을 지정할 수 없는 경우에는 이러한 순회가 나가는 엣지를 따르도록 모델을 변경하는 것이 좋습니다. 이렇게 하려면 관련 엣지의 방향을 반대로 바꾸고 이 방향 변경의 의미를 반영하도록 엣지지 레이블을 업데이트하세요. 예를 들어, 다음과 같이 변경할 수 있습니다.

person_A — parent_of — person_B to: person_B — child_of — person_A

대량으로 로드되는 엣지 CSV 파일에서 이러한 변경을 수행하려면 간단히 ~from~to 열 제목을 바꾸고 ~label 열 값을 업데이트하면 됩니다.

엣지 방향을 바꾸는 대신 네 번째 Neptune 인덱스인 OSGP 인덱스를 사용할 수 있습니다. 이 인덱스를 사용하면 들어오는 엣지를 순회하거나 객체 기반 검색을 훨씬 더 효율적으로 수행할 수 있습니다. 하지만 이 네 번째 인덱스를 활성화하면 삽입률이 낮아지고 스토리지가 더 많이 필요합니다.

Neo4j에서 Neptune으로 데이터를 마이그레이션할 때의 필터링 최적화

Neptune은 속성이 사용 가능한 가장 선택적인 속성으로 필터링될 때 가장 잘 작동하도록 최적화되었습니다. 여러 필터를 사용하는 경우 각 필터에 대해 일치하는 항목 세트를 찾은 다음 일치하는 모든 세트의 겹침이 계산됩니다. 가능한 경우 여러 속성을 단일 속성으로 결합하면 인덱스 조회 횟수가 최소화되고 쿼리 지연 시간이 줄어듭니다.

예를 들어 이 쿼리는 두 개의 인덱스 조회와 한 개의 조인을 사용합니다.

MATCH (n) WHERE n.first_name='John' AND n.last_name='Doe' RETURN n

이 쿼리는 단일 인덱스 조회를 사용하여 동일한 정보를 검색합니다.

MATCH (n) WHERE n.name='John Doe' RETURN n

Neptune은 Neo4j와 다른 데이터 유형을 지원합니다.

Neptune이 지원하는 데이터 유형에 대한 Neo4j 데이터 유형 매핑
  • 논리적:   Boolean

    Neptune에서 Bool 또는 Boolean에 이것을 매핑하세요.

  • 숫자:   Number

    Neptune에서 이를 해당 숫자 속성의 모든 값을 지원할 수 있는 다음 Neptune OpenCypher 유형 중 가장 좁은 유형에 매핑하세요.

    Byte Short Integer Long Float Double
  • 텍스트:   String

    Neptune에서 String에 이것을 매핑하세요.

  • 특정 시점:

    Date Time LocalTime DateTime LocalDateTime

    Neptune에서 지원하는 다음 ISO-8601 형식 중 하나를 사용하여 Neptune에서 Date에 UTC로 매핑합니다.

    yyyy-MM-dd yyyy-MM-ddTHH:mm yyyy-MM-ddTHH:mm:ss yyyy-MM-ddTHH:mm:ssZ
  • 소요 시간: Duration

    필요한 경우 Neptune에서 이를 날짜 산술의 숫자 값에 매핑합니다.

  • 공간:   Point

    Neptune에서 이를 구성 요소 숫자 값에 매핑하면 각 값이 별도의 속성이 되거나 클라이언트 애플리케이션에서 해석할 수 있는 String 값으로 표현됩니다. 참고로 OpenSearch를 사용한 Neptune의 전체 텍스트 검색 통합으로 지리적 위치 속성을 인덱싱할 수 있습니다.

Neo4j에서 Neptune으로 다중값 속성 마이그레이션

Neo4j를 사용하면 단순 유형의 동종 목록을 노드와 엣지의 속성으로 저장할 수 있습니다. 이 목록에는 중복된 값이 포함될 수 있습니다.

그러나 Neptune은 정점 속성에 대해 집합 또는 단일 카디널리티만 허용하고 속성 그래프 데이터의 간선 속성에는 단일 카디널리티만 허용합니다. 따라서 중복 값이 포함된 Neo4j 노드 목록 속성을 Neptune 정점 속성으로 마이그레이션하거나 Neo4j 관계 목록 속성을 Neptune 엣지 속성으로 간단하게 마이그레이션할 수 없습니다.

값이 중복된 Neo4j 다중값 노드 속성을 Neptune으로 마이그레이션하기 위한 몇 가지 가능한 전략은 다음과 같습니다.

  • 중복된 값을 무시하고 다중값 Neo4j 노드 속성을 설정된 카디널리티 Neptune 정점 속성으로 변환합니다. 단, Neptune 세트는 원본 Neo4j 다중값 속성의 항목 순서를 반영하지 않을 수 있습니다.

  • 다중값 Neo4j 노드 속성을 Neptune 정점 문자열 속성에 있는 JSON 형식 목록의 문자열 표현으로 변환합니다.

  • 다중 값 속성 값 각각을 value 속성이 있는 별도의 정점으로 추출하고 속성 이름이 표시된 엣지를 사용하여 해당 정점을 상위 정점에 연결합니다.

이와 비슷하게 Neo4j 다중값 관계 속성을 Neptune으로 마이그레이션하기 위한 몇 가지 가능한 전략은 다음과 같습니다.

  • 다중값 Neo4j 관계 속성을 JSON 형식 목록의 문자열 표현으로 변환하고 Neptune 엣지 문자열 속성으로 저장합니다.

  • Neo4j 관계를 중간 정점에 연결된 들어오고 나가는 Neptune 엣지로 리팩터링합니다. 다중값 속성 값 각각을 value 속성이 있는 별도의 정점으로 추출하고 속성 이름이 표시된 엣지를 사용하여 해당 정점을 중간 정점에 연결합니다.

참고로 JSON 형식 목록의 문자열 표현은 OpenCypher 쿼리 언어에 불투명하지만 OpenCypher에는 문자열 값 내에서 간단한 검색을 허용하는 CONTAINS 술어가 포함되어 있습니다.

Neptune으로 마이그레이션할 때 Neo4j에서 데이터 내보내기

Neo4j에서 데이터를 내보내는 경우 APOC 프로시저를 사용하여 CSV 또는 GraphML로 내보냅니다. 다른 형식으로 내보내는 것도 가능하지만 Neo4j에서 내보낸 CSV 데이터를 Neptune 벌크 로드 형식으로 변환하는 오픈 소스 도구와 Neo4j에서 내보낸 GraphML 데이터를 Neptune 벌크 로드 형식으로 변환하는 오픈 소스 도구도 있습니다.

다양한 APOC 프로시저를 사용하여 Amazon S3로 데이터를 직접 내보낼 수도 있습니다. Amazon S3 버킷으로 내보내는 것은 기본적으로 비활성화되어 있지만 Neo4j APOC 설명서의 Amazon S3로 내보내기에 강조 표시된 프로시를 사용하여 활성화할 수 있습니다.

Neptune으로 마이그레이션할 때 Neo4j에서 데이터 가져오기

Neptune 벌크 로더를 사용하거나 openCypher와 같은 지원되는 쿼리 언어의 애플리케이션 로직을 사용하여 Neptune으로 데이터를 가져올 수 있습니다.

Neptune 벌크 로더는 모범 사례를 따르는 경우 최적화된 가져오기 성능을 제공하므로 많은 양의 데이터를 가져올 때 선호되는 접근 방식입니다. 벌크 로더는 두 가지 CSV 형식을 지원하며, 데이터 내보내기 섹션에서 언급한 오픈 소스 유틸리티를 사용하여 Neo4j에서 내보낸 데이터를 변환할 수 있습니다.

또한 OpenCypher를 사용하여 파싱, 변환 및 가져오기를 위한 사용자 지정 로직이 포함된 데이터를 가져올 수 있습니다. HTTPS 엔드포인트(권장)를 통해 또는 Bolt 드라이버를 사용하여 OpenCypher 쿼리를 제출할 수 있습니다.