Mine is a typical website developed with LAMP stack. Due to scalability issues we are planning to incorporate NoSQL for the application.

For the implementation, we are planning to implement hybrid solution: using NoSQL only for few of the high volume tables in database and keep on using MySQL for all the other. So, we are splitting the database in two with two different servers which use different database technology.

We are weighing pros and cons for this approach. For example, with this approach we will have to depend on the web application to maintain data integrity. There will be 2 points of failure due to 2 DB servers, instead of one.

Is it a usual practice? What are the pros and cons?

  • What are your reasons for keeping MySQL? – Adam Zuckerman Mar 26 '14 at 5:31
  • To save relational data like user details and to keep application re-write to minimum. – Ruchit Rami Mar 26 '14 at 5:33
  • 3
    What are you finding the limit to be w/ MySQL? Are you sure you've used its capabilities to the fullest? – GrandmasterB Mar 26 '14 at 5:39
  • 2
    In line with @GrandmasterB's comment, can you please explain the high volume tables and why they are exceeding MySQL's capability? It is not really possible to assess the pros and cons of this choice without knowing that. – user82096 Mar 26 '14 at 9:42
  • Does your database have billions of records in it? If it doesn't, I doubt you need a NoSQL solution. Even then, there are still things you can do to improve scalability. – Robert Harvey Mar 26 '14 at 15:34

Your best bet to improve scalability is to focus on removing calls to the database, rather than to remove data from the database. (although that may happen with things like session data)

If your web application is like most I've seen, a single page load triggers multiple HTTP requests. Each of these requests is likely to trigger a session data retrieval, user details retrieval and then also hit the database for the data for the information to respond to the request.

There are some obvious things that can be done here.

  1. Session data is a obvious thing to move into a NoSQL database. Its a straight Key/Value operation, and something like Riak is good place to store this data.
  2. Database data such as user details that are read often, but changed rarely are also a good match for storing in Riak. How you handle the race condition when updates occur will vary depending on your ability to tolerate using stale data.
  3. Likewise, your website probably also has lots of other data that it processes into HTML sections that do not vary from user to user. Implementing a caching mechanism to store the outcome of this processing can also substantially reduce the hits on your database.

In the end though, you will find that some tables will contain some critical information that cannot be cached. When you reach this point, your choices are to either redesign your core data structure (which is probably not possible, you you would already have done it) or to throw money (and hardware) to enable the database to keep running. In one environment i've worked with, this meant a MS SQL server with 128 cores with the fastest disk and max memory money could buy.

Your Answer

