Live data from Hacker News

The trouble with Cassandra as an object storage metadata database

blog.min.io

81–82 of 82 posts

Re: The trouble with Cassandra as an object storage metadata database

#81

Earlier quoted context omitted.

We initially looked at Cassandra. We liked its use case, we liked its scalability. However we also ran into maintenance and setup pains. We ended up going with ScyllaDB, which is a drop in replacement for Cassandra. It’s written in C. Much easier in resource demands and we didn’t have to deal with Zookeeper directly.

Cassandra doesn't require Zookeeper

Ah, good to know. Our admins set up Zookeeper with Cassandra, so I had always assumed it was part of the deal.

Re: The trouble with Cassandra as an object storage metadata database

#82

The most basic and trivial way that you're going to get burned by cassandra is that you have to divide your primary key into two parts: partition key columns, and clustering key columns. Partition keys must be in every "where" clause; only clustering keys are optional. Okay, I'll just not bother with partition keys, right? Except partition keys determine which "partition" your data goes in. So if your only partition…

> New problem: Your partitions need to be people work around that by storing the data in something like S3 and then keeping the handle in cassandra. Yet another hack on top of another hack.

While part of this is Cassandra's architecture, it may also be a limitation of the designer's way of thinking. Recently we had a hackathon project where we decided to implement the s3 API on top of Scylla (a Cassandra-compatible database) and were able to chunkify binary large objects (BLOBs) of up to 5 TB, and even turn Scylla into a FUSE filesystem.

https://www.scylladb.com/2020/12/15/scylladb-blog-scylladb-d...

Post reply on HN