41–50 of 79 posts
Bashing non-COMPACT storage is nonsense. non-COMPACT store by itself doesn't add any significant overhead (only 2 bytes per cell and even less after compressed). What really wastes space is using collections types. Even using that I doubt it will ever reach the 30x mark the author stated.
The article is full of nonsense and the OP is here so criticism is being downvoted.
This Team Used Apache Cassandra Without Reading The Fine Manual… You Won’t Believe What Happened Next “You honestly expected that adopting a data store at your scale would not require you to learn all of its internals?” These aren't even internals, these are basic facts about Cassandra.
I do believe Cassandra requires a much more intimate knowledge of its internals if you want to do anything serious with it - more so than any other database I've worked with.
Great power, great responsibility.
We used C* for a similar use case and encountered some of the same issues. The article doesn't even mention that there are a lot of places in the docs where it says: "If you configure a keyspace like this, your node will most likely crash". Not just degraded performance, any develeoper with some access might crash a node (and maybe the whole cluster) with a userspace error. The main lesson I took away from Cassandra…
This is entirely true. We are big users/consumers/fans of Cassandra at Spotify. We have approximately one crap-ton of Cassandra clusters with several metric crap-tons of data. But we have an entire team that provides support and tooling around Cassandra. We contribute upstream, and have employed core Cassandra contributors in the past.
In return we get a datastore that scales pretty much infinitely with our data sets, has performance characteristics that we are now well aware of and are able to reason about, and provides us cross-DC replication and topology-awareness. It took years to get to this point though, and to build the operational expertise required to run Cassandra. Only recently have we gotten to the point where teams are able to self-service provision their own Cassandra clusters.
This is a resilient, scalable solution, but if I were to quit tomorrow and start a five-person startup, there is no way I would consider C* as a workable solution.
I still think of Cassandra as the tool the Digg engineers used to kill Digg as we all loved/hated it at it's time.
I've deployed C* on some similarly large datasets and encountered none of these issues - even when storing terabytes of time-series data. The difference - I read through the documentation from head to foot before getting started, did numerous dry-runs to figure out the data modeling, and when I wasn't sure about something asked the community (who are usually incredibly quick to respond on IRC, twitter, or elsewhere).
The thing is that contrary to many other tools, you can't run Cassandra with almost any of its default settings (maybe besides ports). In most tools you'll need to tweak a few defaults, with Cassandra you need to thoroughly read the docs on every little configuration in the server and schema definitions (especially if you're working in multiple DCs), you'll always find a little surprise if you skim through it. It's a…
The one that is really irksome is the COMPACT STORAGE one, as it is explicitly disrecommended and deprecated by the Cassandra documentation. I have not yet gotten around to using Cassandra in any production environment, nor have I done any large-scale tests, and it has been a while since I delved deeply into the data model, but I remember looking at this part of the storage system and thinking it was "wrong", but won…
Instead of using a map (or COMPACT STORAGE), they should have defined their schema upfront (one of the limitations brought on by not-SQL). However if they didn't want to do that then COMPACT STORAGE is obviously a better solution than using a Map.
To answer your question about COMPACT STORAGE, standard CQL basically does the work for you (in terms of parsing the "xsv") but you have you define the schema upfront (as in, you have know all the map keys before hand). The reason they tell you not to use COMPACT STORAGE is for those cases where you don't need a dynamic schema, using COMPACT STORAGE doesn't really get you anything.
Lastly, IMO, I wouldn't touch CQL Collections or COMPACT STORAGE unless absolutely necessary. If you do need a dynamic schema I would rather encode the data as a msgpack or protobuf blob.
Earlier quoted context omitted.
So are you still running Cassandra? And why rely on counters for analytics when it's wildly known to be a bad idea.
We are still running Cassandra. It's used in a more restricted way than we originally thought we'd use it, but we're following the recommendations we wrote up in linked article. We don't use counters -- at all. (This is discussed in one of the sections.) Counters are one of the few Cassandra features that can offer you some form of value aggregation inside the data store, but we decided they weren't worth it, due to…
Earlier quoted context omitted.
Given your experience: Have you considered a NewSQL db like MariaDB with one of its modern storage engines? Also Facebook moved from their Cassandra to Hadoop/Hive a long time ago (and the MySQL side was never touched).
We've moved most of our data to redis (which we were using way before cassandra), with a bit of classic MySQL for off-line data, and Redshift for analytics. Right now redis is not using cluster mode, but we'll switch to it eventually. It's a big move, but I find redis more predictable, and for our data sizes (10s of Gs), cheaper to maintain.
My concern with Redis is reliability. Redis Cluster has problems with consistency [1], whereas unclustered Redis -- well, it syncs to disk every 10 seconds or so, but even then I'm concerned that the reliability of its on-disk structures haven't been as battle-tested as, say, PostgreSQL. Or has it?
If you care, the characters are:
FS -- file separator 1C
GS -- group separator 1D
RS -- record separator 1E
US -- unit separator 1F
As you can see, they also have the benefit of being self-describing (unlike \x01, as the article points out).
(The sad thing is I only learned about these characters because I had to parse files in a 1960s format originally designed to be stored on tape drives -- and they used these delimiters and they worked great.)
Earlier quoted context omitted.
We've moved most of our data to redis (which we were using way before cassandra), with a bit of classic MySQL for off-line data, and Redshift for analytics. Right now redis is not using cluster mode, but we'll switch to it eventually. It's a big move, but I find redis more predictable, and for our data sizes (10s of Gs), cheaper to maintain.
> We've moved most of our data to redis Redis is neet if your information fits in RAM, but that's not what Cassandra is for.
You can easily get commodity servers with 256GB of RAM per node x 10 shards. Cluster or not, as per your use case.