gh-ost VS yugabyte-db

I’ve been through multiple incidents where everything worked fine in the testing environment but ended up locking the production database for minutes when deployed. A category of open-source tools called OSC (Online Schema Change) exists to mitigate such pain, like gh-ost used by GitHub and OSC used by Meta. They work by creating a set of "ghost tables" to apply the migrations, copy over old data from the original tables, and catch up with new writes simultaneously. When all old data is migrated, you can trigger a cutover to make the "ghost tables" production. Check the post below for a great introduction and comparison:

Sounds like it's basically explained in the gh-ost readme https://github.com/github/gh-ost#how

I think it amounts to "use views to decouple access to the table with a fixed interface" and "use triggers for migrating data between tables"

Gh-ost is the new hotness. Simple to use and lots of great features: https://github.com/github/gh-ost

If the performance of the db is a concern during migrations (locking, high cpu consumption for large writes) there are tools that can help and do similiar to what your describing but with the benefit that they are battle tested tools. This one spring to mind https://github.com/github/gh-ost there are other options as well and its worth reading the trade off docs

Not sure which version of MySQL you're using, but one approach would be to use a tool like pt-online-schema-change (from Percona) or g-host -- which will create a duplicate table and then swap it in place of the original table. It's a safer approach when operating in production environments. Here's a good comparison of the tools many people use https://planetscale.com/docs/learn/online-schema-change-tools-comparison

No, especially on large tables with billions of records. They make online schema changes impossible. More details: https://github.com/github/gh-ost/issues/331#issuecomment-266...

Tip #4: Consider slow-running migrations. Some tables can be so large that the traditional migration way is simply not a viable option for them. In such cases, you can consider embedding the data migration code right into your application, or use a special utility like GitHub's online schema migration for MySQL. A slow-running migration can work in production for days or even weeks. It gradually converts the data by small chunks, so you can carefully balance the load on the database while making sure that it doesn't cause slowness or downtime.

GitHub gh-ost

Actually I never tried but I was scared by the small print of GH not using RDS themselves [1] and Ghost relying on lower-level features that might be not easily available in RDS. Also I had the impression you have to setup a normal non-RDS replica attached to your RDS master?

[1] https://github.com/github/gh-ost/blob/master/doc/rds.md

It is possible to apply Batched Nested Loop but with additional code that checks the range of the outer bigint and compare it only if it matches the range of integer. This has been added in YugabyteDB 2.21 with #20715 YSQL: Allow BNL on joins over different integer types to help migrations from PostgreSQL with such datatype inconsistencies.

It can be done like https://github.com/yugabyte/yugabyte-db/ has.

Therefore, interleaving or co-partitioning is probably not necessary, and would reduce agility and scalability more than improving the performance. Unless you have a good reason for it that you can share on Issue #79. But, first, test and tune the queries to see if you need something else.

This is a workaround, not supported. I've opened the following issue to get it solve in the YugabyteDB deployment: https://github.com/yugabyte/yugabyte-db/issues/19389

Note that there may still be a need for bitmaps, especially with disjunctions (OR) as the following is about conjunction (AND), and it can still be implemented, differently than PostgreSQL. This is tracked by #4634.

FROM almalinux:8 as build RUN dnf -y update &&\ dnf groupinstall -y 'Development Tools' # get YugabyteDB sources ARG YB_TAG=2.18 RUN git clone --branch ${YB_TAG} https://github.com/yugabyte/yugabyte-db.git WORKDIR yugabyte-db # install dependencies and compilation tools RUN dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm RUN dnf -y install epel-release libatomic rsync python3-devel cmake3 java-1.8.0-openjdk maven npm golang gcc-toolset-12 gcc-toolset-12-libatomic-devel patchelf glibc-langpack-en ccache vim wget python3.11-devel python3.11-pip clang ncurses-devel readline-devel libsqlite3x-devel RUN mkdir /opt/yb-build RUN chown "$USER" /opt/yb-build # Install Python 3 RUN alternatives --remove-all python3 RUN alternatives --remove-all python RUN alternatives --install /usr/bin/python python /usr/bin/python3.11 3 RUN alternatives --install /usr/bin/python3 python3 /usr/bin/python3.11 3 # add #include "pg_yb_utils.h" to src/postgres/src/pl/plpython/plpy_procedure.c RUN sed -e '/#include "postgres.h"/a#include "pg_yb_utils.h"' -i src/postgres/src/pl/plpython/plpy_procedure.c # if using python > 3.9 remove #include and #include from src/postgres/src/pl/plpython/plpython.h RUN sed -e '/#include /d' -e '/#include /d' -i src/postgres/src/pl/plpython/plpython.h # add '--with-python', to python/yugabyte/build_postgres.py under the configure_postgres method RUN sed -e "/'\.\/configure',/a\ '--with-python'," -i python/yugabyte/build_postgres.py # Build and package the release RUN YB_CCACHE_DIR="$HOME/.cache/yb_ccache" ./yb_build.sh -j$(nproc) --clean-all --build-yugabyted-ui --no-linuxbrew --clang15 -f release RUN chmod +x bin/get_clients.sh bin/parse_contention.py bin/yb-check-consistency.py RUN YB_USE_LINUXBREW=0 ./yb_release --force WORKDIR / RUN mv /yugabyte-db/build/yugabyte*.tar.gz /yugabyte.tgz

You have seen me using the official YugabyteDB Docker image extensively. This image is suitable for various purposes, including labs, development, testing, and even production. In the past, we used to create it internally due to its seamless integration with our build process. However, some companies prefer to construct the image on their own, which is indeed a commendable practice. After all, it's not advisable to run random images with root privileges on your servers. As a result, we have made a significant alteration by introducing a refined Dockerfile to our Github repository.

Of course, I can guess from the function names, but YugabyteDB is Open Source and I can search for them. What happens here is that I didn't declare a Primary Key for my table and then an internal one (ybctid) is generated, because secondary indexes need a key to address the table row. This ID generation calls /dev/urandom. I made this simple example to show that low-level traces can give a clue about high level data model problems.

To show that it is not difficut to understand what you run, when in a PostgreSQL-compatible database, I'll look at the HammerDB benchmark connected to YugabyteDB. HammerDB has no specific code for it but YugabyteDB is PostgreSQL-compatible (it uses PostgreSQL code on top of distributed storage and transaction).