Why MongoDB is a bad choice for storing our scraped data

Re:Why MongoDB is a bad choice for storing our scraped data by rdtsc on Tuesday May 14, 2013 @11:55PM (#5710084)

Marketing.

They are also on my blacklist, forever.

They used to ship with unacknowledged writes as the default option. Think about it for a little, a database that just throws your _data_ over the fence and prays for the best, proceeding without an write acknowledgement.

There was not flashing warning on their front page about, no bold disclaimers, but there were sure plenty of "Oh look super fast benchmarks beating SQL and other NoSQL database, albeit created by fanboys".

That decision told me the story of who they are and what kind of principles they use to build their product. It wasn't a mistake it was a deliberate shady tactic employed.

(Yes, I know I have written about it at least 3 times before and will mention it every time I see MongoDB mentioned )

[ Parent | on HN ]

Re:Why MongoDB is a bad choice for storing our scraped data by est on Wednesday May 15, 2013 @12:24AM (#5710162)

So can you tell us what's your easieast way to implement something like:

    books: [
        {id: 1, tags: ['a', 'b'], author: ['c', 'd'], count_read: 123, count_bought: 456},
    ]

where count_read and count_bought is atomic increment, tags are arbitrary string array and could be indexed for searching.

Yeah I knew Postgre could do that. But MongoDB is the most simple and direct way on the market. Stuff like tags makes MySQL m2m joins very inefficient.

[ Parent | on HN ]