When developing applications and distributed systems, understanding and implementing distributed job queues can dramatically improve your infrastructure and ensure your apps remain robust, scalable, and efficient. This blog demonstrates how you can design a simple ordered distributed job queue using YugabyteDB, and covers architecture, advantages, and typical applications.
Adopting AI to automate release note creation, the software development teams at YugabyteDB have significantly streamlined their processes. By harnessing OpenAI’s GPT-4, they now generate precise, user-friendly documentation from extensive code changes, enhancing both efficiency and readability for end users.
Server racks can be strategically utilized as fault domains to boost resilience and ensure high availability in on-premise YugabyteDB deployments. It remains up despite rack outages by spreading data across multiple racks. Read our blog to learn how to configure and deploy nodes across racks.
In distributed databases like YugabyteDB, managing unique, sequential numbers across multiple applications can introduce latency. This blog explores the different ways YugabyteDB makes sequence generation efficient and offers insights on enhancing performance in distributed setups.
Despite advancements in public clouds, region and zone outages still occur once or twice a year. This blog offers best practices to improve performance and reduce latencies in a multi-region deployment.
In a distributed database, data is split into multiple tablets which reside on different nodes. So it is not just tables, but indexes, that are distributed across nodes. So let’s examine how to optimally design distributed indexes to get the best query performance.
In storage systems based on LSM/MVCC, when a record is deleted, it’s not immediately removed. A delete marker (typically called a Tombstone) is placed on the record. As the number of tombstones increases, it could adversely affect the performance of a scan. In this blog, we are going to understand this problem and come up with solutions to address it.
In a previous blog, we developed an application-level sharding layout to avoid hotspots. With that layout in mind, where order is maintained within each shard, let’s discuss how to design a query to return data with pagination while maintaining the global ordering.
Some data model choices in distributed databases cause data to grow in one node before it moves to another node. This will cause one node to become a hotspot for reads and writes. This article explains how to avoid that.
