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

61–70 of 80 posts

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

#61

Post by ahi »

kenjackson wrote: post #24
davidw wrote: post #14

Earlier quoted context omitted.

To play devil's advocate, aren't a lot of these places where it's best not to rock the boat and risk screwups? In other words, they'll learn about new things in good time once they have big companies advertising them and have been around the block once or twice. Whether that's sensible or not, I'm not in a position to judge, just that in that sort of world, perhaps learning about things a bit late is not a problem.

True enough. And in hindsight, I think asking people if they've heard of "NoSql" is somewhat an unfair question. The term itself is s trendy one. I'm sure there are probably people who have fixed more lines of code in NoSql databases than most people have here have written, and don't know that specific term.

Disagree. It's everywhere in tech news sources. If you read any tech news on a regular basis you can't possibly be unaware. Part of being a professional is keeping on top of new products/solutions in the field, even if they aren't immediately useful.

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

#62

Post by CitizenKane »

Stonebraker makes a point of saying that the lack of standards in NoSQL system prevents their adoption. While there are standards surrounding SQL most SQL databases do not adhere to the standards. They have connection semantics and syntax that are at times mutually exclusive. Drupal 7 has a dynamic query builder specifically to take care of this (see this podcast for more info http://www.lullabot.com/podcasts/drupal-voices-24-larry-garf...). But for most organizations, it's not like they can simply switch from one database system to another without a fair amount of work.

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

#63

Post by ahi »

ahoff wrote: post #5

The 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.

I don't mind that Stonebraker has a conflict of interest. He's marketing, I get it. I do mind that ACM has given him the platform to do it. Any other ACM publication would consider it incredibly unethical to publish articles with such clear conflicts.

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

#64

Post by jbooth »

jbooth wrote: post #48
jfager wrote: post #43

Earlier quoted context omitted.

Actually, yes: http://developer.postgresql.org/pgdocs/postgres/release-9-0....

Awesome. Was an honest question, don't do a lot of mysql or postgres these days.

Geez, touchy subject I guess.

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

#65

Post by muloka »

rmorrison wrote: post #7

Another big reason: money is not an issue. You want to create ten interconnected tables w/ a bajillion records each, then query across them needlessly every microsecond? No problem, with enough money and hardware there are ways to make almost anything happen using commercial SQL databases.

Your statement reminds me of this quote "A boat is a hole in the water which you throw money into."

This is the general point of view executive committees have of IT. A necessary cost to keep them afloat in the sea of business.

So as much as money is not an issue the bottom line at most enterprises is money. If you figure out how to greatly reduce the overall costs IT, or in this case data storage, the enterprise company you work for will probably appreciate it.

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

#66

Post by muloka »

j_baker wrote: post #49

Say what you will about SQL databases and I'll probably agree with you. However, larger organizations have to think at a much larger scale than the typical startup does. Migrating from a SQL database to a NoSQL database is a much more difficult decision to make once you reach a few hundred thousand lines of code, much less millions. And I haven't even gotten into the logistical issues yet. Do we have server capacity…

Earlier CitizenKane made a point about the lack of standards across SQL databases in general. As such migrating from one SQL db to another would probably present just as equally a challenge.

Let me tell you migrating from Informix 9.4 to SQL Server 2005 was no walk in the park.

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

#67

Post by muloka »

j_baker wrote: post #49

Say what you will about SQL databases and I'll probably agree with you. However, larger organizations have to think at a much larger scale than the typical startup does. Migrating from a SQL database to a NoSQL database is a much more difficult decision to make once you reach a few hundred thousand lines of code, much less millions. And I haven't even gotten into the logistical issues yet. Do we have server capacity…

In terms of the adoption of NoSQL databases (or any dev technology) within your enterprise, write a small and useful app as a side project in your spare time. Once you're done present it to your manager (or team lead) and I'm sure it'll increase its chance of it becoming more widely used within said company.

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

#68

Post by kragen »

It seems to me that there are two or three things being conflated here under the "NoSQL" moniker, and Stonebraker isn't helping things.

First, there's the standard relational storage model. We've known for almost 40 years that some kinds of queries are a lot faster if you denormalize so you're not even in 1NF. Occasionally this matters. "Document stores" are a lot better suited to things that aren't in 1NF than relational databases. In theory you could maybe make this problem go away by throwing more hardware at the problem, so that the extra factor of lg N (which might be around 20 or so) goes away.

Second, there's SQL and all of the hassles it comes with, which can be largely papered over by things like SQLAlchemy and Django and the like, but there are still tricky issues like schema migration and incremental rollout.

Third, there's the CAP theorem. ACID requires consistency (the C in ACID and the C in CAP are the same), so you give up either availability or partitionability, and when you give up partitionability you're usually giving up parallelizability as well, which can put a crimp in the "throw hardware at the problem" approach.

It's true that the costs of abandoning standard SQL databases are high. But there are things you can't get any other way. If you need a million queries per second per database server (serving up variable-length lists of structured data), if you need to be able to incrementally roll out a new database schema across your site, or if you need to tolerate network partitions (and latency; a partitioned network is just the limiting case of high latency) without your database becoming unavailable, standard SQL databases aren't going to give you what you need, as far as I know.

As far as I can tell, these are the three sources of "NoSQL": rejecting the relational model as a way to organize on-disk storage, rejecting the SQL DDL as a way to manage change, and rejecting ACID transactions. Interestingly, none of these necessarily implies rejecting SQL as a user-interface language, and indeed FQL is an SQL user interface on top of some very non-SQL-ish systems.

(SQL itself is a terrible language, as Stonebraker will no doubt tell you if you ask, but it's not so terrible as to justify the switching costs.)

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

#69

Post by gaius »

thibaut_barrere wrote: post #37
edw519 wrote: post #19

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

That article is very peculiar

A data warehouse is a separate RDBMS installation that contains copies of data from on-line systems. A data warehouse would not be necessary if RDBMS software worked as advertised. It is merely a $10 million bandaid applied to the limitations of modern computers and RDBMS software.

If you want to do more computation, you require more computers, and this is "insight"?

You might as well say "A level 2 cache would not be necessary if RAM worked as advertised". Duh!

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

#70

Post by thibaut_barrere »

ergo98 wrote: post #53
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…

>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 loading/lookup part which is a large part of ETL in my cases).

Post reply on HN