OrientDB-성능 조정

이 장에서는 OrientDB를 사용하는 애플리케이션을 최적화하는 방법에 대한 몇 가지 일반적인 팁을 얻을 수 있습니다. 다양한 유형의 데이터베이스에 대한 성능을 향상시키는 세 가지 방법이 있습니다.

Document Database Performance Tuning − 모든 새 문서에 대한 문서 생성을 방지하는 기술을 사용합니다.
Object Database Performance Tuning − 일반적인 기술을 사용하여 성능을 향상시킵니다.
Distributed Configuration Tuning − 분산 구성에서 성능을 향상시키기 위해 다른 방법론을 사용합니다.

메모리, JVM 및 원격 연결 설정을 변경하여 일반 성능 튜닝을 수행 할 수 있습니다.

메모리 설정

성능 향상을위한 메모리 설정에는 다양한 전략이 있습니다.

서버 및 임베디드 설정

이 설정은 직접 사용하여 임베디드 모드에서 OrientDB를 사용하여 Java 애플리케이션이 실행되는 서버 구성 요소 및 JVM 모두에 유효합니다. plocal.

튜닝에서 가장 중요한 것은 메모리 설정이 올바른지 확인하는 것입니다. 실제 차이를 만들 수있는 것은 메모리 매핑에 사용되는 가상 메모리와 힙 사이의 올바른 균형이며, 특히 인 메모리 캐시 구조가 원시 IO보다 적은 수의 대규모 데이터 세트 (GB, TB 등)에서 사용됩니다.

예를 들어 Java 프로세스에 최대 8GB를 할당 할 수있는 경우 일반적으로 작은 힙과 큰 디스크 캐시 버퍼 (오프 힙 메모리)를 할당하는 것이 좋습니다.

힙 메모리를 늘리려면 다음 명령을 시도하십시오.

java -Xmx800m -Dstorage.diskCache.bufferSize=7200 ...

그만큼 storage.diskCache.bufferSize 설정 (이전 "로컬"스토리지 사용시 file.mmap.maxMemory)는 MB 단위이며 디스크 캐시 구성 요소에 사용할 메모리 양을 알려줍니다. 기본적으로 4GB입니다.

NOTE − 최대 힙과 디스크 캐시 버퍼의 합이 너무 높으면 OS가 크게 느려지면서 스왑 될 수 있습니다.

JVM 설정

JVM 설정은 server.sh (및 server.bat) 배치 파일로 인코딩됩니다. 사용량 및 hw / sw 설정에 따라 JVM을 조정하도록 변경할 수 있습니다. server.bat 파일에 다음 줄을 추가합니다.

-server -XX:+PerfDisableSharedMem

이 설정은 JVM에 대한 디버그 정보 쓰기를 비활성화합니다. JVM을 프로파일 링해야하는 경우이 설정을 제거하면됩니다.

원격 연결

원격 연결을 사용하여 데이터베이스에 액세스 할 때 성능을 향상시키는 여러 가지 방법이 있습니다.

가져 오기 전략

원격 데이터베이스로 작업 할 때 사용 된 가져 오기 전략에주의를 기울여야합니다. 기본적으로 OrientDB 클라이언트는 결과 집합에 포함 된 레코드 만로드합니다. 예를 들어 쿼리가 100 개의 요소를 반환하지만 클라이언트에서 이러한 요소를 교차하는 경우 OrientDB 클라이언트는 누락 된 각 레코드에 대해 서버에 한 번 이상의 네트워크 호출을 사용하여 요소를 느리게로드합니다.

네트워크 연결 풀

기본적으로 각 클라이언트는 하나의 네트워크 연결 만 사용하여 서버와 통신합니다. 동일한 클라이언트의 여러 스레드가 동일한 네트워크 연결 풀을 공유합니다.

여러 스레드가있는 경우 무료 네트워크 연결을 기다리는 데 많은 시간이 소요되므로 병목 현상이 발생할 수 있습니다. 이것이 네트워크 연결 풀을 구성하는 것이 중요한 이유입니다.

구성은 매우 간단합니다.

minPool− 연결 풀의 초기 크기입니다. 기본값은 전역 매개 변수 "client.channel.minPool"로 구성됩니다.
maxPool− 연결 풀이 도달 할 수있는 최대 크기입니다. 기본값은 전역 매개 변수 "client.channel.maxPool"로 구성됩니다.

모든 풀 연결이 사용 중이면 클라이언트 스레드는 첫 번째 사용 가능한 연결을 기다립니다.

데이터베이스 속성을 사용한 구성 명령의 예입니다.

database = new ODatabaseDocumentTx("remote:localhost/demo"); 
database.setProperty("minPool", 2); 
database.setProperty("maxPool", 5);  

database.open("admin", "admin");

분산 구성 조정

분산 구성에서 성능을 향상시키는 방법에는 여러 가지가 있습니다.

거래 사용

그래프를 업데이트하더라도 항상 트랜잭션에서 작업해야합니다. OrientDB를 사용하면 외부에서 작업 할 수 있습니다. 일반적인 경우는 읽기 전용 쿼리이거나 실패시 대량 및 비 동시 작업을 복원 할 수 있습니다. 분산 구성에서 실행할 때 트랜잭션을 사용하면 대기 시간을 줄이는 데 도움이됩니다. 이는 분산 작업이 커밋 시간에만 발생하기 때문입니다. 대기 시간으로 인해 하나의 큰 작업을 배포하는 것이 작은 여러 작업을 전송하는 것보다 훨씬 효율적입니다.

복제 대 샤딩

OrientDB 분산 구성은 전체 복제로 설정됩니다. 확장 읽기에는 동일한 데이터베이스 복사본이있는 여러 노드가 있어야합니다. 실제로 각 서버는 읽기 및 쿼리 실행에 독립적입니다. 10 개의 서버 노드가있는 경우 읽기 처리량은 10 배입니다.

쓰기의 경우 그 반대입니다. 전체 복제가있는 여러 노드가 있으면 복제가 동기식 인 경우 작업 속도가 느려집니다. 이 경우 여러 노드에서 데이터베이스를 분할하면 노드의 하위 집합 만 쓰기에 관련되므로 쓰기를 확장 할 수 있습니다. 또한 하나의 서버 노드 HD보다 큰 데이터베이스를 가질 수 있습니다.

쓰기 확장

네트워크가 느리고 동기식 (기본) 복제가있는 경우 지연 비용을 지불 할 수 있습니다. 실제로 OrientDB가 동기식으로 실행될 때 최소한writeQuorum. 즉, writeQuorum이 3이고 노드가 5 개인 경우 코디네이터 서버 노드 (분산 작업이 시작된 위치)는 클라이언트에 응답을 제공하기 위해 3 개 이상의 노드에서 응답을 기다려야합니다.

일관성을 유지하려면 writeQuorum을 과반수로 설정해야합니다. 5 개 노드가있는 경우 대부분은 3 개입니다. 4 개 노드에서도 3 개입니다. writeQuorum을 4 또는 5 대신 3으로 설정하면 대기 시간 비용을 줄이고 일관성을 유지할 수 있습니다.

비동기 복제

속도를 높이기 위해 대기 시간 병목 현상을 제거하도록 비동기 복제를 설정할 수 있습니다. 이 경우 코디네이터 서버 노드는 로컬에서 작업을 실행하고 클라이언트에게 응답을 제공합니다. 전체 복제는 백그라운드에 있습니다. 쿼럼에 도달하지 않은 경우 변경 사항이 투명하게 롤백됩니다.

읽기 확장

이미 대부분의 노드에 writeQuorum을 설정 한 경우 readQuorum1 (기본값)입니다. 이렇게하면 모든 읽기 속도가 빨라집니다.