Live data from Hacker News

Mongodb – not evil, just misunderstood

siddharth-ravichandran.com

1–10 of 53 posts

Re: Mongodb – not evil, just misunderstood

#4
> How can the default writes be fire and forget? It just made sense, given all the information to configure it the way you prefer I would always go with this approach

Yes, we should bring unacknowledged writes as a default back.

(Often a technology's greatest detractors are its own fans, they are digging its grave without even realizing).

Re: Mongodb – not evil, just misunderstood

#7
I have been using MongoDB since the beta days but after many replica set/sharding bugs springing up, I am less inclined to use it. That was the major feature we used if for. Addressing this article:

-Yes you can make aggregate results using map reduce (In javascript with a single core, idempotent) and you can store the aggregates as separate documents. I do not see what is so magical about this.

-It is true that you do not have a set schema thus no migrations, but you do have to have a schema in mind for nearly everything as something has to make sense of that field.

If you add fields to a document and you already have documents in there, you are going to have to add that data to them unless you want them to be nil. If you rename a field you have to iterate all documents and add rename it. If you remove a field you have to remove it from all existing documents if you do not want to have that data around anymore. Certainly you do not HAVE to do any of this but if you are fetching meaningful data from a field you need to.

And you need to index on whatever you want to search on or the performance is terrible as Mongo is not very good on the disk so you have to keep that in mind too. I think most people were attracted to Mongo due to "no migrations" and schema but when you work with it almost any use case you find yourself using an unenforced schema and doing script based "migrations" The recent Mongo criticism is that it markets itself as a all purpose DB but in reality document stores are not that.

Re: Mongodb – not evil, just misunderstood

#8

I have seen a lot of good use and success stories with MongoDB as well. This negative reaction lately makes me want to give it a shot and see why there is so much fear.

Nobody denies that it's an attractive API, but the problems I've seen are in companies at scale. You won't run into insurmountable problems at first, only later when performance matters.

Re: Mongodb – not evil, just misunderstood

#9
post #8

I have seen a lot of good use and success stories with MongoDB as well. This negative reaction lately makes me want to give it a shot and see why there is so much fear.

Nobody denies that it's an attractive API, but the problems I've seen are in companies at scale. You won't run into insurmountable problems at first, only later when performance matters.

I actually have first hand experience from merely a small data set of 37,000 records of a couple fields each. I needed to run a batch update to calculate a property of each document. The property is dependent upon a count of other similar documents. Turns out that it was so unbearably slow, that there was no way to do the batch update without waiting hours.. I searched long and hard for a solution to the write/read locks but there is none. So this is my holy grail to share, and if you don't use Mongo..more power to you.

I ended up figuring out a workaround but it left a bad taste in my mouth. My workaround was to create a temporary collection and insert all the previous records, with their Category attribute updated, in a single .insert call.

I am more than sure that an SQL UPDATE query using a subselect for the COUNT(*) would have probably executed in less than a couple seconds. That's what's so sad about MongoDB. And I even had everything indexed, it made almost no difference. The write/read locks are _murder_.

    houses.db.eval(function(){
		const tmp = db[Math.random().toString(36).slice(2)];
		tmp.insert(
			db.houses.find().map(function(e){
				e.Block = db.houses.count({
					Street: e.Street,
					Sector: {$lte: e.Sector},
					Quadrant: 1
				});
				return e;
			})
		);
		tmp.renameCollection("houses", true);
	}, {nolock: true}, function(err){
		dbCallback(err);
		console.log("Done!");
		process.exit();
	});
Eh.

Re: Mongodb – not evil, just misunderstood

#10
post #8

Earlier quoted context omitted.

Nobody denies that it's an attractive API, but the problems I've seen are in companies at scale. You won't run into insurmountable problems at first, only later when performance matters.

I actually have first hand experience from merely a small data set of 37,000 records of a couple fields each. I needed to run a batch update to calculate a property of each document. The property is dependent upon a count of other similar documents. Turns out that it was so unbearably slow, that there was no way to do the batch update without waiting hours.. I searched long and hard for a solution to the write/read l…

that is an paragon of maintainability if I ever saw one.
Post reply on HN