The clustrix guy criticized mongodb that it locks the whole database quite often. Can anyone confirm or deny that?
MongoDB 1.8 (stable) released
51–60 of 69 posts
Re: MongoDB 1.8 (stable) released
#52Could someone with Mongo experience help me gut-check this? I want my data store to be durable and unsurprising -- barring a hardware failure or such, if I submit data it should either tell me that it failed to commit or it should be stored durably and without surprises (e.g., it should not truncate a long string to fit). I've read some of the Mongo docco, and it's pretty exciting, but the lack of ACID -- primarily t…
I am aware that I may be opening the flame portal, but what you want is called CouchDB. No more and no less.
Re: MongoDB 1.8 (stable) released
#53MongoDB is not something I have a good handle on yet. What's its sweet spot? Where should I consider using it instead of Postgres?
It's schema-less, and as the data format is a binary form of JSON, you can store arbitrary, even nested data structures directly. Indexes can be put on fields deep within the structure.
This saves a lot of time you'd normally spent defining schemas, and is very flexible. It didn't completely replace SQL for me, but it's a good fit for the heterogeneous free-form data generally encountered on the web.
Re: MongoDB 1.8 (stable) released
#54Earlier quoted context omitted.
If you are working with location data, Mongo has built in geospatial indexing built in since 1.4 (earlier in the unstable builds) - http://www.mongodb.org/display/DOCS/Geospatial+Indexing which has been a big draw for a number of people I know using it (it looks like 1.8 brings spherical distances to the stable branch which makes the geo lookups a lot more useful if you need accurate distances and not just near by lo…
I got excited and looked it up. > We don't currently handle wrapping at the poles or at the transition from -180° to +180° longitude, however we detect when a search would wrap and raise an error. generalized grumble Why does everyone always seem to punt on doing geospatial right? It's not _that_ hard.
> Why does everyone always seem to punt on doing geospatial right? It's not _that_ hard.
Do you mean you think they don't know how to do it?
As I followed the roadmap on this specific point, it looks more like an incremental development to me: they first used rectangular coordinates in 1.6, then a spherical model in 1.7 etc.
It allows to bring a more lightweight solution quickly to people that need it (like me), then to evolve based on the feedback etc.
Re: MongoDB 1.8 (stable) released
#55MongoDB is not something I have a good handle on yet. What's its sweet spot? Where should I consider using it instead of Postgres?
For me the sweet spot is its flexibility.
I work a lot on data aggregation, where I can create a bunch of tables each day, then maintain them etc. For me it's almost a dream really :)
As well they are adding features such as geonear that makes it appealing for other uses (which I have, too).
Re: MongoDB 1.8 (stable) released
#56As a newb to non-relational databases, but planning on learning one soon, what is the advantage of MongoDB vs Redis? I'm planning to use ruby with either, but was interested if there was a reason to pick one over the other.
(I work on MongoDB, but trying to give a balanced opinion.)
Redis is a great key-value store, MongoDB is more of a fully-featured database. Redis has some nice set operations and is pretty easy to learn (all of the commands are here: http://redis.io/commands). MongoDB is also pretty easy to learn (click the "Try it out" button at http://mongodb.org/), but there are a lot of advanced features to learn about.
So, if you need a key-value store, Redis is a great choice. If you want to do something more complex, MongoDB would probably work better.
Re: MongoDB 1.8 (stable) released
#57But is it web scale?
I got in so much trouble for a very similar web scale comment. Never shall trite jokes be used on hacker news. You'll get your head bit off. Personally, it gives me a giggle, and I guess that means I am much less mature than most consumers of Hacker News. http://news.ycombinator.com/item?id=2104276
I think it's just an old joke at this point. It's funny the first time you see it and the second time, but the 50th?
Re: MongoDB 1.8 (stable) released
#58Earlier quoted context omitted.
I got excited and looked it up. > We don't currently handle wrapping at the poles or at the transition from -180° to +180° longitude, however we detect when a search would wrap and raise an error. generalized grumble Why does everyone always seem to punt on doing geospatial right? It's not _that_ hard.
> Why does everyone always seem to punt on doing geospatial right? It's not _that_ hard. Do you mean you think they don't know how to do it? As I followed the roadmap on this specific point, it looks more like an incremental development to me: they first used rectangular coordinates in 1.6, then a spherical model in 1.7 etc. It allows to bring a more lightweight solution quickly to people that need it (like me), then…
The problem I have is at least partly one of truth in advertising.
For example: If they were truly using a "spherical model", then one would not expect to have queries fail at the poles & dateline, would you?
At least it is documented and fails hard with an error rather than giving wrong results, so a developer can quickly figure out the weak spots --- though I bet a lot of people would prefer the wrong results to queries that cause exceptions in their systems.
> Do you mean you think they don't know how to do it?
I think it has more to do with the absurdly low bar they've set for themselves to check the "geospatial" box than it does with competence.
Re: MongoDB 1.8 (stable) released
#59Earlier quoted context omitted.
> Why does everyone always seem to punt on doing geospatial right? It's not _that_ hard. Do you mean you think they don't know how to do it? As I followed the roadmap on this specific point, it looks more like an incremental development to me: they first used rectangular coordinates in 1.6, then a spherical model in 1.7 etc. It allows to bring a more lightweight solution quickly to people that need it (like me), then…
The problem I have is at least partly one of truth in advertising. For example: If they were truly using a "spherical model", then one would not expect to have queries fail at the poles & dateline, would you? At least it is documented and fails hard with an error rather than giving wrong results, so a developer can quickly figure out the weak spots --- though I bet a lot of people would prefer the wrong results to qu…
I don't know really - if limitations are documented like they are apparently, it's really not an issue for me - I don't feel cheated (but it's really an opinion!).
Your mileage may vary as they say: I used the GIS since 1.6 and it was very helpful for me in this form already :)
Re: MongoDB 1.8 (stable) released
#60Earlier quoted context omitted.
I got excited and looked it up. > We don't currently handle wrapping at the poles or at the transition from -180° to +180° longitude, however we detect when a search would wrap and raise an error. generalized grumble Why does everyone always seem to punt on doing geospatial right? It's not _that_ hard.
Why not go ahead and help them? I'm sure they'd be happy to have the assistance. Fork mongo from github at https://github.com/mongodb/mongo . Happy hacking!
You know, nobody ever replies to these comments with an "I will", but I'm seriously considering it.
(It's a nice opportunity to publicly show off a specialty/core competency and brush up a bit on C++ a the same time. I'm not that easily provoked into action by internet commentary! ;) )
But, looking at the source, I think I will be probably a Bad Contributor and end up with a gigantic pull request and a (mostly) full re-implementation...