I never understood the hype around MongoDB. Maybe it is the fact that I started programming when SQL DBs were the prevalent/mainstream option, and got too much used to it... Anyways, Im glad people are recognizing the hype and realizing that RDBMS has enough to offer.
The growing irrelevance of MongoDB
71–80 of 114 posts
Re: The growing irrelevance of MongoDB
#72MongoDB 2.8 (in RC4 right now, due out "in early January" last I heard) has the WiredTiger storage engine, and as well as high performance and compression also gets document level locking and multi document transactions. The roadmap says this'll become the default storage engine in 3.0 (3rd quarter 2015). I think the blog author's claim that for basically those omissions "MongoDB can still beat TokuMX on a future rel…
Could you provide a source for "multi document transactions" support in 2.8? According to this comment they are supported by WiredTiger but won't be in the MongoDB API anytime soon: http://blog.mongodb.org/post/102461818738/announcing-mongodb...
Re: The growing irrelevance of MongoDB
#73Earlier quoted context omitted.
"I don't want to create a schema..." You are always going to end up creating a schema, whether it's explicit in your tables or implicit within your code. Otherwise you end up with completely heterogeneous data which is impossible to query in any useful way. This is a red herring.
Not really. Maybe some products have an attribute that others don't. Maybe you want to query by that attribute. The query won't turn up products without that attribute. Maybe that's ok. Like if you wanted to find all shoes with black laces you can just query for that. Tractors don't even have laces and so they don't come up in the results. In a sql db, every single thing needs to fit into a flat schema with nesting d…
I would probably solve this problem using Relational DB by having an ItemHeader table with all the common attributes. Then will make an ItemAttributes table where I'd use the foreign key of the first table and just have Key/value pairs for all the unique attributes you want to give to the item. Any sort of query on any of the attributes can be one via a simple join.
Though i suppose it gets trickier if attributes may have sub attributes etc....
Re: The growing irrelevance of MongoDB
#74Earlier quoted context omitted.
I've used it and been happy. If you want something that's simple to use, know your schema partly but not entirely, and you don't mind losing a few writes, then mongo fits. Relational databases place such emphasis on reliability. Mongo is generally reliable but only two or three nines, and it's simple. For example, if you're collecting sub-cent line items for invoices, you might prefer to collect 99.x% of the line ite…
This is satire, right? Right?…
Not at all. Let me run an example with simple and made-up numbers.
Consider two storage solutions used to gather line items to invoices. The line items are ten cents on average.
One system is properly ACID, and running it costs one cent per line item on the invoice. The other loses 1% of writes randomly, but its hardware/backup/ops requirements are lower, so it costs just 0.1c/item.
The ACID way gives you complete invoices, but you spend 10% of the invoiced amount on the invoices. The lossy way makes your invoices 1% smaller, randomly, but the loss+cost adds up to about 2% instead of 10%.
It's like returns on physical goods, really. A random percentage of customers will return goods, you can't control that but you can estimate and monitor it, and optimize if the numbers aren't good enough.
Re: The growing irrelevance of MongoDB
#75Earlier quoted context omitted.
query = db.products.find({'type': 'Film', 'details.actor': 'Keanu Reeves'}) @see: http://docs.mongodb.org/ecosystem/use-cases/product-catalog/ I personally miss Joins in MongoDB - but other vendors support Joins.
There - you're consistently using a field named "type" across your objects - you're using a schema.
Not quite. The 'type' in the example is a label for what it contains - it's wholly semantic - as opposed to a field that would exert some sort of constraint such as describing the data type, collation, restraints, etc. Schemaless databases don't completely abandon all forms of organisation because that'd be unusable. They just make the organisation looser. For example, if the user wanted to they could add a record to the products in that example that doesn't have a 'type' (although in the case of that example that probably wouldn't be useful).
Re: The growing irrelevance of MongoDB
#76Earlier quoted context omitted.
I've used it and been happy. If you want something that's simple to use, know your schema partly but not entirely, and you don't mind losing a few writes, then mongo fits. Relational databases place such emphasis on reliability. Mongo is generally reliable but only two or three nines, and it's simple. For example, if you're collecting sub-cent line items for invoices, you might prefer to collect 99.x% of the line ite…
What? When would it ever be OK to lose parts of an invoice. Mongo apologists baffle me sometimes. To anyone considering MongoDB, don't be fooled, you probably want to stick with an RDBMS.
When the parts are cheap compared to the cost of storing them in a real database.
I even know someone who stores invoice items in memcached. Whenever memchached evicts something that hasn't made it onwards to real storage, they lose the ability to invoice the right customer for an ad impression.
Re: The growing irrelevance of MongoDB
#77Earlier quoted context omitted.
This is satire, right? Right?…
Not at all. Let me run an example with simple and made-up numbers. Consider two storage solutions used to gather line items to invoices. The line items are ten cents on average. One system is properly ACID, and running it costs one cent per line item on the invoice. The other loses 1% of writes randomly, but its hardware/backup/ops requirements are lower, so it costs just 0.1c/item. The ACID way gives you complete in…
So, if I want to incorrectly invoice my customers then I should use MongoDB?
I don't understand how you can say any of this seriously.
Re: The growing irrelevance of MongoDB
#78Actually, they posted thw wrong link. That article is not written by wwwdesigned, but by me. Here is the original text: http://www.itexto.com.br/devkico/en/?p=60
I actually came there via two other aggregators (Twitter and Prismatic) and thought that I had found the source. Will be more careful next time - sorry about that. In any case it was an interesting read.
Thanks!
Re: The growing irrelevance of MongoDB
#79I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
We are building a music streaming website. Think of it as a Spotify for Pakistan and Mongo has been wonderful for the kind of Data Structure we have. Its perfect for a catalogue like structure where objects can very easily nest inside each other. Each Artist has multiple albums, and multiple artists have multiple songs. All of this nestles very neatly inside eachother, and when i want a song, i almost always need its album and artist data, so i can very easily get that. Mongo is blazing fast on such kind of nested data structures. The only slight problems is where you have playlists and need to reference songs for a certain Artist. That could be countered by Data Duplication, since the song artist data etc once entered will very rarely change. So for us it makes perfect sense. You really need to understand what your data model is, and what you want from it, and then Mongo will be your friend, other than that it will cause you a world of pain.
Re: The growing irrelevance of MongoDB
#80I have seen many people try and shoehorn various problems into MongoDB, when in most cases a relational database would have been better suited. I have yet to see a real use case for Mongo unless you are building a Facebook clone. Can someone suggest when it is actually useful over a properly tuned relational database? I guess I kind of reached the irrelevance stage just thinking about the sort of problems it would be…
We are building a music streaming website. Think of it as a Spotify for Pakistan and Mongo has been wonderful for the kind of Data Structure we have. Its perfect for a catalogue like structure where objects can very easily nest inside each other. Each Artist has multiple albums, and multiple artists have multiple songs. All of this nestles very neatly inside eachother, and when i want a song, i almost always need its…
How does that hierarchical model work when songs or albums have more than one artist?
Why does a traditional relational db fail for such a well-defined data model? I mean, there's nothing about 'given an song (id), retrieve artist and album' that would make mongo inherently better.