blocks|key|1252593|text|SQL需要做相当多的事情，Mongo只需要在磁盘上放一些位(几乎)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1252594|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

SQL has to do quite a lot, Mongo just has to drop bits onto disk (almost)

blocks|key|4919236|text|MongoDB与传统的关系数据库不同。它是基于noSQL或文档的，它提供了弱的一致性保证，并且它不必像SQL那样保证一致性。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4919237|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/NoSQL^0|N|5|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

MongoDB isn't like a traditional relational database. It's <a href="http://en.wikipedia.org/wiki/NoSQL" rel="noreferrer">noSQL</a> or document based, it provides weak consistency guarantees, and it doesn't have to guarantee consistency like SQL.

blocks|key|3318915|text|Mongo不兼容ACID，因此它不必处理几乎同样多的"cruft“，以确保您尝试放入DB中的内容稍后可以再次返回。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3318916|如果你不介意失去一些功能和可能丢失的数据来换取速度，那么Mongo是好的。如果您绝对需要保证数据完整性和/或具有复杂的连接需求，那么请避免使用类似瘟疫的Mongo类型的系统。|3318917|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Mongo's not ACID compliant, so it doesn't have to deal with nearly as much "cruft" to make sure that what you try to put into the DB can come back out again later. 

If you don't mind losing some functionality and possibly losing data in exchange for speed, then Mongo's good. If you absolutely need to guarantee data integrity and/or have complex join requirements, then avoid Mongo-type systems like the plague.

blocks|key|1976189|text|正如前面提到的，MongoDB不是创建的，也不应该与SQL数据库一样使用。MongoDB+(和其他基于关系数据库)存储关系数据，即表X中的数据可以设置为与表Y中的信息有直接关系。SQL没有这种功能，因此可以降低大量开销。这就是为什么MongoDB通常用来存储列表，而不是关系。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1976190|再加上它还不完全符合ACID的事实(尽管自从它第一次被引入以来已经取得了很大的进步)，这就是速度差异的主要原因。|1976191|以下是在实际站点上概述的完整事务模型和它们的模型之间的差异。|1976192|在实践中，MongoDB的非事务性模型具有以下含义：|1976193|1976194|No回滚。您的代码必须在没有回滚的情况下运行。在执行第一次数据库写入操作之前，请检查所有编程条件。对写操作进行排序，以便最重要的操作发生在锁定时。您的代码可能会在执行操作时显式锁定对象。因此，应用程序程序员有能力在需要时确保“可序列化”。锁定功能将在启动的MongoDB.|unordered-list-item|offset|length|style|BOLD|1976195|Database+check的后期alpha+/早期测试版中可用。如果数据库异常终止(罕见)，数据库检查过程将在启动时自动运行(类似于fschk)。|1976196|1976197|entityMap^0|0|0|0|0|0|0|4|0|0|22|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|W|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|X|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|Z|8|@$L|10|M|11|N|O]]|9|@]|A|$]]|$1|P|3|Q|5|K|7|12|8|@$L|13|M|14|N|O]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|T|$]]

As it has been mentioned MongoDB isn't created and shouldn't be used the same as a SQL database. SQL (and other relational databased) store relational data, that is that data in table X can be set up to have direct relations to information in table Y. MongoDB doesn't have this ability, and can therefore drop a lot of overhead. Hence why MongoDB is usually used to store lists, not relations.

Add in the fact that it isn't not quite ACID compliant yet (though it has taken large strides since it was first introduced) and that's the bulk of the speed differences. 

Here are the differences outlined on the actual site between a full transactional model and their model.

In practice, the non-transactional model of MongoDB has the following implications:

<ul>
<li>No rollbacks. Your code must function without rollbacks. Check all programmatic conditions before performing the first database
write operation. Order your write operations such that the most
important operation occurs last.</li>
<li>Explicit locking. Your code may explicitly lock objects when performing operations. Thus, the application programmer has the
capability to ensure "serializability" when required. Locking
functionality will be available in late alpha / early beta release of
MongoDB.</li>
<li>Database check on startup. Should the database abnormal terminate (rare), a database check procedure will automatically run on startup
(similar to fschk).</li>
</ul>

blocks|key|3319001|text|MongoDB+is+fast+because+its+web+scale!|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|3319002|这是一个有趣的视频，值得每个人观看，但它确实回答了你的问题-大多数像MongoDB这样的noSQL引擎并不健壮，对崩溃和其他停机没有弹性。这种安全性是他们为获得速度而牺牲的。|3319003|entityMap|0|LINK|mutability|MUTABLE|url|http://www.youtube.com/watch?v=b2F-DItXtZs^0|0|12|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]]|C|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]]]

<a href="http://www.youtube.com/watch?v=b2F-DItXtZs" rel="noreferrer">MongoDB is fast because its web scale!</a>

Its a fun video and well worth everyone watching, but it does answer your question - that most of the noSQL engines like MongoDB are not robust and not resilient to crashes and other outages. This security is what they sacrifice to gain speed.

blocks|key|1976246|text|虽然其他答案很有趣，但我想补充的是，至少在基准测试中，MongoDB“如此快速”的原因之一是write+concern。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1976247|您可以阅读更多关于不同写入问题的，但基本上您可以在写入数据时定义所需的“安全”级别。|1976248|默认级别过去是unacknowledged，，这意味着写操作只是被触发，但驱动程序不会检查它是否成功执行。它速度更快，但可靠性要差得多。|BOLD|1976249|他们把acknowledged.改成了但我猜大多数基准测试仍然使用“未确认”模式以获得更好的结果。|1976250|如果你想看看性能方面的差异，你可以查看+(有点老了，但它仍然给出了一个想法)。|1976251|entityMap^0|1A|D|0|0|7|E|7|E|0|3|C|3|C|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|T|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|U|8|@$9|V|A|W|B|J]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|K|3|L|5|6|7|Z|8|@$9|10|A|11|B|J]|$9|12|A|13|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|14|8|@]|D|@]|E|$]]|$1|O|3|-4|5|6|7|15|8|@]|D|@]|E|$]]]|P|$]]

While the other answers are interesting I would add that one of the reasons MongoDB is "so fast", at least in benchmarks, is the <code>write concern</code>.

You can read more about the different write concerns <a href="http://docs.mongodb.org/manual/core/write-concern/" rel="noreferrer">here</a> but basically you can define the level of "security" you want when writing data.

The default level used to be <code>unacknowledged</code>, which means the write operation is just triggered but the driver does not check if it performed successfully. It is faster, but way less reliable.

They changed it about <a href="http://docs.mongodb.org/manual/release-notes/drivers-write-concern/" rel="noreferrer">one year ago</a> to <code>acknowledged</code>. But I guess most of the benchmarks out there still use the 'unacknowledged` mode for better results.

If you want to see the difference in term of performance, you can check <a href="http://whyjava.wordpress.com/2011/12/08/how-mongodb-different-write-concern-values-affect-performance-on-a-single-node/" rel="noreferrer">this article</a> (a bit old but it still gives an idea).

blocks|key|1976267|text|我还要补充的是，另一个区别不在于速度，而在于概念化(尽管我认为它可能有助于提高速度，因为加入问题的空间较小)是基于文档的存储非常类似于面向对象的思维模式。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1976268|基于文档的可能不是完全酸的，但我相信MongoDB更容易获得您想要的东西，只获取整个文档，而不是打乱SQL+DB的所有连接，冒着一些糟糕的连接的风险。|1976269|向所有的铁杆粉丝道歉。|1976270|entityMap^0|1L|J|0|0|0|4|0^^$0|@$1|2|3|4|5|6|7|L|8|@$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|J|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|K|$]]

I will also add that another difference is less about speed and more about conceptualization (although I believe that it might help with speed because there is less room for joining issues) is the document-based storage is very similar to object oriented mindset. 

The document-based might not be perfectly ACID, but I believe MongoDB is easier to get what you want by just getting the whole document rather than messing with all the joins of a SQL DB, risking some bad joins as well. 

Apologies to any SQL die-hard fans.

blocks|key|1979350|text|MongoDB是fast™，因为：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1979351|consistency.|1979352|Asynchronous插入和更新不是ACID:可用性优先于|unordered-list-item|1979353|和update:这意味着，MongoDB不会在处理insert查询时立即将数据插入数据库，但它会在一段时间后刷新数据。更新也是如此。|ordered-list-item|1979354|No+Joins开销:当他们说MongoDB是文档数据库时，他们的意思是，它是一个包含自给自足数据的数据库，所有信息都像真正的文档一样嵌入。|1979355|1979356|1979357|entityMap^0|0|H|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@$9|U|A|V|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|W|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|X|8|@]|D|@]|E|$]]|$1|K|3|L|5|M|7|Y|8|@]|D|@]|E|$]]|$1|N|3|O|5|M|7|Z|8|@]|D|@]|E|$]]|$1|P|3|-4|5|6|7|10|8|@]|D|@]|E|$]]|$1|Q|3|-4|5|6|7|11|8|@]|D|@]|E|$]]|$1|R|3|-4|5|6|7|12|8|@]|D|@]|E|$]]]|S|$]]

MongoDB is fast™ because:
<ol>
<li>Not ACID: Availability is given preference over consistency.</li>
<li>Asynchronous insert and update: What it means is, MongoDB doesn't insert the data to DB as soon as insert query is processed but it flushed the data after certain amount of time. Same is true for updates.</li>
<li>No Joins overhead: When they say MongoDB is a document database, what they mean is, it is a database that contains data that is self sufficient and all the information is embedded like a real document.</li>
</ol>

blocks|key|4919572|text|MongoDb的速度更快，因为:+1.没有事务；2.表之间没有关系；|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4919573|如果您将尝试在SQL+server上执行完全相同的逻辑，例如:+1.不使用带锁的选择；2.表之间没有关系；SQL+Server和MongoDB之间的速度差距不会那么大。只在一个地方写和更新记录肯定会更快，因为在队列和事务中插入和更新表，在MondoDB上它是异步发生的。在我的预测中，我不能在SQL+SERVER和MongoDB之间获得任何大的速度差异，因为两个项目之间的业务逻辑非常相似。在MongoDb上获得真正的速度收益您可以使用投标数据的分析项目，或大型内容管理引擎，如报纸，在线商店等。同样，在MongoDB上没有优化，在SQL+server上进行良好的优化可以使这些数据库几乎相等。|offset|length|style|BOLD|4919574|entityMap^0|0|2W|V|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@$D|L|E|M|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

MongoDb is faster because:
1. No transactions;
2. No relations between tables;

If you will try to do exact the same logic on SQL server, for example :
1. Do not use Select with locks ;
2. No relations between tables;
It will not be so big gap in speed between SQL Server and MongoDB. 
Only one place definitely will be faster , write and update records, because SQL doing insert and update table in the queue and in a transaction, on MondoDB it happens asynchronously. 
In my projections I could not gain any big differences in speed between SQL SERVER and MongoDB, because business logic was very similar between 2 projects.
Real speed gain on MongoDb you can get on Analytical projects with bid data, or on big content management engines, like news papers, online stores and etc. 
Again no optimization on MongoDB and good optimization on SQL server can make these databases almost equal.

blocks|key|3319403|text|根据MongoDB的网站，MongoDB是一个文档数据库，具有你想要的可扩展性和灵活性，以及你需要的查询和索引。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3319404|让我们试着理解这到底是什么意思。因此，我们知道MongoDB是基于文档的，所以它将数据存储在文档中，这些文档是像JSON这样的字段值对数据结构。同样，它将数据存储在这些文档中，而不是像传统关系数据库那样存储在表中的行。因此，它是一个NoSQL数据库，而不是关系数据库。|3319405|此外，MongoDB具有内置的可伸缩性，当您的应用程序获得越来越多的用户并开始生成大量数据时，跨多台计算机分发数据变得非常容易。因此，无论您做什么，MongoDB都会让您轻松成长。|3319406|MongoDB的另一个大特性是它极大的灵活性。在用数据填充文档数据模式之前，不需要定义文档数据模式，这意味着每个文档可以有不同数量和类型的字段。我们也可以随时更改这些字段。所有这些都非常符合现实世界的业务情况，因此它可以变得非常有用。|3319407|MongoDB也是一个性能非常好的数据库系统，这要归功于嵌入式数据模型、索引、分片、灵活的文档、原生复制等等。它是一个免费的开源数据库，在SSPL许可下发布。|3319408|总而言之，我们可以说MongoDB是一个很棒的数据库系统，可以构建许多类型的现代、可伸缩和灵活的web应用程序。事实上，Mongo可能是使用节点JS最多的数据库。|3319409|现在让我们更深入地了解这些文档，考虑到博客文章的例子，这里是完全相同的数据如何看起来像MySQL这样的关系数据库中的行，甚至是Excel电子表格中的行。|3319410|​|3319411|📷|atomic|offset|length|3319412|MongoDB使用类似于JSON的数据格式进行数据存储，称为BSON。它看起来与JSON基本相同，但它是类型化的，这意味着所有值都有一个数据类型，如字符串、布尔值、日期和对象(如教师对象、双对象)等等。因此，这意味着所有的MongoDB文档实际上都是类型化的，这与JSON不同。|3319413|现在就像JSON一样，这些BSON文档也将有字段，数据存储在键-值对中。另一方面，在关系数据库中，每个字段被称为一列，数据库以表结构排列数据，而我们的JSON数据要灵活得多。|3319414|以上图中的tags字段为例，我们实际上有一个数组，所以基本上一个字段有多个值，但在关系数据库中，这是不允许的，我们不能在一个字段中有多个值。因此，我们实际上必须在关系数据库中找到解决此问题的方法，这可能会涉及更多的工作，甚至更复杂。|3319415|现在，MongoDB中另一个极其重要的特性是嵌入式文档的概念，这是关系数据库中所没有的。因此，在注释字段中，我们有一个包含三个对象的数组，每个对象对应一个文档。想象一下，我们有一个评论集合，其中包含一堆评论文档，每个评论文档实际上看起来都像这样，所以对于作者和评论文本，我们没有这样做，而是将这些评论直接包含到博客文章文档中，换句话说，我们将评论文档直接嵌入到文章文档中，这是嵌入或反规范化的过程，基本上是将一些相关数据都包含到一个单独的文档中。|3319416|在上面的示例中，注释与post和os相关，它们包含在同一个文档中，这使得数据库在某些情况下性能更高，因为这样可以更容易地一次读取我们需要的所有数据。|3319417|现在，嵌入或反规范化的对立面是规范化，这就是在关系数据库中始终对数据建模的方式。在上面的示例中，不可能在关系系统中嵌入数据，解决方案是为注释创建一个全新的表，然后通过引用comments表的ID字段来连接表。|3319418|关于BSON文档，您需要了解两件事：|3319419|首先，每个文档的最大大小当前为16MB|3319420|其次，每个文档都包含一个惟一的ID，它充当该文档的主键，每次有新文档时都会使用object+ID数据类型自动生成它，您不必担心这个问题。|3319421|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://i.stack.imgur.com/Io8oW.png|imageAlt^0|0|0|0|0|0|0|0|0|0|1|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1P|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1R|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1S|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|1T|8|@]|9|@$S|1U|T|1V|1|1W]]|A|$]]|$1|U|3|V|5|6|7|1X|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|20|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|21|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|22|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|23|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|24|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|25|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|26|8|@]|9|@]|A|$]]]|1D|$1E|$5|1F|1G|1H|A|$1I|1J|1K|-4]]]]

According to MongoDB's website, MongoDB is a document database with the scalability and flexibility that you want and with querying and indexing that you need.

Let's try tho understand what this actually means. So as we know MongoDB is a document-based so it stores data in documents which are field value paired data structures like JSON. So again, it stores data in these documents instead of rows in a table like in traditional relational databases. It's therefore a NoSQL database and not a relational one. 

Also, MongoDB has built-in scalability, making it very easy to distribute data across multiple machines as your apps get more and more users and start generating a ton of data. So whatever you do, MongoDB will make it very easy for you to grow.

Another big feature of MongoDB is its great flexibility. There is no need to define a document data schema before filling it with data, meaning that each document can have a different number and type of fields. And we can also change these fields all the time. All this is really in line with some real-world business situations, therefore it can become pretty useful.

MongoDB is also a very performant database system, thanks to features like embedded data models, indexing, sharding, the flexible documents that you know I believe, native duplication and so much more. And it is a free and open-source database, published under the SSPL license.

In summary, we can say that MongoDB is a great database system to build many types of modern, scalable, and flexible web applications. In fact, Mongo is probably the most used database with node JS.

Now let's know about a bit deeper about these documents considering a blog post example, here is how that exact same data could look like as a row in a relational database like MySQL, or even in an Excel spreadsheet.

<a href="https://i.stack.imgur.com/Io8oW.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/Io8oW.png" alt="enter image description here"></a> 

MongoDB uses a data format similar to JSON for data storage called BSON. IT looks basically the same as JSON, but it's typed, meaning that all values will have a data type such as String, Boolean, Date, and Object (such as Teacher Object, Double Object) and more. So what this means is that all MongoDB documents will actually be typed, which is different from JSON.

Now just like JSON, these BSON documents will also have fields, and data is stored in key-value pairs. On the other hand in a relational database, each field is called a column, and database arranges data in table structures while our JSON data is so much more flexible.

Take for example the tags field in the above picture, where we actually have an array, so we have basically multiple values for one field, but in relational databases, that's not really allowed, we cannot have multiple values in one field. So we would actually have to find workarounds for this in a relational database, which could then involve more work and even more overall complication.

Now another extremely important feature in MongoDB is the concept of embedded documents, which is something not present in relational databases. So in our comments field here we have an array that contains three objects, one for each document. So just imagine we have a comments collection which contained a bunch of comment documents, each of them could actually look exactly like this, so with an author and with the comment text, but instead of doing that, we include these comments right into that blog post document, so in other words, we embed the comment documents right into the post document, this is the process of embedding or de-normalizing which is basically to include some related data all into one single document.

In the above example the comments are related to the post and os they are included in the same document which makes a database more performant in some situations because this way it can be easier to read all the data that we need all at once.

Now the opposite of embedding or de-normalizing is normalizing, and that's how the data is always modeled in a relational database. In the above example case it's not possible to embed data in a relational system, solution is to create a whole new table for the comments and then join the tables by referencing the ID field of the comments table.

Two things about BSON documents you need to know:

First, the maximum size for each document is currently 16 MB

Second, each document contains a unique ID, which acts as a primary key of that document, it's automatically generated with the object ID data type each time there is a new document, you don't have to worry about it.

blocks|key|1976607|text|Mongodb在插入和更新方面要快得多，因为它不检查模式和执行外键检查，但在通过属性读取数据和搜索时，它并不总是更快，特别是当你没有索引键的时候。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1976608|更多信息请点击这里：https://www.youtube.com/watch?v=K8xsuFgCRkU|offset|length|1976609|entityMap|0|LINK|mutability|MUTABLE|url|https://www.youtube.com/watch?v=K8xsuFgCRkU^0|0|A|17|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Mongodb is a lot faster in inserts and updates, because it does not check the schema and perform foreign key checks, but in reading the data by attributes and searching, its not always faster, specially if you dont have index keys.
More about it here: <a href="https://www.youtube.com/watch?v=K8xsuFgCRkU" rel="nofollow noreferrer">https://www.youtube.com/watch?v=K8xsuFgCRkU</a>

I was showing my co-worker performance benchmarks of MongoDB vs SQL 2008 and while he believes MongoDB is faster, he doesn't understand how its possible. His logic, was that SQL has been around for decades, and has some of the smartest people working on it, and how can MongoDB; a relatively new kid on the block be so superior in performance? I wasn't able to really provide a solid and technical answer, and I was hoping you guys could assist.

Why Is MongoDB So Fast

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我向我的同事展示了MongoDB与SQL2008的性能基准测试，虽然他相信MongoDB更快，但他不明白这是怎么回事。他的逻辑是，SQL已经存在了几十年，并且有一些最聪明的人在处理它，MongoDB；一个相对较新的新手怎么会在性能上如此优越？我不能真正提供一个可靠和技术性的答案，我希望你们能提供帮助。

问为什么MongoDB如此之快
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么MongoDB如此之快EN