A Tale of Two Databases, Revisited: DynamoDB and MongoDB

Questioning his belief in relational database dogma, new submitter Travis Brown happened to evaluate Amazon's Dynamo DB and MonogDB. His situation was the opposite of Jeff Cogswell's: he started off wanting to prefer Dynamo DB, but came to the conclusion that the benefits of Amazon managing the database for him didn't outweigh the features Mongo offers. From the article: "DynamoDB technically isn't a database, it's a database service. Amazon is responsible for the availability, durability, performance, configuration, optimization and all other manner of minutia that I didn't want occupying my mind. I've never been a big fan of managing the day-to-day operations of a database, so I liked the idea of taking that task off my plate. ... DynamoDB only allows you to query against the primary key, or the primary key and range. There are ways to periodically index your data using a separate service like CloudSearch, but we are quickly losing the initial simplicity of it being a database service. ... However, it turns out MongoDB isn't quite as difficult as the nerds had me believe, at least not at our scale. MongoDB works as advertised and auto-shards and provides a very simple way to get up and running with replica sets." His weblog entry has a few code snippets illustrating how he came to his conclusions.

Comments

Correct comparison?

[Bodero]

Did he compare MongoDB to the correct product then? I'd love to have seen him also include Amazon SimpleDB.

MongoDB is broken by design.

[Anonymous Coward]

Nice astroturf. See here for a detailed analysis of why MongoDB is broken by design.

Re:MongoDB is broken by design.

[Anonymous Coward]

Why is this comment at -1? The analysis of how Mongo is broken is longer, more detailed and much more in depth than the OP's craptastic article.

Re:MongoDB is broken by design.

[_merlin]

Mongo fanboys. They're a menace to society. I worked at a trading firm that was infested with them, and they tried making Mongo a dependency in all parts of our codebase. It's nasty stuff, polluting your code with macros if you aren't extremely careful about #include order, running the server wreaks havoc with I/O on a box, and it really didn't perform that well when trying to extract the kinds of data sets needed for useful analysis.

Re:MongoDB is broken by design.

[Anonymous Coward]

Not ACID is all the reason I need to not use it.

Re:MongoDB is broken by design.

[stephanruby]

Nice astroturf. See here for a detailed analysis of why MongoDB is broken by design.

Speaking of which, the same back to you.

Did you know the author of the article you pointed to is a competitor and recommends his NoSQL Database called HyperDex as a reasonable alternative (although, he doesn't state he's the developer for HyperDex, nor does he state the fact that HyperDex is still in alpha and doesn't work properly)?

Nicely played Anonymous Coward!

Re:MongoDB is broken by design.

[Anonymous Coward]

Actually, his connection to HyperDex is pretty clear on his pages. And if anything it puts him in a position of authority. I don't like Mongo pushing these kinds of blog posts with low information content and I really don't like Mongo maligning other hackers who have technical points. Ad hominem attacks show that Mongo has no technical comeback.

Re:MongoDB is broken by design.

[philip.paradis]

The author of that article clearly references his association with HyperDex in the "About Me" box in the top right area of the page. Following the "more..." link, you find another reference to HyperDex. He's not exactly hiding his involvement in the project; how are you supposing people would miss it or somehow feel the urge to claim deceit on his part?

I didn't know about HyperDex before reading the GPP comment, and might play with it this weekend. Maybe you should, too, especially since it's apparently at rc2 status now. Cheers!

Re:MongoDB is broken by design.

[Anonymous Coward]

that link is a joke. Basically it all boils down to the author does not like the default Mongo settings for persistence. Then you have all the RDBA drones piling on. It is actually enteraining to read all the idiots including the author who just happens to be pitching his favorite nosql database.

Re:MongoDB is broken by design.

[Anonymous Coward]

I read it. His complaint seems to boil down to "WriteConcern.REPLICAS_SAFE isn't!" but won't elucidate why, other than to continually say "I'll tell you later!"

Even if his assertion is true (and it's utterly unconvincing right now that it is) it doesn't make MongoDB "broken": it means it isn't suitable for use where you absolutely care about the data being written. Given that MongoDB was specifically designed for data where you don't care if a write works or not (and now the relational guys are going to start ranting about ACID, all while missing the point) it would appear that MongoDB is working as intended and the author of a competing product just has a bug up his ass.

Re:MongoDB is broken by design.

[stephanruby]

Actually, his connection to HyperDex is pretty clear on his pages.

My mistake, I didn't read everything in the "About Me" box on the right of his blog, but still his connection could have been made clearer. This was a very-very long blog post, which I actually read completely, which he obviously crafted very carefully, and I only found out about his connection to HyperDex in the comments of others.

And if anything it puts him in a position of authority.

Why couldn't it be both?

By being a competitor posting about MongoDB, he's in a position of authority, and he also has a conflict of interest possibly motivating his opinion.

...and I really don't like Mongo maligning other hackers who have technical points. Ad hominem attacks show that Mongo has no technical comeback.

It wasn't Mongo. It was me. I have no affiliation with Mongo/MongoDB. I don't even use MongoDB, you can check my posting history, I've never spoken about MongoDB and I really couldn't care less about it. I'm just a by-standard. Saying that the author didn't talk about his connection to Hyperdex was a mistake on my part (thought, like I said, he could have made that part clearer by including it in the article itself).

And calling you (or the previous poster) an Anonymous Coward wasn't an Ad hominen attack. "Anonymous Coward" is the all-purpose anonymous username that you (or that the previous poster) have deliberately chosen to post under. After all, the previous comment by the "Anonymous Coward" (or you) that MongoDB is astrosurfing may be completely valid, but posting that comment anonymously also calls into question the provenance of that claim as well. After all, you could also be that same author of HyperDex as well, just posting links to your own blog (which praises your own HyperDex project and criticizes MongoDB).

Re:MongoDB is broken by design.

[Anonymous Coward]

You may have read it, but you clearly didn't understand it. The complaint you highlighted is only one of many points he made.

Given that MongoDB was specifically designed for data where you don't care if a write works or not (and now the relational guys are going to start ranting about ACID, all while missing the point) it would appear that MongoDB is working as intended and the author of a competing product just has a bug up his ass.

And his point is that the way MongoDB is intended to work is stupid, because they're trading write reliability for speed, but not actually getting speed. Sounds like a dumb trade if you ask me.

MongoDB is web scale

[Anonymous Coward]

MongoDB is web scale

And... /thread.

Re:MongoDB is web scale

[Anonymous Coward]

This application could easily have been done in mysql and maybe memcached

Re:MongoDB is web scale

[hazah]

No, because it's not web-scale.

Are you done, yet?

[Anonymous Coward]

The comments on the last story shows what a joke this was considered before.

"No one cares. Stop click-baiting the buzzword Slashdot sub-sites. If we wanted to go to them we would do so voluntarily."

"Having actually RTFA, it just enforces how poorly most programmers understand relational databases and shouldn't be let near them. It's so consistently wrong it could be just straight trolling (which given it's posted to post-Taco Slashdot, is likely)."

"I think the author and his team failed the customer in this case by providing them with an inflexible system. Either they forced the client into accepting these horrible limitations so they could play with new (and expensive!) toys, or the client just flat-out doesn't need this database for anything (in which case it's a waste of money.) This kind of data absolutely needs to be kept in a relational database to be useful.

Which, along with his horrible Java vs. C# comparison, makes Jeff Cogswell officially the Slashdot contributor with the worst analytical skills."

Me too

[Anonymous Coward]

I wanted DynamoDB to work, but concluded that Mongo is a safer and more accessible place for my data.

Relational is the only way

[zmooc]

"in some strange way my brain had been conditioned to think of modeled data in a relational way"

The relational model is not much more or less than the mathematically sound way of dealing with sets and relations between their items in ways that enforce and maintain consistency. There is no alternative to that. It's not merely the status quo, as the article states. Even when designing a datamodel for storage in a NoSQL database, the rules of the relational model are best taken into account.

The only sound reason for deviating from the relational model and its rules is that your (reasonably priced) relational database server has shortcomings, typically related to dealing with large datasets in clusters, situations in which relational database solutions typically don't scale well and a compromise is needed.

Note that NoSQL has its place and I have encountered and worked on projects in which there was just no alternative, but I wouldn't trust my precious data to any developer that chooses NoSQL over a proper datamodel for arguments other than those mentioned above, because they're bound to be wrong.

I don't get how anybody educated in computer science fails to understand this.

All hail Edgar F. Codd!

Re:Relational is the only way

[21mhz]

Well said, sir. I started to exclude Slashdot from my regular browsing routine because of all the dumb shit going on here recently (like articles written by incompetents about NoSQL solutions they don't understand the purpose of), but comments like yours make me reconsider.

Re:Relational is the only way

[Sarten-X]

A conclusion I apparently forgot to type: There are reasons to consider NoSQL solutions, and even some circumstances in which to actually use them. They are a tool, just as RDBMSs are, and like all tools should be used only when and where appropriate.

Re:Relational is the only way

[martin-boundary]

The only sound reason for deviating from the relational model and its rules is that your (reasonably priced) relational database server has shortcomings, typically related to dealing with large datasets in clusters, situations in which relational database solutions typically don't scale well and a compromise is needed.

That's unfortunately incorrect. The Codd model is not as fundamental as you imply. It is a finite dimensional model, suitable for when your data is naturally representable as a finite number of attributes such as name, address, etc. If there are N attributes, then each record is representable as a point in an N dimensional cartesian product.

Perhaps the simplest example where that assumption fails is when representing a free text document as a bag of words, which is a standard representation for information retrieval applications (eg the google web index). In this case, the natural data representation is infinite dimensional, ie there can be abitrarily many attributes in a document. In such applications, even defining meaningful schemas as done in RDBMS's is impossible.

Google would not have amounted to anything had they tried to work with relational models.

Re:Relational is the only way

[Jonner]

Unfortunately, the vast majority of people talking about databases don't know the difference between the relational model and SQL. They can't understand that limitations of SQL and SQL databases are not necessarily limitations of the relational model. They don't realize that certain features of SQL databases such as ACID have absolutely nothing to do with the relational model. It's very often unclear whether "NoSQL" is a reaction against SQL, the relational model, or features of many SQL databases such as ACID. If designers and users are confused about what they're rejecting, how can they be expected to choose something better?

I can partly understand why so many don't understand the difference between SQL and the relational model because like them, I'm done almost nothing with the relational model without using SQL. Travis Brown seems to think that hierarchical data is incompatible with the relational model. I suspect that his confusion results from the fact that working with hierarchical data via SQL is often cumbersome, though entirely possible. Though having SQL is far better than no relational language, it's a terrible, ugly language that badly needs to be replaced with something better. Why do so many "NoSQL" proponents seem bent on discarding the advantages of the relational data model while trying to come up with a language or API better than SQL?

Re:Relational is the only way

[Anonymous Coward]

Perhaps the simplest example where that assumption fails is when representing a free text document as a bag of words, which is a standard representation for information retrieval applications (eg the google web index). In this case, the natural data representation is infinite dimensional, ie there can be abitrarily many attributes in a document. In such applications, even defining meaningful schemas as done in RDBMS's is impossible.

BTW, you can represent the bag of words model in a relational database in a table with the attributes 'document ID' and 'word'. This gets around the infinite dimension.

Re:Relational is the only way

[Anonymous Coward]

how do you index that? How do you scale that beyond a single server? How do you scale that up to 100's of terrabytes?

Re:Relational is the only way

[Anonymous Coward]

How are you going to end up with terabytes of words unless you have massive duplication?

Re:Relational is the only way

[Anonymous Coward]

These implementation details you list are a very good example of "shortcomings, typically related to dealing with large datasets in clusters, situations in which relational database solutions typically don't scale well and a compromise is needed." that zmook was referring to.
They do not fundamentally change the nature of information, and therefore do not invalidate the relational model in any way.
If I don't have enough money to buy a bigger database server, it does not invalidate arithmetic, and I do not start crying for a new theory of numbers.
But of course, we were all forced to learn arithmetic at school... whereas most of us did not actually have to read E.F Codd or Chris Date, we just only had buy a computer at Best Buy and we could start having cute opinions.

Re:Relational is the only way

[ultranova]

Perhaps the simplest example where that assumption fails is when representing a free text document as a bag of words, which is a standard representation for information retrieval applications (eg the google web index). In this case, the natural data representation is infinite dimensional, ie there can be abitrarily many attributes in a document. In such applications, even defining meaningful schemas as done in RDBMS's is impossible.

Document ID, word number, word. There's no reason why you'd need to represent a single document in a single row. In fact you'd probably not want to, because this structure allows for easier subexpression searching.

It might not be the most space efficient representation, but that's usually not the most important factor when using databases, especially when storing text files.

Re:Relational is the only way

[Anonymous Coward]

How does NoSQL (or any other system) do it behind the scenes?

Re:Relational is the only way

[Anonymous Coward]

how are you going to scale a word database? Have fun doing hundreds to thousands of joins a query. let me know how that scales. ROFL.

Re:Relational is the only way

[Anonymous Coward]

exactly. relational database do not scale beyond a couple terabytes unless you have many millions to buy something like Oracle Exadata. the fact remains, relational databases have their place for probably 90% of data problems. When you have to scale up beyond the 100 user internal business app, the cost of doing so becomes unmanageable unless you work for the government or wall street. I just LOL at all the Mongo haters as 99.9% of them are totally clueless RDBA drones.

Re:Relational is the only way

[Anonymous Coward]

and join hundreds of thousands of columns on every document retrieval? LOL. yeah, that would run real fast. call me next year when it returns if ever.

Re:Relational is the only way

[martin-boundary]

Document ID, word number, word. There's no reason why you'd need to represent a single document in a single row. In fact you'd probably not want to, because this structure allows for easier subexpression searching.

You can represent literally every finite object dataset as a set of triples (object-number,variable-within-object-number,value), and in fact all you need is a single number to encode the pair (object-number,variable-within-object-number), using a Cantor enumeration for example. This is a poor abstraction of the problem domain however.

In the case of the (doc-id,word-pos,word-value) table, what is a primary key? If you go through all 7 possibilities, I think you'll find that the only primary key is the triple (doc-id,word-pos,word-value) itself. Also, the only single valued function in this design is (doc-id,word-pos) - word-value. This suggests that relational algebra offers no simplification or benefit over pure brute force search for all queries.

Re:Relational is the only way

[Anonymous Coward]

Are people typing in hundreds to thousands of words in a google search box? I don't think so. Most of the times it's well under a dozen.

Re:Relational is the only way

[Anonymous Coward]

Perhaps the simplest example where that assumption fails is when representing a free text document as a bag of words, which is a standard representation for information retrieval applications (eg the google web index).

Another good example is this: I have several entity types each of which has a different set of attributes. I have a further entity type, members of which have a relationship with exactly one entity of one of the other types but I don't know in advance which type it will be. As an extension to the problem, I may want to be able to easily add new entity types and not restrict the choice to preexisting ones.

This is not an uncommon scenario in many fields; consider, for example, a role playing game. A character possesses some number of inventory items. These items could be of many different types: weapons, keys, money, armour, magical items, containers that may have other items inside them, and so on. Game designers may want to add new item types at any time, preferably without having to rebuild the entire database. NoSQL databases (particularly either object databases or graph-structured databases, but column stores can cope with it quite well too) are quite simply a better fit for this problem.

Re:Relational is the only way

[Anonymous Coward]

The only sound reason for deviating from the relational model and its rules is that your (reasonably priced) relational database server has shortcomings, typically related to dealing with large datasets in clusters, situations in which relational database solutions typically don't scale well and a compromise is needed.

Actually, I don't think this is a good reason to abandon relational databases at all. RDBMSs actually scale reasonably well, and we have well developed tools for handling very large SQL databases.

There are, however, several kinds of data structure which the relational model maps very poorly to, which necessitates the use of poorly designed and inefficient structures that are the closest it can manage where a more direct representation would work better. Some examples include:

* spacial data (some SQL databases have extensions to handle this, but those extensions take them outside of the relational model, thus losing the advantages you talk about)
* time sequences (again there are extensions, but again those extensions are not relational)
* references between entities of types that may vary (i.e. polymorphic object structures)
* graph structures (these can be defined very easily in a relational model, and that is how they are usually presented mathematically, but reasoning about them in relational algebra is very hard)

Re:Relational is the only way

[martin-boundary]

Linguists are particularly interested in both single words, pairs of words, triples and so on. The Google Ngram database fits on several dvds.

Better headline

[HalAtWork]

Mongo not just pawn in game of DB

Re:Better headline

[Anonymous Coward]

It's definitely not a pawn. I'd say it's more like a bishop. A bishop who molests your data behind closed doors.

Re:Better headline

[Sulphur]

Mongo not just pawn in game of DB

Mongo karate chop data into report.

Re:Better headline

[Anonymous Coward]

Mongo no loose words Mongo fast and smart.
Mongo future.

Why I'm going to head the word of my fathers and stick to SQL.

At least until the tools catch up the the hype.

If you can afford to pay SYSOP guys that are smart enough to be programmers to support your million node cluster go home. Use SQL.
Otherwise Mongo will hurt you.

Re:Better headline

[Anonymous Coward]

Mongo only *pwn* in game of DB

fixed that for ya.

Re:Better headline

[Jawnn]

Mongo no loose words Mongo fast and smart. Mongo future.

But Mongo sad, because Mongo not know how to spell the word "lose".

Re:Better headline

[hackingbear]

No. This headline is better:

Mongo Not a New Lemon In the World of DB

For all the Wrong Reasons

[Anonymous Coward]

"Sure, it looks simple enough, but what about the 50th and 100th time you have to remodel your hierarchical data into different, but still hierarchical data?"

The structure of data should reflect its semantic relationships, and these are necessarily pretty static (information wouldn't be much use if its meaning constantly changed.) Therefore, I find it hard to believe that the author's data semantics are changing rapidly enough to demand 50-100 remodellings. More plausible, I think, is that a great many of those models were poorly thought-out. If this is the case, then the author seems to be selecting a database to conform to a flawed approach to software development.

Re:For all the Wrong Reasons

[Anonymous Coward]

"The structure of data should reflect its semantic relationships"

Certainly, if the parent needs to remodel 50~100 times is because he hasn't a properly thought out data model.

But the base problem remains (which is probably why he finds so dificult to model his data): hierarchical datasets and relational model are not good friends.

Re:For all the Wrong Reasons

[Capt.Albatross]

But the base problem remains (which is probably why he finds so dificult to model his data): hierarchical datasets and relational model are not good friends.

Data modeling should be performed at a level of abstraction higher than the access methods of a DBMS. The relational model is at a higher level and handles hierarchical models very easily, while not being limited to them. If, on the other hand, you are trying to think about the semantic structure of your data in SQL terms, you are doing it wrong.

Re:For all the Wrong Reasons

[travispbrown]

For clarification, I did not mean the 50th - 100th time you remodel the same data, I meant the 50th - 100th time you have to remodel different data. In retrospect, I should have said the 50th to 100th time you have to write code to TRANSFORM data. I used the wrong word.

Re:For all the Wrong Reasons

[Unknown Lamer]

We'd all like to think that the data model is 100% clear at the beginning of a project and comes from the heavens in perfectly formed 3NF.

Reality bites. Needs change... the domain expands, human judgement is limited (there are multiple ways to model the same data, at least once you have tuples in your relational language... and we're not perfect), etc.

I mean, ... you really only need triples so why bother with supporting operations on tuples?

Re:For all the Wrong Reasons

[Anonymous Coward]

I think what you mean to say is that querying hierarchical data can be complex and slow. While there is some validity to this statement, the underlying representation of hierarchies in the relational model itself is as easy as defining any other non-hierarchical relationship - with a foreign key.

The solution to the hierarchical querying problem is not to dispense with the relational model - the relational model can "model" these "relationships" perfectly well. There are a number of ways of doing this, from standard normalisation ala Boyce-Codd or the Fact / Dimension table designs ala Kimball. Each have pros and cons, but the actual modelling of the hierarchy is straight forward.

That is to say, there is a difference between the modelling problem and the querying problem. "Fact" tables are an attempt to reduce the impact of the querying problem within the relational model - these tables are typically in 2NF.

More generally, there isn't a blanket solution for the querying problem as each situation is unique. Database experts and good developers with strong database backgrounds will have an array of options to solve these problems beyond indexing. My general approach is to start with the "pure" relational model - getting the actual relationships right in the first place - and then selectively denormalise those aspects of the model which profiling indicates are problematic in terms of performance. These could be additional fields here and there, or additional tables built specifically to service certain queries. In all cases, the source of truth is the "pure" relational model. The other pieces feed from this.

Truth is, if you get your model close enough to right, you can solve any problem with your data by extending and building upon that. If you get the model sufficiently wrong, you are hosed when you are asked to handle some unforeseen scenario. That's why the modelling problem is king while the querying problem is more of an implementation detail (an important one, to be sure, but nowhere near as important as having a good model).

And that's why all this concentration on schema-less databases and the evils of joins seems to me a bit like putting the cart before the horse. Solving the problem of query speed before defining what the data looks like is not only pointless, but will inevitably involve much more rework if the site in question becomes marginally successful. The chances for catastrophe are immense. Besides all that, having a good model and a high-performing view of that model are not exclusive.

If this guy is remodeling his "hierarchical data" 50 - 100 times, then lets be honest about it. It's not that he hasn't properly thought out his data model - it's that he has no clue what data modelling even is.

Re:For all the Wrong Reasons

[rycamor]

Yes, there are several ways of modelling hierarchies in SQL, each optimized for different usage patterns. The old foreign key adjacency list is only one of them (and my least favorite). Aside from Fact Tables, the most popular are Nested Set, Materialized Path, and Tropashko 'Nested Interval'. Materialized path usually gets poor treatment because values are conceived as strings to be parsed, rather than custom data type, but it can yield to some very fast tree traversal or searching if used right.

Ironically

[sexconker]

He's still using "ironically" incorrectly, despite the fact that i defined it for him in the comments on last story. He saw and replied to my comment, acknowledging his error.

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

"Ironically, it was a session at AWS Re:invent that initially scared me away from MongoDB."

I'm not sure which word he wants, but "ironically" isn't it.

Re:Ironically

[travispbrown]

The article was written before I received my vocabulary lesson. I vow to never use this word again on slashdot, as I clearly do not understand its meaning.

Re:Ironically

[Anonymous Coward]

We'd settle for you never posting another article to slashdot.

HTH

Re:Ironically

[Capt.Albatross]

The author's use looked reasonable to me, and in agreement with common usage, so I looked into it a bit more, and it is not so simple.

Wikipedia's entry on irony includes these statements:

The American Heritage Dictionary's secondary meaning for irony: "incongruity between what might be expected and what actually occurs". This sense, however, is not synonymous with "incongruous" but merely a definition of dramatic or situational irony.

Situational irony: This is a relatively modern use of the term [citation needed], and describes a discrepancy between the expected result and actual results in a certain situation.

The free online dictionary has this usage note:
The words ironic, irony, and ironically are sometimes used of events and circumstances that might better be described as simply "coincidental" or "improbable," in that they suggest no particular lessons about human vanity or folly. Thus 78 percent of the Usage Panel rejects the use of ironically in the sentence 'In 1969 Susie moved from Ithaca to California where she met her husband-to-be, who, ironically, also came from upstate New York.' Some Panelists noted that this particular usage might be acceptable if Susie had in fact moved to California in order to find a husband, in which case the story could be taken as exemplifying the folly of supposing that we can know what fate has in store for us. By contrast, 73 percent accepted the sentence 'Ironically, even as the government was fulminating against American policy, American jeans and videocassettes were the hottest items in the stalls of the market', where the incongruity can be seen as an example of human inconsistency.

The author describes a situation that involves situational irony as defined by Wikipedia: at an event promoting the use of MongoDB, he sees something that dissuades him for using it, at least temporarily. In fact, there is not just a discrepancy between expected and actual results, but an opposition. Furthermore, it does not fall foul of the 'mere coincidence' rule in the usage note. FWIW, I would not avoid using 'ironically' here.

Re:Ironically

[travispbrown]

You got it!

Re:Ironically

[Capt.Albatross]

I hope you are not permanently discouraged by the unproductive complaining that everyone who tries to do something useful on the web gets.

Re:Ironically

[sexconker]

The author's use looked reasonable to me, and in agreement with common usage, so I looked into it a bit more, and it is not so simple.

Wikipedia's entry on irony includes these statements:

The American Heritage Dictionary's secondary meaning for irony: "incongruity between what might be expected and what actually occurs". This sense, however, is not synonymous with "incongruous" but merely a definition of dramatic or situational irony.

Situational irony: This is a relatively modern use of the term [citation needed], and describes a discrepancy between the expected result and actual results in a certain situation.

The free online dictionary has this usage note:
The words ironic, irony, and ironically are sometimes used of events and circumstances that might better be described as simply "coincidental" or "improbable," in that they suggest no particular lessons about human vanity or folly. Thus 78 percent of the Usage Panel rejects the use of ironically in the sentence 'In 1969 Susie moved from Ithaca to California where she met her husband-to-be, who, ironically, also came from upstate New York.' Some Panelists noted that this particular usage might be acceptable if Susie had in fact moved to California in order to find a husband, in which case the story could be taken as exemplifying the folly of supposing that we can know what fate has in store for us. By contrast, 73 percent accepted the sentence 'Ironically, even as the government was fulminating against American policy, American jeans and videocassettes were the hottest items in the stalls of the market', where the incongruity can be seen as an example of human inconsistency.

The author describes a situation that involves situational irony as defined by Wikipedia: at an event promoting the use of MongoDB, he sees something that dissuades him for using it, at least temporarily. In fact, there is not just a discrepancy between expected and actual results, but an opposition. Furthermore, it does not fall foul of the 'mere coincidence' rule in the usage note. FWIW, I would not avoid using 'ironically' here.

And Wikipedia is wrong. Irony has to do with the literal intention of words being different from the meaning intended by the person using them. That's it. If the genuine intent is the same as the literal intent, then there is no irony. Even if an eventual outcome seems humorous, incongruous, or unexpected when compared to the literal intent, there is no irony.

Telling an actor to "break a leg" to wish them well is ironic.
An actor actually breaking their leg after being told that is not ironic.
If the speaker had planned to break the actor's leg, told the actor to "break a leg", and then broke the actor's leg, the speaker was being literal, not ironic.

"Situational irony" as a needless extension of "dramatic irony" is fucking horse shit. Dramatic irony is the extension of irony, and it exists to describe uses in literature/film/whatever in which characters are unaware of their irony, but the author/narrator/audience is. This extension allows the transfer of intent from the speaker to the author or the work as a whole.

The Weird Sisters said "none of woman born shall harm Macbeth".
The literal intention of that line is that no man born from a woman could harm Macbeth. Of course, we find out the actual meaning throws away the literal meaning of "born" in order to exclude Macduff.

If you believe they were tricking Macbeth, then they were being ironic.
If you believe they were crazy old hags and didn't know about the twist, then it's an instance of dramatic irony. The statement was true with no tricks intended from the characters's perspectives, but the author loaded it up for the ironic reveal of Macduff's Cesarean delivery.

You, Wikipedia, and a gaggle of shitwicks with no authority over the language can say otherwise, but you can't just change the meaning of the word irony anymore than the government can call a tomato (or a slice of pizza...) a vegetable.

Re:Ironically

[IwantToKeepAnon]

From the Dilbert Newsletter:

I've also learned recently that "ironic" means anything you want it to mean. Example:

Me: "I heard that Bob was killed by a meteor."

Induhvidual: "Wow. That's ironic."

Me: "Why is it ironic? Was he an astronomer?"

Induhvidual: "No, it's ironic because, you know, what are the odds?"

Me: "So anything unlikely is automatically ironic?"

Induhvidual: "No, it also needs to be bad."

Me: "This conversation is ironic."

Re:Ironically

[Capt.Albatross]

... irony ... irony ... fucking horse shit ... ironic ... gaggle of shitwicks ... irony

What a terrible situation you are in! You know something, but nobody gives a shit. It must be incredibly galling, and I am deeply sympathetic (would you call that irony, given that I am actually amused by your pedantic petulance?)

Re:Ironically

[Anonymous Coward]

I hope he is. Shilling over the latest technology fad and telling people they should use it even though it's the wrong tool for the job is not just unproductive like the complainers, it's outright counterproductive.

I'll take unproductive over counterproductive any day.

Dear slashdot editors, we are not hard of hearing

[Anonymous Coward]

we are ignoring you. - make them love you, or make them hate you, but don't ever bore them.

Amazon Pricing problems

[EmperorOfCanada]

I am sufficiently freaked out by Amazon pricing that I just can't use it. I have two simple fears. One is that I screw up with my code and do a bazillion transactions per second that result in either a ridiculous bill or exhausting my budget resulting in my service having to shut down. Secondly I am scared that some kind of DDOS would blow through my life savings. I much prefer the control of having my own dedicated servers with extremely fixed costs. It might not be the most efficient scheme but with the service I use they can throw extra servers on pretty quickly and I can set them up in a flash. So yes I am potentially hosed if Opera or Slashdot feature my work but I sleep like a baby knowing that amazon won't be billing me a house tomorrow. I even tried out their free service and while loving it was deathly afraid of getting billed.

If my sites really grew I would even contemplate going a step further and running my own physical servers. The joy of being able to reach out and jam USB sticks into them would be pretty good.

Re:Amazon Pricing problems

[MariusBoo]

Actually there is no reason to be freaked out by their pricing. Just buy the number of instances that you need (one for example) and don't set up any auto-scaling. This way if you get slashdoted your instance will just fail as a normal server would and you will incur no charges. Also no service...

I have worked with amazon aws and with dedicated server providers. Amazon has been much faster and reliable.

Furthermore, the way to protect your life savings from a potential business failure is not through inefficient procurement practices. Just incorporate, otherwise you will be open to all kind of risks (must of it unknown to you, and uninsured)

Re:Amazon Pricing problems

[stephanruby]

If my sites really grew I would even contemplate going a step further and running my own physical servers. The joy of being able to reach out and jam USB sticks into them would be pretty good.

Except that, it does suck to have to service your own servers 24 hours a day / 7 days a week (and your own backup generators, etc.)

Re:Amazon Pricing problems

[EmperorOfCanada]

But what about bandwidth charges? With my present service if I get slashdotted the server will be overwhelmed but I have no expanding charges with bandwidth. On Amazon more bandwidth = more money, way more bandwidth=way more money.

So maybe the instance falters but the bandwidth keeps being used.

And I agree setting up a server on Amazon was at first confusing but once I figured it out quite easy. With my present system the easiest and fastest way to set up a new server is to phone them. But as I say, my bill this month is X and next month will be X and if I add another server it will be X+1 server. With amazon I couldn't figure out if even the free trial was going to be free.

Re:Amazon Pricing problems

[Anonymous Coward]

Actually I assumed that once the machine fails they will no longer charge you for the requests that fail completely (the responses will definitely will be smaller but maybe not by enough).

The real solution would probably be to set a cloudwatch alarm trigger to shutdown the machine when it costs more than x$. It's probably possible.

I know you aren't planing on switching, I am just working through solutions out of curiosity. And because I never thought of this kind of problem for the servers I setup with them before :).

apples and oranges

[bennini]

We are heavy users of MySQL (Percona) and MongoDB at my work. Recently I have been researching DynamoDB because of a specific use-case. A side project I run uses Google App Engine with Datastore (aka bigtable) for persistence.

Comparing DynamoDB with MongoDB is like comparing apples and oranges. The only thing the two share in common really is the fact that neither supports SQL (and for that reason are called NoSQL databases). Their intended purpose is completely different which is why I found it strange that the author of the original Slashdot story would pit them against each other the way he did.

If DynamoDB is to be compared against another datastore, the most similar alternative would probably be Google App Engine's Datastore/big table.

Similarities between DynamoDB and GAE Datastore

• both use "schema-less" table structures for storing items (i.e. two items in a single table can have different columns)
• both support relatively simple primary keys (GAE only allows a single column PK, Dynamo allows a pseudo-two-column PK)
• both encourage only efficient queries (GAE forces it, Dynamo allows full table scans but they are highly discouraged)
• both support list properties (a column with multiple string values for example)
• both are hosted "in the cloud" and scale horizontally almost infinitely
• both are billed based on reads/writes + total stored data (Dynamo has an extra dimension to cost which is throughput)
• both have very limited support for referential integrity between items (GAE supports "embedded" entities and recently added basic relationships but nothing like many to many)
• GAE supports transactions across entities within the same group (i.e. on the same server) and recently added support for XA transactions (tx's across entities in different groups/on different servers). Dynamo does not have transactions but it supports some atomic operations on an individual item like compare and get.

Differences between DynamoDB and GAE Datastore
One major difference between GAE Datastore and DynamoDB is that GAE supports single and multi property indexes while Dynamo does not support indexes at all aside from a table's primary key. GAE datastore supports efficient queries that use the indexes (if you try to run a query that does not use an index it will fail) along with some basic predicates like equality, inequality, greater than and less than expressions, etc. In DynamoDB, if you want an index, you have to build it yourself in a supplementary table.

GAE Datastore Self-Merge Joins
GAE datastore also supports what they call "self-merge joins" which are super powerful. I don't know if any other schema-less datastore has this.

DynamoDB Purpose
The main reason one would use DynamoDB is when they need scalable throughput; in other words, when your needs for write and/or read speeds fluctuate drastically and when you know you will occasionally spike to extremely high throughput requirements. For times when you expect to have huge throughput for writing, you can pay to scale for that small period of time and then you can reduce your costs by throttling down to a more sane limit. You can run MapReduce jobs over DynamoDB tables using Amazon Elastic Map Reduce. And you can also copy a DynamoDB table into an Amazon Redshift "warehouse"; once the data is copied into Redshift you can run efficient SQL queries over it and Redshift can efficiently do that over petabytes worth of data.

MongoDB
MongoDB, on the other hand, is a "schema-less," document oriented database that is good for organizing clumps of information as a single "item" in the datastore. So for example, you can have a single book document which contains nested information about its authors, keywords, reader reviews, and statistics about word usage in the book....all in a single mondodb "record." This is essentially impossible in DynamoDB (unless you do what the previous article's author did by

Another senseless nerd fight.

[Anonymous Coward]

Argue all you want. My company *ships products* built on MongoDB. We get them done quickly, the DB performs super well, and these apps make us good money with the least effort.

But go on and have your little nerd fights. I'll just keep doing useful work and raking in the cash.

Cheers! :)

Re:Another senseless nerd fight.

[Anonymous Coward]

Business can succeed by pure chance alone. You've not proven a solid causal link between using MongoDB and your business being able to market your product.

The world is complex. You are probably wrong.

Re:Another senseless nerd fight.

[hazah]

"ships products"? how very specific. "more quickly"? I can write hello world in under 1 minute! "super well"? is that like superswell? "apps" what ones? "good money with least effort"? how quantitative.

At last!

[Anonymous Coward]

Someone who actually knows what they're talking about joins the conversation.

Billing Anxiety

[Anonymous Coward]

This billing anxiety has cause me to also completely rue out Amazon. All you need is an errant backup or DDOS, as you stated, and your I/O and bandwidth charges reach epic proportions.

Also, when you factor the cost against a powerful server, with average usage levels, over the course of three years, the price is more or less break even. Use that server for four or five years and physical servers become the cheaper option.