Imagine you're watching a baseball game. In the middle of the fifth inning, your pitcher throws a strike and then another one. The fan sitting next to you jumps to his feet in a jubilant celebration.
You could be forgiven for wondering what's going on. After all, it takes three strikes to get a batter out — why is this guy dancing like the game is already over?
What Do You Mean By a “Distributed Database?”
The earthly landscape we walk upon usually changes very slowly. It’s measurable in centimeters or inches per year. But the digital landscape, and specifically the distributed database landscape, is changing at a massive rate. You can read more about the tremendous changes currently occurring in the industry in our recent blog on this next tech cycle.
Before we can look at the way these changes are impacting the distributed database landscape, we have to define what we mean by the term “distributed database.” That’s the purpose of this article.
What Java Developers Need to Know About Geo-Distributed Databases
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. Architects require databases that can stay available during major cloud region outages, enable hybrid cloud deployments, and serve data close to customers and end users. This is where geo-distributed databases come into play.
Spotlight on CockroachDB
The construction, process, and usage of databases has evolved a lot over the last few decades. Traditional relational databases were enough to work with the data present at that time, but with the innate reliance on the Internet, the progression of cloud-native architecture, and the advancement of how businesses utilize and analyze data science, relational databases are not cutting it. What happens if a node fails in a traditional single machine of a relational database? Your database would go down along with any applications that depend on it.
Over time as NoSQL databases were introduced—which are capable of handling a large amount of data in real-time—the risk of apps failing began to decrease but the risk of data inconsistencies increased. So, there has been a growing need for a better storage solution for data to cope with today’s dynamic cloud-native architecture. CockroachDB was specifically designed to solve and meet this need.
Today’s World Calls for a New Kind of Database
Over the past decade, applications have become more and more data-intensive. Dynamic data, analytics, and models are now at the core of any application that matters. To support these requirements, there is a commonly held, but often incorrect, belief that modern applications need to be built on top of a variety of special-purpose databases, each built for a specific workload. It is said that this allows you to pick the best ones to solve your application needs.
This trend is apparent when you look at the plethora of open-source data tools that have proliferated in recent years. Each one was built to scratch an itch, optimized for specific, narrow use cases seen in a smattering of projects. In response, some of the cloud vendors have packaged up these multiple database technologies for you to choose from, commonly forking from existing open-source projects. You’re then meant to wire together several of these tools into the needed data solution for each application.
How to Geo-Partition Data in Distributed SQL
We are excited to announce the availability of row-level geo-partitioning in YugabyteDB, a feature heavily requested by our user community and enterprise customers alike. This feature allows fine-grained control over pinning data in a user table (at a per-row level) to geographic locations, thereby allowing the data residency to be managed at the database level.
Making the nodes of a multi-region database cluster aware of the location characteristics of the data they store allows conforming to regulatory compliance requirements such as GDPR by keeping the appropriate subset of data local to different regions, and is arguably the most intuitive way to eliminate the high latency that would otherwise get incurred when performing operations on faraway, remote regions.
How-To: YugabyteDB 2.5 Security Features
The YugabyteDB 2.5 release adds many critical enterprise-grade security features. This blog post outlines these newly added features.
Authentication
Adding scram-sha-256 Authentication
The first notable addition is the addition of a much improved, password-based authentication mechanism called Salted Challenge Response Authentication Mechanism (or simply SCRAM) as described in RFC5802. This scram-sha-256 authentication mechanism, identical to the most secure PostgreSQL authentication schema, is a challenge-response scheme that prevents password sniffing on untrusted connections and supports storing passwords on the server in a cryptographically hashed form that is thought to be secure. To enable this feature, simply pass the following flag when starting the yb-tserver.
Distributed SQL Essentials
Getting Started With Longhorn Distributed Block Storage and Cloud Native Distributed SQL
Longhorn is cloud native distributed block storage for Kubernetes that is easy to deploy and upgrade, 100 percent open source, and persistent. Longhorn’s built-in incremental snapshot and backup features keep volume data safe, while its intuitive UI makes scheduling backups of persistent volumes easy to manage. Using Longhorn, you get maximum granularity and control, and can easily create a disaster recovery volume in another Kubernetes cluster and fail over to it in the event of an emergency.
Cloud Native Infrastructure Stack: Computing, deployment, administration, storage and database.
Distributed SQL Change Management With Liquibase and YugabyteDB on GKE
Liquibase is an open source and extensible change management project that supports a variety of databases including Snowflake, MySQL, and PostgreSQL via JDBC. Liquibase allows users to easily define changes in SQL, XML, JSON, and YAML. These changes are then managed in a version control system so the changes can be documented, ordered, and standardized. For more information on the features and benefits of Liquibase, check out their documentation site.
In this blog post we’ll show you how to:
Distributed SQL: An Evolution of the Database
As organizations transition to the cloud, they eventually find that the legacy relational databases that are behind some of their most critical applications simply do not take advantage of the promise of the cloud and are difficult to scale. It is the database that is limiting the speed and effectiveness of this transition. To address this, organizations want the reliability of a tested relational data store, such as Oracle, SQL Server, Postgres, and MySQL, but with the benefits of scale and global coverage that comes with the cloud
Some have turned to NoSQL stores to try to meet these requirements. These alternatives can typically meet the scale requirements but then fall short as a transactional database because they were not designed from the ground up to provide true consistency. Recently, some of the NoSQL solutions have offered “ACID transactions” but they’re full of caveats and fail at delivering isolation levels necessary for mission-critical workloads like a financial ledger, inventory control, and identity management.
Getting Started With Distributed SQL
Getting Started With Distributed SQL on Azure Kubernetes Service
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.
What Is Distributed SQL?
SQL has been the de-facto language for relational databases (aka RDBMS) for almost four decades. Relational databases are, therefore, also known as SQL databases. However, the original SQL databases like Oracle, PostgreSQL, and MySQL are monolithic from an architectural standpoint. They are unable to distribute data and queries across multiple instances automatically. NewSQL databases emerged to make SQL scalable. However, they also introduced their own painful compromises.
You may also like: Working With PostgreSQL Data Types in a Distributed SQL Database
After the introduction of Docker containers and Kubernetes orchestration to create flexible, composable infrastructure starting in 2015, microservices-based applications have been on the rise. Cloud-native principles of built-in scaling, resilience, and geo-distribution are at the center of this architectural shift. Time was ripe for the introduction of a new class of databases called “Distributed SQL”. The defining characteristic of a distributed SQL database is that the entire database cluster (irrespective of the number of nodes in it) looks to applications as a single logical SQL database.
TechTalks With Tom Smith: Distributed SQL Databases for Cloud-Native Environments
I had the opportunity to meet with Karthik Ranganathan, Founder & CTO, Yugabyte during the Distributed SQL Summit in San Jose. Earlier in the week, they announced the general availability of Yugabyte DB 2.0, the 100% open-source, high-performance distributed SQL database for global, internet-scale applications.
Updates include PostgreSQL syntax and wire-protocol compatibility, high-performance benchmarks, Jepsen-tested correctness, and Oracle-to-Yugabyte migration utilities. With Yugabyte DB’s SQL API (YSQL) ready for production, organizations are able to move away from monolithic SQL systems like Oracle to a distributed SQL database that is both open source and cloud-native.