There are folks who try to keep a mobile SQLite in sync with a server SQL DB, but they are playing a game of wack-a-mole, as the sync code is application specific, and each time they add an application feature, they have to write new sync code with new bugs.

Synchronization should not live in the app layer. CouchDB handles sync (offline replication) transparently, leaving devs to write apps, not debug conflict resolution strategies.

I assume many people will start/use Cassandra as a plain DHT, not with it’s SCF/CF schema. Then you can change the value as much as you like without down time (see Akkas Cassandra store for an example).

http://akkasource.org/

1. “Unlike with relational systems, where you model entities and relationships and then just add indexes to support whatever queries become necessary, with Cassandra you need to think about what queries you want to support efficiently ahead of time, and model appropriately.”

http://wiki.apache.org/cassandra/DataModel

And

2. “Can I add/remove/rename Column Families on a working cluster?

Yes, but it’s important that you do it correctly.

Restart and wait for the log replay to finish.
Shutdown Cassandra and verify that there is no remaining data in the commitlog. (as of 0.6, you can do this using “nodetool drain”)
Delete the sstable files (-Data.db, -Index.db, and -Filter.db) for any CFs removed, and rename the files for any CFs that were renamed.
Make necessary changes to your storage-conf.xml.
Start Cassandra back up and your edits should take effect.”

http://wiki.apache.org/cassandra/FAQ#modify_cf_config

After reading Cassandra’s documentation I had the impression that a change in application requirements still can cause down time and the need to move a big amount of data from one “place” to another “place”. Why else do I need to think ahead about what queries I want to support? When the requirements change, the queries change.

“My experience is that most complaints about RDBMS’ are complaints about MySQL and PostgreSQL, not Oracle, [...]”

Ah, an anecdote! Wonderful.

” They scale well for most mainstream purposes, and Oracle in particular is in heavy use at Amazon.com, Yahoo, eBay, etc.”

Ahh, another anecdote. Could be a collection.

See the post about Oracle. Oracle should work well, considering the M$ for hardware and M$ for licenses. But still – another anecdote from me and to quote Roy Batty: “I’ve seen things you people wouldn’t believe. Oracle Real Application Clusters on fire.”

Another difference: I’m quite confident I can scale Cassandra to a 10 server cluster without much help for $2000 a month, I couldn’t manage that with RACs and not for the money.

“[...] you’re really dealing with data structures & documents, not “structured information”

Dealing with data structures, which are not structured information? You’ve lost me there, this is too meta for me.

“[...] you’re a startup and can’t afford a real database.”

Uhuh, the 160 node Cassandra cluster at Facebook is not a “real database”? I beg to differ.

“The RDBMS is returning.”

Nope. Go the stony way of read/write splitting, partitioning and sharding and one will never want to go back there. And the “mystical” scaling RAC is thorny as hell too.

“80,000 transactions per second (yes, you read that right”

In memory? Durable? On what disk? Which size? With parallel reads or append-only?

Ahh, anecdotes, the mystical support to any claim…

My experience is that most complaints about RDBMS’ are complaints about MySQL and PostgreSQL, not Oracle, MS SQL, or DB2. They scale well for most mainstream purposes, and Oracle in particular is in heavy use at Amazon.com, Yahoo, eBay, etc.

NoSQL is useful if
- you’re really dealing with data structures & documents, not “structured information”
- you’re a startup and can’t afford a real database
- you’re a small team and want to tinker

But let’s not kid ourselves and think that it’s the only game in town for write scalability. The RDBMS is returning. VoltDB is certainly an RDBMS, with SQL, though arguably an AltDB since it is an “in-memory data grid” that uses replication for durability instead of a disk log. In pre-release it can hit 80,000 transactions per second (yes, you read that right) with a single node, and 1 million transactions per second on a 12-node cluster. Then, there’s ScaleDB , which is releasing RAC-like shared disk clustering for MySQL. Jim Starkey is working on NimbusDB. Oracle & Microsoft aren’t sitting still.

So, from my point of view, it isn’t “just a MySQL problem”.

Maybe the real solution is just to use a relational database that doesn’t fall apart when you do an ALTER TABLE? I’m not DBA, but I use ALTER TABLE on my Oracle databases that have millions of rows and its back in a few seconds.

I’m not against NoSQL, but this whole ALTER TABLE thing is really just a Mysql problem, isn’t it?

RDBMS will still be around (of course) for cases needing:
- complex transactional semantics
- legacy SQL support
- where the data model fits relational naturally (e.g., general ledger)
- in reporting applications, as SQL and GROUP BY are quite powerful there

dwight/mongodb

- Transactions that need to scale: Banks, Airlines, … in sum fewer than there are web sites that need to scale – my impression at least, especially as some have outsourced and pooled their databases.

- There are many more transactional datastores than scaling web apps, but those data stores (our intranet :-) do not need to scale

So transactional, web site scaling niche would have been better to write.

Just remember there’s a ton of software out there (most of it proprietary stuff that is never seen outside the company that wrote it) that is massively empowered by the solid transactional databases that sit underneath it. So it’s not so much a “much smaller nice” as a “more focussed use-case” – your points still stand though, and I think it may be a good thing for RDBMS vendors if people stop expecting databases to “do everything for everyone”…

I think the point of his post is that he sees “NoSQL” as a hype that he rather want to die because he fears everybody jumps the NoSQL train and rewrites his or her software just because of that. See your first laugh in that light (usage RoR + MySQL are very popular).

You’re correct on so many levels and I wish more people would take NoSQL as what it is — another option — not necessarily meant to straight replace “foo” with “bar”.

Well done! :)

You can, but I think transactional data like payments, orders, … are easier in RDBMS than in (current) NoSQL storages. Some support distributed transactions, most don’t and do not follow ACID principles (ACID make transactions easy). Conflict resolution is often done during read times are left otherwise to the client.

You said that SQL will survive because transactional data. But isn’t possible to do atomic operations with nosql?