yugabyte-db VS geo-distributed-messenger

In a distributed database, NTP synchronization is essential and should be carefully monitored and fixed in case of any failures. To allow some time drift, a maximum clock skew is set. This skew should be kept low enough for performance to avoid too many read retries and high enough for availability to avoid any node evictions caused by network errors. It is a good idea to check the NTP synchronization when starting a YugabyteDB node. This will be implemented by 22255.

Different ways exist to implement locking mechanisms on arbitrary values. For example, PostgreSQL provides pg_advisory_lock, MySQL has get_lock, Oracle Database offers dbms_lock, and SQL Server use sp_getapplock. For YugabyteDB, the PostgreSQL version is not currently supported (#3642).

When it comes to production, it is recommended to use the official docker image for YugabyteDB. You can either obtain it from Docker Hub or build it yourself using the Dockerfile. If you are using CI/CD pipelines, it may be helpful to reduce the size of the image. One way to do this is to remove the debug symbols from the compiled binaries. These symbols are useful for troubleshooting but not essential for automated testing. If you encounter any issues, you can easily reproduce them using the regular image.

YugabyteDB is a transactional database that brings together four must-have needs of cloud native apps – namely SQL as a flexible query language, low-latency performance, continuous availability, and globally-distributed scalability. Other databases do not serve all 4 of these needs simultaneously.

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.

My development journey of the first version of the geo-distributed messenger has ended. So in this last article of the series, I’d like to talk about multi-region database deployment options that were validated for the messenger.

Suppose Ms. Blue, one of my application users, is vacationing in the Tampa Bay area of Florida. She promised not to open my corporate Slack-like messenger (the geo-distributed app I’m building) while on vacation.

When I start a VM in Google Cloud, the VM executes a special startup script that installs required libraries, builds and runs the microservices, and configures Kong Gateway. These are the steps for Kong setup:

I developed the habit of coding the geo-distributed messenger two days a week (strictly during business hours, as evenings are for my mischievous sons and dear wife!). So, here is the latest summary, for those of you who are following my development journey.

Ahoy, matey! I'm back from a short vacation and ready to continue my pet project: geo-distributed messenger in Java!

Let me walk you through the main components of the first version of my messenger application. Here are its GitHub coordinates.