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

The thrill of a new technology: CouchDB

tempe.st

Post reply on HN
Print view View original

11–20 of 48 posts

Re: The thrill of a new technology: CouchDB

#11

Post by dagheti »

jrockway wrote: post #9

No, graph databases will rule the world. Couch only supports trees, which is annoying if you want to have relationships between "documents". Also, Couch's implementation of map/reduce arbitrarily limits the kinds of queries you can run. If you actually want to ditch your relational database, take a look at things like KiokuDB, Elephant, AllegroCache, and so on. They may not have exciting web 2.0 screencasts, but the…

Hierarchies and graphs are both fundamentally navigational data models, which force a physical-logical coupling of concerns, hampering flexibility significantly.

The network model recognizes the flexibility issue with hierarchies, however I'm not sure how it can guarantee the same scalability benefits. Due to this it doesn't have the flexibility of the relational model, nor the performance characteristics of the hierarchical model.

This is probably why it isn't ruling the world.

Re: The thrill of a new technology: CouchDB

#12

Post by Tichy »

intinig wrote: post #4
Tichy wrote: post #3

Hm, flat files will rule the world? No more messy SQL, just iterate over the file's entries with a for loop - even Java programmers can understand that. Sorry, but I am not convinced yet.

Tichy, give it a spin. The ease of execution (and the sheer speed, even over giant amounts of data) is impressive.

I can imagine some benefits, but as for speed of execution I am really doubtful. Your example suggests a "select all" followed by some analysis done in code. I can't imagine this scales well.

Re: The thrill of a new technology: CouchDB

#13

Post by gcv »

jrockway wrote: post #9

No, graph databases will rule the world. Couch only supports trees, which is annoying if you want to have relationships between "documents". Also, Couch's implementation of map/reduce arbitrarily limits the kinds of queries you can run. If you actually want to ditch your relational database, take a look at things like KiokuDB, Elephant, AllegroCache, and so on. They may not have exciting web 2.0 screencasts, but the…

I've looked at AllegroCache before, and really liked it. Can you briefly discuss how a graph database of type you describe (AllegroCache or KiokuDB) differs from the object-oriented databases which have not exactly taken the world by storm?

Edited: I also just Googled around a bit and found something called Neo4j. Do you know anything about it?

Re: The thrill of a new technology: CouchDB

#14

Post by moe »

jrockway wrote: post #9

No, graph databases will rule the world. Couch only supports trees, which is annoying if you want to have relationships between "documents". Also, Couch's implementation of map/reduce arbitrarily limits the kinds of queries you can run. If you actually want to ditch your relational database, take a look at things like KiokuDB, Elephant, AllegroCache, and so on. They may not have exciting web 2.0 screencasts, but the…

Well, just to state the obvious, no particular database will "rule the world".

They are different tools for different tasks.

RDMBS will not go away in data warehousing for a while. Key/Value stores are useful for many webapps where they match the access pattern. Graph DBs have yet their own area of application.

There is not "one tool to rule them all". Albeit it would be an interesting project to wrap up all those engines under a common API (SQL?) and have the server choose the optimal one either on user demand or even by magically analyzing the workload.

I'm saying that because the real uglyness that many of us are facing is that we need not one but several of the aforementioned tools for our particular app. For parts of the data we like the guarantees and integrity of RDMBS, for other parts we need the scalability of a key/value store.

Re: The thrill of a new technology: CouchDB

#15

Post by jrockway »

dagheti wrote: post #11
jrockway wrote: post #9

No, graph databases will rule the world. Couch only supports trees, which is annoying if you want to have relationships between "documents". Also, Couch's implementation of map/reduce arbitrarily limits the kinds of queries you can run. If you actually want to ditch your relational database, take a look at things like KiokuDB, Elephant, AllegroCache, and so on. They may not have exciting web 2.0 screencasts, but the…

Hierarchies and graphs are both fundamentally navigational data models, which force a physical-logical coupling of concerns, hampering flexibility significantly. The network model recognizes the flexibility issue with hierarchies, however I'm not sure how it can guarantee the same scalability benefits. Due to this it doesn't have the flexibility of the relational model, nor the performance characteristics of the hier…

This is probably why it isn't ruling the world.

Technical merit and popularity are only occasionally related in the computer world, so I won't comment on this.

I will elaborate further on the use case of graphs versus a relational database. Basically, I see relational databases as especially useful for cases where you have a big pile of data, and have no idea what it really means. You do queries to learn what you have. ("Aha, in March, people from Illinois buy more of product 23894735 than people from California.") The relational model is good for this, since it doesn't build any preconceived notions into your data.

However, most applications don't need anything like this. They have a well-defined data-model, and rarely run "queries" (except to work around the fact that that's the only interface to their data). In this case, the relational model is basically being used as a dumb key/value store supplemented with joins. This results in a ton of code in the application to translate in-memory structures to something that can be stored in the database.

If you use a graph database, you can just store your in-memory structures directly, and get them back later. (Most good object database give you other features, like the ability to index your data so you can still run searches efficiently. Kioku and Elephant do this, anyway.)

So really, you should use the right tool for the job. Want to persist and search in-memory structures? Use an object database. Have a big pile of data you need to make sense of? Use a relational database.

You are allowed to use more than one, they are tools, not religions.

(FWIW, I see relational databases as filling a very specialized role, and I see object databases as the general thing you should use when you want to persist some state. The rest of the world seems to have gotten this backwards, which is somewhat depressing. I think it's because people think databases are magical, as a result of not understanding how they actually work.)

Re: The thrill of a new technology: CouchDB

#16

Post by jshen »

Tichy wrote: post #3

Hm, flat files will rule the world? No more messy SQL, just iterate over the file's entries with a for loop - even Java programmers can understand that. Sorry, but I am not convinced yet.

You may not be convinced yet, nor am I, but your strawman argument makes you look ... well a little silly.

Re: The thrill of a new technology: CouchDB

#17

Post by jshen »

Tichy wrote: post #12
intinig wrote: post #4

Earlier quoted context omitted.

Tichy, give it a spin. The ease of execution (and the sheer speed, even over giant amounts of data) is impressive.

I can imagine some benefits, but as for speed of execution I am really doubtful. Your example suggests a "select all" followed by some analysis done in code. I can't imagine this scales well.

It creates an index for each view essentially. It's not anything like a "select all".

Re: The thrill of a new technology: CouchDB

#18

Post by jshen »

old-gregg wrote: post #8
intinig wrote: post #7

Earlier quoted context omitted.

The code is easy to read, and the data model is as flexible as you want it to be, since it's schemaless. Reasoning about what the code does is simple once you shift your paradigm to document from relational.

Do your research. "document-based" DBs already "ruled the world" right until relational databases were invented, which quickly obsoleted them. The only advantage of disk-backed hash table is ease of scalability, this is why they're useful for hm.... top 0.005% of web sites, who handle thousands of updates per second.

They are also useful for rapid app development or prototyping. I've used couchdb this way a few times and it works great.

Re: The thrill of a new technology: CouchDB

#19

Post by dasil003 »

jrockway wrote: post #15
dagheti wrote: post #11

Earlier quoted context omitted.

Hierarchies and graphs are both fundamentally navigational data models, which force a physical-logical coupling of concerns, hampering flexibility significantly. The network model recognizes the flexibility issue with hierarchies, however I'm not sure how it can guarantee the same scalability benefits. Due to this it doesn't have the flexibility of the relational model, nor the performance characteristics of the hier…

This is probably why it isn't ruling the world. Technical merit and popularity are only occasionally related in the computer world, so I won't comment on this. I will elaborate further on the use case of graphs versus a relational database. Basically, I see relational databases as especially useful for cases where you have a big pile of data, and have no idea what it really means. You do queries to learn what you hav…

I sort of see where you're coming from in terms of the parity mismatch between RDBMSs and typical application code. Certainly we can avoid some coding headaches by just dumping things into a data store that is optimized for what we want to do with that data right now. But then you say that most applications have a well-defined data model and rarely run "queries". This is where I think you've gone terribly terribly wrong.

The value of a relational database is that it most agnostically represents the reality of what the data represents. It's not about "big piles of data" or "making sense of your data", relational databases are about making your data as expressive as possible. You're selling this idea that most applications only use data in a few predefined ways. I have to say that sounds like a complete pipe dream. Requirements change all the time. Reporting needs often are not even conceived until you have hundreds of megabytes of data. Let's not even get into multiple applications using the same database.

In every business I've ever been involved with, the data is always more valuable than the code, and it always outlives the code. Too much of the hype around these alternative database technologies are throwing the baby out with the bathwater. The idea that "most" applications don't need structured data just strikes me as incredibly naive and short-sighted. Far more applications need structured data than need to scale.

Post reply on HN