This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
You need to think about why you are moving from a relational DB to a NoSQL DB, and about the requirements of your application, and the nature of your data. Most relational databases share core features both in terms of the data modelling principles they support and their general properties e.g. ACID properties. So it is reasonably easy to migrate from e.g. PostgreSQL to Oracle because both databases share similar design principles.
Unlike relational databases, however, different NoSQL databases have different characteristics that may be more or less appropriate to your needs e.g. different degrees of consistency and different levels of availability, so you would need to ask which factors are important for your application or not. You will also have to convert your relational data to fit a different data model for your chosen NoSQL option e.g. a document store, key-value store, graph database etc. The most suitable model will depend on your application and its data needs.
Incidentally, as you are already using Spring, you may know that Spring has been expanding its support for NoSQL databases e.g. there is a very video talk on Spring Data and NoSQL at Infoq which discusses using NoSQL databases with Spring Data, as well as giving a quick overview of MongoDB and Neo4J for example.
Ashwin Sridhar wrote:We want to move away from Oracle in an effort to cut down on licensing costs. At the same time, we don't want to compensate on quality.
The big issue may be transaction support/consistency, but obviously you'll need to evaluate your NoSQL database against your selection criteria. If you simply want to cut down on licence costs, rather than needing the features of a particular NoSQL solution, then PostgreSQL might be a good relational option. I'm not a PostgreSQL expert, but from what I've seen it's mature, robust and flexible, and can handle pretty large volumes of data, and of course it's free and open source. It even supports an implementation of PL/SQL (PL/pgSQL) if you have stored procedures you need to migrate. There are also various paid-for options for supported/enhanced versions of PostgreSQL via EnterpriseDB, which might give you a middle path.
Ashwin Sridhar wrote:I found that NoSql databases are used at many places including google, Amazon. So I think Transaction or consistency would have been handled. ( Just a guess though ).
Do you think that Google and Amazon use NoSql databases exclusively? I'm pretty sure that's not true. They use all sorts of databases. The truth is that NoSql databases can beat RDBMS in some aspects, but are lacking in others. It all boils down to choosing the right tool for the job. And, actually, there is plenty of situations where consistency can be sacrificed to a degree. If you run a website, you can lose a post or comment here and there. But if you're a bank, you cannot afford losing a single transaction. Yes, NoSql databases are cool. But they are not the silver bullet.
Taking an application which is tightly tied to Oracle and overhauling it into NoSql world is certainly a major project, even if the NoSql concept fits your real needs exactly. If, in reality, RDBMS is a good fit for your application, moving to NoSql wouldn't be just a major project, it would be a major disaster.
If your only motivation is slashing down licensing costs, then I'd say your best fit really is a cheaper (perhaps free) RDBMS. Preferrably one which uses similar concurrency model, and, as far as I know, Postgre is a good fit in this regard.
If you have concluded that your app can use NoSql better than RDBMS, then yes, it might be good idea to do the move, but the overhaul will be much more costly than moving to another RDBMS. The two worlds are too different.
Ashwin Sridhar wrote:So I think Transaction or consistency would have been handled. ( Just a guess though ).
Traditional relational databases guarantee transaction consistency, the "C" in ACID properties. The new NoSQL databases do not necessarily guarantee to support all of these properties in the same way.
[edit to remove unwarranted FUD around updates in MongoDB: we live and learn, eh? ]
Each NoSQL database has different characteristics - there is no single "NoSQL" approach to these issues (unlike relational databases) - and although it may be a great solution for some problems, NoSQL is definitely not a silver bullet. As Martin says, you need to make sure your application is suitable for migration to your chosen NoSQL platform. You may well find yourself re-designing and re-implementing significant aspects of your application in order to take full advantage of the benefits you expect to gain from NoSQL. It may be a while before you actually see any of those cost savings from moving off Oracle.
No one database fits all your data in the NoSQL world. So if you are just trying to choose one, you already lost. For instance, I am working on an app where we will use all the 4 types of NoSQL, as well as a relational database.
NoSQL databases have many configurations to get different forms of CAP principles. CAP stands for Consistency, Availability, and Partitionability. You can only have 2 in the CAP triangle, you cannot get all three. So while a relational database will give you great consistency, depending on your vendor you might get great availability or Partitionability, but not both, so that is why many people talk about poor scalability of relational databases. Because they were built when we didn't need to be "Web Scale" In the past 2 years we(the world) have collected more data in databases than in all the years before that combined.
About consistency in No SQL. Some have a form of eventual consistency, which while not immediate consistency, with async functionality, eventually it becomes consistent.
So there is a lot to learn about all these databases, to get it correct.
Be careful of anyone that says there is only one solution and everything else out there is wrong or bad. Because that isn't correct. Even say blogs that complain about MongoDB Document database are based on the blogger not knowing that you can easy change your configuration in MongoDB and get exactly fixed what they were complaining about. Because the blogger just took the default setting, which is perfect for clickpoint, but not for everyone else.
Good Luck, it is an amazing world of databases today, and it is very exciting. I love working with the NoSQL databases. But also don't turn your back to relational databases or NewSQL DBs like Postgres and VoltDB.
There is a free online introductory course in MongoDB for developers (and a parallel course for DBAs) which has just started yesterday at the 10Gen website: http://education.10gen.com/
The course lasts 8 weeks, and they say each week will require about 10 hours of work, but I've just done the first week's work in about 2 hours, so you shouldn't have any problem catching up this week!