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

MongoDB还是Redis？

我听说我应该在MongoDB中保留较小的集合以实现更好的索引(以及适合RAM的索引),并且我听说redis"非常快速",但如果你有更大的集合,MongoDB会更好.

如果我拥有数千个哈哈的数千个集合,那么效率最高的是什么？

我问这个是因为在我的项目中,将可用数据用于基准测试还为时过早,我可能会设计糟糕的基准测试脚本,因为我不太了解这两个数据库引擎的理论概念,特别是Redis.

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

这在很大程度上取决于具体的用例.如果您希望能够使用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.