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.
We have been hard at work expanding our ecosystem to be available across major cloud infrastructure providers so we can power applications in any cloud or across clouds. In addition to deploying the YugabyteDB Anywhere (formerly YugabytDB Platform), our commercial database-as-a-service (DBaaS) offering, natively in AWS and GCP, we’re excited to announce the beta release of the Yugabyte Platform on Microsoft Azure. While it’s true Yugabyte Anywhere can already be deployed on Azure as an on premise cloud provider,
Remote joins in Hasura GraphQL extend the concept of joining data across tables, to being able to join data across tables and remote data sources. In this blog post we are going to demonstrate this capability by configuring the following set up.
- A 3 node YugabyteDB cluster running on GKE with a Hasura GraphQL Engine attached
- A 3 node YugabyteDB cluster running on AKS with a Hasura GraphQL Engine attached
- A Remote Schema and Remote Relationship configured
- The ability to issue GraphQL queries that join data from two different databases,
Microsoft’s Azure Kubernetes Service (AKS) offers a highly available, secure, and fully managed Kubernetes service for developers looking to host their applications on containers in the cloud. AKS features elastic provisioning, an integrated developer experience for rapid application development, enterprise security features, and the most available regions of any cloud provider.
YugabyteDB is a natural fit for AKS because it was designed to support cloud native environments since its initial design.
One of our users was interested to learn more about YugabyteDB’s behavior for a random read workload where the data set does not fit in RAM and queries need to read data from disk (i.e. an uncached random read workload).
The intent was to verify if YugabyteDB was designed well to handle this case with the optimal number of IOs to the disk subsystem.
This post is a sneak peak into just one of the aspects of YugabyteDB’s innovative storage engine,
Updated April 2019.
The famed CAP Theorem has been a source of much debate among distributed systems engineers. Those of us building distributed databases are often asked how we deal with it. In this post, we dive deeper into the consistency-availability tradeoff imposed by CAP which is only applicable during failure conditions. We also highlight the lesser-known-but-equally-important consistency-latency tradeoff imposed by the PACELC Theorem that extends CAP to normal operations.