> The hardest parts of linear scaling in RDBMS are enforcing C.
The hardest parts of linear scaling in RDBMS is actually doing the scaling - it's "what do I do when I'm about to outgrow a master and need to add a bunch of capacity", and "what do I do when the master crashes". At Crowdstrike we would add 60-80 servers to a cassandra cluster AT A TIME, no downtime, no application changes, no extra work on our side - just bootstrap them in, they copy their data, and they answer queries. The tooling to do that in an RDBMS world probably exists at FB/Tumblr/YouTube, and almost nowhere else.
> Think transactional systems that absolutely must be consistent. Like your bank account
Most banks use eventual consistency, with running ledgers reconciled over time.
> It takes a lot of time and a lot of effort. Hell, most companies don't even have an EDW. Let alone a pipeline from the OLTP server to Spark/Hadoop to the non-existent EDW.
In the cassandra world, it's incredibly common to setup an extra pseudo-datacenter, which is only queried by analytics platforms (spark et al). Much less work, and doesn't impact OLTP side.
> 1a) If you want a CP system, you have no choice but to deal with scaling problems of relational databases. You must have transactional guarantees for this to work.
This is fundamentally untrue - you can query cassandra with ConsistencyLevel:ALL and get strong consistency on every query (and UnavailableException anytime the network is partitioned or a single node is offline). Better still, you can read and write with ConsistencyLevel:Quorum and get strong consistency and still tolerate a single node failure in most common configs.
> Use the right tools for the right job, is basically my point.
And this is the real point, with the caveat that you need to know all the tools in order to choose the right one.
1) scaling is easy . . . oh casandra. Where you can't have C and don't care about P.
2) Let me tell you about banks. I used to work for banks. Banks do not use systems that are eventually consistent. Banks use systems--however old and outmoded--that are strongly consistent. Banks do not use systems that are eventually consistent except for ACH transfers. And that's not a database. That's a flat file
3) There is no cassandra world that you speak of. This is utter bullshit.
4) No it's not untrue. Cow--as we call it on me team--absolutely sucks at C when you're talking about scaling horizontally.
Make up your mind. Is this good at single node guarantees or is it good at sharded guarantees?
Pick one.
We know for a fact that if you want CAP, you can't have all three. You can have AP or CP, but you can't have all of them. If you're arguing that you can have C and A, you have failed at P.
Maybe that's a thing you're willing to trade-off. But it doesn't in any way relate to my point.
My point, if you missed it, was this: if you want strong consistency, you need a relational database, and you need transactional guarantees.
That is hard to do, and no one does it well yet. You're just lying to people if you say otherwise.
I don't know what your background is, but I'm really encouraged by the fact that I've worked my whole career without having to deal with people that behave like you.
> 1) scaling is easy . . . oh casandra. Where you can't have C and don't care about P.
This isn't about teaching me the CAP theorem. I know the CAP theorem. I know the tradeoffs. I've built and managed systems that handle hundreds of billions of events a day, writing millions of writes a second into a thousand cassandra nodes. You can have C, if you want it - you dont get transactions with rollbacks, but that doesn't mean you dont have consistency.
> 2) Let me tell you about banks. I used to work for banks. Banks do not use systems that are eventually consistent
Cassandra lets you tweak the C or A trade-off on each query by setting the consistency level. So yes, the same system can provide both guarantees, depending on which you need.
> if you want strong consistency, you need a relational database
You can have consistency without transactions.
Overall, it really sounds like you've never used or know much about Cassandra, and are possibly confused on the CAP theorem.
The hardest parts of linear scaling in RDBMS is actually doing the scaling - it's "what do I do when I'm about to outgrow a master and need to add a bunch of capacity", and "what do I do when the master crashes". At Crowdstrike we would add 60-80 servers to a cassandra cluster AT A TIME, no downtime, no application changes, no extra work on our side - just bootstrap them in, they copy their data, and they answer queries. The tooling to do that in an RDBMS world probably exists at FB/Tumblr/YouTube, and almost nowhere else.
> Think transactional systems that absolutely must be consistent. Like your bank account
Most banks use eventual consistency, with running ledgers reconciled over time.
> It takes a lot of time and a lot of effort. Hell, most companies don't even have an EDW. Let alone a pipeline from the OLTP server to Spark/Hadoop to the non-existent EDW.
In the cassandra world, it's incredibly common to setup an extra pseudo-datacenter, which is only queried by analytics platforms (spark et al). Much less work, and doesn't impact OLTP side.
> 1a) If you want a CP system, you have no choice but to deal with scaling problems of relational databases. You must have transactional guarantees for this to work.
This is fundamentally untrue - you can query cassandra with ConsistencyLevel:ALL and get strong consistency on every query (and UnavailableException anytime the network is partitioned or a single node is offline). Better still, you can read and write with ConsistencyLevel:Quorum and get strong consistency and still tolerate a single node failure in most common configs.
> Use the right tools for the right job, is basically my point.
And this is the real point, with the caveat that you need to know all the tools in order to choose the right one.