Comment by acdha | Hacker News Reader

Comment by acdha | Hacker News Reader

Parent Full thread

So, say I do use a document database and object serialization is indeed easy and fun again. Now I need to do reporting, only it's really slow until I heavily denormalize (i.e. reinvent half of a SQL database and update every time my reports change). Now I need to share data across objects so it turns out I did need joins after all. Maybe I could invent an Object-Non-Relational-Mapper to make some of that complexity easier to maintain…

None of this is saying a particular technology is wrong or bad but it's a reminder that Eric was right to point out that they all have drawbacks which developers should consider when picking a good fit for their application. Blindly asserting that a particular one is good or bad is no better than telling carpenters they only need hammers.

Even Google, for all of their massive resources and BigTable's deserved respect, uses a ton of SQL databases - and they didn't add support to AppEngine simply because they were unwilling to tell developers to try something new.

The answer is to use both. Do you really need realtime reporting? If you don't, store everything in a document database and write a small job to copy the data to a relational store for querying and reporting.

If you're going to store in a relational database anyway, why have the expense of having to develop and support both? It'd make more sense to try to either denormalize - with some support framework - or just use the SQL database from the beginning, the deciding factor being how important aggregate operations are to your app and simple questions like how much your NoSQL database costs to operate vs. your SQL database.

tl;dr: "Know your data access patterns and pick a good fit with your resources"

Can you cite evidence, other than anecdotal, that Google "uses a ton of SQL databases"?

Google has contributed quite a few large patches to MySQL. I doubt they would be spending engineering time on improving MySQL if they did not use it internally for at least _some_ projects, and probably many.

Do a Google search for mysql google contributions and plenty of stuff pops up.

div's comment summed it up: one of the most useful MySQL patch sets floating around was released by Google to help address scalability (http://code.google.com/p/google-mysql-tools/) and this appears to have continued until the present: https://groups.google.com/d/msg/google-mysql-tools/Bc7P5SIRC...

I also know that they use at least one big financial reporting packages but I'm not sure whether the use of Oracle Hyperion is evidence for or against wisdom.

This probably counts as an argument for both sides: http://research.google.com/pubs/pub37200.html

Reply on news.ycombinator.com