Hacker News Reader

Comment by reedlaw | Hacker News Reader

I see a lot of negative comments that lead me to believe that few here have seen the problems with RDBMS's that lead some of us to consider NoSQL alternatives. An application that frequently times out (page loads over 30 seconds) to me is a good candidate for a NoSQL backend, especially considering we are mainly storing documents. This app was not developed by us and granted the design is terrible with many N+1 queries (which we are eliminating one by one), but I'm very eager to consider alternatives to MySQL for this and future apps. Any comment that dismisses this need off-hand strikes me as somewhat unaware of the problem. What I would like to see more discussion of is what are the viable alternatives to RDBMS + ORM (specifically MySQL + ActiveRecord). I am specifically considering Mongo + Mongoid. Now if anyone can give me some solid reasons why this is not a good idea, I would be glad to hear it.

View on HN

"An application that frequently times out (page loads over 30 seconds) to me is a good candidate for a NoSQL backend" -Why? What tells you that the application is spending most of its time waiting on the database? If it's spending a lot of time waiting on the relational database, I would suggest it's a good candidate for: 1) query optimization (as you start to surmise with your N+1 observation) 2) possibly better disk IO 3) possibly a different db architecture

We have New Relic installed. MySQL is not the only bottleneck, but it's a big one. Ruby code is another. New Relic can't show us how much Ruby execution time is ActiveRecord and how much is our application code, but we recently upgraded from Rails 2.3 to 3 and noticed some decrease in speed. We have been implementing memcached and optimizing queries with pure SQL but still have a long way to go to get decent performance. Most of the slow pages are back end admin stuff, so it's not absolutely critical, but nevertheless it's left me with a bad impression of the traditional stack.

But that sounds like a problem with the application, not the stack. What makes you think that document oriented databases are any more immune to bad application design than relational databases?

I believe it's a combination of application and stack that's the problem. I've been comparing Rails 3 apps to similar apps in other frameworks. Locomotive is a Rails CMS and it was taking ~1 second per page load. Calypso is a CMS in Node.js and page loads were nearly instant. Both used Mongodb. Locomotive sped up when 4 unicorn workers were applied, but it still didn't match Node.js.

I did not say that "nosql" databases don't have their place, I said that I'm not interested in using them as the 'default'. If you've built a site that just isn't running well with SQL, well by all means, use what works for you, but to me it seems logical to start with something solid and well known and then optimize later, should it prove necessary.

  > An application that frequently times out (page loads over  
  > 30 seconds)

An application like this is a good candidate for review what the hell is going on, before making any decisions about changing the stack.

We have done months of review and optimization. Still many page loads must be backgrounded (mainly reports and admin interfaces). We are dealing with a large amount of data.

People like you give nosql a bad name. Yes, nosql can help, but you're looking at it for the wrong reasons.

Go back to school, or hire capable developers.

Reply on news.ycombinator.com