什么是存储数千个中型文档的最有效的面向文档的数据库引擎？

Question

MongoDB还是Redis？

我听说我应该在MongoDB中保持较小的集合，以实现更好的索引编制（并使索引适合RAM），并且听说redis是“快速发展”的，但是如果您有更大的集合，MongoDB会更好。

如果我有成千上万个哈希值的数千个集合，哪一种是最有效的？

我之所以这样问，是因为在我的项目中，尚无可用数据进行基准测试，而且我可能会设计不良的基准脚本，因为我对这两个数据库引擎（特别是Redis）的理论概念不太了解。

感谢所有回答此问题的人。

Answer 1

这在很大程度上取决于特定的用例。如果您想查询文档的ID以外的其他内容，则不要选择Redis。使用Redis，您将必须实现自己的索引编制方案，而这是不必要的。

实际上，在极少数情况下，对于我认为您的用例而言，Redis会是一个更好的选择（不是Redis出现任何问题，我经常同时使用Redis和Mongo，但是用于不同的事情）。在我看来，您有一些可以表示为哈希的对象。Mongo和Redis都可以存储哈希，但是Mongo可以做更多的事情。使用Mongo，您可以在文档的任何字段中搜索文档，可以添加索引来加快文档的速度，并且该字段甚至不必是字符串，可以是数字，日期，列表甚至文档（或文档列表），并且所有文档都不必放在RAM中（尽管在Redis的磁盘存储功能完成时会有所变化）。Redis没有任何东西。您必须自己实现索引才能进行搜索，哦）。

您还提到了速度。Redis的运行速度非常快，Mongo也不错，但是，使用Mongo的用例可能会更快。注意我说 使用
Mongo，不是说Mongo本身会更快。事实是，如果您使用Redis并仍然希望能够使用不是主键的字段来搜索文档，则如上所述，您必须自己实现此功能。然后，搜索必须至少向Redis发出两个请求，一个用于查找索引，另一个用于获取文档。如果搜索结果涉及多个文档，则您必须分别请求每个文档。发出所有这些请求的开销可能会使使用Redis比使用Mongo更糟。以我的经验，除最简单的缓存，队列或类似操作外，其他任何事情都需要向Redis发出多个请求，以获取其所需的一切。

因此，鉴于我掌握的信息有限，我建议使用MongoDB。