Обычно я не являюсь большим поклонником бенчмарков, но этот интересен по нескольким причинам:
- он опубликован консалтинговой компанией, а не вендором
- он воспроизводит современный сценарий использования (IoT ingest от датчиков), где применимы как SQL, так и NoSQL альтернативы
- они оптимизируют для каждой базы данных, так что это также документирует лучшую конфигурацию для данной рабочей нагрузки. Я внес свой вклад в оптимизацию для PostgreSQL и для YugabyteDB.
Эталон находится здесь:
https://github.com/MaibornWolff/database-performance-comparison
а в этой статье блога показано, как запустить его на AWS Kubernetes.
Я запускаю кластер EKS с 32 vCPU и 64 ГБ на 4 узлах:
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 для мастеров и 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 по умолчанию, таблица хэш-шаринга будет разбита на один планшет на каждый процессор (например, 12 на 3 сервера с 4 vCPU на сервер). Возможно, я отправлю 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
Это важно для понимания производительности. Здесь у нас нет чтений, только записи: вставка в LSM-дерево DocDB. Это происходит потому, что соединение определяет yb_enable_upsert_mode=on: мы не проверяем наличие существующих строк. Пожалуйста, не устанавливайте это вслепую для любой программы. Здесь, поскольку я вставляю с последовательностью, у меня никогда не будет дубликатов, поэтому нет необходимости проверять конфликты по первичному ключу. Есть некоторые чтения и обновления последовательности, но благодаря кэшированию накладные расходы незначительны. 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)
Я продолжу эту серию с части Query. Здесь речь пойдет о самом важном в IoT: масштабируемом получении данных.
очистка
Чтобы очистить лабораторию, вы можете уменьшить масштаб до нуля узлов (чтобы остановить экземпляры EC2), удалить развертывание эталона (чтобы настроить его снова), удалить YugabyteDB (и удалить постоянные тома), удалить стеки CloudFormation, используемые EKS, и завершить кластер Kubernetes.
# 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
Обратите внимание, что вы можете использовать его для тестирования на управляемых базах данных, просто изменив строку подключения в config.yaml, как Aurora, или ваше собственное развертывание YugabyteDB или других. Вызовы выполняются в пакетном режиме, и вы можете запустить много рабочих.