Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Jepsen: YugaByte DB 1.1.9

jepsen.io

Post reply on HN
Print view View original

21–30 of 49 posts

Re: Jepsen: YugaByte DB 1.1.9

#21

Post by marknadal »

the_duke wrote: post #20
marknadal wrote: post #18

Earlier quoted context omitted.

As an expert in the DB space, I'm extraordinarily cynical. But their willingness to license it as truly open, Apache-style, instantly is a big win-over. I'm a competitor, but I can tell these guys/gals are genuine in their efforts. We need more people, teams, and DBs like YugaByteDB in the world. Thank you for your efforts.

The question is, how many of these very similar databases can the market support? The field is getting crowded, and the database market is already quite competitive as it is, without these new competitors. There just are not that many use cases where a larger Postgres/MySQL instance with one or two replicas is insufficient. From a user perspective, I'd much rather have one or two successful companies where I can be r…

This is why the license matters.

Even if the commercial/AGPL/GPL ones "win" for a few years, they won't be able to compete with these more Open licensed DBs when they catch up.

So at any given moment, too many DBs may be annoying, but for the long term and long game it is important there is this type of competition & research going on.

Although, I absolutely agree, when it comes to Master-Slave based systems (I've been very vocal in criticizing them) that market is drying up to some very limited use cases (banking, etc.). 99%+ of use cases will be Strong Eventual Consistency and CRDT with distributed or decentralized/P2P tools.

Some really old, yet very relevant, thoughts on this subject:

https://hackernoon.com/the-implications-of-rethinkdb-and-par...

Re: Jepsen: YugaByte DB 1.1.9

#22

Post by sllabres »

shin_lao wrote: post #9
aphyr wrote: post #7

Earlier quoted context omitted.

I think the YB team members are probably best equipped to talk about this, but I can note that while some databases do build their own clock synchronization protocol, many prefer to let the OS handle clocks. For one thing, clock sync is surprisingly tricky to do well, so it makes sense to write daemons that do it well once and be able to re-use them in lots of contexts. There's also the question of HW support: in the…

My comment was that PTP is a much better protocol than NTP, and in the doc they only talk about NTP: https://docs.yugabyte.com/latest/deploy/checklist/#clock-syn... https://en.wikipedia.org/wiki/Precision_Time_Protocol

https://en.wikipedia.org/wiki/The_White_Rabbit_Project

Re: Jepsen: YugaByte DB 1.1.9

#23

Post by curun1r »

the_duke wrote: post #3

First time I heard about them. Seems to be another distributed SQL (aka 'newsql') alternative to TiDB and CockroachDB. Based on RocksDB (like Cockroach) with a custom distributed key/val layer and and additional SQL layer on top. PostgreSQL protocol compatible. OS with Apache license. Seems interesting. (when ignoring the "planet scale SQL" marketing speak... [1]) [1] https://www.yugabyte.com/planet-scale-sql/

We had a sales call with them last year and got to speak to one of their devs. The impression they gave was that it was mostly ex-Facebook data guys that left to start a company based on the work they did on Cassandra and a few other internal projects.

The really interesting feature, to us, was the promise that once the Postgres-compatible layer was complete, we could use whatever semantics were appropriate for our business use case while using the same logical database cluster. We could use the Redis interface for persistent caching, the CQL interface for our NoSQL-appropriate use cases and the Postgres interface for our more traditional use cases. And the client libraries for all those interfaces are the same ones we already use to talk to Redis and Postgres (our conversation happened because we were starting a project that was more NoSQL-appropriate, so we weren’t using Cassandra yet), so very little of our code would have to change.

Re: Jepsen: YugaByte DB 1.1.9

#24

Post by mbautin »

spullara wrote: post #19

Since it doesn't support serializable transactions I'm not sure why FoundationDB would be mentioned as a comparison in the write up. The operations it does support seem to set the bar pretty low as to what to test. edit: good reply by the founder of YugaByte but for some reason the comment is dead. I have noticed that when founders don't have an account on here and then something comes up where they need to reply the…

We have run a significant number of useful/practical tests via Jepsen, that only need snapshot isolation level. The tests that were run included a single-key counter test, set tests with and without a secondary index, a "long fork" test ensuring that the order of operations is the same when observed by different clients, and a bank test verifying that the total balance of multiple accounts stays the same when cross-shard transactions transfer funds between pairs of accounts. These tests were run under a variety of failure modes, including different types of network partitions and clock skew. Also, snapshot isolation covers a very large spectrum of practical uses cases, including secondary indexes, for building real-world applications.

Having said that, we have recently added support for serializable isolation level to YugaByte DB, and we will be adding tests to the Jepsen suite for that in near term.

Regards, Mikhail (a co-founder at YugaByte)

Re: Jepsen: YugaByte DB 1.1.9

#25

Post by DigitalVerse »

the_duke wrote: post #20
marknadal wrote: post #18

Earlier quoted context omitted.

As an expert in the DB space, I'm extraordinarily cynical. But their willingness to license it as truly open, Apache-style, instantly is a big win-over. I'm a competitor, but I can tell these guys/gals are genuine in their efforts. We need more people, teams, and DBs like YugaByteDB in the world. Thank you for your efforts.

The question is, how many of these very similar databases can the market support? The field is getting crowded, and the database market is already quite competitive as it is, without these new competitors. There just are not that many use cases where a larger Postgres/MySQL instance with one or two replicas is insufficient. From a user perspective, I'd much rather have one or two successful companies where I can be r…

I do think there are going to be more and more use cases where having more than one or two replicas is necessary, even if there aren't that many right now. IoT strikes me as an example. But even so, I'm with you. I'd much rather have two companies that I know will maintain the software long term than a plethora of competitors that might die out at any time. And while being open source is helpful in that regard, there's no guarantee that the open source community will maintain it after the backing company is gone. Databases are too important to gamble on imo.

On the other hand, a little competition to make sure the big guys stay on their toes is a good thing.

Re: Jepsen: YugaByte DB 1.1.9

#26

Post by jimktrains2 »

marknadal wrote: post #21
the_duke wrote: post #20

Earlier quoted context omitted.

The question is, how many of these very similar databases can the market support? The field is getting crowded, and the database market is already quite competitive as it is, without these new competitors. There just are not that many use cases where a larger Postgres/MySQL instance with one or two replicas is insufficient. From a user perspective, I'd much rather have one or two successful companies where I can be r…

This is why the license matters. Even if the commercial/AGPL/GPL ones "win" for a few years, they won't be able to compete with these more Open licensed DBs when they catch up. So at any given moment, too many DBs may be annoying, but for the long term and long game it is important there is this type of competition & research going on. Although, I absolutely agree, when it comes to Master-Slave based systems (I've be…

I'm thourghly confused by your association of (a)GPL and commercial and calling apach/bad licenses more open. AGPL ensures that users always retain the 4 freedoms, by restricting developers. BSD allows developers to do whatever, including restricting the users. Neither is "more open", they both make trade offs and neither is comparable to proprietary except to say the BSD style licences allow for it if the developer chooses.

Look at the kurfuffle around mongo, redis, and elastic search because of their licenses. However, you don't hear the same issues coming from the postgres community. The licenses you're claiming will win the day cause problems for for-profit I companies, for exactly the reason you think they're "more open".

In the end, either entrenched proprietary software or open, community-focused, community-stewarded software will win the day.

Re: Jepsen: YugaByte DB 1.1.9

#27

Post by gigatexal »

spullara wrote: post #19

Since it doesn't support serializable transactions I'm not sure why FoundationDB would be mentioned as a comparison in the write up. The operations it does support seem to set the bar pretty low as to what to test. edit: good reply by the founder of YugaByte but for some reason the comment is dead. I have noticed that when founders don't have an account on here and then something comes up where they need to reply the…

We use cockroachDB in production and before that we were on MySQL and as of yet we don’t have a specific usecase where we use serializable transactions. Snapshot isolation or even read committed is just fine. So I don’t think it’s absolutely necessary

Re: Jepsen: YugaByte DB 1.1.9

#28

Post by robterrell »

Not a comment on YugeByte, but... I love it when a new Jepsen report get released. Kyle Kingsbury has single-handedly raised the bar on an entire industry. (Well, not single-handedly anymore, but still.)

Re: Jepsen: YugaByte DB 1.1.9

#29

Post by manigandham »

curun1r wrote: post #23
the_duke wrote: post #3

First time I heard about them. Seems to be another distributed SQL (aka 'newsql') alternative to TiDB and CockroachDB. Based on RocksDB (like Cockroach) with a custom distributed key/val layer and and additional SQL layer on top. PostgreSQL protocol compatible. OS with Apache license. Seems interesting. (when ignoring the "planet scale SQL" marketing speak... [1]) [1] https://www.yugabyte.com/planet-scale-sql/

We had a sales call with them last year and got to speak to one of their devs. The impression they gave was that it was mostly ex-Facebook data guys that left to start a company based on the work they did on Cassandra and a few other internal projects. The really interesting feature, to us, was the promise that once the Postgres-compatible layer was complete, we could use whatever semantics were appropriate for our b…

They're a good team. The same data isn't available across different interfaces but there is definitely value in having a single core system that serves multiple apps and models.

Re: Jepsen: YugaByte DB 1.1.9

#30

Post by marknadal »

jimktrains2 wrote: post #26
marknadal wrote: post #21

Earlier quoted context omitted.

This is why the license matters. Even if the commercial/AGPL/GPL ones "win" for a few years, they won't be able to compete with these more Open licensed DBs when they catch up. So at any given moment, too many DBs may be annoying, but for the long term and long game it is important there is this type of competition & research going on. Although, I absolutely agree, when it comes to Master-Slave based systems (I've be…

I'm thourghly confused by your association of (a)GPL and commercial and calling apach/bad licenses more open. AGPL ensures that users always retain the 4 freedoms, by restricting developers. BSD allows developers to do whatever, including restricting the users. Neither is "more open", they both make trade offs and neither is comparable to proprietary except to say the BSD style licences allow for it if the developer…

I believe we both have reasonable arguments from our paradigm, it is just the paradigms have conflicting definitions.

When people who share camp with me say "Open" or "Freedom" we mean Free Speech AND Free Beer.

Where the disagreement happens is on Free Speech:

There are many people/governments that define Free Speech as "Free Speech as long as someone does not shout 'fire' in a crowded room." This is the spirit of (a)GPL in restricting people.

The other group defines Free Speech and/or "Freedom" as "without restriction". Not because they want people to yell "fire" but because they attribute restriction/regulation as the mechanism towards monopoly & centralization. Not that regulation/restriction on its own is bad (every individual ought exercise self-discipline), but it is particularly dangerous once monopoly & centralization emerges because it produces totalitarian or fascist structures.

To counter my own view, many people in the camp opposite of me, have expressed same end-goal concerns "we want to restrict hate speech so fascism doesn't rise". I think it is admirable we have shared-goals (stopping totalitarianism), but for reasons you probably don't share, I think it is more effective to stop fascism by removing the ability for fascists to enforce rules/regulation/restrictions on individuals, even if that comes at the cost or risk of someone yelling "fire".

Why? (I don't assume anyone cares about my view, so don't feel obligated to read) Because I have higher optimism that humans will eventually overcome their individual immaturity (shouting "pen--" in a crowd), especially through incentive design, than in humans overcoming their tendency towards abuse of power (or even worse, most people who "abuse" power don't think they are abusing it, they have a conviction that the use of power is for some greater good). Wielding power is often the end game of any incentive structure, but yelling "fire" or "p--is" often ruins your reputation/power so naturally is disincentivized over time (or where it matters most).

Post reply on HN