What MongoDB got right

144 点作者 reqres超过 9 年前

12 条评论

s_kilk超过 9 年前

> Let's start with the simplest one. Making the developer interface to the database a structured format instead of a textual query language was a clear win.I think this is the most significant factor, by far. With Mongo it's turtles (or at least Maps/Hashes) all the way down, without a strange pseudo-english layer near the bottom that forces you to translate back and forth. For some devs that's a big deal.For the last while I've been experimenting with bringing the same feature to PostgreSQL (<a href="http://bedquiltdb.github.io" rel="nofollow">http://bedquiltdb.github.io</a>), turns out it's very do-able, but I don't have enough time to make it as featureful as it needs to be.

评论 #10559583 未加载

评论 #10559439 未加载

评论 #10559494 未加载

评论 #10560072 未加载

评论 #10559890 未加载

评论 #10560176 未加载

评论 #10561328 未加载

bryanlarsen超过 9 年前

"So while MongoDB today may not be a great database, I think there's a good chance that the MongoDB of 5 or 10 years from now truly will be."Either MongoDB will be, or other databases that have learned the lessons, both good and bad, of MongoDB.RethinkDB appears to have captured the "MongoDB done right" mindshare, and PostgreSQL has gained JSON and is gaining better replication in order to cover the same niches.

评论 #10559423 未加载

评论 #10560810 未加载

评论 #10560409 未加载

评论 #10559604 未加载

yummyfajitas超过 9 年前

Counting arguments very carefully? Nearly every SQL library does this for you.<pre><code> cur.execute("INSERT INTO a (b,c) VALUES (%(a)s, %(b)s);", { 'a' : a, 'b' : b }) </code></pre> Also, SQL is typed, so even if you did fail to count arguments there is a good chance you'd just detect it the first time you ran it.The article acts as if treating the DB like native structures is somehow innovative and new - it's not. <a href="https://en.wikipedia.org/wiki/Object_database" rel="nofollow">https://en.wikipedia.org/wiki/Object_database</a>We mostly abandoned object databases because they sucked. SQL was a huge improvement over them. SQL is a great way to organize and preserve the integrity of a lot of business data.It's also a fantastic way to avoid repeated trips to the DB:<pre><code> SELECT * FROM employees AS e WHERE e.department_id = (SELECT id FROM departments WHERE name = "engineering"); </code></pre> In Mongo, I'm pretty sure you need to first lookup engineering, then lookup the employees in engineering. That could be O(# employees in engineering) queries rather than 1.

评论 #10561961 未加载

评论 #10561989 未加载

krisdol超过 9 年前

I don't understand the recent backlash against NoSQL here.First off, almost all of the complaints would have been valid years ago. Secondly, there is so much more choice out there today if mongodb wasn't the right answer for your project, and so many NoSQL stores have had time to mature and get polished APIs and docs.We use various data stores for different purpose across microservices, mostly ES, couchbase, and datomic, and "use the right tool for the job" and "do one thing and do it well" feels like the right approach to take. For most applications, a SQL DB feels like a really big hammer that is put to a lot of things that don't look like nails.

评论 #10560431 未加载

评论 #10560701 未加载

评论 #10560157 未加载

评论 #10561381 未加载

评论 #10560184 未加载

rwmj超过 9 年前

Just a note that in PG'OCaml (an OCaml interface to PostgreSQL), you can write:<pre><code> "insert into foo (col1,col2,col3) values ($a, $b, $c)" </code></pre> and it creates the safe prepared statement with ? placeholders. At compile time. Type-checked against the database to make sure your program types match your column types.<a href="http://pgocaml.forge.ocamlcore.org/" rel="nofollow">http://pgocaml.forge.ocamlcore.org/</a>

评论 #10559524 未加载

ngrilly超过 9 年前

I agree that the three areas outlined in the article are things that MongoDB got right: a structured query language (instead of a textual query language), replica sets, and the oplog.But the lack of transactions over multiple documents (in the same shard at least) and the lack of joins over multiple collections are a big showstopper for the kind of applications I develop.I note that solutions like YouTube's Vitess provide something similar to MongoDB's replica sets.I also note that PostgreSQL's logical decoding provide the same functionality than MongoDB's oplog tailing.

评论 #10559525 未加载

评论 #10559470 未加载

bsg75超过 9 年前

> You can argue, and I would largely agree, that this is actually part of MongoDB's brilliant marketing strategy, of sacrificing engineering quality in order to get to market faster and build a hype machine, with the idea that the engineering will follow later.Author nearly lost me here with this logic. Placing Marketing ahead of quality in something that is supposed to store a very valuable asset (data) is near insanity.I get the mindset of "break fast", "release often", etc. in terms of customer facing features, but in something that is supposed to be a core part of your foundation, stability is if utmost importance. Otherwise nothing else works - and you lose customers, business, opportunities - because you can't look them up later.Its not "brilliant marketing", its just marketing.

评论 #10561365 未加载

emilburzo超过 9 年前

I have to agree with the author, especially since the points he raises are the ones that helped me greatly on my first "serious" personal project[1].Coming from postgresql land I would have never thought you can have such great replication with automatic failover. I've had literally 100% uptime for the past year.And that's on commodity servers (one of them being in a room in my apartment, the other two in a proper datacenter) going through the usual upgrades, downtime, reboots, going from mongo 2 to mongo 3 and such.Speaking of which, the migration from mongo2 to mongo3 was another pleasant surprise: they've made it backwards compatible. So I could do the upgrade on the servers, one by one, checking everything was ok and after that I could focus on updating the drivers and rewriting the deprecated queries, no need to have everything ready at once.The accessible oplog was another gem that fit my project really well. Gone was the need to poll the database, I could just "watch" the oplog. That, coupled with long polling on the browser side meant I'd have very little chatter between the db/server/web client when idle. Websockets would have been nice, but adoption wasn't high enough that I'd be comfortable going forward with it.And all this considering MongoDB was my first NoSQL experience.I agree it doesn't fit every project, but when it does, it's a really nice experience.[1] <a href="https://graticule.link/" rel="nofollow">https://graticule.link/</a>

评论 #10559466 未加载

_yy超过 9 年前

RethinkDB took all the good parts of MongoDB and added proper engineering.<a href="https://www.rethinkdb.com/" rel="nofollow">https://www.rethinkdb.com/</a>

评论 #10560335 未加载

angelbob超过 9 年前

I love the point about the Oplog.There are a few equivalents for common SQL DBs (see LinkedIn's Databus for Oracle and MySQL), but in general, getting access to the write log is really hard. Even though it's sitting there!It would be wonderful if there were some kind of established API or library that would let you parse the MySQL write log without doing hideous, fragile operations that change from version to version. Sure, change the format, but at least version and document it!

sriku超过 9 年前

When we chose MongoDB for a project, a dominant criterion was out of the box geo queries. It helped that the storage and query approach had good impedance match with NodeJS. From a query perspective, we wouldn't have benefited much from SQL anyway, since much of the reading is free text or social graph or location based search which we moved to Solr.

franzwong超过 9 年前

It becomes much simpler to setup replication in PostgreSQL than before.reference: <a href="https://www.digitalocean.com/community/tutorials/how-to-set-up-master-slave-replication-on-postgresql-on-an-ubuntu-12-04-vps" rel="nofollow">https://www.digitalocean.com/community/tutorials/how-to-set-...</a>