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

12 Months with MongoDB

blog.wordnik.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: 12 Months with MongoDB

#31

Post by michaelchisari »

luigi wrote: post #20
michaelchisari wrote: post #12

Alright, so, I fully understand the scalability reasons for using MongoDB, but I need someone to clearly explain to me when NoSQL would be a better solution than SQL from a development standpoint . Because like someone pointed out, Postgres without fsync can be just as fast. What is the advantage of giving up the ability to use SQL and the associated relational algebra that has long been established in that query lan…

Funny, I've been using MongoDB for well over a year, and I use it not for scalability/durability, but because it's so nice to develop on top of. Simply put: it gives you a much more natural way to persist the objects you work with in the OO language of your choice. It's a joy to use. Until I used it, I didn't realize how unnatural it was to map OO programming to an RDBMS. We work with objects in our languages. We don…

It's a joy to use. We work with objects in our languages. We don't work with rows of data.

And I totally get that, I really do, but to me, that's more of an issue of personal preference, and less of an issue of a clear advantage. There's nothing wrong with personal preferences. For instance, I like schemas that aren't easily changed, and a clear separation of logic and data, and I prefer to think of data as rows, not objects. But that's my personal preference. I'm more interested in how the functional approach to a use case would make NoSQL the clearly superior technology in that scenario.

Re: 12 Months with MongoDB

#32

Post by mhd »

luigi wrote: post #20
michaelchisari wrote: post #12

Alright, so, I fully understand the scalability reasons for using MongoDB, but I need someone to clearly explain to me when NoSQL would be a better solution than SQL from a development standpoint . Because like someone pointed out, Postgres without fsync can be just as fast. What is the advantage of giving up the ability to use SQL and the associated relational algebra that has long been established in that query lan…

Funny, I've been using MongoDB for well over a year, and I use it not for scalability/durability, but because it's so nice to develop on top of. Simply put: it gives you a much more natural way to persist the objects you work with in the OO language of your choice. It's a joy to use. Until I used it, I didn't realize how unnatural it was to map OO programming to an RDBMS. We work with objects in our languages. We don…

Most of the time, I get the reverse problem: It's pretty odd to map data to objects. For a lot of applications, a relational view is pretty natural. That's why I never got the "NoSQL instead of RDBMS" rhetoric. A document-oriented database is just another tool in your kit. Choose the right one, depending on the usual format of the data. If one is always reaching for one tool, it's much more likely that there's not enough expertise with other tools than that this one tool is so great and universally applicable.

Silver bullets…

Re: 12 Months with MongoDB

#33

Post by Charuru »

weixiyen wrote: post #3

Where are the "MongoDB is Web Scale" jokes? crickets. If you are not using MongoDB, you are missing out badly and are probably developing at a much slower rate than someone who is.

Stop trying to convert people. I'm sure that all or nearly all of the people that can benefit from Mongo has already heard of it and has heard of its benefits.

Please have a little faith in other people, that if for any reason they're not using nosql it's a good one!

Re: 12 Months with MongoDB

#34

Post by fehguy »

saurik wrote: post #26
emmett wrote: post #16

Earlier quoted context omitted.

For example, it's extremely awkward in SQL to find all the elements in a tree. There are at least 4 hacks I know of to fix this, none totally satisfactory. In a NOSQL context you can just store the entire tree - your implementation becomes straightforward and simple. In general though I agree with you. I can whip out SQL queries in seconds that would take me minutes to write against Mongo, even though they're all tec…

You usually want to query and update subtrees, often concurrently. Storing the entire tree is a horrible way to think about this problem. While some NoSQL databases try to help with this, they are not in any better position to solve the problem than a simple library over an SQL database.

Kinda depends on the use case. Let's say you have a caching layer and update a subtree in your RDBMS. Then you need to go find all values referencing that object and invalidate them. That's potentially a lot of complexity. Of course you could cache only parent objects and fetch the subtree on demand (cache or db). Hello slow.

So I prefer to not use words like "usually" as it truly depends on your application and use case.

Re: 12 Months with MongoDB

#35

Post by thibaut_barrere »

saurik wrote: post #28
thibaut_barrere wrote: post #14

Earlier quoted context omitted.

Hi Michael, from a development standpoint only, I like the fact that I don't have to write database migrations (as defined in Rails). It means I can iterate more quickly during the development. As well for data aggregation kind of jobs (such as http://www.toutpourmonipad.com/ where I munge different-formatted data streams), it's really convenient to be able to mix datas that are partly equal, partly different, when i…

This is because you are simply never updating your schema: if you actually want to rename a field, change a datatype, or reorganize your content, you are still going to need to run a migration, and now it won't even be possible to transanction lock the upgrade (better database servers, like PostgreSQL, can do multiple whole-daabase schema modifications within a transaction while still allowing non-conflicting access)…

The OP question was "during development". I obviously change the schema in production too: sometimes keeping null-values will work, sometimes a migration will be needed.

My point is that I only do the "production" migration when needed and once per release that requires it, while I can tweak the schema at ease while developing.

If you have a large-enough volume of data, you will meet the situation where just adding a single column takes ages, too.

Re: 12 Months with MongoDB

#36

Post by binspace »

michaelchisari wrote: post #12

Alright, so, I fully understand the scalability reasons for using MongoDB, but I need someone to clearly explain to me when NoSQL would be a better solution than SQL from a development standpoint . Because like someone pointed out, Postgres without fsync can be just as fast. What is the advantage of giving up the ability to use SQL and the associated relational algebra that has long been established in that query lan…

Also, consider the fact that Mongo is a document database, where each document has it's own schema. Postgres (and most other relational databases), has a single schema for the table.

There are tradeoffs with each approach. I've found that that migrating Mongo documents tends to require more software for easy migrations, but also tends to be more flexible.

For example, you can lazily cache data from services and since the schema is flexible, a single collection can seamlessly hold different types of records.

Replication is also more natural with Mongo.

Of course, reporting and getting aggregate data is easier with Postgres.

Re: 12 Months with MongoDB

#37

Post by Devilboy »

emmett wrote: post #16
michaelchisari wrote: post #12

Alright, so, I fully understand the scalability reasons for using MongoDB, but I need someone to clearly explain to me when NoSQL would be a better solution than SQL from a development standpoint . Because like someone pointed out, Postgres without fsync can be just as fast. What is the advantage of giving up the ability to use SQL and the associated relational algebra that has long been established in that query lan…

For example, it's extremely awkward in SQL to find all the elements in a tree. There are at least 4 hacks I know of to fix this, none totally satisfactory. In a NOSQL context you can just store the entire tree - your implementation becomes straightforward and simple. In general though I agree with you. I can whip out SQL queries in seconds that would take me minutes to write against Mongo, even though they're all tec…

You just store the entire tree? Then how do you get a subtree? I don't think you're solving anything by just storing the whole tree as one thing. I mean you can do that in SQL too if you want.

Re: 12 Months with MongoDB

#38

Post by jasonjei »

ergo98 wrote: post #27
mathias_10gen wrote: post #13

Earlier quoted context omitted.

While I don't support a blanket statements along the line of "every app should be using MongoDB," it is equally invalid to say that "anything that deals with money" has no use for MongoDB. If you look at http://www.mongodb.org/display/DOCS/Production+Deployments you will see a few financial and ecommerce sites. I can tell you that there are even more financial firms not on that list in various stages of production. E…

>you will see a few financial and ecommerce sites Could you provide some examples? Scanning the list I see a couple that have a very periphery relation to financials, but the actual applications have very little financial applicability (and the implementations are trivial). Though the person you responded to didn't actually say that `"anything that deals with money" has no use for MongoDB"', so you're setting up a st…

Thanks, ergo98. I definitely think MongoDB can be used in money applications.

But there's almost always some ACID requirement when you're dealing with accounting, e.g, crediting payment or billing fees.

I would use something that could handle transactional ACID processing in combination with MongoDB depending on the application.

Re: 12 Months with MongoDB

#39

Post by Devilboy »

fehguy wrote: post #19
megaman821 wrote: post #7

It is kind of odd that speed is the main motivation to switch from MySQL. Horizontal scaling is the usually given reason. From what I have seen Mongo achieves most of its speed by not using fsync by default. There were some slides floating around a while ago that showed Postgres at about the same speed by turning off fsync.

You could run mysql with the memory storage engine and with our schema--which would require multiple outer joins OR subqueries--mongodb will still be much faster. So I think it's much more than an fsync issue.

If the multiple outer joins or subqueries are too slow you can always denormalise a bit, you don't have to give up on your SQL database if you don't want to.

Re: 12 Months with MongoDB

#40

Post by j_baker »

danudey wrote: post #24
megaman821 wrote: post #7

It is kind of odd that speed is the main motivation to switch from MySQL. Horizontal scaling is the usually given reason. From what I have seen Mongo achieves most of its speed by not using fsync by default. There were some slides floating around a while ago that showed Postgres at about the same speed by turning off fsync.

I remember reading that when the developer of Sphinx was benchmarking MySQL's fulltext searches at Craigslist, most of the time spent performing a query was spent in locks and mutexes. The actual query time was very fast, but the overhead was what killed performance. From what I understand, Postgres doesn't (necessarily) have those kinds of locking issues, but MongoDB does let you fetch documents (especially hierarch…

Surely those locking issues go away if you use READ COMMITTED mode though, right?
Post reply on HN