Live data from Hacker News

ScyllaDB is Moving to a New Replication Algorithm: Tablets

scylladb.com

11–20 of 27 posts

Re: ScyllaDB is Moving to a New Replication Algorithm: Tablets

#11
post #7

Earlier quoted context omitted.

How so? Mind saying more?

I suppose that they are saying that CockroachDB is a single binary which you just drop on a machine and you are good to go. For ScyllaDB you need to install Java, Python and several ScyllaDB related packages.

The Docker images for ScyllaDB work perfectly fine and ship with all administrative tools included.

Re: ScyllaDB is Moving to a New Replication Algorithm: Tablets

#12
post #9

Earlier quoted context omitted.

Java? I thought the whole raison d'etre for ScyllaDB was "Cassandra without Java"?

The server implementation is, but administering it still requires the Java based Cassandra tooling like nodetool and cqlsh

cqlsh is written in Python. Which doesn't mean it's less of a pain in the ass ;)

Re: ScyllaDB is Moving to a New Replication Algorithm: Tablets

#13
post #8

Very similar to how BigTable[1] works under the hood which was built ~20 years ago. [1] https://static.googleusercontent.com/media/research.google.c...

The load shifting part is similar to the way BigTable splits, merges, and assigns tablets. But the rest of it is not related, because BigTable does not try to offer mutation consistency across replicas. If you write to one replica of a BigTable, your mutation may be read at some other replica, after an undefined delay. Applications that need stronger consistency features must layer their own replication scheme atop BigTable (such as Megastore).

What this post is describing for replication seems more comparable to Spanner.

Re: ScyllaDB is Moving to a New Replication Algorithm: Tablets

#16
This is the right move for Scylla. Overall, looks similar to YugabyteDB that distirbutes data by sharding tables into tablets as well. The cluster monitors the cluster size (number of nodes) and the size of each tablet (data volume), and adds new tablets or re-shards large ones automatically:https://docs.yugabyte.com/preview/architecture/docdb-shardin...

Re: ScyllaDB is Moving to a New Replication Algorithm: Tablets

#17
post #12

Earlier quoted context omitted.

The server implementation is, but administering it still requires the Java based Cassandra tooling like nodetool and cqlsh

cqlsh is written in Python. Which doesn't mean it's less of a pain in the ass ;)

Sorry, that was phrased poorly; was in reference to the parent comment’s “For ScyllaDB you need to install Java, Python and several ScyllaDB related packages”.

Just meant to say it does have tooling which requires other languages/environment specifics.

Re: ScyllaDB is Moving to a New Replication Algorithm: Tablets

#19
post #13
post #8

Very similar to how BigTable[1] works under the hood which was built ~20 years ago. [1] https://static.googleusercontent.com/media/research.google.c...

The load shifting part is similar to the way BigTable splits, merges, and assigns tablets. But the rest of it is not related, because BigTable does not try to offer mutation consistency across replicas. If you write to one replica of a BigTable, your mutation may be read at some other replica, after an undefined delay. Applications that need stronger consistency features must layer their own replication scheme atop B…

I don't understand this comment. Bigtable requires that each tablet is only assigned to one tablet server at a time, enforced in Chubby. There's no risk of inconsistent reads. Of course this means that there can be downtime when a tablet server goes down, until a replacement tablet server is ready to serve requests.

Re: ScyllaDB is Moving to a New Replication Algorithm: Tablets

#20
post #6

This sounds a lot like ranges in CockroachDB. Anyone familiar with the deep details to highlight the differences?

I thought of the same thing, so I am trying to find information on the documentation about things that CockroachDB does very well: 1. Consistent backups/transactions. When a backup is made, is that a single point in time, or best-effort by individual tablet. For example, backing up an inventory and orders table, the backup could have an older version of inventory, where orders have already been completed for some of…

> My personal guess is that Scylla optimized their code for performance, and less worry about data integrity.

Definitely, but they are implementing Raft-based transactions which provide higher consistency. That should enable a higher variety of use cases.

Post reply on HN