9 ms·
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
by dvirsky 11y ago
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 also almost mandatory to read the internal design docs of cassandra even if you're not the admin but just working with it. And modelling data is a lost less trivial than it looks - and almost always not what you assume.
Anyway, this is the best talk I've seen on Cassandra data modeling even if you know Cassandra but not on an expert level. I made sure everyone on my team saw it at least once. https://www.youtube.com/watch?v=qphhxujn5Es https://www.youtube.com/watch?v=qphhxujn5Es
- saurik 11y agoThe 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 wondered if I was just misunderstanding things, given how clearly and strongly it was discouraged. Flipping through the presentation you just linked, they are using all the new features and there are no slides that mention compact storage. "30x", as reported in this article, is clearly non-trivial: what is your take?
- dvirsky 11y agoI haven't dealt with the ops side of running our clusters, and the details are not fresh in my mind, so I don't remember much about the storage engines. But we encountered surprises on almost any front when taking C* to production.
- frik 11y agoGiven 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).
- dvirsky 11y agoWe'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.
- manishsharan 11y agoIf you moved your data off Caasandra to Redis, I am going to assume you must be using a lot of Lua to maintain some relationships in data in Redis. How is the performance? I have been experimenting with Redis and my lua scripts are long and I have been wondering how they will fare under production level loads.
- fweespeech 11y agoA Redis Hash is similar enough to Casandra's data structure I doubt they'd need that. row key = key column = field I know Lua is "an option" in Redis but I avoid it like the plague because under production loads, Redis hashes perform and are easy to maintain w/o Lua.
- dvirsky 11y agoMore or less this. Row = HASH key, sorted sets for secondary key indexing, and also for iterating primary key entries. I've built an abstraction layer on top of redis to automate all that and it works rather well.
- chisleu 11y ago> 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.
- nemothekid 11y agoThe GP is right, I started using Cassandra right before they got a hardon for "CQL" and the docs used to explicitly layout the data model when using the thrift interface. (The Thrift data model is basically what you get when you use COMPACT STORAGE, we still using CQL). Simply put, I bet the 30x increase in performance is not because they used COMPACT STORAGE, and is because Map/collections have terrible performance, and COMPACT STORAGE forced them describe the data the "right" way. 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.
- gpvos 11y agoIt wasn't 30x performance improvement; it was 30x less disk space used. Which is nontrivial at their scale.
- pixelmonkey 11y agoYou said: "they should have defined their schema upfront". We tried. It was not only less disk efficient, but also slower for queries. Wasn't the result we expected, but alas.
- nemothekid 11y agoIf thats the case, then thats something you should have highlighted that as well. Now that I think about it we decided to store blobs under one column using msgpack for a similar reason (although mine was "we had mongo eat up all our disk space because of field names, so now our code is littered with single character field names"). I've thought about fixing it, but if its the case I guess thats related to CASSANDRA-4175. The map solution makes it come across you weren't quite sure what you were doing. However, I'm even more surprised at the "slower for queries" part. Maybe I'll do some tests with COMPACT STORAGE.
- threeseed 11y agoI have to disagree. But again given how scalable Cassandra is we could live in different worlds. I've run multi-gigabyte data sets in Cassandra without any config changes. And when I responsible for a 40 node Cassandra cluster we didn't do any tweaks other than a few JVM settings here and there. Cassandra I have to admit though is very sensitive to how you model and store your database. The whole tombstone saga is never a fun one to go through.
- dvirsky 11y agoMy biggest cluster was 12 nodes, actually a 3*4DCs cluster. I don't recall what the exact issues were, but it took months to stabilize this cluster, and it never performed as well as we'd wanted.
- easytiger 11y ago> I've run multi-gigabyte data sets WOW. You've run several GB of data through it? Wow.
- fweespeech 11y agoWhat tools, etc. did you use to manage the 40-node cluster? How were you querying 40-nodes or were you offloading the querying to Lucene or something [e.g. like Parsely is]?
- cassandranot 11y agoWe found cassandra to be too finicky and flakey and ended up using mongodb - simple to get going, admin, use and maintain. Cassandra was a huge pain in the ass, had to read all the source code just to get it running!
- samkone 11y agoHere's laughing. I guess you chose convenience over performance or scalability, which is a valid choice. But We're running a 1000 Cassandra nodes to handle Millions of ops where mongo would simply require too much admin work. the whole clusters are managed by two guys. Mongo's simplicity comes at a cost at some point.
- schmichael 11y ago> We found cassandra to be too finicky and flakey and ended up using mongodb Oh my. I look forward to your next "X is not a panacea" article on MongoDB. Turns out commercial db vendors lie. A lot. Never use a feature until it's been in a couple point releases (y in x.y.z versioning). Upgrade slowly. Also, Cassandra - and MongoDB when used with clustering - requires writing your data to best fit your queries. This often leads to wildly different schemas than you'd create in a traditional relational database. You should probably read Kyle Kingsbury's article on MongoDB to have some idea of what you're really getting into: https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-read...