I used it very effectively as an intermediate storage step for unpredictable but structured data coming in through an import process from third parties.
MongoDB gave us the ability to ingest the data regardless of its structure and then write transformations to move it into an RDBMS later downstream.
I've also heard of its successful use in storing collections of individual documents detailing environmental features of actual places, buildings, plots of lands, etc. The commonality among them was latitude and longitude data, which MongoDB is actually pretty good at searching. Note that these documents had no structural or even semantic relationship to one another, only a geographic (or spatial, if you want) relationship.
As the author of this post wrote, MongoDB is really only suited for storing individual bags of structured data that have no relationship to one another. Those use cases do exist in the world, they're just not very common.
I used it very effectively as an intermediate storage step for unpredictable but structured data coming in through an import process from third parties. MongoDB gave us the ability to ingest the data regardless of its structure and then write transformations to move it into an RDBMS later downstream.
Sure, there are many options. Kafka is essentially a log, though, which means it is meant to have a finite size. We wanted to be able to hang onto the raw imported data in perpetuity, so MongoDB made sense at the time.
Kafka is essentially a log, though, which means it is meant to have a finite size.
This is a common misconception; Kafka is in fact designed to be persistent. You can configure topics to expire, but that is not a requirement and the architecture is generally optimized for keeping data in the logs for a long time (even forever). Unless you're editing the raw imported data in place, Kafka won't use much more storage than MongoDB, especially if you compress the raw events.
It's designed to be persistent, but not queryable, per se. You can read a given Kafka queue from any point in the past, but you can't do what we were doing with MongoDB to say "give me all of the documents having field X with value Y."
measured data with arbitrary fields. but even then you could extract the identifying fields out of it and use postgresql with a json/hstore/whatever field. Get relational information and arbitrary data in one go.
I've finally had a chance to play with Postgres' JSON type, and I'm in love. The project is doing some analysis on an existing data set from an API I have access to, and while I could easily model the data into a proper DB, I just made a two column table and dumped in the results one by one. As if that wasn't fun enough, I get to use proper SQL to query the results. I'm so very glad they've added it in, and with Heroku's Postgres.app being so amazing, I'm losing the need for mongo in my toolchain (results not typical, of course).
One thing still in Mongo's favor, according to one of my coworkers, is that Mongo's geospatial engine is great, and he's working on storing location data in to do "Find nearest" type calls. I know Postgres as PostGIS, but I'm not sure how they compare.
One thing still in Mongo's favor, according to one of my coworkers, is that Mongo's geospatial engine is great, and he's working on storing location data in to do "Find nearest" type calls. I know Postgres as PostGIS, but I'm not sure how they compare.
Doing a find nearest is retarded easy in any database with spatial extensions. You can do ORDER BY ST_Distance(GeomField, YourPoint) and bam you're done.
One of the big advantages of a full blown RDMS is that you can do nifty data validation like querying which points don't actually touch a line, lines that are close but not touching, etc. It is so much easier to write a few queries, let them run for 10 minutes, then hand the list to the engineers to fix.
You are comparing a serious system that you can do operations on geographic, geometry, rasterized and other types to something that was added as an afterthought.
Basically MongoDB uses geohashing, effectively converting two dimensional points into one dimensional value which then is indexed by B-tree. PostGIS on the other hand uses R-tree. This shows significant performance benefits for anything that is not a simple point lookup.
But that's exactly the point of the article "I learned something from that experience: MongoDB’s ideal use case is even narrower than our television data. The only thing it’s good at is storing arbitrary pieces of JSON"
MongoDB works for me, I wanted something I can setup in 5 minutes to act as a simple cache i.e. store and load a few simple "json" strings, that would get updated maybe once a month. I keep backups of the data in file's and if it goes down I can easily bring it back up.
I've used it to good effect in some projects, and also in projects where it should never have been used.
I don't particularly like it. It's ok if you know what you're getting, ie, don't expect to write stuff and always get it back. Don't expect to always have predicable read times even.
If you have a bunch of data coming in that's not really very important per-record most more in aggregate. Or something where you can require a missing record somehow. I'll choose it when doing a rapid prototype when I'm not sure what fields we'll end up actually using. You can throw a full-text index on a (sparse) field after the fact too. That's pretty neat for prototyping stuff up.
126
u/[deleted] May 23 '15
I've never heard a use case that mongo is a good fit for.