×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Making Sense of the NoSQL Standouts

timothy posted more than 2 years ago | from the matching-this-to-this-to-this dept.

Databases 152

snydeq writes "InfoWorld's Peter Wayner provides an overview of the more compelling NoSQL data stores on offer today in hopes of helping IT pros get started experimenting with these powerful tools. From Cassandra, to MongoDB, to Neo4J, each appears geared for a particular set of application types, providing DBAs with a wealth of opportunity for experimentation, and a measure of confusion in finding the right tool for their environment. 'There are great advantages to this Babelization if the needs of your project fit the abilities of one of the new databases. If they line up well, the performance boosts can be incredible because the project developers aren't striving to build one Dreadnought to solve every problem,' Wayner writes. 'The experimentation is also fun because the designers don't feel compelled to make sure their data store is a drop-in replacement that speaks SQL like a native.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

152 comments

Also (0, Insightful)

Anonymous Coward | more than 2 years ago | (#36837318)

From the Anything-Better-Without-Oracle department.

One page (2)

just_another_sean (919159) | more than 2 years ago | (#36837356)

less ads.

Print version [infoworld.com]

Re:One page (0)

Anonymous Coward | more than 2 years ago | (#36838984)

less ads.

Print version [infoworld.com]

No ads. [adblockplus.org]

I'm always dumbfounded to see someone on Slashdot not running ABP, yet I see it fairly often. You'd think the one thing that actually makes browsing the internet bearable to begin with would be at the top of every "nerd's" list.

Re:One page (1)

imthesponge (621107) | more than 2 years ago | (#36840784)

Some people are less comfortable with stealing.

Re:One page (1)

praxis (19962) | more than 2 years ago | (#36841028)

Do you also never get up during commercial breaks in ad-supported televisions shows lest you feel a pang of guilt that you stole?

Here's how HTTP works:

1) My browser, an agent on my behalf, requests a document on my behalf from you.
2) Your server, an agent on your behalf, returns to me the document data.
3) My browser parses the document, choosing to run or not run code that is included in your document as well as load or not load referenced elements in the document. For a variety of reasons, I may or may not be interested in requesting all referenced documents.

How is choosing not to download all supporting documents stealing the one document that I requested and you gave me?

Re:One page (0)

Anonymous Coward | more than 2 years ago | (#36841038)

less ads.

You really meant to say, FEWER ads. Right?

Bend Over ... (0)

Anonymous Coward | more than 2 years ago | (#36837362)

"providing DBAs with a wealth of opportunity for experimentation" they need to start targetting the right audience group of
developers.

DBA : We should use mongoDB
DEV : Bend over ...

Re:Bend Over ... (2)

telekon (185072) | more than 2 years ago | (#36837408)

More typically, it goes:

Dev: We should use MongoDB.
DBA: THE END IS UPON US!!! The Beast and his armies shall rise from the Pit and make war against God!!! ZALGO!!! HE COMES!!!

Re:Bend Over ... (1)

FlyingGuy (989135) | more than 2 years ago | (#36838014)

No, it should go...

DEV: We should use MongoDB
DBA: Really? Here, have a nice big frosty glass of shut the fuck up. Now go back to your toy scripting languages and leave the data to those of us who actually understand data storage.

That should be the end of the discussion right then and there. The problem with these script kiddies is that 99.5% of them don't fucking have a clue about data. They are the ones who still embed SQL statements, log in credentials and the like in their php/python/rails/whatever.scripting.language.is.popular.this.week code. They have never even heard of stored procedures and views and wouldn't know a constraint from a hole in the ground. Sadly, it is not really their fault. MySQL ruined many a dev because it was so utterly primitive for so many versions that they never had to take the time to learn a proper database like Postgres, Oracle, DB2, MS-SQL which would have forced them to actually learn about data storage and retrieval.

MongoDB one of those fine databases that have managed to turn simple into complex eg:

--- simple ---
insert into users values('bob','123 Main Street','Springfield','NY');

-- a mess of curly braces, colons, commas and quotes ---
{
"username" : "bob",
"address" : {
"street" : "123 Main Street",
"city" : "Springfield",
"state" : "NY"
}
}

Re:Bend Over ... (0)

Anonymous Coward | more than 2 years ago | (#36838344)

Right on!! But you are preaching to wrong audience. Most of the 'online' developer community (including /.) exclusively deal with OOO SHINY front end applications, having no grasp of basic concept of RDBMS. So when their shitty queries start taking long time as data start piling up, they turn in to cry babies instead of learning some basics.

I have hardly seen any C / C++ developers complaining about database. Java/Ruby/Python/whatever on the other hand are just pussies.

Re:Bend Over ... (0)

Anonymous Coward | more than 2 years ago | (#36838398)

God what a drama queen. Hope you can back that up.

Not too long ago the nosql DBs were curious exotic toys only useful in very specific circumstances by some very big players.
Today the situation is similar but the toys have evolved and more applications with more 'players' are on the field.
I'd suggest that the current trend of turning every bit and word ever in to some sort of database might make these things even more common in the near future.

I remember reading a blurb from a google developer that said something to the effect of. "Yes, we could do it with SQL. Yes it work work fine.. But fuck it, it would be too expensive."

Re:Bend Over ... (1)

edumacator (910819) | more than 2 years ago | (#36840592)

Ok, I'm bracing for a crayon comment or some flaming, but I'm one of those script kiddies trying to move onwards and upwards.

I've read a lo about data, but the stuff I've found is all over the place. Can you point me in a good direction to start understanding data better?

Re:Bend Over ... (0)

Anonymous Coward | more than 2 years ago | (#36840872)

I guess it's just his ego. (i.e. read the Postgres manual and experiment.) However I'm not fan of YAML either, and that's also the invention of these script kiddies.

Re:Bend Over ... (3, Insightful)

epiphani (254981) | more than 2 years ago | (#36840948)

No, it should go...

DEV: We should use MongoDB

DBA: Really? Here, have a nice big frosty glass of shut the fuck up. Now go back to your toy scripting languages and leave the data to those of us who actually understand data storage.

That should be the end of the discussion right then and there. The problem with these script kiddies is that 99.5% of them don't fucking have a clue about data. They are the ones who still embed SQL statements, log in credentials and the like in their php/python/rails/whatever.scripting.language.is.popular.this.week code.

Congrats. You're the reason we get devs storing images in databases.

Either you have to educate your developers on what is appropriate to go into a relational database, or you need to get out of the way. Your attitude is exactly the reason NoSQL is picking up steam. I'm not a dev, but I've done dev work - nor am I a DBA, but I've done DBA work. And I can tell you, DBA's are often folks running around with a hammer: everything looks like a nail.

Devs, on the other hand, are looking for a solution, and thinking like devs: I'll build the solution to my problem! Of course, they usually end up reimplementing stuff other people have done.

If devs understood how full RDBMS's worked, database use would drop like a stone. If DBAs tool the time to understand requirements, database use would drop like a stone. NoSQL makes a _huge_ amount of sense. While you maintain your "script kiddies" attitude, the rest of the world will happily glide past you.

RDBMS's are 90% misused, and a massive waste of money. NoSQL is an overraction to that fact. Sometime in the future people will swing back to the middle and realize that files in directories are a surprisingly good way of storing data -- and each will have its place.

Re:Bend Over ... (2, Insightful)

Anonymous Coward | more than 2 years ago | (#36841078)

insert into users values('bob','123 Main Street','Springfield','NY');

I want to punch you in the head for not specifying the columns you're inserting into!

not worth reading (5, Informative)

rla3rd (596810) | more than 2 years ago | (#36837384)

Don' t bother reading this fluff. Wikipedia offers a better overview. http://en.wikipedia.org/wiki/NoSQL [wikipedia.org]. Oh I forgot, this is slashdot, no one here reads the articles :).

Re:not worth reading (0)

Anonymous Coward | more than 2 years ago | (#36837582)

Not trying to be negative, but the wikipedia page basically tells nothing about NoSQL. Yeah, I know it is not "relational", but what does that really mean? Why would you see a performance increase? What are the pros/cons and why?

Re:not worth reading (4, Informative)

doublebackslash (702979) | more than 2 years ago | (#36837914)

The abridged version:
Atomicity: actions or sets of actions complete or they don't. No half states. Ever.
Consistency: The database has rules. Rules like, "this can only be X when X exists in this other table" or "You cannot put a picture of a jabberwocky in this column." The rules are always obeyed even if one transaction fails. The DB itself will still be clean.
Isolation: Everything accessing the DB views it as if it were the only thing accessing the DB.
Durability: If the DB tells you it happened that means that you could yank the network jack, axe the power, or any other Bad Thing(tm) and so long as the disks are still there and intact your data also will be.

That is SQL. NoSQL: Pick three, or two.

Is it faster? You bet your ass it is. The limitations are, generally, that the DB won't do things like JOINs for you, or perhaps you have to deal with the idea of a half state, etc. Aside from ACID guarantees being, generally, broken the DB might act more as a key->value lookup (think a dictionary or encyclopedia, but with data). It might not have rigid fixed columns (some SQL databases do this too, but it is not a standard feature and generally comes with more cost vs a NoSQL that offers it).

NoSQL is useful, though, if you have a tremendous (REALLY REALLY huge, I mean it has to be worth it!) data set or some strange demanding special need. Some things don't need isolation because the actions are intrinsically isolated (Slashdot comments, for example, are just appended and only one column needs to be mutated (the moderation)) . Durability might not need to be met at the disk level, you might be comfortable with writing it to two node's memory (Cassandra even lets you return after it is in the target node's memory and after it has been flushed to the network send buffer. You know, to kill those pesky nanoseconds of latency). If your nodes are good and isolated this might be fine. Atomicity might not be a big deal.... though I can't think of any that don't provide THIS. Atomicity is really rather important almost everywhere. Getting rid of fixed tables or "relations" (foreign keys) makes consistency a non-issue. Consistency is one of the first things to be tinkered with in most of these NoSQL things, though it is not 100% gone (still can't put that jabberwocky in that int column!)

So by trading off some guarantees for a more simplistic DB one can gain speed and some degree of burden can be lifted from the programmer to work within the confines of that guarantee system. However, an ACID SQL system is universal (can store anything and meet any guarantees you require, but not necessarily quickly). NoSQL systems only work for some workloads and requirements. Almost (but not quite) anything can be shoehorned into them but weather it is a good idea remains a question to ask before you dive right in. If you can see gain from NoSQL then it might be a good idea, but don't paint yourself into a corner where you trade a working system of moderate speed for a blazingly fast system that has subtle (or blatant!) flaws which effect your company or customers.

Hope that helps!

Re:not worth reading (1)

nabsltd (1313397) | more than 2 years ago | (#36838228)

That is SQL.

No, that is a relational database with a lot of extras that protect the data.

SQL is a query language that could be used against any collection of data (with the correct parser and engine).

Re:not worth reading (1)

doublebackslash (702979) | more than 2 years ago | (#36838278)

I abridged too far =p
I do know it isn't SQL, I should have said "This is a standard ACID Compliant database like MySQL, PostreSQL, Oracle, and SQLite".

Re:not worth reading (0)

Anonymous Coward | more than 2 years ago | (#36840272)

MySQL until recently used a non-ACID storage type as it's default database store. It's still available and unfortunately used a lot (people like the wrong answer as long as it's fast apparently). MSSQL would have been a better example of an ACID complaint database.

Re:not worth reading (1)

shutdown -p now (807394) | more than 2 years ago | (#36838862)

Yes, but in the context of "NoSQL" this is a reasonable simplification, since that term itself really means "non-relational".

Re:not worth reading (1)

angel'o'sphere (80593) | more than 2 years ago | (#36839176)

That is SQL. NoSQL: Pick three, or two.

NoSQL has absolutely nothing to do with ACID.

True is that most NoSQL DB systems blur the points they enforce in ACID ... so you can emphasize on one or the other.

However you also can strictly enforce ACID in NoSQL DBs.

So what is the difference? They don't use tables, they don't define types per column and they don't support SQL as query language ... thats it.

NoSQL is garbage, plain and simple. (-1, Troll)

Anonymous Coward | more than 2 years ago | (#36837394)

NoSQL is garbage, plain and simple.

Re:NoSQL is garbage, plain and simple. (5, Interesting)

Anonymous Coward | more than 2 years ago | (#36837492)

If you view it as a SQL replacement, then yes, utter garbage. But if you take it for what it is, then no.

The problem is there is a fad surrounding NoSQL and young, ignorant, inexperienced developers think RDBMs are for old farts who refuse to get with the times rather than viewing it as a different tool for solving a different problem. If you want/need ACID properties, you go with SQL. If you don't, NoSQL may be appropriate.

Re:NoSQL is garbage, plain and simple. (3, Interesting)

fusiongyro (55524) | more than 2 years ago | (#36837834)

Yeah, the problem is that you want and need ACID, even if you don't know what it means. Very, very rarely, you may find yourself in a situation where availability demands are too great for systems with the ACID property, and then you should consider using one of these non-relational systems. The problem from where I'm sitting, is that too many young, ignorant, inexperienced developers think that their shitty little website needs to be prepared for handling millions of hits per second, and jump to two conclusions: one, that the problem is their database (and not the way they're using it), and two, that ACID should be thrown out the window to fix it.

All other things being equal, you are much more likely to be implicitly depending on ACIDity than in a situation where demand is great enough that choosing NoSQL is worth the trouble you're going to get into.

Re:NoSQL is garbage, plain and simple. (1)

Vanders (110092) | more than 2 years ago | (#36837956)

I need to dump millions of lines of syslog output to a structured datastore. I don't give a toss about ACID: I just need to know that the write succeeded. A NoSQL like MongoDB does the job brilliantly.

Re:NoSQL is garbage, plain and simple. (0)

Anonymous Coward | more than 2 years ago | (#36838510)

Exactly, assuming that everybody needs ACID for every datastore is not a valid assumption and if you think it is, you have a very limited imagination.

Re:NoSQL is garbage, plain and simple. (1)

NoOneInParticular (221808) | more than 2 years ago | (#36838758)

If your data is worth something out of this single application, you need relational and ACID. Syslog records might not qualify as being worth something. I heard flat file works fine for those.

Re:NoSQL is garbage, plain and simple. (1)

shutdown -p now (807394) | more than 2 years ago | (#36838884)

I think what GGP is saying is that it is reasonable to assume that ACID is needed by default, with proof required that it is not the case. Which makes sense for the same reason why assuming that something can be written in some high-level programming language makes sense, before deciding that, no, it really has to be in C.

Neo4j Information incorrect (0)

Anonymous Coward | more than 2 years ago | (#36837546)

As Michael Hunger points out in the comment on the article, it seems like the article author Wayner did almost no research on the Neo4j graph database. Some of his points are flat-out incorrect.

In b4... (3, Informative)

Anonymous Coward | more than 2 years ago | (#36837554)

This discussion is likely to lean towards "OMG NoSQL IS SO RETARDED!". So let me just say that if you don't care about NoSQL, then fine. If MySQL/Postgres/Oracle/MS-SQL fit your needs, then fine.

That doesn't mean "NoSQL" databases are useless.

I've had exposure to both MongoDB and CouchDB so far. CouchDB is the newest experience, as part of a Chef installation. Yes, it is a very immature product, and yes it has a long way to go, but it's very simple to configure and it does it's job with very few resources. I don't personally have a need for CouchDB myself, but I can see why people use it for certain specific needs (I.e. I can understand why Chef uses).

MongoDB is a little marvel for certain applications. In my current and previous jobs we've used MongoDB for Syslog collection and SMTP mail logging. MongoDB is excellent for this sort of thing: each log entry is a single entry in the collection, the data is NOT relational in any interesting way and the insertion rate is far beyond anything a traditional relational database engine could manage on the same hardware at the same resource utilisation. Even better you can write some quite clever Map/Reduce functions on top that allow you to do some amazingly deep inspections of the log data, so you can produce on-demand data as well as graph out long term trends.

NoSQL is a NOT a replacement for traditional SQL databases, but it sure is useful for stuff where SQL databases struggle.

Re:In b4... (1)

Anonymous Coward | more than 2 years ago | (#36837658)

NoSQL may not be retarded, but the article is. To start with, they didn't cover two of the major offerings, H-Base and Project Voldemort. From everything I've read, Voldemort is one of the few that will actually scale really well, so ignoring it makes me really suspect of the research that went into the article and makes me think that they're just trying to capitalize on the NoSQL buzz word by writing an article with a brief summary of the first few options they found.

Re:In b4... (1)

bhcompy (1877290) | more than 2 years ago | (#36838240)

Can't talk about NoSQL databases without including PICK. Hell, it predates SQL by years. And scaling is what it does best.

Re:In b4... (1)

fortyonejb (1116789) | more than 2 years ago | (#36838670)

Well technically you're not allowed to mention Project Voldemort by name, so they couldn't really cover it.

Re:In b4... (0)

Anonymous Coward | more than 2 years ago | (#36837738)

Needs more buzzwords and didn't tell me how it would provide synergy to my project.

Re:In b4... (1)

shutdown -p now (807394) | more than 2 years ago | (#36838914)

NoSQL does not provide synergy, it's optimized for performance. If you need synergy, you should use a traditional full-featured RDBMS. ~

Re:In b4... (1)

angel'o'sphere (80593) | more than 2 years ago | (#36839510)

What kind of synergy do you refer to?

The only thing where SQL excels in my opinion is the ability to write ad hoc queries. Random queries no one thought of before and they work ... in NoSQL you need to know the layout / hierarchy and have a good idea where to peek in and navigate from.

Re:In b4... (1)

mcmonkey (96054) | more than 2 years ago | (#36838596)

What's an example of where NoSQL is useful? I'm not a DBA or SQL guru, but I do work with traditional relational databases, and I'm having trouble thinking of a scenario where I'd want NoSQL.

I did a little research and the example I found was Twitter, and it sounded like a mess. You have a list of feeds with their followers, and a list of followers with the feeds each follows. It sounds nice for finding who follows a feed or for finding which feeds someone is following.

The issue I see is the duplication of information. Every time someone changes which feeds they follow, the number of data updates to make is doubled. And what happens when the 2 lists get out of sync? How much extra resources are spent making sure the feeds-to-followers list is consistent with the followers-to-feeds? Any time you store a piece of information in 2 places, it's just a matter of time until the 2 don't agree.

If that's poster child for NoSQL, I can see why some people are skeptical.

Re:In b4... (1)

angel'o'sphere (80593) | more than 2 years ago | (#36839260)

And what happens when the 2 lists get out of sync? How much extra resources are spent making sure the feeds-to-followers list is consistent with the followers-to-feeds?

Who would care about that?

If you and I follow Lady Gaga and Paul Mc Cartney, and both of them publish a new tweet, you see Lady Gags new message before Pauls, and I see Pauls before Lady Gagas .... who the fuck cares?

Big volume NoSQL DBs have one goal: they are eventually consistent.

It does not matter if I and you see the exact same result at the exact same time. As long as we see the same "pig picture".

Re:In b4... (1)

mcmonkey (96054) | more than 2 years ago | (#36839932)

If you and I follow Lady Gaga and Paul Mc Cartney, and both of them publish a new tweet, you see Lady Gags new message before Pauls, and I see Pauls before Lady Gagas .... who the fuck cares?

If the list of feeds I follow includes Lady Gaga, but the list of Lady Gaga followers does not include me, then when I check my account, it looks like I should get Gaga's tweets. But when Gaga tweets, it won't get sent to me.

Big volume NoSQL DBs have one goal: they are eventually consistent.

Ah, I get it now. It's perfect for something like Twitter, where your users are your product and your only goal is to maximize your number of users. This allows Twitter to handle the maximum number of feeds and subscribers by ignoring quality.

But for a service where the users are the customers, that is if I don't deliver quality data I don't get paid, this doesn't work at all.

And I don't mean that sarcastically. For something like Facebook or Twitter, "eventually consistent" is good enough. Of course, that's only if I don't think about how Twitter is becoming part of the emergency warning system. If the campus PD are sending out an alert because a Columbine or Virginia Tech type situation, I'd like to know sooner than "eventually".

But if my 'friend' needs to be at the gym in 26 minutes, yeah I can wait for that news flash.

Re:In b4... (1)

angel'o'sphere (80593) | more than 2 years ago | (#36840194)


  Of course, that's only if I don't think about how Twitter is becoming part of the emergency warning system. If the campus PD are sending out an alert because a Columbine or Virginia Tech type situation, I'd like to know sooner than "eventually".

You know it soon enough. That is not the point.
In this situation lets assume 1000 people give a warning. Lets assume the cluster has 100 nodes. And the "persistance rule" is: if ten nodes have it stored it is considered persistant(Quorum).
Now 10 thousands or more users fetch data from the cluster. Every write transactions is pending until 10 nodes confirm persistence. But every read transaction is fetching from random (or usually not so random master node), so you might get old data.
In other words: thousands of concurrent running write transactions are all partial committed. The reader randomly picks up data fragments from more or less random nodes.
That means the raw idea what is going on is transported to every reader.
Ofc, as you stated above: you might miss the tweet/message of your sister. But millions of other people will see your sisters message. Long long long before a traditional RDBM system could do that.

And in the end, you will see your sisters message as well. However: the whole point was about: "get the fuck out of the danger zone!!!" For that you don't need to wait for your sisters tweet, the thousands and millions other tweets already told you so.

Re:In b4... (0)

Anonymous Coward | more than 2 years ago | (#36839422)

I just gave you three examples of where NoSQL is used in the real world. Your mental model of how Twitter works is also badly incorrect: you're trying to apply a relational model a non-relational dataset.

Re:In b4... (1)

sacridias (2322944) | more than 2 years ago | (#36839330)

Retarded, no. Most people like to use the tools that best fit the job. 1) Well Known and established by all, in other words, support is everywhere, people that can manage it cost less and can be found at all skill levels. 2) Universal. SQL fits into so many places, where as nosql fits into a few small areas, and tends to be limited to perform well in just those areas. Meaning you need multiple databases for each section of your code based (not always a bad thing). 3) Stable. SQL has been around, optimization is stable, years of theories built on the core. 4) Non-experimental: SQL is known, NoSQL is a gamble, go to the owners and say hey we want to experiment, we are not sure that it will be better, but it may, it will only cost you a lot of time as we learn this new technology. Professional NoSQL will be used only where it can be fully proven to present great advantage, not just possibly give us advantage.

Use an IMDG as a front (1)

SpaceCracker (939922) | more than 2 years ago | (#36837588)

Read Nati Shalom's blog for an interesting article (http://natishalom.typepad.com/nati_shaloms_blog/2011/07/real-time-analytics-for-big-data-an-alternative-approach.html) about how to impliment an application using an In Memorg Data Grid as a front for the data and for real time or near real time analytics. The data can be persisted to a SQL or NoSQL database of your choice, depending on what best suits your application's needs.

Really, wikipedia? (3, Funny)

Anonymous Coward | more than 2 years ago | (#36837594)

Key-value store

Key-value stores allow the application to store its data in a schema-less way. The data could be stored in a datatype of a programming language or an object. Because of this, there is no need for a fixed data model. This is generally of interest to friendless sperglords only.[16] The following types exist:

Crowdsourcing at its finest.. Although, I suppose the comment is accurate?

Re:Really, wikipedia? (1)

indeterminator (1829904) | more than 2 years ago | (#36837828)

It has to be accurate, there's even have a citation for it.

Btw it's not there anymore (if it ever was).

Re:Really, wikipedia? (1)

MikeyC01 (231948) | more than 2 years ago | (#36838024)

Btw it's not there anymore (if it ever was).

I can vouch for him, it most definitely was there ... I shoulda grabbed that screenshot I was gonna make

Re:Really, wikipedia? (0)

Anonymous Coward | more than 2 years ago | (#36838128)

Btw it's not there anymore (if it ever was).

I can vouch for him, it most definitely was there ... I shoulda grabbed that screenshot I was gonna make

You guys do know that wiki has history [wikipedia.org], right?

Re:Really, wikipedia? (0)

Anonymous Coward | more than 2 years ago | (#36838180)

I, for one, welcome our friendless sperglords.

Mysql ITSELF is a "NoSQL" solution (4, Interesting)

mcrbids (148650) | more than 2 years ago | (#36837652)

Sure, some solutions are faster than MySQL out of the box by skipping much of the language parsing and stuff that any SQL solution has to do. But that's not to say that they are actually more efficient at key retrieval.

For example, one developer found that the best no-sql solution was.... MySQL, which excels at simple key retrieval [blogspot.com]. He was able to best MemCached by a factor of almost 2.

Use the right tool for the job.

Re:Mysql ITSELF is a "NoSQL" solution (2)

Billly Gates (198444) | more than 2 years ago | (#36838110)

The issue with SQL is with joins particularly. MySQl is not a noSQL solution to this problem. If you do not use them and just need a single database you will be fine with traditional SQL. NoSQL wont be a benefit. If you host a simple website you wont run into that scalability problem.

Now imagine your a systam analyst who needs joins to do things, such as comparing a pricing database with a sales order database to see if a discount worked and by how much? This is where you need join. Now imagine the size of both databases are 1 terabyte? Also imagine you have to pull this data from a regular ethernet connection shared by 100 other users only offering 10 mpbs speed? Also imagine the database is distributed among a cluster of computers and the RDMS needs to wait on the other servers to pull the whole table? See the performance problem?

Can noSQL offer a solution where I could do this?

My above example is why companies love Oracle and people doing analysis or statistics or even accountants need joins. The problem is with many databases and big iron and probably fiber optic connections and switches is that it gets very very expensive and is too much for a startup. The licensing costs then come up as well. Zdnet (dont have link) did an article showing it would cost $650,000,000 for Google to use Oracle to host Youtube. I can see why they went with their own solution.

Re:Mysql ITSELF is a "NoSQL" solution (0)

Anonymous Coward | more than 2 years ago | (#36840722)

Can noSQL offer a solution where I could do this?

well can it?

Re:Mysql ITSELF is a "NoSQL" solution (1)

MemoryDragon (544441) | more than 2 years ago | (#36840054)

Given how bad some versions of mysql support sql itself you can qualify them as nosql as well :-)

Don't forget about RavenDB (-1)

Anonymous Coward | more than 2 years ago | (#36837690)

http://ravendb.net/

some comments (1)

Anonymous Coward | more than 2 years ago | (#36837752)

first off, you have to really really understand your dataset before committing to either an sql or no-sql solution. this is because the main theoretical difference, as i see it, in sql, one basically generates a result set and the "game" is to find a particular record (or records) within result set, whereas with nosql, you basically already have your "object" (or key) and the "game" is to find what the object connects to. a subtle yet extremely important difference.

im towards the end of an 8 month project that i started with mysql, and switched to mongodb about a month in. why? because we are dealing with facebook data, and with facebook data, you start with the "id" (profile id) and nothing else. so it made sense to use nosql, or else the end result would have been implementing a hash table in mysql.

one totally amazing aspect of mongodb are the embedded documents. i use them to create a embedded "connection" for each key, and i can query an object (hash)'s connections and figure out what relates to what. it is extremely powerful. the key is deciding what is a connection and what is an object. for example, a user is an object, a community is an object, but a users role within that community is a connection. so you can group your objects (or "documents") into "collections" that have connections. in facebook's case, a page is an object but a "like" is a connection.

but, really, dont use nosql just because its cool (its not even a new idea, is it!?). its certainly a really neat and novel way to program a database, but could be your downfall if you dont understand your data set first.

Re:some comments (0)

Anonymous Coward | more than 2 years ago | (#36837958)

and one final thought: i have yet to find a framework that can fully support querying objects based on its connections; for example, trying to fit a URL request structure like /123456789/users

where 123456789 is your community id, into your favorite MVC framework is a giant headache because the mapping to controllers is not straightforward (do the controllers act as objects or connections!?). while weve already built our own queryable interface to handle this, it was all custom work. keep this in mind when deciding on a nosql solution.

Funny story (0)

Anonymous Coward | more than 2 years ago | (#36837854)

So, Netflix won't work on my Roku. Get "internal services error" messages. Google gets me to this [roku.com] two month long thread. Been going on since mid June and still isn't fixed. There is some problem with the Netflix "instant queue"; looks like the server has a cache that is out of date somehow. Can be fixed by altering or deleting entries from a web browser. Problem pops up with several different clients. Thinking to myself; this is a caching problem in the Netflix web services stack; probably some multi-tier coherency problem and reckless programming. Things like NoSQL come to mind; Digg and Twitter learned the hard way in public too.

Then this story appears. More muddled thinking about databases. I decided to make the effort to see if my blue sky guesswork about Netflix and their screwups have any basis in fact. Result [netflix.com] of Google query #1 ("netflix nosql"):

This is Yury Izrailevsky, Director of Cloud and Systems Infrastructure here at Netflix. As Netflix moved into the cloud, we needed to find the appropriate mechanisms to persist and query data within our highly distributed infrastructure ... move beyond the constraints of the traditional relational model ... high availability ... trumps strong consistency ... we have found ourselves braving the new frontier of NoSQL distributed databases.

22 weeks from that blog post to first damage.

This is just the sort of unthinking buzzword driven nonsense I have come to associate with all things NoSQL, the technology of celebrity wannabe PHBs. The results speak for themselves.

Chicken/Egg Problem (with NoSQL) (2)

Manip (656104) | more than 2 years ago | (#36837902)

We want to jump on the NoSQL ship. I won't bore you with all of the details but briefly put SQL databases and tables are too restrictive for our work. Unfortunately because there are SO many NoSQL solutions, and none of them are backed by big names nobody here has the balls to sign off on one. Unfortunately, and ironically, NoSQL's biggest downside is the lack of cross compatibility. Once you make that call you're stuck with it good or bad.

The other issue, is that because all of these solutions are relatively young the toolsets simply don't exist for many of them. No libraries, backup solutions, third party support, etc. I wish we'd see someone like Microsoft, Oracle, IBM, or any big name roll out some kind of complete solution (in particular XML compatible). I know a few big Cloud solutions exist but again we come back to being locked into a solution.

Re:Chicken/Egg Problem (with NoSQL) (3, Informative)

bhcompy (1877290) | more than 2 years ago | (#36838206)

Not every solution is young. PICK is a NoSQL db that predates SQL. It's descendants are supported and cross-compatible to a degree. NoSQL is a generic term. You need a specific database. For a PICK based solution, I'd look at Reality. Reality has been around for decades and is highly supported and has many features for compatibility with modern databases and modern operating systems. OpenQM is GPL licensed and of the same class. jBASE might be a more recognizable descendent.

MV databases (PICK etc) (1)

Anonymous Coward | more than 2 years ago | (#36840912)

DO NOT use PICK. I've been using it for 3 years, and the kindest thing I can say about it is that it is a cool idea implemented by an ugly hack. Library & inter-communications options just suck.

Re:Chicken/Egg Problem (with NoSQL) (0)

Anonymous Coward | more than 2 years ago | (#36838210)

We want to jump on the NoSQL ship. I won't bore you with all of the details but briefly put SQL databases and tables are too restrictive for our work. .

I find it odd that you're considering NoSQL because you find relational databases too restrictive. You'll find post-modern databases far more restrictive.

Re:Chicken/Egg Problem (with NoSQL) (1)

PCM2 (4486) | more than 2 years ago | (#36838226)

I won't bore you with all of the details but briefly put SQL databases and tables are too restrictive for our work.

Care to make a case for that?

Perhaps your work is too chaotic and disorganized for SQL tables?

(BTW, C. J. Date would take issue with anyone who thinks "tables" are part of the relational model, but I digress...)

Re:Chicken/Egg Problem (with NoSQL) (1)

angel'o'sphere (80593) | more than 2 years ago | (#36839670)

I doubt it is easy to make a case for that. As you coin it. However everyone I met last 10 years who is using NoSQL DBs made a gut decision. When I met the shop they always could show me a few things where I agreed that it is not really possible to do with a traditional SQL DB.

E.g. when you have to write giga bytes per second to the DB you are out of luck with any of our days RDBSs.

Keep in mind, NoSQL DBs are usually optimized for write performance and for the "exact retrieval path". There is no join involved. Always where you would join in an RDBMs you use redundancy and a precomputed hash to pick "exactly" the data you want. That is lightyears faster than ordinary DBs, but well your data storage is a mess. NoSQL is write once, never update but read often. SQL is read, write update all the time.

Re:Chicken/Egg Problem (with NoSQL) (2)

PCM2 (4486) | more than 2 years ago | (#36840552)

NoSQL is write once, never update but read often. SQL is read, write update all the time.

And yet most MySQL installations (Web apps, anyway) are: read all the time; write some; update seldom. That's why MySQL became a popular database for Web apps -- it was faster for that model than Oracle (on the same hardware). SQL or the relational model wasn't the problem. The implementation was the problem.

I'm sure there are some cases where NoSQL is absolutely game-changing -- but those cases seem rare, and where they have occurred, the companies that really need NoSQL seem to be the ones who invented it (as you might expect). But "Google uses it so I should" is a poor argument; you are not Google, no matter what your VP of sales likes to think.

E.g. when you have to write giga bytes per second to the DB you are out of luck with any of our days RDBSs.

I suppose that's true, but can you really process gigabytes of data per second? Maybe this is a case for data warehousing, and you don't even use a traditional database to capture the data. Er, wait -- maybe I just gave a case for using NoSQL. But in this case, NoSQL isn't a replacement for a RDBMS, it's an adjunct to one, so I guess all I'm really saying is that it gets tiresome to read discussions of NoSQL this, NoSQL that, when most folks seem to have a poor understanding of the dimensions of their own problem spaces and they've chosen a tool before they've figured out how they'll use it.

Re:Chicken/Egg Problem (with NoSQL) (1)

angel'o'sphere (80593) | more than 2 years ago | (#36841180)

Well, you basically got the point what NoSQL is all about.

As I mentioned in a different post, "NoSQL" does not necessarily mean "no" SQL but mostly it is referred to "not only" SQL and means you mix your storage strategies.

Imagine facebook, 100 millon users concurrently online. 1 million of them is writing a 100 characters comment on "something" per hour. That is 100 MB data to store per hour. And no one cares if he reads it just in time, 1 min after posting or 10 mins after posting. In other words: everything a traditional (and that has nothing to do with the query language) DB has to offer is not relevant. Why should all my friends get an XXX when they load my page, just because some random comment is not "acid committed"???

Everyone of them will see my *now* comment tomorrow anyway ...

Re:Chicken/Egg Problem (with NoSQL) (0)

Anonymous Coward | more than 2 years ago | (#36838254)

every copy of windows comes with an industrial stength journaling nosql database. Extensible storage engine for NT - engine used by exchange and AD for their backends

Re:Chicken/Egg Problem (with NoSQL) (1)

shutdown -p now (807394) | more than 2 years ago | (#36838980)

ESENT is just an ISAM database, no? What's "NoSQL'y" about it? I don't think it allows much schema flexibility (extra fields for individual records), for example.

Re:Chicken/Egg Problem (with NoSQL) (1)

MemoryDragon (544441) | more than 2 years ago | (#36840104)

It really depends on what kind of data you have. In the 90s when OODBs where the next big thing I was in a project where they tried to shoehorn tabular data and operations into an OODB, the project failed utterly, thanks to non existing well working query languages etc... entire simply sql ops became a major pain.
Schema updates forget about them every second one broke the existing db and data etc...
I assume with nosql the situation is rather similar, blazingly fast for certain use cases but utterly unusable for others.

learn something useful first (3, Interesting)

roman_mir (125474) | more than 2 years ago | (#36837954)

First you need to learn something useful, like understand a normal database, like PostgreSQL, SQLLite, DB2 or whatever your heart desires (not MySQL, that's just not right.) Once you really understand the normal databases and you understand your requirements only then you can make a statement by going 'nosql' something, otherwise it's most likely for most scenarios is counterproductive, you are not all FBs out there.

Re:learn something useful first (1)

roman_mir (125474) | more than 2 years ago | (#36838182)

Oh, and before you get on my case, I know that FB uses MySQL. The point is you are not all in need of huge quick data caches, and if you are serving static pages from a dynamic source, you are doing something else wrong altogether.

Re:learn something useful first (1)

angel'o'sphere (80593) | more than 2 years ago | (#36839820)

First you need to learn something useful, like understand a normal database,
First you need to learn something challenging, like implementing your own data base.

like PostgreSQL, SQLLite, DB2 or whatever your heart desires (not MySQL, that's just not right.)
like VMS on VAX with its build in DB, or Mumps or PICK (not SQL, that is not right).

Once you really understand the normal databases and you understand your requirements only then you can make a statement by going 'nosql' something,

Once you really understand the true databases and you realize how much easier they fit your requirements, you can justify going for 'SQL'.

otherwise it's most likely for most scenarios is counterproductive, you are not all FBs out there.
Otherwise you pay big money to Oracle for no reason.

Sorry, FTFY ...

If you never have used or had learned in school / university what "other DB paradigms" exist (coming back en vougue under the lable 'NoSQL') then you don't qualify at all to give a hint about databases.

Claiming that only SQL (and RDBMSs) is right is like claiming only Windows is the right OS. It simply shows you never saw any other OS and have no clue at all.

Re:learn something useful first (1)

Billly Gates (198444) | more than 2 years ago | (#36840274)

I am not a database programmer nor a DBA.

However I have worked with database software that needed to
1. Compare several tables in different databases
2. Do relational logic to analyize relationships, hence relational RDBMS.

A typical business task at work would be to figure out if a discount worked and by how much with certain stores in only a certain section of the country. Gee, I would need a SQL join (I hear the booing of the noSQL evanglists on that) to look at the orders database, the pricing database, as well as the inventory and store database which are on 2 different tables. Explain how I could do this without a RDMS? I could be full of it, but all the *lack of scalability* arguments the noSQL crowd uses can not produce the same results without joins. Frankly, I need to compare several terabytes of data and write software that triggers and records a log about it so I can let the executives know what is going on in business. Joins are a necessary evil and Oracle does managing very large data quickly quite well as slashdotters hate them.

All I see noSQL databases are good for is storing and retrieving data. I need to compare it, view it, perform logic, and most importantly compare several tables. I also have to work with MS Access or Crystal reports so my boss can pay me. What is the point of storing data if you are not going to use it? Until someone can tell me that a noSQL database can do these things it is all hogwash.

Re:learn something useful first (1)

angel'o'sphere (80593) | more than 2 years ago | (#36840392)

NoSQL DB does not imply you can not join ....

Until someone can tell me that a noSQL database can do these things it is all hogwash.

That is your misconception. There are countless more reasons for NoSQL than for SQL. Every situation where you can calculate your key, and that means in an extended way "can calculate the exakt disk address" of the data to retrieve, NoSQL is several magnitudes faster.

Typical NoSQL is not to REPLACE your SQL/RDBMS solutions, it is to ACCOMPLISH them. However with our days hardware you can put everything into NoSQL DBs with joins etc. and you are magnitudes faster than Oracle on a high end system.

After all NoSQL does not mean no SQL but not only SQL.

Re:learn something useful first (1)

roman_mir (125474) | more than 2 years ago | (#36840648)

Claiming that only SQL (and RDBMSs) is right is like claiming only Windows is the right OS. It simply shows you never saw any other OS and have no clue at all.

- while my advice is actually something that's useful to people who may otherwise be going in the wrong direction, yours is just stupid and pretentious and doesn't even apply to me, since I did enough work for AT&T, Bell Canada, Symcor, IFDS to have worked with some things, you may not even recognize as databases.

Yes, for the majority of people RDBMS is correct, both from their business perspective and the skill sets necessary.

Re:learn something useful first (1)

angel'o'sphere (80593) | more than 2 years ago | (#36841106)

Yes, for the majority of people RDBMS is correct, both from their business perspective and the skill sets necessary.

I doubt that.
Either there are no DBAs there used to be 20 - 30 years ago or business demand increased far far far more than DBs could follow.
Last 20 years I never saw any DB that could meet demand of the business.
That includes a "cluster" of 4 M4000 servers and lots of attached terabytes of storage. In this case based on Sybase, not Oracle.
The majority of people is just storing records into one single table. Fetching them with date and/or key. There is no join involved or anything.
The situation I'm in is: we have 4 main servers, 4 fail backs, and as they are at the edge of keeping up with the load, all "analyzing" is done on read only copies that are kept up to date with some DB magic.
Franky: you could invest $300.000 into a competent DBA and ditch 2 (+ back ups) $4M systems (not including maintenance) however, the true solution is: don't abuse the DB for stuff, a single file can do.

Don't forget lotus notes (1)

acomj (20611) | more than 2 years ago | (#36838352)

I was a notes programmer a decade ago... (wow...) I went to a talk on CouchDB and It all seemed strangely familiar.

Basically lotus Notes is a NoSQL database with an email and calendar program attached. Of course anything was better than "lotus script" but I can see why this stuff is very appealing. I think some of the couchDB developers are former notes developers are involved in the NoSQL movement.

Breaking the backs of DBAs (4, Interesting)

EmperorOfCanada (1332175) | more than 2 years ago | (#36838856)

One the many reasons that programmers that I know are adopting these technologies is that it breaks the back of the in-house DBA. Often there are a few in-house DBAs with certifications up the wazoo who squeeze themselves into every project that has to store data(all projects). But somehow their word becomes the final word. Getting a table added to a schema can take days or even weeks and might not be approved at all. Suddenly with MongoDB or whatever the DBA has no possible input. One can make all kinds of arguments for and against relational systems and how valuable a DBA is to the long term health of a datastore but from many developer's / project manager's perspective a modern DBA often acts as a brick wall to on time on budget.

Re:Breaking the backs of DBAs (1)

Billly Gates (198444) | more than 2 years ago | (#36840334)

Yeah and when data is lost and the middleware app crashes then who is at blame? I doubt the DBA as he/she did not implement it. The manager would have some explaining to do to IT on why he thought he could circumvent the DBA and corporate policies.

nHibernate (0)

Synerg1y (2169962) | more than 2 years ago | (#36838872)

anybody use this? I believe it falls under this category... we're about to get a large system that uses it, the developers say its not too bad, but I've use ADO.NET since 1.1 .

Why do they all have retarded names? (0)

Anonymous Coward | more than 2 years ago | (#36839764)

Really - why do they all have retarded names?

They should have called it fuck-you-SQL instead of noSQL

Cassandra @ ClubCompy (1)

BeforeCoffee (519489) | more than 2 years ago | (#36840440)

We use Cassandra for all the user management and virtual file system storage at ClubCompy, It is so blazing fast compared to SQL for both read and writes, and it is very scalable. I've had a node of my storage cluster go down and whole system stays up with no data loss, and it can repair itself once I bring the downed node back up.

Coding to Cassandra is pretty challenging, you have to do all of your data modeling in code or use the new CQL to access the cluster. I wrote about my experiences recently, where I have started using Google's Protocol Buffer to give me more flexibility in how I store my data and describe my column families: Coding to Apache Cassandra with Google's Protocol Buffers [clubcompy.com]

Dave

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...