Linked by MOS6510 on Fri 2nd Aug 2013 18:06 UTC
Databases
Let’s say you’ve decided to set up a website or an application. You'll obviously need something to manage the data. Yes, that's right, a database. So, what is it going to be? MySQL, MS-SQL, Oracle or PostgreSQL? After all, nothing can be as amazing as a good old RDBMS that employs SQL to manage the data.

Well, allow me to introduce to you an entirely unique and unconventional Database model - NoSQL.

Order by: Score:
It isn't exactly new.
by lucas_maximus on Fri 2nd Aug 2013 18:56 UTC
lucas_maximus
Member since:
2009-08-18

NoSQL has been around well before SQL.

Also there is this talk.

http://www.youtube.com/watch?v=qI_g07C_Q5I

Where he said he remembered a time before SQL.

Most of these databases are key value stores and have their advantages in some circumstances.

Reply Score: 4

RE: It isn't exactly new.
by galvanash on Fri 2nd Aug 2013 22:10 UTC in reply to "It isn't exactly new."
galvanash Member since:
2006-01-25

NoSQL has been around well before SQL.


No doubt. At my job we work with something called Cache, which used to be known as Mumps:

http://en.wikipedia.org/wiki/MUMPS
http://robtweed.wordpress.com/2012/10/21/mumps-the-universal-nosql-...
http://vschart.com/compare/intersystems-cache/vs/mongodb

It has changed quite a lot over the years, but this software is still in heavy use by the healthcare industry. It is used in a number of products, notably GE Centricity Business.

I can't help but notice the similarities between Mumps and Mongo... They are VERY similar in form and function (although obviously differ in many of the details).

Mumps was introduced in 1966...

Edited 2013-08-02 22:13 UTC

Reply Score: 6

...
by Hiev on Fri 2nd Aug 2013 19:00 UTC
Hiev
Member since:
2005-09-27

NoSQL databases were a boom for a time till many started to note that it didn't solved much of the scalability issues, and it was just on pair with traditional SQL Databases.

Edited 2013-08-02 19:00 UTC

Reply Score: 4

RE: ...
by Lennie on Fri 2nd Aug 2013 22:09 UTC in reply to "..."
Lennie Member since:
2007-09-22

That totally depends on the needs of the application.

It's easier to scale something like Redis than to scale a SQL-server.

But that doesn't mean you need to rely on just one.

PostgreSQL has a key value store called hStore and newer version have a JSON-type and also Foreigh Data Wrappers that can talk to other SQL or NoSQL or flat files or webclients, DNS-clients, whatever you want to create code for.

Reply Score: 3

RE[2]: ...
by Hiev on Fri 2nd Aug 2013 23:35 UTC in reply to "RE: ..."
Hiev Member since:
2005-09-27

It's easier to scale something like Redis than to scale a SQL-server.

That depends of you definition of scale.

Reply Score: 3

RE[3]: ...
by galvanash on Sat 3rd Aug 2013 02:58 UTC in reply to "RE[2]: ..."
galvanash Member since:
2006-01-25

That depends of you definition of scale.


True. If you are trying to scale up read performance and you do not have a write bottleneck - there is little inherent advantage to the noSQL approach. Generally speaking, either approach can scale out reads rather well, and traditional relational databases have tremendous advantages when it comes to querying flexibility.

Of course if you have that particular problem consider yourself lucky ;)

On the other hand, if you are primarily write bound, can plan your data model so that you do not need the flexibility SQL offers, and can live with the consistency tradeoffs, noSQL approaches have significant advantages.

In my opinion it isn't a matter of SQL vs noSQL, it is a matter of ACID vs BASE (eventual consistency) when the discussion is about scaling...

https://en.wikipedia.org/wiki/Eventual_consistency
https://en.wikipedia.org/wiki/CAP_theorem

I would add that, in my opinion, if your problem can be adequately handled by 1 or 2 high powered servers you are probably better off with a traditional RDBMS and all the benefits of ACID compliance that come with it.

NoSQL makes sense when:

1. Your problem is so simple and so small that it doesn't actually matter. Some developers like the key-value approach just to avoid having to deal with a traditional RDBMS complexities. Schema-less datastores are nice and easy for developers who want to model their data in their application layer. If this is you go for it, you will likely learn a lot on the way - and if your problem set grows or evolves you will learn all the bad stuff about noSQL too... I'm not saying I think this is a "good" reason to use noSQL, I just think it is very useful to learn by doing, even if you discover it was a bad idea along the way...

2. Your problem is really big. You have a absolutely huge dataset that requires ALOT of write throughput and you only need to query it in very specific ways. If you _really_ understand your problem well and can live with some of the tradeoffs brought about in eventual consistency models, noSQL can make your life easier (and dramatically reduce your maintenance and hardware costs).

Most real world problems are somewhere in the middle of those two extremes... All I can say is you don't really appreciate the benefits of an ACID compliant RDBMS until you discover you need them, usually at the point you are too far along to do anything about it ;) Tread carefully...

Reply Score: 4

RE: ...
by Soulbender on Sat 3rd Aug 2013 04:11 UTC in reply to "..."
Soulbender Member since:
2005-08-18

Eh, NoSQL and RDBMS's solve different problems and it's not only about scalability.
If your data is relational then an RDBMS is the best choice but for data that isn't relational (and a lot of data isn't) you might want to look at NoSQL. At least it might reduce the chance that you use an RDBMS as a glorified flat-file storage...

Reply Score: 4

Comment by Kroc
by Kroc on Fri 2nd Aug 2013 19:22 UTC
Kroc
Member since:
2005-11-10

Assess the tools available to you and use the right one for the job. If you're comfortable with SQL then that's no excuse to ignore NoSQL methods.

IMO SQL databases are heavily overused on the web. If you don't need to do highly selective data cherry-picking (such as filtering of a result set), or mashing of two sets of data together (analytics), then often a flat data store is simpler, faster and more reliable. For the web, you don't need an SQL database to serve static content, and where you need to index and search content you have offline systems like Syphinx that give you a database for searching but you can keep the fast static caches for the content. (i.e. use flat files for what they're good for and SQL for what it's good for)

Because I didn't like the downsides of SQL databases for web content (portability / maintenance / security / setup&config time) I created a forum system that has no database, just RSS feeds -- each discussion thread is itself an RSS feed. This means that setup is a matter of seconds (unzip and run) and the data is portable, easy to parse, transform, manage, convert and generally process without the need of specialised / my software. Google for NoNonsense Forum should you be interested.Google for NoNonsense Forum should you be interested.

The benefits for my use case made NoSQL the right choice, but I wouldn't think twice about using an SQL database if a project needed those kind of requirements. My point is: learn what's possible with each approach (benefits / drawbacks) and use each to its full potential, and don't be afraid of mixing methods!

Reply Score: 5

RE: Comment by Kroc
by Lennie on Fri 2nd Aug 2013 22:11 UTC in reply to "Comment by Kroc"
Lennie Member since:
2007-09-22

Many now use a version control system to store their versioned flat files.

Some Wiki implementations for example store and retrieve directly from git.

Reply Score: 2

RE: Comment by Kroc
by henderson101 on Fri 2nd Aug 2013 22:57 UTC in reply to "Comment by Kroc"
henderson101 Member since:
2006-05-30

I've done it as a traditional database, a key/value store and an ORM, where I really didn't care what the DB looked like. Honestly, the best approach is to either ORM the dataset (I used Entity Framework code first in a number of projects, doing so, the database structure became competely opaque) or use tables for static data and K/V for dynamic data. The biggest issue with K/V is reporting on the data. If a reporting solution is critical (e.g. Sales, stats etc) then K/V really falls down. Pivoting giant chunks of data is no real fun. Neither is field bloat in traditional tabular databases, so the happy middle ground works well.

Reply Score: 3

Just another tool
by Nelson on Fri 2nd Aug 2013 19:59 UTC
Nelson
Member since:
2005-11-29

I find that in many use cases SQL is overkill where a document db will do, plus the flexibility afforded by storing straight JSON makes rapid prototyping a breeze.

For a while we had square peg round hole situations where everything was shoved into a relational model, which is where I think the rapid uptake of NoSQL databases came from.

For Redis, since stuff like ram became cheap, ensuring low latency by just using a K/V store in memory works pretty well too.

At massive scales, the least path of resistance to scale is usually the one that prevails.

Reply Score: 4

Before SQL
by kwan_e on Sat 3rd Aug 2013 00:35 UTC
kwan_e
Member since:
2007-02-18
RE: Before SQL
by sithlord2 on Mon 5th Aug 2013 06:54 UTC in reply to "Before SQL"
sithlord2 Member since:
2009-04-02

And don't forget Lotus Domino either.

Reply Score: 1

RE[2]: Before SQL
by kwan_e on Mon 5th Aug 2013 08:04 UTC in reply to "RE: Before SQL"
kwan_e Member since:
2007-02-18

And don't forget Lotus Domino either.


That wasn't before SQL.

Reply Score: 2

Comment by ssokolow
by ssokolow on Sat 3rd Aug 2013 07:44 UTC
ssokolow
Member since:
2010-01-21

Many excellent points but one nobody has drawn attention to:

Calling NoSQL "a type of database" is about as accurate as calling atheism "a religion".

I always hate seeing people lumping key-value stores, hierarchical databases, document-oriented databases, and everything else under the sun that isn't SQL-based under one term. It smacks of "as long as it's not SQL-based, it suits my needs" thinking.

Edited 2013-08-03 07:46 UTC

Reply Score: 4

RE: Comment by ssokolow
by Soulbender on Sat 3rd Aug 2013 10:51 UTC in reply to "Comment by ssokolow"
Soulbender Member since:
2005-08-18

Calling NoSQL "a type of database" is about as accurate as calling atheism "a religion".


Well, it does seem like quite a few atheists practice it with an almost religious zeal and elitism.


I always hate seeing people lumping key-value stores, hierarchical databases, document-oriented databases, and everything else under the sun that isn't SQL-based under one term


Why? That's what they are. Relational, object-oriented, key-value, hierarchical etc etc are all different types of databases.

Reply Score: 2

RE[2]: Comment by ssokolow
by kwan_e on Sat 3rd Aug 2013 23:22 UTC in reply to "RE: Comment by ssokolow"
kwan_e Member since:
2007-02-18

"Calling NoSQL "a type of database" is about as accurate as calling atheism "a religion".


Well, it does seem like quite a few atheists practice it with an almost religious zeal and elitism.
"

What do those atheist practice? Not stamp collecting?

Reply Score: 3

RE[2]: Comment by ssokolow
by ssokolow on Mon 5th Aug 2013 12:53 UTC in reply to "RE: Comment by ssokolow"
ssokolow Member since:
2010-01-21

"Calling NoSQL "a type of database" is about as accurate as calling atheism "a religion".


Well, it does seem like quite a few atheists practice it with an almost religious zeal and elitism.
"

No argument there. The presence of personality attributes like zeal and elitism is orthogonal to the presence or absence of any given set of religious beliefs.

"I always hate seeing people lumping key-value stores, hierarchical databases, document-oriented databases, and everything else under the sun that isn't SQL-based under one term


Why? That's what they are. Relational, object-oriented, key-value, hierarchical etc etc are all different types of databases.
"

That's what I said. They're different types of databases so it makes no sense to use the same term to describe "every type of database except SQL-based relational".

Edited 2013-08-05 12:54 UTC

Reply Score: 2

RE[2]: Comment by ssokolow
by BallmerKnowsBest on Mon 5th Aug 2013 19:53 UTC in reply to "RE: Comment by ssokolow"
BallmerKnowsBest Member since:
2008-06-02

"Calling NoSQL "a type of database" is about as accurate as calling atheism "a religion".


Well, it does seem like quite a few atheists practice it with an almost religious zeal and elitism.
"

Atheism is a religion in the same way that not smoking cigarettes is an addiction.

Reply Score: 3