Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The growing irrelevance of MongoDB

itexto.com.br

Post reply on HN
Print view View original

101–110 of 114 posts

Re: The growing irrelevance of MongoDB

#101

Post by phpnode »

filearts wrote: post #97
phpnode wrote: post #96

Earlier quoted context omitted.

OrientDB is very cool software, I find it pretty hard to go back to traditional databases now that I've seen how powerful graphs are, but the cool thing about it is that it's still a document store at heart, so you get all the same advantages of mongo, but with the graph awesomeness on top. It's a fantastic tool, but there are a few quirks that can catch beginners out and the documentation is not stellar . It also re…

I actually JUST discovered oriento and was absolutely delighted to see a bluebird promise-based api. API looks fantastic. Thanks a ton for creating the lib. Do you have any advise for someone thinking of deploying on GCE? My use-case would be for an online code editor (Plunker, if you've heard of it) with users, projects, packages, collections (of projects), comments and project versions (stored as content-addressabl…

> Do you have any advise for someone thinking of deploying on GCE?

No, sorry, I've never used that. However, generally - like all dbs, Orient is happiest when it has access to a lot of RAM. Also the Write Ahead Log can take up a significant amount of disk space, those are two things to be immediately aware of.

> I'm also interested in understanding if there is any built-in compression mechanism because I will be storing a large volume of very similar text files. Any hints?

Sadly it doesn't yet do leveldb style document compression, and I've seen no hints that it's on the horizon, but the OrientDB guys are pretty responsive and would probably be open to the suggestion.

> Have you used the lucene indexes much? If so, can you do any of the crazy faceting delivered by ElasticSearch?

I'm just starting to use the lucene indexes now so I can't give much feedback on those yet. It should be possible to do faceting using SQL to a limited degree, but I don't think there's native support for it yet. I think that will get improved in the next few versions because people are crying out for it.

Re: The growing irrelevance of MongoDB

#102

Post by dang »

kicolobo wrote: post #54

Actually, 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

We've changed the URL from http://wwwdesigned.com/growing-irrelevance-mongodb/. Did that site publish your article without permission?

Re: The growing irrelevance of MongoDB

#103

Post by filearts »

phpnode wrote: post #101
filearts wrote: post #97

Earlier quoted context omitted.

I actually JUST discovered oriento and was absolutely delighted to see a bluebird promise-based api. API looks fantastic. Thanks a ton for creating the lib. Do you have any advise for someone thinking of deploying on GCE? My use-case would be for an online code editor (Plunker, if you've heard of it) with users, projects, packages, collections (of projects), comments and project versions (stored as content-addressabl…

> Do you have any advise for someone thinking of deploying on GCE? No, sorry, I've never used that. However, generally - like all dbs, Orient is happiest when it has access to a lot of RAM. Also the Write Ahead Log can take up a significant amount of disk space, those are two things to be immediately aware of. > I'm also interested in understanding if there is any built-in compression mechanism because I will be stor…

Thanks a lot for your contributions to the node module and your answers.

Re: The growing irrelevance of MongoDB

#104

Post by takeda »

onion2k wrote: post #75
ris wrote: post #42

Earlier quoted context omitted.

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 thing is that in order to use that /label/ you need to write logic to handle it in your code, ultimately you end up implementing schema, the only difference is that you enforce it in your application. This label becomes not much different than a column in database that is nullable.

Now things become more hairy when you realize that perhaps you want to keep more information about the actor so for example you want to change details.actor to details.actor.name. You will have two choices, either run through your database and modify all documents (which is something similar to RDBMS is doing) or write code to handle both cases. The second one seems easier, but as you'll have more changes it'll come back and bite you hard.

Later in the future you might realize that by repeating details about actor for every single movie you simply not only wasting a lot of resources (your database is bigger and slower) but also this affects integrity (in one movie perhaps you include actor's middle name, or maybe you have a typo).

At that point you'll start creating a collection that holds actors and then only store key of it in "details.actors". You will soon realize that you're basically reimplementing a relational database on top of Mongo, except not only it is way slower, your application is becoming more complex.

There are uses for NoSQL, but whenever you have to ask yourself which model you should go with pretty much always the answer will be: relational.

Re: The growing irrelevance of MongoDB

#105

Post by proveanegative »

phpnode wrote: post #24
collyw wrote: post #9

I 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…

> I have yet to see a real use case for Mongo unless you are building a Facebook clone People seem to keep making the mistake of building a social network in mongo. It's entirely unsuitable for that. Source: I've helped 3 companies move their social networks from MongoDB to OrientDB when they figured out that MongoDB prevents them from shipping features that users expect, e.g. friend-of-a-friend style queries

Did they choose OrientDB instead of Neo4j for the license or for technical reasons?

Re: The growing irrelevance of MongoDB

#106

Post by phpnode »

proveanegative wrote: post #105
phpnode wrote: post #24

Earlier quoted context omitted.

> I have yet to see a real use case for Mongo unless you are building a Facebook clone People seem to keep making the mistake of building a social network in mongo. It's entirely unsuitable for that. Source: I've helped 3 companies move their social networks from MongoDB to OrientDB when they figured out that MongoDB prevents them from shipping features that users expect, e.g. friend-of-a-friend style queries

Did they choose OrientDB instead of Neo4j for the license or for technical reasons?

actually both in many cases, Neo4j does have quite a hostile license, but its biggest downside is that it is graph only, whereas OrientDB (and ArangoDB which is also worth looking at) are "multi-model" - you can use them as pure document (or even key / value) stores, and the graph is just another way of viewing / representing that data. This is really powerful and means that you don't have the problem of duplicating data between different database systems or needing to do cross-data-store joins in your application.

Re: The growing irrelevance of MongoDB

#107

Post by avasdvasdv »

collyw wrote: post #9

I 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…

> I have seen many people try and shoehorn various problems into MongoDB

MongoDB is easy and was used by web "developers" too lazy to learn SQL and RDBMs.

MongoDB is fine if you don't really care about the data. If you don't need ACID compliance and can afford to lose transactions.

Re: The growing irrelevance of MongoDB

#108

Post by avasdvasdv »

annnnd wrote: post #50
ttty wrote: post #33

Earlier quoted context omitted.

>And I would appreciate a way to define schema Use mongoose! >On the other hand, I do miss JOINs when I need them (though we solved that on app level). How you do that? (maybe is different than me) What about transactions?

>Use mongoose! We don't use node.js. Also, we have app-level schema, but enforcing should (IMHO) be done on DB level so as to avoid any chance of invalid data. Joins: easy, we specify which fields are connected (on app level), then fetching goes to connected collections and fetches data from there too. Not ideal, but it works. We made a similar solution for foreign keys. Transactions: no need for any further guarante…

> If this is not possible, we have app-level locking to avoid conflicts.

app-level locking is a recipe for disaster if data matters and more than 1 process/user/client/etc can access your data. if the data doesn't matter then I guess you can do whatever you want.

web "developers" have a bad reputation for a reason. so many amateurs amongst web developers...

Re: The growing irrelevance of MongoDB

#109

Post by annnnd »

avasdvasdv wrote: post #108
annnnd wrote: post #50

Earlier quoted context omitted.

>Use mongoose! We don't use node.js. Also, we have app-level schema, but enforcing should (IMHO) be done on DB level so as to avoid any chance of invalid data. Joins: easy, we specify which fields are connected (on app level), then fetching goes to connected collections and fetches data from there too. Not ideal, but it works. We made a similar solution for foreign keys. Transactions: no need for any further guarante…

> If this is not possible, we have app-level locking to avoid conflicts. app-level locking is a recipe for disaster if data matters and more than 1 process/user/client/etc can access your data. if the data doesn't matter then I guess you can do whatever you want. web "developers" have a bad reputation for a reason. so many amateurs amongst web developers...

I will assume the last part is just a generic statement and is not directed towards me. You are a Java dev I presume?

As for app-level locking, I am talking about sacrificing performance, not safety. We just make sure that some piece of code runs exactly once. Since the need for this is very rare and the places are not performance critical, we can live with that. So no, we have no need for additional transactional guarantees on DB level.

Post reply on HN