Geo-Distribution in YugabyteDB: Engineering Around the Physics of Latency
This blog examines the geo-distributed deployment topologies offered with YugabyteDB that can future-proof your data infrastructure and support your app’s needs.
This blog examines the geo-distributed deployment topologies offered with YugabyteDB that can future-proof your data infrastructure and support your app’s needs.
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.
To illustrate how to build a geo-distributed application, we will use as an example a Slack-like messaging app. This step-by-step guide starts with the distributed application and API layers, continues on to the distributed SQL database, and finishes with the need/purpose of the global cloud load balancer.
In an earlier blog, we broke down the definition of geo-distributed apps. So now let’s compare and contrast geo-distributed apps those apps that are deployed within a single data center or availability zone. A good way to make this comparison to understand the differences and find the similarities is to drill down into the architecture.
So what is a geo-distributed app? It is generally defined as an app that spans multiple geographic locations for high availability and resiliency. However, Iet’s expand (and then break down) that definition for a better understanding.
I’ve been working with distributed systems, platforms, and databases for the last seven years. Back in 2015, many architects began using distributed databases to scale beyond the boundaries of a single machine or server. They selected such a database for its horizontal scalability, even if its performance remained comparable to a conventional single-server database.
Now, with the rise of cloud native applications and serverless architecture, distributed databases need to do more than provide horizontal scalability.
…
This post is an in-depth look at the various techniques that applications needing low latency and high availability can leverage while using a geo-distributed SQL database like YugabyteDB so that the negative impacts of a high-latency, unreliable Wide Area Network (WAN) are minimized.
This post delves into the technical requirements of fast-growing geo-distributed applications with low latency reads and explores the limitations of Amazon DynamoDB for this use case, as well as alternative solutions such as MongoDB, Apache Cassandra, and YugabyteDB, a high-performance distributed SQL database.
YugabyteDB’s compatibility with the Redis API enhances data replication and consistency, offering a ‘unified cache + database’ solution. It simplifies data sharding, supports large datasets without full memory reliance, and provides polyglot persistence for diverse workloads.