기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Neptune과 Neo4j의 아키텍처에 대한 차이점
고객이 애플리케이션을 Neo4j에서 Neptune으로 마이그레이션하는 것을 처음 고려할 때 인스턴스 크기에 따라 비교를 수행하고 like-to-like 싶은 경우가 많습니다. 그러나 Neo4j와 Neptune의 아키텍처에는 근본적인 차이점이 있습니다. Neo4j는 EC2 인스턴스와 같은 동일한 컴퓨팅 리소스 집합에서 데이터 로드, 데이터ETL, 애플리케이션 쿼리, 데이터 스토리지 및 관리 작업이 모두 발생하는 접근 방식을 기반으로 all-in-one 합니다.
반면 Neptune은 아키텍처가 책임을 분리하고 리소스가 분리되어 동적으로 독립적으로 확장할 수 있는 OLTP 집중 그래프 데이터베이스입니다.
Neo4j에서 Neptune으로 마이그레이션할 때 애플리케이션의 데이터 내구성, 가용성 및 확장성 요구 사항을 결정하세요. Neptune의 클러스터 아키텍처는 높은 내구성, 가용성 및 확장성이 필요한 애플리케이션의 설계를 단순화합니다. Neptune의 클러스터 아키텍처를 이해하면 이러한 요구 사항을 충족하는 Neptune 클러스터 토폴로지를 설계할 수 있습니다.
Neo4j의 클러스터 아키텍처
많은 프로덕션 애플리케이션은 Neo4j의 인과 클러스터링
코어 서버는 Raft 프로토콜을 사용하여 데이터를 복제하여 데이터 내구성과 내결함성을 제공합니다.
읽기 전용 복제본은 트랜잭션 로그 전달을 사용하여 데이터를 비동기적으로 복제하여 읽기 처리량이 높은 워크로드를 처리합니다.
코어 서버든 읽기 전용 복제본이든 클러스터의 모든 인스턴스에는 그래프 데이터의 전체 사본이 포함됩니다.
Neptune의 클러스터 아키텍처
Neptune 클러스터는 기본 라이터 인스턴스와 최대 15개의 읽기 전용 복제본 인스턴스로 구성됩니다. 클러스터의 모든 인스턴스는 인스턴스와는 별개인 동일한 기본 분산 스토리지 서비스를 공유합니다.
기본 라이터 인스턴스는 데이터베이스에 대한 모든 쓰기 작업을 조정하며 수직적으로 규모를 조정할 수 있어 다양한 쓰기 워크로드를 유연하게 지원합니다. 또한 읽기 작업도 지원합니다.
-
읽기 전용 복제본 인스턴스는 기본 스토리지 볼륨에서 읽기 작업을 지원하며, 높은 읽기 워크로드를 지원하도록 수평적으로 규모를 조정할 수 있습니다. 또한 기본 인스턴스의 장애 조치 대상 역할을 하여 고가용성을 제공합니다.
참고
쓰기 워크로드가 많다면 읽기 복제본 인스턴스를 라이터 인스턴스와 같은 크기로 규모를 조정하여 리더가 데이터 변경에 일관성을 유지할 수 있도록 하는 것이 가장 좋습니다.
기본 스토리지 볼륨은 데이터베이스에 있는 데이터가 증가함에 따라 스토리지 용량을 자동으로 규모를 조정하여 최대 128테비바이트(TiB)의 스토리지가 됩니다.
인스턴스 크기는 동적이고 독립적입니다. 클러스터가 실행되는 동안 각 인스턴스의 크기를 조정할 수 있으며, 클러스터가 실행되는 동안 읽기 전용 복제본을 추가하거나 제거할 수 있습니다.
Neptune Serverless 기능은 수요 증가 및 감소에 따라 컴퓨팅 용량을 자동으로 스케일 업 및 다운할 수 있습니다. 이렇게 하면 관리 오버헤드를 줄일 수 있을 뿐만 아니라, 성능 저하나 오버프로비저닝 없이도 대규모 수요 급증을 처리하도록 데이터베이스를 구성할 수 있습니다.
Neptune 클러스터는 최대 7일간 중지할 수 있습니다.
또한 Neptune은 자동 크기 조정을 지원하여 워크로드에 따라 리더 인스턴스 크기를 자동으로 조정합니다.
Neptune의 글로벌 데이터베이스 기능을 사용하면 최대 5개의 다른 리전에 클러스터를 미러링할 수 있습니다.
Neptune은 설계를 통한 내결함성을 지니고 있습니다.
클러스터의 모든 인스턴스에 데이터 스토리지를 제공하는 클러스터 볼륨은 단일 에서 여러 가용 영역(AZs)에 걸쳐 있습니다 AWS 리전. 각 AZ는 클러스터 데이터의 전체 사본을 포함합니다.
기본 인스턴스를 사용할 수 없게 되면 Neptune은 일반적으로 30초 이내에 데이터 손실 없이 기존 읽기 전용 복제본을 통해 자동으로 장애 조치를 처리합니다. 클러스터에 기존 읽기 전용 복제본이 없다면 Neptune은 데이터 손실 없이 새 기본 인스턴스를 자동으로 프로비저닝합니다.
이 모든 것이 의미하는 바는 Neo4j 인과 클러스터에서 Neptune으로 마이그레이션할 때 높은 데이터 내구성과 고가용성을 위해 클러스터 토폴로지를 명시적으로 설계할 필요가 없다는 것입니다. 따라서 다음과 같은 몇 가지 방법을 통해 예상되는 읽기 및 쓰기 워크로드와 향상된 가용성 요구 사항에 맞게 클러스터 크기를 조정할 수 있습니다.
읽기 작업의 규모를 조정하려면 읽기 전용 복제본 인스턴스를 추가하거나 Neptune Serverless 기능을 활성화하세요.
가용성을 개선하려면 여러 가용 영역()을 통해 클러스터의 기본 인스턴스와 읽기 전용 복제본을 배포합니다AZs.
장애 조치 시간을 줄이려면 기본 인스턴스의 장애 조치 대상으로 사용할 수 있는 읽기 전용 복제본 인스턴스를 하나 이상 프로비저닝해야 합니다. 각 복제본에 우선순위를 지정함으로써 장애 이후 기본 인스턴스로 승격할 읽기 복제본 순서를 사용자 지정할 수 있습니다. 기본 인스턴스로 승격되는 경우 장애 조치 대상이 애플리케이션의 쓰기 워크로드를 처리할 수 있는 인스턴스 클래스를 갖도록 하는 것이 가장 좋습니다.