AWS EKS에서 MaibornWolff의 분산 SQL에 대한 IoT 벤치마크

나는 보통 벤치마크를 좋아하지 않지만 이것은 여러 가지 이유로 흥미롭습니다.

공급업체가 아닌 컨설팅 회사에서 게시한 것입니다

.

SQL 및 NoSQL 대안이 모두 유효한 최신 사용 사례(센서에서 IoT 수집)를 재현합니다

.

각 데이터베이스에 대해 최적화하여 이 워크로드에 가장 적합한 구성도 문서화합니다. PostgreSQL 및 YugabyteDB

에 대해 최적화하기 위해contributed 했습니다.

벤치마크는 다음과 같습니다.
https://github.com/MaibornWolff/database-performance-comparison
이 블로그 게시물은 AWS Kubernetes에서 실행하는 방법을 보여줍니다.

4개 노드에서 vCPU 32개 및 64GB로 EKS 클러스터를 시작합니다.

eksctl create cluster --name yb-demo3 --version 1.21 \
--region eu-west-1 --zones eu-west-1a,eu-west-1b,eu-west-1c \
--nodegroup-name standard-workers --node-type c5.2xlarge \
--nodes 4 --nodes-min 0 --nodes-max 4 --managed

이것은 다른 데이터베이스에 결과를 게시하기 위해 내 MaibornWolff를 사용한 클러스터보다 작지만 문제가 되지 않습니다. 나는 YugabyteDB의 확장성을 알고 있으며 사용자가 독립적인 테스트 결과로 이동하는 것을 선호합니다.

MaibornWolff 프로젝트로 이동합니다.

git clone https://github.com/MaibornWolff/database-performance-comparison.git
cd database-performance-comparison

내 클러스터에 맞게 제한된 리소스로 YugabyteDB를 설치하지만(원래 CPU 선언은 마스터의 경우 2이고 tserver의 경우 7입니다.) 다시 말하지만 처리량을 확인하는 것이 아니라 모든 구성이 최적인지 확인하는 것입니다.

helm install yugabyte yugabytedb/yugabyte -f dbinstall/yugabyte-values.yaml \
--set storage.master.storageClass=gp2,storage.tserver.storageClass=gp2 \
--set resource.master.requests.cpu=0.5,resource.tserver.requests.cpu=4 \
--set gflags.master.enable_automatic_tablet_splitting=false \
--set gflags.tserver.enable_automatic_tablet_splitting=false \
--version 2.15.1

하나의 태블릿으로 시작하고 벤치마크 중에 자동 분할이 시작되는 것을 원하지 않기 때문에 태블릿 분할도 비활성화합니다. 그것 없이 기본적으로 모두 num_shards 및 num_tablets로 해시 샤딩된 테이블은 CPU당 하나의 태블릿으로 분할됩니다(예: 서버당 4개의 vCPU가 있는 3개의 서버에서 12개). 아마도 PR을 제출하여 yugabyte-values.yaml에서 자동 분할을 비활성화할 것입니다.

모두 시작되었는지 확인하고 콘솔의 URL을 표시합니다.

kubectl get all
echo $(kubectl get svc --field-selector "metadata.name=yb-master-ui"  -o jsonpath='http://{.items[0].status.loadBalancer.ingress[0].hostname}:{.items[0].spec.ports[?(@.name=="http-ui")].port}')

또한 yb-master 및 yb-tserver를 시작하는 데 사용되는 플래그를 확인합니다.

time python run.py insert --target yugabyte_sql -w 1 -r 1 \
 --clean --batch 1000 --primary-key sql \
 --num-inserts 31250000

이것이 실행되는 동안 몇 가지 통계를 표시합니다.

kubectl exec -i yb-tserver-0 -c yb-tserver --\
 /home/yugabyte/bin/ysqlsh -h yb-tserver-0.yb-tservers.default \
 -d postgres <<'SQL'
\! curl -s https://raw.githubusercontent.com/FranckPachot/ybdemo/main/docker/yb-lab/client/ybwr.sql > ybwr.sql
\i ybwr.sql
SQL

이는 성능을 이해하는 데 중요합니다. 여기서는 읽기가 없고 쓰기만 합니다. DocDB LSM-Tree에 삽입합니다. 이는 connection이 yb_enable_upsert_mode=on를 정의하기 때문입니다. 기존 행을 확인하지 않습니다. 어떤 프로그램에 대해서도 맹목적으로 설정하지 마십시오. 여기서는 시퀀스로 삽입하기 때문에 중복이 발생하지 않으므로 기본 키에 대한 충돌을 확인할 필요가 없습니다. 시퀀스에 일부 읽기 및 업데이트가 있지만 caching 덕분에 오버헤드는 무시할 수 있습니다. YugabyteDB는 NoSQL(빠른 수집)의 확장성과 모든 SQL 기능(여기서 순서)을 결합합니다.

삽입 결과는 생각을 보여줍니다. 여기서는 단일 작업자로부터 초당 38500개의 행이 삽입됩니다.

 Workers Min     Max     Avg
 1       38570   38570   38569

모든 행이 있는지 확인합니다.

kubectl exec -it yb-tserver-0 -c yb-tserver --\
 /home/yugabyte/bin/ysqlsh -h yb-tserver-0.yb-tservers.default \
 -d postgres -c "
select count(*) from events
"

  count
----------
 31250000
(1 row)

쿼리 부분으로 이 시리즈를 계속하겠습니다. 이것은 IoT에서 가장 중요한 확장 가능한 데이터 수집에 관한 것입니다.

대청소

랩을 정리하려면 노드 0개로 축소(EC2 인스턴스 중지), 벤치마크 배포 제거(다시 조정), YugabyteDB 제거(및 영구 볼륨 제거), EKS에서 사용하는 CloudFormation 스택 제거 및 쿠버네티스 클러스터 종료

# scale down to stop nodes
eksctl scale nodegroup --cluster=yb-demo3 --nodes=0  --name=standard-workers

# deinstall the benchmark
helm delete dbtest

# deinstall yugabyte
kubectl delete pvc --all
helm delete yugabyte 

# cleanup CloudFormation stacks
aws cloudformation delete-stack --stack-name eksctl-yb-demo3
aws cloudformation delete-stack --stack-name eksctl-yb-demo3-cluster
aws cloudformation delete-stack --stack-name eksctl-yb-demo3-nodegroup-standard-workers
eksctl delete cluster --region=eu-west-1 --name=yb-demo3

결과

벤치마크 결과에 대해
https://github.com/MaibornWolff/database-performance-comparison#insert-performance



Aurora와 같은 config.yaml의 연결 문자열이나 YugabyteDB 또는 기타 자체 배포를 변경하기만 하면 관리형 데이터베이스에서 테스트하는 데 사용할 수 있습니다. 호출은 일괄 처리되며 많은 작업자를 실행할 수 있습니다.