Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Software Cloud Databases Technology

Why My Team Went With DynamoDB Over MongoDB 106

Nerval's Lobster writes "Software developer Jeff Cogswell, who matched up Java and C# and peeked under the hood of Facebook's Graph Search, is back with a new tale: why his team decided to go with Amazon's DynamoDB over MongoDB when it came to building a highly customized content system, even though his team specialized in MongoDB. While DynamoDB did offer certain advantages, it also came with some significant headaches, including issues with embedded data structures and Amazon's sometimes-confusing billing structure. He offers a walkthrough of his team's tips and tricks, with some helpful advice on avoiding pitfalls for anyone interested in considering DynamoDB. 'Although I'm not thrilled about the additional work we had to do (at times it felt like going back two decades in technology by writing indexes ourselves),' he writes, 'we did end up with some nice reusable code to help us with the serialization and indexes and such, which will make future projects easier.'"
This discussion has been archived. No new comments can be posted.

Why My Team Went With DynamoDB Over MongoDB

Comments Filter:
  • No one cares (Score:5, Insightful)

    by Anonymous Coward on Thursday February 21, 2013 @03:11PM (#42970597)

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

  • by Anonymous Coward on Thursday February 21, 2013 @03:32PM (#42970893)

    "Our client is paying less than $100 per month for the data. Yes, there are MongoDB hosting options for less than this; but as I mentioned earlier, those tend to be shared options where your data is hosted alongside other data."

    I think someone failed to explain how "the cloud" actually works.

  • It's so ... wrong (Score:5, Insightful)

    by Anonymous Coward on Thursday February 21, 2013 @03:43PM (#42971023)

    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).

    "However, the articles also contained data less suited to a traditional database. For example, each article could have multiple authors, so there were actually more authors than there were articles."

    This is completely wrong, that's a text book case of something perfectly suited to traditional (relational) database.

  • by ranton ( 36917 ) on Thursday February 21, 2013 @04:27PM (#42971603)

    Don't try to actually make sense of the decisions made in the article. I am glad that he summed up all of the reasons why he didn't go with a relational database early in the article, so I didn't have to bother reading the rest. I am an advocate of NoSQL, but this whole article is describing a project that is almost perfect for a relational database.

    But considering this author's previous analysis of Java vs C#, I am not surprised that this article was hardly worth the time to read.

  • by ranton ( 36917 ) on Thursday February 21, 2013 @04:37PM (#42971695)

    Oh come on now. Play fair. If you start throwing around advanced database features like materialized views then you will immediately invalidate 90% of the use cases commonly used for choosing NoSQL over relational databases. That is just mean.

  • by Torvac ( 691504 ) on Thursday February 21, 2013 @04:45PM (#42971799)
    "with big data comes big responsibility". i mean a few very static 100k items require a NoSQL DB solution and cloud storage ? and a full team to do this ?
  • by Tom ( 822 ) on Thursday February 21, 2013 @04:54PM (#42971915) Homepage Journal

    Mod parent up.

    After a few years in other fields, I'm doing some serious coding again. Postgres and Doctrine. I can do in a few lines of code and SQL what would take a small program or module to do without the power of SQL and an ORM.

    Anyone who reinvents that wheel because he thinks he can do the 2% he recoded better is a moron.

  • by CHK6 ( 583097 ) on Thursday February 21, 2013 @05:49PM (#42972661)

    Their budget was limited.

    The same sentiment is echoed multiple times in the article. So this really isn't about how a development team choose DynamoDB over MongoDB. But rather the financial limitations of the client mandated the development team to use DynamoDB. In fact the article is more in favor for using MongoDB over DynamoDB, but the client's requirements forced their hands into using an alternative that was not as favorable for development.

  • by MightyMartian ( 840721 ) on Thursday February 21, 2013 @07:04PM (#42973607) Journal

    I jest slightly. Certainly there are applications where SQL and relational systems in general are overkill, or where they do not solve certain kinds of problems well. But I'll be frank, they're pretty rare. I will use binary search/sort mechanisms for simple hashes and other similar two column key-value problems, mainly because there's absolutely no need to truck along gazillions of bytes worth of RDBMS where quicksort and a binary search is all that is needed. But if you get beyond that, you're almost inevitably going to start wishing you had JOIN? And then you end up having to implement such functionality.

    Every tool for the job, to be sure, but I just happen to think there are far fewer problems that nosql style systems solve than some like to think.

  • by PRMan ( 959735 ) on Thursday February 21, 2013 @07:53PM (#42974023)
    Yeah. Going without ORM you typically get a minimum of 50% better.

The absence of labels [in ECL] is probably a good thing. -- T. Cheatham