31–40 of 188 posts
Is it a joke? > Error establishing a database connection Or is it truly an error? In a page that from the title is bashing another DB
Amusingly ironic, eh? ;)
I think it's ironic that the page says "Error establishing a database connection". As someone who used MongoDB extensively in the past (8TB+ of data) and also managed the devops side of things, I can tell you straight out that MongoDB has a place in a lot of startup stacks. I would likely not use it as a main source of truth for any application. However for a lot of things, it's a good database. Since I can't read th…
> I would likely not use it as a main source of truth for any application but for a lot of things, it's a good database. I really don't understand this. In what case is it every acceptable for a data store to lose data? And that's not even MongoDB's only problem: it memory leaks!
Memory leaks weren't a huge issue for us as well. After stabilizing the setup I have to say it was basically a fire and forget part of the stack for us.
The role of MongoDB was to act as a fast-insert and aggregation framework for other parts of the system.
So, we would insert BIG amounts of data at a time and aggregate it into a K/V store where we pulled the data from.
After a while, the setup became to expensive to run, at this point we turned it off for a cheaper solution, but in terms of functionality, it functioned pretty well.
Earlier quoted context omitted.
If you read the post, the problem wasn't Mongo as much as they chose the new hotness (document db/graph model) when in reality their problem was already well solved by a RDBMS and tabular model, they had classic problems like duplicate data and performance issues when they tried to use a document db as a RDBMS. They changed over and everything was fine.
before: mongodb is bad because it imposes we handle the case where we'd like to shard the db (which breaks joins). after: mysql is sooo much easier with joins. Who cares about sharding anyway. I hope people understand distributed systems a bit better today, but I don't have high hopes.
I think it's ironic that the page says "Error establishing a database connection". As someone who used MongoDB extensively in the past (8TB+ of data) and also managed the devops side of things, I can tell you straight out that MongoDB has a place in a lot of startup stacks. I would likely not use it as a main source of truth for any application. However for a lot of things, it's a good database. Since I can't read th…
The placement of the commas in your post is blowing my mind!
I stopped reading where it said "never".
I'm usually against absolutes, but I'm really in agreement here. It's almost always better to use a relational database, and in the rare cases where you wouldn't want a relational database, MongoDB is the worst of the major options. It literally memory leaks and drops data without warning or provocation. If you're not going to go with a relational database, RethinkDB, Cassandra, Redis, or BerkeleyDB would all be bett…
I think it's ironic that the page says "Error establishing a database connection". As someone who used MongoDB extensively in the past (8TB+ of data) and also managed the devops side of things, I can tell you straight out that MongoDB has a place in a lot of startup stacks. I would likely not use it as a main source of truth for any application. However for a lot of things, it's a good database. Since I can't read th…
> I would likely not use it as a main source of truth for any application what the point then ? MongoDB isn't even good for analytics and big data. What do you store in MongoDB ?
My first introduction to databases was with PHP/MySQL, where normalization was the name of the game. The whole point of normalization is that there is no duplication of data anywhere. If it's possible for duplicate data to exist, that's a symptom of a design flaw in the schema. I've been using Mongo recently, and every time I raise criticism of it, the counterargument I hear is "forget about normalization! Duplicatio…
CouchDB does this to a certain extent, but its JSON-document approach is not appropriate enough.
TFA says: "In 2010, when the Diaspora team was making this decision, Etsy’s articles about using document stores were quite influential, although they’ve since publicly moved away from MongoDB for data storage. Likewise, at the time, Facebook’s Cassandra was also stirring up a lot of conversation about leaving relational databases. Diaspora chose MongoDB for their social data in this zeitgeist. It was not an unreasonable choice at the time, given the information they had."
Yes, it was an unreasonable choice. This is basically saying that the cool kids are using document stores, so we should too. There is no discussion of requirements, no recognition of the obvious conflict between Diaspora's data model and MongoDB's, and no discussion at all of the need for transactions, let alone distributed transactions!
TFA says: "In this post I’ve talked about how we used MongoDB vs. how it was designed to be used. I’ve talked about it as though all that information were obvious, and the Diaspora team just failed to research adequately before choosing. But this stuff wasn’t obvious at all."
Of course it was obvious. If you have a highly recursive data structure, and you decide to basically store the result of a seven-way join in a single document, then there is duplication. You should know, just from your earliest programming days, that duplicating data in data structures leads to grief. How are updates going to be handled? And if you decide against duplication, you have to do the joins, and clearly MongoDB doesn't solve that problem. So even before worrying about transactions it is obvious that you have a problem.
Finally, they migrate to MySQL and (then also? in addition?) Postgres. Although I don't quite see how this fits their database per pod architecture. I'm guessing that each pod talks to -- what -- one centralized database? Maybe they will eventually figure out what's wrong with that.
Oy.