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

NoSQL Data Modeling Techniques

highlyscalable.wordpress.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: NoSQL Data Modeling Techniques

#21

Post by grannyg00se »

bartonfink wrote: post #19
batista wrote: post #11

Earlier quoted context omitted.

First off I find the NoSQL term in itself very strange. How can you say anything intelligent about "everything that is not using SQL as a query language"? Its like talking about NoJava, instead of talking about Ruby. Only it's not like that, because SQL is a well defined way of thinking at problems, not just a particular implementation of it. So, NoSQL is like saying NonFunctional. Or NonImperative. Or NoRegister VMs…

SQL is a language that is not particularly well defined, nor essential to solving problems. What you're referring to as a "well defined way of thinking" is the relational model. There have been relational databases that did not use SQL as their query language, and although they're not widespread, the same points the NoSQL community makes against e.g. Postgres could be made against them.

Like most buzz words, its popularity has overshadowed it's usefulness. I agree that a word to categorize these recently popular non-relational databases would be handy. But nosql is really not accurate. Unless you abandon all attempts to interpret it literally. When I see "nosql" that now tranlates into "that group of recent and fashionable databases which are primarily key/value stores with some traditional database features added in to varying degrees". So at least it means something (to me anyway), and it's abstracting quite a mouth full. Much better than "Web2.0" was. That always just translated simply to "ajax with nice UI" for me, but I saw the term used in so many ways that didn't fit that definition.

Re: NoSQL Data Modeling Techniques

#22

Post by Maro »

batista wrote: post #15
Maro wrote: post #14

Earlier quoted context omitted.

NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff).

NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. Per gmail account, you'd still dump all the mails into one gigantic emails table, either an SQL or a NoSQL one. As for the totality of the gmail accounts, well, you'd use sharding, which is the same whether you use NoSQL or SQL. You also want to cache the hell out of it, which i…

So you'd have one 'emails' table per Inbox, right? So for 1 million users, you'd have 1 million tables, and no SQL database can handle that.

Re: NoSQL Data Modeling Techniques

#23

Post by Maro »

mattmanser wrote: post #16
Maro wrote: post #14

Earlier quoted context omitted.

NoSQL is a better fit for Gmail because you wouldn't want one gigantic 'emails' or 'contacts' table, which is how you would model it in SQL. You also want to cache the hell out of it, which is easier done in a NoSQL model (e.g. if the cache layer is integrated and hence uses the same API as the persistent stuff).

Huh, why wouldn't you want those tables? You seem to be confusing the need to scale with how you would design the system. Somewhere I worked before we used to import 100,000s of a companies email into the project system to display them against the system. They were all in an Emails table which just stored the body, I think there was an email header table and an email contacts table which was relationally linked direc…

I wasn't talking about "email" as a use-case, I was talking about "Gmail". Obviously you can serve 1000s of email users using an SQL and IMAP database.

Re: NoSQL Data Modeling Techniques

#24

Post by michaelmior »

bni wrote: post #6

First off I find the NoSQL term in itself very strange. How can you say anything intelligent about "everything that is not using SQL as a query language"? Its like talking about NoJava, instead of talking about Ruby. Props for a well written article with lots of nice graphs but I dont agree with much of its content. A few examples: "software applications are not so often interested in in-database aggregation" In my e…

I agree that NoSQL is a strange term, although perhaps not quite for the same reason. I agree with the statement by @batista that SQL in this context is a defined way of thinking about problems. But NoACID seems much more appropriate especially as many "NoSQL" systems get SQL interfaces stuck on top.

Re: NoSQL Data Modeling Techniques

#25

Post by ericmoritz »

antirez wrote: post #8

I've the feeling that when talking about Data Modeling, Redis really does not fit into the key-value category.

That's somewhat true. There's no need to model data structures like trees, maps, sets and lists in a data store that supports them natively.

This article is still useful when using Redis because the article describes techniques apart from modeling fundamental data structures; most of the indexing techniques are still applicable to Redis, for instance.

As an example, the Composite Key Index technique could be accomplished using a sorted set to store the ordered set of keys and Redis's k/v functionality to retrieve the values.

Re: NoSQL Data Modeling Techniques

#26

Post by zorked »

grannyg00se wrote: post #21
bartonfink wrote: post #19

Earlier quoted context omitted.

SQL is a language that is not particularly well defined, nor essential to solving problems. What you're referring to as a "well defined way of thinking" is the relational model. There have been relational databases that did not use SQL as their query language, and although they're not widespread, the same points the NoSQL community makes against e.g. Postgres could be made against them.

Like most buzz words, its popularity has overshadowed it's usefulness. I agree that a word to categorize these recently popular non-relational databases would be handy. But nosql is really not accurate. Unless you abandon all attempts to interpret it literally. When I see "nosql" that now tranlates into "that group of recent and fashionable databases which are primarily key/value stores with some traditional database…

"that group of recent and fashionable databases which are primarily key/value stores with some traditional database features added in to varying degrees" is exactly what the term means.

So I guess it works.

Re: NoSQL Data Modeling Techniques

#27

Post by mark_l_watson »

I had a good talk with a potential customer two days ago and we covered non-relational databases in some detail. I blog about non-relational databases a lot so he thought it was 'religion' for me, but this is not the case at all: I default to wanting to use PostgreSQL (or another relational database) and instead choose MongoDB, CouchDB, etc. depending on special requirements.

As per the article, it is required to understand the CAP theorem and specific capabilities of different data stores.

Client library support varies a lot. Some ORM tools like Ruby's Datamapper let you design composite storage schemes using a relational database and, for example, MongoDB. For document oriented data stores I very much prefer writing client apps in languages like Ruby and CLojure that have a nice syntax for maps, etc.

Re: NoSQL Data Modeling Techniques

#28

Post by JackC »

zorked wrote: post #26
grannyg00se wrote: post #21

Earlier quoted context omitted.

Like most buzz words, its popularity has overshadowed it's usefulness. I agree that a word to categorize these recently popular non-relational databases would be handy. But nosql is really not accurate. Unless you abandon all attempts to interpret it literally. When I see "nosql" that now tranlates into "that group of recent and fashionable databases which are primarily key/value stores with some traditional database…

"that group of recent and fashionable databases which are primarily key/value stores with some traditional database features added in to varying degrees" is exactly what the term means. So I guess it works.

Yeah, I think that's good. It's kind of like the term "Modernism," which makes no inherent sense but made sense when it was coined as a response to particular styles that came before it and were seen as, well, not modern enough. (Art people will tell me I'm wrong, but close enough.)

NoSQL refers to the databases that are proposed as alternatives in areas where programming culture had gotten used to thinking that the only solution was an ACID-compliant relational database. It means, "hey, this isn't the model you're used to, but give it a try anyway." You can't figure out the word without knowing the culture it emerged from.

And now I'm getting post-modern.

Re: NoSQL Data Modeling Techniques

#29

Post by eternalban »

antirez wrote: post #8

I've the feeling that when talking about Data Modeling, Redis really does not fit into the key-value category.

To the extent that one could talk about data modeling using the constructs of an imperative language e.g. C then one can do the same with Redis (with the caveat that Redis lacks a reference type). K/V only stores restrict the semantics to that of maps e.g. map["foo"]=bar, but if they introduce richer operations e.g. map-reduce on the K/V containers (e.g. map.apply(func)), then it is pretty much Redis restricted to its String type.

I personally have a preference for unified views of systems so my bias is to look at the entire hierarchy of storage (image) and memory model (semantics) as a singular space, with back end disks as Ln to L1 cache on the CPU. In this light, to me Redis is a memory manager(/cache) + DSL, serving at Lx (where x is somewhere south of local Disk and north of a durable and consistent distributed FS backend e.g. HDFS).

Re: NoSQL Data Modeling Techniques

#30

Post by leif »

einhverfr wrote: post #2

This is an interesting article. I am primarily a PostgreSQL guy who does all sorts of things like hierarchical data representation in SQL. While these things have come a long way in the past few years. This being said, the more I read about NoSQL data modelling techniques, the more it occurs to me that some of these techniques may work well in relational data environments where data is read-frequent/write-seldom. In…

Even if it's not write-infrequent, you can still try these ideas in SQL if you use a write-optimized database like tokudb (the one I work on).
Post reply on HN