Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

cacm.acm.org

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

#71

Post by thibaut_barrere »

jaxn wrote: post #42
thibaut_barrere wrote: post #37

Earlier 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…

I am currently doing reports/datawarehouses/dashboards. When something more complicated that simple questions is needed (see Data Warehousing for Cavemen), ad-hoc queries are quite often not the answer anymore, either with NoSQL or with SQL.

I don't want my clients to be dependent on me (or someone else) to build complicated SQL queries when they have questions, so I focus on getting an easy to maintain facts/dimensions model (as advocated by Ralph Kimball http://www.amazon.com/Data-Warehouse-Toolkit-Complete-Dimens...) which can evolve if needed.

The nice point about MongoDB when doing this is that it makes it a lot easier to add attributes to dimensions, or load the data, or evolve the reporting system in general (and I like that).

You can apply the same principles to build dimensions/facts based data structure and answer questions that SQL alone wouldn't be able to answer easily.

Example of such question: how many calls did we receive during french legal week #9 that were handled by team X outside the normal working hours or while we were in vacations ? In those calls, how many were issued by a woman (as it has a financial impact in this case) ?

Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

#74

Post by Locke1689 »

aloneinkyoto wrote: post #52
jaxn wrote: post #51

Earlier quoted context omitted.

I am not a MongoDB expert by any stretch, so please correct me where I am wrong. The way I read your link it sounds like I need to store the data in a particular way in order to run a parent/child query. That is great if I know that I need that query at design time. What happens if I have tens of millions of records and need to run that report on an ad-hoc basis? Where the relationship may or may not be important? Wh…

Ease of use is subjective. I dont think writing a mapreduce job needs to be more complex than writing an equivalent SQL query. What really matters is elegance, flexibility and power. My personal experince is that the MongoDB model seems to win in most cases. Especially when it comes to flexibility and ad-hoc querying. Having a real language (javascript) and a flexible schema tend to make most business problems easier…

Ease of use is subjective. I dont think writing a mapreduce job needs to be more complex than writing an equivalent SQL query. What really matters is elegance, flexibility and power.

Unfortunately it seems you have completely misunderstood the nature of both SQL and MapReduce. MapReduce is a distributed computation engine. While it can be used in that way it was never meant to be a database system. BigTable is proof enough of that.

In general, SQL is the syntactical representation of relational algebra with some hacky additions for programmer convenience. Comparing just "SQL" to the MongoDB language model is misguided since you then break down to a question of algebraic expressivity and relational power.

I'm not going to try and build a proof here but we do know that a formal relational algebra system is equivalent to first-order logic. As far as MongoDB's relational language goes, one would probably have to make an argument that it is equivalent to either tuple or domain relational calculus, but I know of no theoretical work that has attempted this. If anyone has any more information to the theoretical expressiveness of the MongoDB relational system I would love to read it.

Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

#75

Post by terra_t »

pbh wrote: post #47
terra_t wrote: post #32

Earlier quoted context omitted.

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

I'm very confused by this comment. Did you switch mysql and pgsql in this comment, or was this what you meant as written? 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,…

you can write

select sum(x=1) from y;

in standard SQL, Oracle, and Mysql. True == 1 in standard SQL, False == 0. Both pgsql and Microsoft SQL server define a nonstandard boolean type that requires you to add a cast or an if statement, bulking up the query.

I did a shootout of mongodb and the three RDBMS systems (!Oracle) I mention for building a system to represent data from Freebase. It was possible to make a VARCHAR(4096) in mysql and only index the first 64 characters which meant I could map freebase types to mysql tables without running into index limitations -- I wanted the better GIS capabilities in pgsql, but I didn't want to double the size of my tables and queries to be able to handle strings losslessly.

Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

#76

Post by ergo98 »

thibaut_barrere wrote: post #70
ergo98 wrote: post #53

Earlier 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. That's why data warehouses rely upon cubes/OLAP for analysis. It is a specialized solution that serves the need very well. >One great point about MongoDB is that it makes the ETL process a lot easier (you don't have to prepare tables with the right sc…

OLAP on SQL comes at a cost, too (which is why some people are diving into analytics and reporting with NoSQL tools, where you can add one server without large expenses). On CSV/XML, my point wasn't clear enough: I wanted to underline the fact that it's a lot easier to load dimensions data then load facts data and achieve foreign keys lookups when working with MongoDB (it's not about the file format, it's about the l…

For the people who need OLAP analysis, the relevant expense range is seldom that much of a consideration. I'm looking at storage systems right now that costs $800,000. It's considered mid-range and is merely the starter system.

Note that OLAP is, in many regards, NoSQL. It is really the most successful variant of NoSQL.

However I'm very curious what sort of analytics people are doing with NoSQL. I have seen people essentially generating reports to MongoDB, for instance, but I have never seen anything remotely approaching flexible analytics on such a system.

Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

#77

Post by aloneinkyoto »

Locke1689 wrote: post #74
aloneinkyoto wrote: post #52

Earlier quoted context omitted.

Ease of use is subjective. I dont think writing a mapreduce job needs to be more complex than writing an equivalent SQL query. What really matters is elegance, flexibility and power. My personal experince is that the MongoDB model seems to win in most cases. Especially when it comes to flexibility and ad-hoc querying. Having a real language (javascript) and a flexible schema tend to make most business problems easier…

Ease of use is subjective. I dont think writing a mapreduce job needs to be more complex than writing an equivalent SQL query. What really matters is elegance, flexibility and power. Unfortunately it seems you have completely misunderstood the nature of both SQL and MapReduce. MapReduce is a distributed computation engine. While it can be used in that way it was never meant to be a database system. BigTable is proof…

I was not arguing about relational algebra or theoretical expressivity or logical equivalence or anything like that. I was simply stating that in practice most business problems are easier to model and more flexible to query in the MongoDB model.

Of course you need some time get used to thinking in terms of documents rather than tables and rows. But once you get used to the idea you can easily model most domains that occur in practice.

> MapReduce is a distributed computation engine. While it can be used in that way it was never meant to be a database system. BigTable is proof enough of that.

Yes, MapReduce in the Google and Hadoop sense is designed for massive batch processing. That's why BigTable and HBase exists. MapReduce in the CouchDB and MongoDB sense is a Turing complete query and processing layer built on top of a column store. In the CouchDB case MapReduce is the only way you can query the database.

http://wiki.apache.org/couchdb/Introduction_to_CouchDB_views http://www.mongodb.org/display/DOCS/MapReduce http://www.mongodb.org/display/DOCS/Aggregation#Aggregation-...

Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

#78

Post by protomyth »

LiveTheDream wrote: post #46
protomyth wrote: post #12

Is 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…

> why add a whole new type? 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.

"right" is often defined by management as something quite different than what a technical person would desire.

Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

#79

Post by senya72 »

thibaut_barrere wrote: post #70
ergo98 wrote: post #53

Earlier 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. That's why data warehouses rely upon cubes/OLAP for analysis. It is a specialized solution that serves the need very well. >One great point about MongoDB is that it makes the ETL process a lot easier (you don't have to prepare tables with the right sc…

OLAP on SQL comes at a cost, too (which is why some people are diving into analytics and reporting with NoSQL tools, where you can add one server without large expenses). On CSV/XML, my point wasn't clear enough: I wanted to underline the fact that it's a lot easier to load dimensions data then load facts data and achieve foreign keys lookups when working with MongoDB (it's not about the file format, it's about the l…

how about high-perf joins at run-time?

Re: Michael Stonebraker: Why Enterprises Are Uninterested in NoSQL?

#80

Post by sriramk »

jfager wrote: post #41
sriramk wrote: post #34

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…

http://cloudera.com http://riptano.com http://couchone.com http://10gen.com http://neotechnology.com http://basho.com ...

None of them are 'large' enterprise companies - think Oracle, MSFT, IBM, etc.
Post reply on HN