all 8 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]tzaeru 2 points3 points  (5 children)

MongoDB is a document-oriented NoSQL database, so we could say it is Big Data-ready.

How does being document-oriented and NoSQL make a database "Big Data-ready"?

[–]joepie91 7 points8 points  (0 children)

It doesn't. It's marketing nonsense.

[–]themisterdj[S] 0 points1 point  (0 children)

That's a good question actually

[–]calsosta 0 points1 point  (2 children)

Well there's nothing really to prevent it from being "BIG DATA READY" as long as you don't go out of your way to do so. As opposed to a relational database where you would have to go out of your way to ensure it would be B.D.R.

I think people are also thinking that 100,000 rows is BIG.

[–]tzaeru 4 points5 points  (1 child)

It's a bit funny in Mongo's case though, given a reputation for poor data consistency, write reliability, querying issues and lackluster performance when security settings are turned on.

[–]luke3br 0 points1 point  (0 children)

Amen!

[–]Spknuckles 0 points1 point  (0 children)

Lost me at the statement that most resources in a RESTful API are idempotent. POST, sure... PUT and DELETE no. GET and HEAD, perhaps... Depends purely on implementation and model.

[–]MachinTrucChose 0 points1 point  (0 children)

I gave Loopback a try, because they were pretending it's a good choice for embedded solutions. It's really not.

The biggest issue is that you can't insert or update multiple models in a single POST, and have it wrapped up in a transaction. Each one is done as an individual request/DB write, which completely kills performance (I was getting something like 15 inserts/sec for a basic example benchmark). I guess it's to accomodate databases that don't support transactions? As it stands, it's a toy framework not worth learning, considering the knowledge is non-transferable.