CODEWITHSUNDEEP
javamysqlmongodbplayframeworkdatabase
user393964
user393964

Reputation:

Changing database type for Java project?

This question is quite hypothetical but I'll ask anyway. Let's say you start a project with Play and you use a mysql database. Later on you decide you want to move your application to something like Google App Engine or Amazon EC2. Or maybe even switch to a NoSQL database like MongoDB or Cassandra.

Are there any tools for this? Or would you basically need to rewrite your models? Especially since mysql is a relational database and has nothing to do with something like Monogo, I'm guessing it's quite hard?

I'm asking because, when you start a project, obviously, you might be hoping to scale your application at one point, and maybe you'll need something like Mongo, but you never know how things turn out. MySQL could end up being more than enough for your needs for a long time. So why go to the trouble of learning to work with Mongo, when you'd be much more productive with MySQL and you could switch later, if necessary?

I'm asking more specifically in combination with using the Play! framework.

What are your thoughts?

Upvotes: 2

Views: 500

Answers (4)

Pere Villega
Pere Villega

Reputation: 16439

we had the experience on this the other way around (from GAE to DB). I would not recommend switching. Ever. For many reasons:

  • Siena, although it's a very cool idea, it has a big problem: it's trying to merge two completely different worlds. The way GAE works is very different than a Relational DB. This means that to work in both worlds the library has to do some assumptions and hide some functionality. Ever heard of leaky abstractions? Yes, Siena as an idea is really cool, but no, it's not what you want for a medium-big project.

  • The aim of a NoSQL and a Relational DB are very different. There are usage cases for each one, and places where you will want the SQL approach while in other areas a NoSQL approach will be better. Trying to do everything with one or the other it may be the wrong approach/design

  • By using NoSQL just in case you may be starting the root of all evil. Let's be honest: banks have used SQL machines for very heavy transactional loads for ages and they had no problems. And i'm not adding Memcache to the equation. Nor SQL optimization, nor code profiling.

    If your website will get to that level of traffic, great for you! But most likely then you will be getting money to scale the database as required (or your web will go bankrupt before). If it gets to the point where you need to scale a whole lot more, then you can always add a MongoDb/Cassandra/etc layer to store the information you may want to store there (relation graphs and other stuff like that). But until then you won't need it, and now a days you may be having your full db in RAM. Don't worry about scalability, it will be quick :)

Upvotes: 2

mandubian
mandubian

Reputation: 4427

There is already a solution designed for this usecase: coding something for Mysql/Postgres/H2 and using the same code in GAE (and other NoSQL DB such as Hbase, sdb, mongo later) and back. This is a project called Siena which is already integrated with Play. It's a lightweight object-mapping framework bridging (at least trying) SQL/NoSQL based on the active record design.
The website is http://www.sienaproject.com (The current doc is a bit outdated and incomplete compared to trunk code because we have been in a deep phase of refactoring and enhancing - the code is quite stable, it is on github but the real trunk is not the main project but a fork http://github.com/mandubian/siena).
There are 2 modules in Play called play-siena and crudsiena that you can find on http://www.playframework.org/modules . Current versions only provide GAE support but a version supporting MySQL/Postgres/H2 + GAE is coming very soon (I'm testing it)!

I'm the lead developer of Siena so don't hesitate to ask me questions about it.
Don't hesitate to join the google group to discuss with us : http://groups.google.com/group/siena-discuss

regards
Pascal

Upvotes: 3

Olaf
Olaf

Reputation: 6289

While it is possible to convert application written for MySQL to work with some NoSQL tools, the ways you use a relational database efficiently are in no way the same as the ways you use NoSQL. The converted application will be very inefficient and on any amount of data large enough to justify NoSQL solution - likely unusable at all.

Upvotes: 2

duffymo
duffymo

Reputation: 308938

There's no guarantee, but one thing you can do to protect yourself is hide the persistence implementation details behind a well-designed interface. It won't keep you from having to rewrite implementation if you switch, but it will isolate clients from the changes. You'll be able to test implementations separately and swap them in and out in a declarative fashion if you're using a dependency injection engine.

Upvotes: 1

Related Questions