Overview

These scripts are for build testing, and evaluating DBT-2 at a small warehouse scale factor. While DBT-2 is compatible with multiple database systems, this initial set of scripts works only for the subset described here. Note that these scripts prefer Podman over Docker but you can specify the engine by setting the ENGINE environment variable to podman or docker, resp.

  • appimage-build - Build the DBT-2 lite AppImage.
  • appimage-prepare - Build a container image to be used for creating an
    AppImage.
  • build-all - Run all of the build scripts to prepare all container images.
  • build-client - Build a container image for the client transaction manager.
  • build-database - Build a container image with a 1 warehouse database.
  • build-driver - Build a container image for the driver.
  • compile-dbt2 - Simply attempt to compile the local source code.
  • prepare-image - Build a container image to be further expanded by the other
    components in the kit.
  • run-test - Run a test using the run-workload script.
  • shell - Helper script to open a shell in any of the DBT-2 container images.
  • start-client - Script to start the client, and create the container image
    if not done already.
  • start-database - Script to start the database, and create the container
    image if not done already.
  • start-driver - Script to execute the driver for a short 2 minute test, and
    create the image if not done already.

Testing binaries

These brief steps are intended to describe how to test the bare minimal individual binaries of the kit. In other words, how to run the workload without capturing any additional data such at system statistics, software profiles, or database statistics.

PostgreSQL

Create a 1 warehouse database and run a test in a 3-tier configuration:

tools/start-database
tools/start-client <database address>
tools/start-driver <client address>

Testing the complete kit

These brief steps are intended to describe how to set up containers such that they can be treated with full virtual machines. In other words, this allows tests scripts to collect system stats, system profiles, and generating reports.

The results will be copied to tools/results.

Testing the complete kit in containers may need more advanced knowledge of Docker or Podman, such as have a host environment capable of running containers that use systemd as entry point of a container.

Testing options

The EXTRAARGS environment variable can be set to pass extra arguments to the dbt2-run-workload script. Normally one would just set the arguments directly when running the dbt2-run-workload script.

Set TIERS=2 in the environment to test the event-driven multi-process altered mode driver. It is also recommended to also set EXTRAARGS to use the flags -A -t 1. See the dbt2-run-workload script help for more details on the options.

Notes for collecting profiles

The containers expect a Linux host to also set kernel.perf_event_paranoid = -1 on the host operating system, which will be inherited by the containers.

CockroachDB

Create all the container images for each tier with a 1 warehouse database:

tools/build-all 1 pgsql

Execute a test:

tools/run-3tier-test 1 pgsql

PostgreSQL

Create all the container images for each tier with a 1 warehouse database:

tools/build-all 1 pgsql

Execute a test:

tools/run-3tier-test 1 pgsql

YugabyteDB

Create all the container images for each tier with a 1 warehouse database:

tools/build-all 1 yugabyte

Execute a test:

tools/run-3tier-test 1 yugabyte