administration

NoSQL Pain? Learn How to Read/write Scale Without a Complete Re-write

Nati Shalom

— 1 min read

Lately I've been reading more cases were different people have started to realize the limitations of the NoSQL promise to database scalability. Note the references below:

Take MongoDB for example. It's damn fast, but it doesn't really know how to save data reliably to disk. I've had it set up in a replica pair to mitigate that risk. Guess what - both servers in the pair failed and corrupted their data files at the same day.

It appears that for many, the switch to NoSQL can be rather painful. IMO that doesn't necessarily mean that NoSQL is wrong in general, but it's a combination of 1) lack of maturity 2) not the right tool for the job.

That brings the question of what's the alternative solution?

In the following post I tried to summarize the lessons from  Ronnie Bodinger

(Head of IT at Avanza Bank AB) presentation on how they turned their current read-mostly scale architecture into a complete read/write scale without a complete re-writing of their existing application and while keeping the database as-is.

The lessons learned:

  • Minimize the change by clearly Identifying the scalability hotspots
  • Keep the database as is
  • Put an In Memory Data Grid as a front end to the database
  • Use write-behind to reduce the synchronization overhead
  • Use O/R mapping to map the data back into its original format
  • Use standard Java API and framework to leverage existing skillset
  • Use two parallel (old/new) sites to enable gradual transition
  • Use RAM for high performance access and disk for long term storage
  • Use commodity Database and HW

For a more detailed explanation read more here.

Read more