MongoDB并不是神奇的更快。如果您以相同的方式存储相同的数据,并以完全相同的方式对其进行访问,那么您真的不应该期望结果会大相径庭。毕竟,MySQL和MongoDB都是GPL,因此,如果Mongo中包含一些神奇的更好的IO代码,则MySQL团队可以将其合并到他们的代码库中。
人们看到现实世界中的MongoDB性能主要是因为MongoDB允许您以更适合您的工作负载的不同方式查询。
例如,考虑一种设计,该设计以规范化方式保留了有关复杂实体的许多信息。这可以轻松地使用MySQL(或任何关系数据库)中的数十个表以标准形式存储数据,并需要许多索引来确保表之间的关系完整性。
现在考虑与文档存储相同的设计。如果所有这些相关表都从属于主表(并且经常属于主表),那么您也许可以对数据建模,以便将整个实体存储在单个文档中。在MongoDB中,您可以将其作为单个文档存储在单个集合中。这是MongoDB开始提供卓越性能的地方。
在MongoDB中,要检索整个实体,您必须执行:
在集合上进行一次索引查找(假设通过id获取实体) 检索一个数据库页面的内容(实际的二进制json文档) 因此,进行b树查找,并读取二进制页面。Log(n)+ 1个IO 如果索引可以完全驻留在内存中,则为1 IO。
在具有20个表的MySQL中,您必须执行:
在根表上进行一次索引查找(同样,假设该实体是通过id获取的) 对于聚集索引,我们可以假设根行的值在索引中 实体pk值的20多次范围查找(希望在索引上) 这些可能不是聚集索引,因此一旦我们确定了合适的子行是什么,就进行了20多个相同的数据查找。 因此,即使假设所有索引都在内存中(这比较困难,因为它们的数量是20倍),mysql的总数也大约为20个范围查找。
这些范围查找可能由随机IO组成-不同的表肯定会驻留在磁盘上的不同位置,并且同一实体在同一表的同一范围内的不同行可能不连续(取决于该实体的状态)更新等)。
因此,对于此示例,与MongoDB相比,每个逻辑访问的最终IO数比MySQL多20倍。
这是MongoDB 在某些用例中可以提高性能的方式。分享来源:stack overflow