Making Sense of the NoSQL Standouts 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.'"
One page (Score:3)
less ads.
Print version [infoworld.com]
Re: (Score:2)
adblock
or better
lynx
Re: (Score:2)
Well sure. of course, but this is one page!
Re: (Score:2)
I do use adblock, and noscript [noscript.net], but not everyone does and the main reason I prefer these links was stated in my subject, one page.
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
No ; I generally don't waste my eyeball time with the lowest-common-denominator retarded shit that advertising-paid TV puts on, in order to get the largest number of the stupidest people to buy the most unappealing crap for the highest price ... that advertising can support.
I wish the wife would let me get rid of the TV and go back to using the radio like I did before we married.
Re: (Score:2)
Do you ever go to the toilet during the commercials?
Do you ever skip over the classifieds in a traditional newspaper?
If so, you're a thief.
Re: (Score:2)
A grammar nazi set you off? You must really be new here. Take a deep breath and cherish this opportunity you were given to learn to speak English, since you evidently don't know what a "mass noun" is.
not worth reading (Score:5, Informative)
Re: (Score:3)
Re:not worth reading (Score:5, Informative)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Yes, but in the context of "NoSQL" this is a reasonable simplification, since that term itself really means "non-relational".
Re: (Score:2)
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.
Re: (Score:2)
The key with ACID was that it allowed applications to offload a lot of basic logic of data consistency to the database, and that was a great thing.
But I think NoSQL is coming out from the fact that there are still times you don't need/want to do that, usually involving massive amounts of data that can be processed in chunks that can just be "done again" if something goes wrong (sort of like Map/Reduce recovery).
In b4... (Score:3, Informative)
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: (Score:1)
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: (Score:2)
Re: (Score:1)
Re: (Score:2)
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
Re: (Score:2)
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 a
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:1)
You asked for it [flickr.com].
Re: (Score:2)
Any time you store a piece of information in 2 places, it's just a matter of time until the 2 don't agree.
create table users (
uid int not null primary key,
username varchar(255) not null,
passwordhash varchar(255) not null,
unique (username)
)
When I insert into this table, a reference to the generated row is stored in two places: the primary key index and the unique username constraint index. Is it just a matter of time until the two don't agree?
Why would this be different for a NoSQL system that stores information in two diff
Re: (Score:2)
Well, the very basic usecase is a key-value store. No relational overhead (and no sql parsing!) means it can be blitheringly fast.
In general, if your data is highly structured and internally consistent, you'll be well off with relational databases. If you want very fast lookups, your best option used to be a hierarchical database (LDAP, for instance), but that's a bit of a bugger for updates. NoSQL can also fit that bill, but there's quite a few very different implementations that make it more or less suit
Re: (Score:2)
NoSQL does not provide synergy, it's optimized for performance. If you need synergy, you should use a traditional full-featured RDBMS. ~
Re: (Score:2)
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: (Score:2)
Re-reading the comment I replied to in this [bizjournals.com] context might help with that whooshing sound.
Re: (Score:2)
LoL your sarcasm is astonishing ... /bow
Use an IMDG as a front (Score:1)
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? (Score:3, Funny)
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: (Score:2)
It has to be accurate, there's even have a citation for it.
Btw it's not there anymore (if it ever was).
Re: (Score:1)
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: (Score:1)
Nope, but I do now :)
I guess you do learn something new every day!
Mysql ITSELF is a "NoSQL" solution (Score:5, Interesting)
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: (Score:2)
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
Re: (Score:2)
Given how bad some versions of mysql support sql itself you can qualify them as nosql as well :-)
Re: (Score:2)
I read his article.
DON'T DO WHAT HE DID!
Although his conclusion is sane, the way he went about to make it happen is overly complex.
In his specific scenario (running always the same SQL queries by primary key but with different parameters) he found out that CPU time spent in SQL parsing and Query cost estimation were resulting in CPU-bound throughtput for MySQL.
He then proceed to "fix" this by getting some library that allows direct access to MySQL's underlying database bypassing the SQL layer and rewritting
some comments (Score:1)
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 t
Chicken/Egg Problem (with NoSQL) (Score:3)
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) (Score:4, Informative)
Re: (Score:2)
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: (Score:2)
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 involv
Re: (Score:3)
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
Re: (Score:2)
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: everyth
Re: (Score:2)
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
Re: (Score:2)
We want to jump on the NoSQL ship
These comparisons [kkovacs.eu] might be of interest...
Re: (Score:2)
Re: (Score:2)
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.
learn something useful first (Score:4, Interesting)
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: (Score:2)
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: (Score:1)
I don't know.
This guy [youtube.com] made a compeling case to use MongoDB over MySQL.
Re: (Score:2)
excellent argument. It wins the Internets.
Re: (Score:2)
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 underst
Re: (Score:1)
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
Re: (Score:2)
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 hardwar
Re: (Score:2)
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: (Score:2)
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 on
Don't forget lotus notes (Score:2)
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.
Re: (Score:2)
Whilst a captive user of Lotus Notes at IBM I frequently grumbled about it. In retrospect I really didn't appreciate how good it was and how much easier it made my life. I regularly synced my mail to Linux and to Windows and was able to seamlessly work offline. If it was an easy install on Linux I'd seriously consider dropping the $100 or so for a copy and I don't own *any* commercial software.
The "slosh data around model" has a strong appeal and Notes seemed to mostly do it pretty well. In a similar way th
Breaking the backs of DBAs (Score:5, Interesting)
faster, cheaper... (Score:2)
but what about that third pillar? the quality thing?
Re: (Score:2)
He did state he was coming from the view of a Developer. Quality is a QA/IT/DBA concern, not Development.
wouldn't fly in NASA (Score:2)
probably wouldn't fly in the linux kernel!
Re: (Score:1)
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.
Re: (Score:3)
One of the main reasons for this is that the DBAs are the ones that keep the production environment functioning. Devs get to put in whatever random thought that crosses their mind and when it breaks in production and data is lost, or clients are impacted they just shrug and say "Odd, didn't expect that".
A 'modern' DBA should be trained in whatever development cycle that dev is using, which may include Scrum/Agile, in which case the process would be integrated and the delay of implementation would be greatl
MongoDB (Score:2)
Amazon SimpleDB (Score:2)
Re: (Score:2)
Only a total nut would intentionally choose a solution that ties you to a single hosting provider who have acquired a reputation for kicking off clients they don't like.
Re: (Score:2)
Cassandra @ ClubCompy (Score:1)
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, whe
Re: (Score:3)
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: (Score:3)
actually:
Dev: We should use MongoDB.
DBA: BWAHAHAHAHAHAHA!!! NO !!! Oracle. get used to it or GTFO!
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
A fair question so here is a fair answer.
I am assuming ( yes, yes I know... ) of course you have some knowledge of basic tables and indexs, etc.
Start by reading and understanding Database Normalization [wikipedia.org]
Someone much wiser then myself once said, "You have to completely understand a set of rules before you can break them". I mention this in reference to data normalization.
The people who are the best coder / data monkey combination have the innate ability to think in structures. This is not to say it cannot
Re:Bend Over ... (Score:4, Insightful)
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: (Score:2)
A perfect illustration why good DBA's are worth having on staff.
Re: (Score:2, Insightful)
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!
Re: (Score:3)
The MongoDB record looks no more complex to me than the insert statement. In fact, the MongoDB record looks more readable, but what do I know, I'm probably one of the "script kiddies" you like to so disparage. I like to have my column names next to the data that actually goes into them, rather than some mess like insert into users (username, address, street, city, state) values('bob','123 Main Street','Springfield','NY'); that the true equivalent SQL would have been. By the way, I wonder why SQL uses such a
Re: (Score:2)
For me, bulk inserts only seem to work well in MySQL, not in any other DB system. (I'm probably doing something wrong; I know little about databases. I just want my data stored.)
Re: (Score:2)
While this is somewhat proper according to SQL-92 and on what is the failure mode? Personally, I believe it violates the atomic nature of an sql statement.
Now given a constraint that specifically only allows 'a'..'z' and 'A'..'Z' into the column lname, what part of this transaction fails? All of it or only (fred 3lmer) ? And if the entire transaction does not fail how does one determine wh
Re: (Score:2)
MongoDB one of those fine databases that have managed to turn simple into complex eg:
Is that what MongoDB code looks like? Looks perfectly readable to me. Cleaner and more structured than the SQL version. More verbose, yes, but highly usable, unlike SQL which always requires a couple of layers of abstraction and conversion and mapping in order to make it usable.
You might have just converted a SQL user to MongoDB.
Re: (Score:2)
Nope, now all that has to be converted into some sort of escaped string do to all the bloody text.
Re: (Score:2)
You don't understand the benefits of Mongo DB.
Please add a column to your users table. In your SQL DB you probably need to convert the table and have an global lock while doing so.
In Mongo DB on the other hand, you just add the whatever you want to include:
{
"username" : "bob", "address" : { "street" : "123 Main Street", "city" : "Springfield", "state" : "NY" }, "an" : "new", "column" : "with some new data"
}
Re: (Score:2)
Nope you are wrong. In Oracle you can alter a table while the entire system is in full use and transactions are flying like mad, no locks, no break in service no sweat. Oracle simply updates the data dictionary and as statements come through older records are modified on the fly and new records are simply, well, inserted.
Re: (Score:2)
I have hardly seen any C / C++ developers complaining about database. Java/Ruby/Python/whatever on the other hand are just pussies.
C/C++ developers are used to cumbersome and arcane rituals. Ruby and Python (Java less so, but still more than C/C++) are supposed to make programming faster and more natural. A more natural way to store and access data makes a lot of sense there. You could call them pussies, but you could also say they're more focused on the goal itself rather than the arcane stuff around it.
Re: (Score:2)
The proper audience is BOTH.
Dev's doing data structures is generally less than optimal (Disks have to spin? Just buy faster ones), DBAs doing logic flows is generally bad (This is the optimal data structure, so let's just change the business logic a bit). Both working together will build a much better application because it broadens the amount of concepts that can be taken into account.
Re:NoSQL is garbage, plain and simple. (Score:5, Interesting)
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. (Score:4, Interesting)
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: (Score:1)
Re: (Score:2)
Re: (Score:2)
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.
but MongoDB is the web scale (Score:2)
Intersting article.
This is a funny Q&A session on Mongo DB [xtranormal.com] which raises a good point.
Re: (Score:2)
NHibernate and ADO.NET are tools for interacting with a data store, this article is about the data stores themselves, not the tools of interaction.
NHibernate is an ORM, more of a competitor to Microsoft's Entity Framework than to ADO.NET.
Re: (Score:2)
At least they have a name, rather than merely a generic description, like MS SQL Server.
Re: (Score:2)
I've thought I'd seen a problem with our Netflix queue. I just assumed my wife had messed it up somehow :)