It's true that many people attempt to prematurely optimize by using Cassandra first instead of something they are already familiar with. However, when faced with some of the pains of growing an RDMBS beyond what a single box can handle, it's worth it to consider your other options. Keep in mind that if it's easy to store and make use of a huge pile of data, you're more tempted to gather that data in the first place, where 10 years ago it might have been prohibitively expensive or difficult.

I can assure you that you're incorrect, but since you don't have any data to back this up, I won't bother either.

Yes, only knuckle-dragging imbeciles are interested in new systems... *sigh*. This is an often-touted piece of flamebait that has little basis in reality. Some of the largest Cassandra users are companies who already have extensive experience scaling MySQL and other RDMBS.

While some might find that document stores like MongoDB are "easier" and use it for that reason, Cassandra has a reputation for being difficult to get started with; the reason it gets used nevertheless is because the benefits outweigh the steep learning curve.

2B columns in a row isn't why you use Cassandra.

Here are some of the actual reasons why you use Cassandra:
- No single point of failure. Every node in the cluster has the same role. This is also nice for maintenance purposes.
- Linearly scalable. Increasing the size of your cluster by N times increases the total ops/second N times.
- Tunable consistency per operation. For every read and write, you can specify how many replicas for a piece of data must respond for the operation to be considered a success. A typical strategy is requiring a quorum of replicas to respond for both reads and writes, ensuring a strongly consistent view of your data (by the pigeonhole principle) while still tolerating the failure of up to half of your replicas. If you're familiar with the CAP theorem, this lets you trade off some amount of C and A for every operation.
- It's fast (while still durable). Sub-millisecond write latencies, read latencies typically 1ms to 10ms, depending on caching, write patterns, and other factors. Pretty standard hardware with cheap rotating media drives work very well, so you don't have to buy any super-boxes.
- Multi-datacenter replication. Cassandra really does a good job of making this transparent while still giving good latencies and tunable availability/consistency.

Basing the clustering aspects of Cassandra off of Amazon Dynamo is what really brings a lot to the table here. The BigTable data model just happens to work really well with this.

Columns in Cassandra aren't analogous to columns in an RDBMS. Every row is basically a list of (key, value) pairs. This is referred to as a column, with the key being the column name. There's no requirement that rows have the same set of column names.

Typically large rows are used for indexes or timelines. In a timeline example, you might use a timestamp for every column name and store the entry as the column value. Cassandra keeps the row sorted by column name, so all of the entries in the row (timeline) will be in chronological order.

In the case of indexes, you may use one row for every indexed value (say, one row for all users from Utah, one for all from Texas, etc). Here, each column would store the row key (primary key) of a row in another column family (table) that matches that indexed value; in this case, every column might hold a userId.

The difference is the perception of competition among corporations. With the federal government, you know you don't even begin to have an option. With corporations, at least you can pretend for a while...

The free market also prioritizes making special "varieties" of products about the same way that the general population does. Consider that you might look for some of the following: organic, low sodium, MSG-free, HFCS-free, sugar-free, low-fat, made from free-range cows, gluten-free, BPA-free, locally made, and vegetarian-friendly (vegetable-based).

It's not generally cost-effective to make, ship, store, and sell all of these varieties; mandating that they all exist would be hugely expensive. So, the free market instead serves as much of the population as it profitably can. It would be too much to ask them to operate at a loss, so this is the most you could hope for. The only way to change this is to increase demand by raising awareness of issues like BPA.

Partially correct.

The size of cache dictates how quickly it can be accessed. This is why L1 caches are always tiny. In fact, the smaller == faster is why you see the idea of a cache repeated endlessly in both hardware and software. Eventually, you end up with regsisters -> L1 -> L2 -> [L3] -> RAM -> [SSD] -> HDD.

The cache is typically puny because that allows it to be faster. You see cache increases for the same price when it becomes afordable to have a bigger cache without latency issues.

Even that is not enough. Even if they are caught 50% of the time, that's still a good deal for them. You have to make the expected profit (in probability terms) negative for price-fixing. In other words, (fine * probability_of_being_caught) > profits.

Thanks for the info. That was an interesting read. :)

The Leidenfrost effect has an upper bound -- it only has maximal effect at a specific temperature. If I remember correctly, anything above ~200 C decreases the effect. So, if the ball of plasma is well over that, the effect will be minor.

I do think the Prisoner's Dilemma is a very good model for the global warming situation. If you think of it strictly in those terms, the only way to change the Nash equilibrium is to alter the benefits of the different strategies for all players. This could either mean some type of guaranteed punishment for defectors or some type of guaranteed benefit for cooperators. I think most people instinctively realize this -- but enforcing the benefits/penalties on a global scale is the difficult part.

Well, actually, they say 90%. From TFA:

Is that independent enough for you?