6 ms·

Used it on my past adtech startup handling billions of http requests per day (backend having multiple more calls). Solid product, it's since reached parity wit

Used it on my past adtech startup handling billions of http requests per day (backend having multiple more calls). Solid product, it's since reached parity with Cassandra and added even more features. Great team, very helpful. It's far easier to run than Cassandra because of its performance so you need less nodes overall (which is the single biggest issue in C* ops). The enterprise edition also has better compaction strategies and an automated system to schedule it all. What scale are you looking at?

throwawaythekey 4y ago
It sounds like you might be a future version of me! We are an adtech startup in the hundreds of millions per day right now, expecting billions per day by the end of the year. Management would be happy if I said I have a plan for tens of billions. The main difference is that we would probably lean towards the cloud version instead of self hosted (do we still need to think about clusters then??)
- manigandham 4y ago
  If you use the cloud version then there are no ops to worry about.
samhw 4y ago
> far easier to run than Cassandra I know precisely nothing about Scylla, but somehow I still agree with this. Cassandra is far and away the most horrendous software I've ever had to work with (Kafka coming in a close second). This was true even when we hired a major core contributor to help manage it; even he wasn't 100% comfortable with it. The word 'anticompaction' is still enough to give me nightmares. I very much welcome – not that it's Cassandra's only problem – this trend of rewriting '00s/early-'10s Java software in simpler languages. (And, languages aside, I think Cassandra - certainly inter alia - simply sits at a level of complexity which is beyond the comprehension of any one human being. And software which is beyond the comprehension of any one human being inevitably begets bugs, even as an operator rather than a developer.)
- _benedict 4y ago
  I'm intrigued: The Apache Cassandra developer community is quite small and well known to each other, and the only major contributor I know to have left the community to run a cluster did so almost a decade ago? Cassandra had a lot of rough edges until very recently, and was only really suitable for sophisticated users, as most contributors would have attested. The project has matured a lot over the past couple of years in particular, as the broader community stepped up in the face of DataStax's (temporary) withdrawal. The investment by some large scale users has transformed it, and the next couple of years will do so even more. None of the issues the project faced were really related to the language chosen, in my opinion, rather than the maturity of the project and how it grew at the time.
  - samhw 4y ago
    His initials were LT, if that helps (if not, I can clarify his whole name over email or however people privately communicate on HN?). I may well be exaggerating his 'major'ness - I'm not that familiar with the Cassandra contributorship, but that was my understanding from my team! As for Cassandra itself, we were certainly quite sophisticated users. There's a decent chance you'd know the company in question. It's a fair point about the language: I'm not a fan of Java and it probably colours my opinion a little; I was speaking more from a philosophical standpoint about reducing the theoretical complexity of software to make it more deterministic & understandable (out of the tar pit and all that), more than to any specific deficiencies in Java that caused any actual issues for us, of which there were no direct examples I can recall. (Pathological GC did cause some occasional degradation, I suppose, though at best that's semi-specific to Java.) I think most of the actual issues, from my on-call years, were as a result of stuff like: (as I mentioned) anticompaction and suchlike causing pathological performance; our own misconfiguration of things like asynchronous replication / bootstrapping (which once caused a very severe incident, as in 'endemic data corruption and loss' severity); application-layer issues from product engineers misconfiguring consistency, choosing poor keys for partitioning, constructing poor data models that require table scans, all the ordinary stuff for which Cassandra is at most very obliquely to blame. Also, I agree it was stupid of us to use Cassandra in (what was) a very serious environment, in probably one of the most safety-critical sectors outside of medicine and rockets. We knew that. We did the same with several technologies. Literally, we had a diktat saying no engineers could mention it in blog posts. On reflection it's quite unfair to blame Cassandra for our decision - to a large extent, yeah, we were holding it very wrong. I would not have made that choice myself, at all.

throwawaythekey 4y ago

It sounds like you might be a future version of me! We are an adtech startup in the hundreds of millions per day right now, expecting billions per day by the end of the year. Management would be happy if I said I have a plan for tens of billions. The main difference is that we would probably lean towards the cloud version instead of self hosted (do we still need to think about clusters then??)

manigandham 4y ago
If you use the cloud version then there are no ops to worry about.

samhw 4y ago

> far easier to run than Cassandra I know precisely nothing about Scylla, but somehow I still agree with this. Cassandra is far and away the most horrendous software I've ever had to work with (Kafka coming in a close second). This was true even when we hired a major core contributor to help manage it; even he wasn't 100% comfortable with it. The word 'anticompaction' is still enough to give me nightmares. I very much welcome – not that it's Cassandra's only problem – this trend of rewriting '00s/early-'10s Java software in simpler languages. (And, languages aside, I think Cassandra - certainly inter alia - simply sits at a level of complexity which is beyond the comprehension of any one human being. And software which is beyond the comprehension of any one human being inevitably begets bugs, even as an operator rather than a developer.)

_benedict 4y ago
I'm intrigued: The Apache Cassandra developer community is quite small and well known to each other, and the only major contributor I know to have left the community to run a cluster did so almost a decade ago? Cassandra had a lot of rough edges until very recently, and was only really suitable for sophisticated users, as most contributors would have attested. The project has matured a lot over the past couple of years in particular, as the broader community stepped up in the face of DataStax's (temporary) withdrawal. The investment by some large scale users has transformed it, and the next couple of years will do so even more. None of the issues the project faced were really related to the language chosen, in my opinion, rather than the maturity of the project and how it grew at the time.
- samhw 4y ago
  His initials were LT, if that helps (if not, I can clarify his whole name over email or however people privately communicate on HN?). I may well be exaggerating his 'major'ness - I'm not that familiar with the Cassandra contributorship, but that was my understanding from my team! As for Cassandra itself, we were certainly quite sophisticated users. There's a decent chance you'd know the company in question. It's a fair point about the language: I'm not a fan of Java and it probably colours my opinion a little; I was speaking more from a philosophical standpoint about reducing the theoretical complexity of software to make it more deterministic & understandable (out of the tar pit and all that), more than to any specific deficiencies in Java that caused any actual issues for us, of which there were no direct examples I can recall. (Pathological GC did cause some occasional degradation, I suppose, though at best that's semi-specific to Java.) I think most of the actual issues, from my on-call years, were as a result of stuff like: (as I mentioned) anticompaction and suchlike causing pathological performance; our own misconfiguration of things like asynchronous replication / bootstrapping (which once caused a very severe incident, as in 'endemic data corruption and loss' severity); application-layer issues from product engineers misconfiguring consistency, choosing poor keys for partitioning, constructing poor data models that require table scans, all the ordinary stuff for which Cassandra is at most very obliquely to blame. Also, I agree it was stupid of us to use Cassandra in (what was) a very serious environment, in probably one of the most safety-critical sectors outside of medicine and rockets. We knew that. We did the same with several technologies. Literally, we had a diktat saying no engineers could mention it in blog posts. On reflection it's quite unfair to blame Cassandra for our decision - to a large extent, yeah, we were holding it very wrong. I would not have made that choice myself, at all.