views:

287

answers:

1

I am planning to make a web app which will eventually use Cassandra. But now that I don't have it and don't have server(s) to run it from, I'd like to start by using MySQL.

The question is, is it possible to structure data and queries in such a way that it would be fairly easy to later port it to Cassandra? Main idea, I guess, would be writing MySQL queries that would be possible to change to same Cassandra queries.

Maybe you have a better suggestion?

+2  A: 

Well, for the easiest transition, you probably just need to use MySQL as a key-value store. Cassandra allows a little more complexity than straight key-value (basically, it allows sub-keys), but that's going to be tricky to do in MySQL without making your eventual conversion efforts a lot harder.

So to use MySQL as a key-value store, that means you just create one table with two columns, key (which should be the primary key on the table) and value. value is probably going to need to be of type text, if you intend to store large amounts of data in it, but key could just be a varchar(255), unless you need large keys for some reason.

Then you just store any data under a key, and retrieve it back with its key, that's it. That'll be very simple to convert to Cassandra later.

Out of curiosity, why are you planning on using Cassandra?

Chad Birch
Hi Chad, thanks for the answer. Re. your last question, I've done some reading about features of different NoSQL databases an Cassandra seems to be capable, simple and free.Re. Cassandra's supercolumns, would that be possible to "emulate" in MySQL?
SODA
It's possible to emulate (just by having more columns than two), but it'll require some work and some code to implement, and won't be as easy to do the conversion when you move to Cassandra. If you stick to straight key-value you can probably migrate to Cassandra in a matter of minutes. And the reason I asked why you were using it is just whether you had an actual need for it. It seems lately that a lot of people are grabbing onto the NoSQL thing just because it's trendy, without having an actual reason to use it over a relational db.
Chad Birch
Well to expand on why I'd like to use NoSQL is because most of the data will be schema-free. In fact I was planning to use both a SQL and a no-SQL DB's - SQL to store entry ID's, ontology OR taxonomy and relations between them, and a no-SQL to store actual entries with arbitrary fields.
SODA
Prefer Key Value storage only as suggested by Chad Birch, this also leaves the room open for hbase if in case it wins over cassandra. Both solve the similar problem so either one is going to prevail.
mamu