| I don't know that it's really much to do with using the right tool for the job. Risk, reliability, performance expectations, etc. I don't know if I've ever met a project of any significant complexity that would have been more of a success in any area, deployed any quicker, or developed any easier by not using a traditional RDBMS. There are those projects out there, I just don't have any personal experience with them. But what's more, I seriously doubt 99% of people using NoSQL solutions do either. Databases cross a funny line. There's language, syntax, a lot going on under the covers, and complex technical decisions and trade-offs at every turn to maintain durability and performance on modern hardware. Sure, I can set work_mem in Postgres to 1GB and sort this query in-memory like a king, but then I'm (worst-case-scenario) reducing my 20-connection server by 20GB it might have used for cache instead speeding every other query up. I can imagine issues are as simple as having the right LRU in front of my data, or I can guarantee durability and achieve really amazing performance if I'm willing to invest myself into learning why particular design decisions, made over years by some genuinely brilliant people, were made. Truth is, just to use one of these systems, you mostly don't have to care to meet your own requirements. And I think people take that for granted. When performance requirements are no longer being met, it's easy to blame the tool (the RDBMS), but I think a much safer assumption is to blame the developer and hit the books. The PostgreSQL 9.0 Administration Cookbook and PostgreSQL 9.0 High Performance books are surprisingly good reads. It doesn't take all that much personal effort really. Less certainly than switching tool-chains. This is one of those comments you write, goes off-track, and then decide to just delete. Well I'm going to post it damn-it. :-) |