I dont think it is about the technology at all. It is more about social factors. Enterprises often shy away from being on the leading edge of anything. There is very limited upside and big downside. I'm willing to bet that once the NoSQL space shakes down with some big winners, some defacto standards, enterprises will be adopting it just the same. Enterprises also need to be sold to. I don't see any startup having a…
Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
41–50 of 80 posts
Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#42Trivial example of what people need to know in enterprises: “Tell me whether pet rocks are selling better than Barbie dolls in the south?” What people really need to know: I already know from existing reporting that 984 orders (18% of our backlog) are already past due. For those 984 orders: - How many are for one item and how many are for multiples? - Do we own what we owe those customers? - If we do own it, is it in…
SQL is actually quite often a bad way to try to answer those questions, too! See http://philip.greenspun.com/wtr/data-warehousing.html for an entertaining explanation. I believe MongoDB in particular can be a fairly good solution to build datawarehouses (I'm starting to use it for reporting systems). One great point about MongoDB is that it makes the ETL process a lot easier (you don't have to prepare tables with the…
Maybe MongoDB is better once you have a well defined query that you need, but I think the point of the parent comment is that those examples of queries are ad-hoc. NoSQL is not as good as SQL when it comes to report specs that are constantly in a state of flux.
I need my data available to answer questions. When building a product you have a well defined set of operations based on the features of your product. When the requirements shift on a regular basis, NoSQL is too limiting.
When the article talks about a low level query language being too limiting, they are talking about missing things like CONNECT BY PRIOR or SUM(CASE IF col IN ('a','b','c') THEN 1 ELSE 0). These are the same kinds of things that are difficult to do with an ORM.
Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#43Earlier quoted context omitted.
> pgsql as going nowhere Eh?! They just released a major update with long-awaited functionality!
Did the new functionality include reliable replication?
Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#44RDB has since become standard. One aspect of a "standard" is uniform interfaces or one-size-fits-all, an essential aspect of which is that it doesn't suit all needs perfectly. It's a modular approach, that involves adapting non-quite circular circles and non-quite triangular triangles to perfectly square slots. You see it in mathematics and (eg) OO polymorphism all the time. It's an unpleasant but often worthwhile tradeoff.
But at the edges, that tradeoff becomes questionable. And the web's REST is a new giant, whose clothing needs a different shape altogether. Applying RDB to it is so ill-fitting and irritating and obviously wrong that hierarchical databases have found a new home and a new life and a new name, NoSQL.
But when NoSQL attempts to spread to others, it is surprised and hurt to find them already tailored for.
---
The above fable is light on detail. There are many complex issues in the NoSQL/RDB comparison, since both have adapted to the detailed problems of their respective domains. However, I think the key aspect is that RDB is meticulously thought out in terms of information, and only then adapted to specific engineering needs. Specifically, it has normal forms and schema (needed for normal forms.)
Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#45The disclosure at the bottom is laughable. It should read, "Michael Stonebraker has a strong economic incentive to steer enterprises away from NoSQL. Whenever a company chooses NoSQL, he will lose money. Hence, his opinions should be considered in this light." Oh, and full disclosure, I have a strong economic interest in promoting NoSQL.
Whether it's hierarchical databases, XML databases, objective databases, proprietary query languages, etc..., people keep trying new things and then coming back to the relational model and SQL. When people say "This time it's different", he gets annoyed. Maybe this time he's wrong, but with an understanding of the history of databases, it's easy for me to see his point of view.
Honestly, I'm not sure if antagonizing the NoSQL community helps his companies or not. The NoSQL crowd is pretty passionate.
Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#46Is there a company with a NoSQL product that is selling support contracts and is listed with Dun & Bradstreet? What do the reports from Gartner and Forrester Research say? Can I sue someone if something goes wrong. Did the options get evaluated with the corporate IT database committee? The sad part is that is how it works in a lot of companies and not just a bunch of snark. Since SQL is so entrenched and most IT shop…
Because using the right tool for the right job makes sense. SQL is great for lots of things. NoSQL hits the sweet spot for other applications.
Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#47Earlier quoted context omitted.
> pgsql as going nowhere Eh?! They just released a major update with long-awaited functionality!
pgsql has a badly nonstandard type system (lots of SQL queries that work in Oracle & mysql don't work in pgsql.) I've still got a long list of queries that run 100x faster in mysql than pgsql
MySQL has always struck me as having a non-standard and quite strange type system (broken time/date types without microsecond accuracy, explicitly sized text types, ...). I've always seen PostgreSQL being marketed as a drop in replacement for Oracle due to superior standards support. If anything, PostgreSQL seems much more similar to Oracle than MySQL.
I'm also very curious what sorts of things I should avoid if you really do have a very long list of queries that PostgreSQL handles really poorly.
Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#48Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#49And I haven't even gotten into the logistical issues yet. Do we have server capacity for the new database? Do we have people who know how to administer the new database? Can I install it in under a month on our server running ? And these questions become doubly important if your clients are running your software on their own servers. Now not only are these logistical issues, they're excuses for your clients to drop you and go with someone else.
To make a long story short, if NoSQL databases are worth it, enterprises will get there. But it's going to take a while. Much as us engineers hate to admit it, that might even be a good thing.
Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?
#50Earlier quoted context omitted.
SQL is actually quite often a bad way to try to answer those questions, too! See http://philip.greenspun.com/wtr/data-warehousing.html for an entertaining explanation. I believe MongoDB in particular can be a fairly good solution to build datawarehouses (I'm starting to use it for reporting systems). One great point about MongoDB is that it makes the ETL process a lot easier (you don't have to prepare tables with the…
I used to be a Business Intelligence consultant for enterprises. We built reports, data warehouses, dashboards, etc. From my experience, the article is spot on, not linkbait. Maybe MongoDB is better once you have a well defined query that you need, but I think the point of the parent comment is that those examples of queries are ad-hoc. NoSQL is not as good as SQL when it comes to report specs that are constantly in…
For examples of how to easily model and query trees (CONNECT BY PRIOR in SQL) see: http://www.mongodb.org/display/DOCS/Trees+in+MongoDB
SUM(CASE IF col IN ('a','b','c') THEN 1 ELSE 0) can be implemented as a group or mapreduce query.
I would say that you have a lot more power and flexibility in MongoDB compared to an average SQL database when it comes to ad-hoc querying.