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.
Let’s see how to capture pg_stat_statements from all the nodes in a persistent table to use for analysis. The data can then be stored in YugabyteDB tables, accessible from any node unless purged. Want to see how it can be done?
YugabyteDB for Python (Django) app can achieve high availability (HA) and handle a cloud outage. To demonstrate this, we will simulate an outage in Google Cloud Platform (GCP) on one of the Yugabyte database nodes to see how YugabyteDB handles the downtime.
Every SQL execution in PostgreSQL and therefore in YugabyteDB YSQL takes time to process. A common way to identify how much is time spent on processing is to use the pg_stat_statements view in the database. However, the time visible in pg_stat_statements might differ from the time a database client registers for the execution. Where does this difference come from? Let’s take a look.
As you look to build a streaming application that scales, there are many database options to choose from. If you’re looking for a high-performance database that can handle large-scale data, YugabyteDB,
is a great option. In this blog, we will build an application with YugabyteDB and Django, using the PubNub market order data stream. You will see how you can use YugabyteDB and Django to make an application that subscribes to the PubNub Market Orders Stream, stores these trades in YugabyteDB, and displays them in real-time.
In this blog, we will explore how YugabyteDB Change Data Capture (CDC) and open table formats like Apache Iceberg can be used to build data lakes in Amazon S3 using a single copy of the data and achieve low data ingestion latency while avoiding costly rewrites to support updates/deletes and schema evolution.
It’s good to keep a record about the growing size of databases and tables to make reporting easier and to quickly determine why there was a sudden drop or increase in table size or infer table create and drop dates. YugabyteDB Anywhere provides an API to capture table-level size metrics on a daily basis in a permanent table. This blog will provide the instructions to capture those table size metrics.
Learn how to best use Query Planner hints in the YugabyteDB database to optimize business queries based on how applications expose them. Walk through a use case that utilizes data sets from two popular TV shows to find total viewership per season, episode, etc.
This blog explores how to import and export Avro (a row-based storage format file) and Parquet (a columnar storage format file) and how to process the data with a YugabyteDB database using Azure Databricks.