5 ms·

When I see databases like this pop up, a part of me wonders why they don't devote effort to develop a plugin for MariaDB or PostgreSQL? Follow in the steps of C

by lykr0n 8y ago

When I see databases like this pop up, a part of me wonders why they don't devote effort to develop a plugin for MariaDB or PostgreSQL? Follow in the steps of Citus Data.

deleted 8y ago
[deleted]
rkarthik007 8y ago
CTO of YugaByte here... this is indeed our plan. We are working with the community on pluggable storage coming out next year, and in the slightly longer term want to make YB a plugin (extension in the case of PG) model. While a reasonable amount of work is needed in order to get there, this is definitely the direction!
- Xorlev 8y ago
  Here's a question -- what makes YugaByte unique? There's already an early but strong market here in the form of Google Spanner on GCP, Cockroach DB, and TiDB -- what does YugaByte bring that none of them do?
  - manigandham 8y ago
    Multiple data models.
- manigandham 8y ago
  Just to be clear, this would mean a PG extension that works with the new PG pluggable storage to use Yugabyte as the backing store? Does that mean still running a separate Yugabyte cluster or is everything self-contained in the extension?
  - kmuthukk 8y ago
    YugaByte DB's design is that a YB cluster supports Postgres in a native, self-contained & scale-out manner (much like YugaByte's Cassandra and Redis flavored offerings). At a high-level, the upper half of the Postgres DB is being largely reused. The lower-half, i.e. the distributed table storage layer, uses YugaByte's underlying core-- a transactional and distributed document-based storage engine. For the DB to be scalable, the lower-half being distributed is necessary but NOT sufficient. The upper-half also needs to be extended to be made aware of other nodes executing DDL/DML statements and dealing with related concurrency while still allowing for linear scale. Also, making the optimizer aware of the distributed nature of table storage is the other major piece of work in the upper-half. These changes required in the upper half is what makes the "100% pure extension" model a bit harder... but that's something we intend to explore jointly with the Postgres community.
  - rkarthik007 8y ago
    Hi @manigandham, great question. As it stands now, YugaByte would not be a PG extension. It will be a fully distributed but standalone PG cluster called "YSQL" API layer. We have started with the 10.4 version of PG for building distributed YSQL. PG is planning the pluggable storage API for version 12.0, but these will only address user tables. This is certainly essential, but not sufficient for true distributed SQL. Some of the other pieces are: * Pluggable storage for system tables * Ability to create the initial set of system tables in a pluggable manner (initdb equivalent) * A number of other changes to the upper half of PG in order to make it "stateless" and scale-out, such as modifications to how certain operations are executed, which locks are held, what operations are pushed down to the underlying storage layer, etc. * Support for different types of indexes * Enhancing the optimizer to understand different storage types (in this case a distributed store) In our current implementation, we have tried to make APIs for the above where ever possible. We need to explore how we can make runtime hooks for the other places. The plan is to see how to contribute these to the open source over the longer time frame so that we can create a self contained extension (though we are nowhere close to that today). Since our PG modifications code-base is open-sourced, the hope is that it would make contributing these changes back to PG easier.
isoos 8y ago
Several months ago, setup of a Citus Cluster seemed to be a not straightforward, while at the same time I was able to setup and run a CockroachDB cluster in less than half hour with docker. I've checked YugaByte documentation about setup, and CockroachDB still won in operation complexity. I doubt that the same will be done with PostgreSQL or MariaDB anytime soon. People are begging for a good and easy psql HA cluster setup for ages, and it is just not happening (yeah, they are getting closer and closer), while such DBs fill a need with good results.
- bmatican 8y ago
  @isoos, I'd be curious to understand more about why you thought YugaByte would be more operationally complex to deploy, as we strive to make things as easy to get started with as possible... For example, for local testing, in our Quick Start docs section, we have info for: mac/linux, involving just downloading and unpacking the release and you should be good to go; for local docker, you can download our control script; for k8s download our sample yml. Finally, for non-local testing, we have a Deploy > Manual Deployment section, highlighting the 3 steps for downloading YugaByte, bringing up Masters (metadata nodes) and then Tservers (data nodes). Note: I work at YugaByte.
  - isoos 8y ago
    With CockroachDB, I was able to create a cluster with three commands, one command on each node (docker run ....), one port on each node. It can't really get more simple than that. With YugaByteDB: I needed to think about master and tserver nodes, to run them and connect them separately. There was no clear guide that had "run these three docker command on the three different nodes" and be done with it. Note: I run everything is in simple docker images (and not compose, not swarm, not kubernates, just plain docker images).
  - manigandham 8y ago
    CRDB is only has one node type which are all symmetrical, deployed as a single binary. It doesn't get simpler than that. Most other databases insist on multiple layers and dependencies which only shifts more work onto developers who have to install and maintain it.
morgo 8y ago
I can't speak to PostgreSQL, but I work on the TiDB team having previously worked on the MySQL team. Ensuring compatibility from a clean slate is hard, but to make MySQL distributed requires more than the current storage engine API provides. Thus, you would be likely be creating a fork and no longer getting the benefits of having an upstream[1]. The surgery you need to perform on the code would also reduce you from full compatibility (switching from pessimistic to optimistic locking means some statements no longer work). There are some great side benefits to a clean slate too: In TiDB we're able to use modern languages such as Go for the TiDB Server, and Rust for TiKV. ([1] Phrasing this question to upstream: I think they'd like to offer such functionality, but introducing this level of backward incompatibility is hard. They are also very concerned about performance regression bugs, which would be very hard to prevent with all the refactoring required.)
manigandham 8y ago
Citus is a great product, but it's still fundamentally hamstrung by the foundations of the underlying database. CockroachDB gives you proper data replication and high-availability at a high density. Postgres doesnt, and requires an entirely separate cluster with fragile replication and manual cutover.

by lykr0n 8y ago

When I see databases like this pop up, a part of me wonders why they don't devote effort to develop a plugin for MariaDB or PostgreSQL? Follow in the steps of Citus Data.

deleted 8y ago

[deleted]

rkarthik007 8y ago

CTO of YugaByte here... this is indeed our plan. We are working with the community on pluggable storage coming out next year, and in the slightly longer term want to make YB a plugin (extension in the case of PG) model. While a reasonable amount of work is needed in order to get there, this is definitely the direction!

Xorlev 8y ago
Here's a question -- what makes YugaByte unique? There's already an early but strong market here in the form of Google Spanner on GCP, Cockroach DB, and TiDB -- what does YugaByte bring that none of them do?
- manigandham 8y ago
  Multiple data models.
manigandham 8y ago
Just to be clear, this would mean a PG extension that works with the new PG pluggable storage to use Yugabyte as the backing store? Does that mean still running a separate Yugabyte cluster or is everything self-contained in the extension?
- kmuthukk 8y ago
  YugaByte DB's design is that a YB cluster supports Postgres in a native, self-contained & scale-out manner (much like YugaByte's Cassandra and Redis flavored offerings). At a high-level, the upper half of the Postgres DB is being largely reused. The lower-half, i.e. the distributed table storage layer, uses YugaByte's underlying core-- a transactional and distributed document-based storage engine. For the DB to be scalable, the lower-half being distributed is necessary but NOT sufficient. The upper-half also needs to be extended to be made aware of other nodes executing DDL/DML statements and dealing with related concurrency while still allowing for linear scale. Also, making the optimizer aware of the distributed nature of table storage is the other major piece of work in the upper-half. These changes required in the upper half is what makes the "100% pure extension" model a bit harder... but that's something we intend to explore jointly with the Postgres community.
- rkarthik007 8y ago
  Hi @manigandham, great question. As it stands now, YugaByte would not be a PG extension. It will be a fully distributed but standalone PG cluster called "YSQL" API layer. We have started with the 10.4 version of PG for building distributed YSQL. PG is planning the pluggable storage API for version 12.0, but these will only address user tables. This is certainly essential, but not sufficient for true distributed SQL. Some of the other pieces are: * Pluggable storage for system tables * Ability to create the initial set of system tables in a pluggable manner (initdb equivalent) * A number of other changes to the upper half of PG in order to make it "stateless" and scale-out, such as modifications to how certain operations are executed, which locks are held, what operations are pushed down to the underlying storage layer, etc. * Support for different types of indexes * Enhancing the optimizer to understand different storage types (in this case a distributed store) In our current implementation, we have tried to make APIs for the above where ever possible. We need to explore how we can make runtime hooks for the other places. The plan is to see how to contribute these to the open source over the longer time frame so that we can create a self contained extension (though we are nowhere close to that today). Since our PG modifications code-base is open-sourced, the hope is that it would make contributing these changes back to PG easier.

isoos 8y ago

Several months ago, setup of a Citus Cluster seemed to be a not straightforward, while at the same time I was able to setup and run a CockroachDB cluster in less than half hour with docker. I've checked YugaByte documentation about setup, and CockroachDB still won in operation complexity. I doubt that the same will be done with PostgreSQL or MariaDB anytime soon. People are begging for a good and easy psql HA cluster setup for ages, and it is just not happening (yeah, they are getting closer and closer), while such DBs fill a need with good results.

bmatican 8y ago
@isoos, I'd be curious to understand more about why you thought YugaByte would be more operationally complex to deploy, as we strive to make things as easy to get started with as possible... For example, for local testing, in our Quick Start docs section, we have info for: mac/linux, involving just downloading and unpacking the release and you should be good to go; for local docker, you can download our control script; for k8s download our sample yml. Finally, for non-local testing, we have a Deploy > Manual Deployment section, highlighting the 3 steps for downloading YugaByte, bringing up Masters (metadata nodes) and then Tservers (data nodes). Note: I work at YugaByte.
- isoos 8y ago
  With CockroachDB, I was able to create a cluster with three commands, one command on each node (docker run ....), one port on each node. It can't really get more simple than that. With YugaByteDB: I needed to think about master and tserver nodes, to run them and connect them separately. There was no clear guide that had "run these three docker command on the three different nodes" and be done with it. Note: I run everything is in simple docker images (and not compose, not swarm, not kubernates, just plain docker images).
- manigandham 8y ago
  CRDB is only has one node type which are all symmetrical, deployed as a single binary. It doesn't get simpler than that. Most other databases insist on multiple layers and dependencies which only shifts more work onto developers who have to install and maintain it.

morgo 8y ago

I can't speak to PostgreSQL, but I work on the TiDB team having previously worked on the MySQL team. Ensuring compatibility from a clean slate is hard, but to make MySQL distributed requires more than the current storage engine API provides. Thus, you would be likely be creating a fork and no longer getting the benefits of having an upstream[1]. The surgery you need to perform on the code would also reduce you from full compatibility (switching from pessimistic to optimistic locking means some statements no longer work). There are some great side benefits to a clean slate too: In TiDB we're able to use modern languages such as Go for the TiDB Server, and Rust for TiKV. ([1] Phrasing this question to upstream: I think they'd like to offer such functionality, but introducing this level of backward incompatibility is hard. They are also very concerned about performance regression bugs, which would be very hard to prevent with all the refactoring required.)

manigandham 8y ago

Citus is a great product, but it's still fundamentally hamstrung by the foundations of the underlying database. CockroachDB gives you proper data replication and high-availability at a high density. Postgres doesnt, and requires an entirely separate cluster with fragile replication and manual cutover.