存储数千个中型文档的最有效的面向文档的数据库引擎是什么? [英] What's the most efficient document-oriented database engine to store thousands of medium sized documents?

问题描述

MongoDB 还是 Redis?

MongoDB or Redis ?

我听说我应该在 MongoDB 中保持较小的集合以实现更好的索引(和适合 RAM 的索引)，我听说 redis 非常快"，但如果您有更大的集合，MongoDB 会更好.

I've heard that I should keep collections small in MongoDB to enable better indexing (and indexes fitting on RAM), and I've heard that redis is "blazing fast" but MongoDB is better if you have bigger collections.

如果我有几千个集合，比如说几千个散列，什么是最有效的?

What's the most efficient one if I have multiple thousand collections of say a few thousand of hashes ?

我之所以这么问是因为在我的项目中，现在获得可用数据进行基准测试还为时过早，而且我可能会设计糟糕的基准测试脚本，因为我不太了解这两个数据库引擎(尤其是 Redis)的理论概念.

I'm asking this because in my project it's too early to have available data to benchmark and I would probably design bad benchmark scripts because I don't understand very well the theoretical concepts of those two database engines, specially Redis.

感谢所有回答这个问题的人.

Thanks for everyone who answers this.

推荐答案

这在很大程度上取决于具体的用例.如果您希望能够根据 ID 以外的其他内容查询您的文档，那么您不应该选择 Redis.使用 Redis，您必须实现自己的索引方案，而这是不必要的.

It depends very much on the specific use case. If you want to be able to query your documents on something other than their ID then you shouldn't choose Redis. With Redis you would have to implement your own indexing scheme, and that's just unnecessary.

实际上很少有 Redis 会是我认为您的用例的更好选择的情况(并不是说 Redis 有什么问题，我经常同时使用 Redis 和 Mongo，但用于不同的事情).在我看来，您有可以表示为散列的对象.Mongo 和 Redis 都可以存储哈希值，但 Mongo 可以做的更多.使用 Mongo，您可以在其任何字段上搜索文档，您可以添加索引以加快搜索速度，并且该字段甚至不必是字符串，它可以是数字、日期、列表，甚至是文档(或文档列表)，并且所有文档都不必放在 RAM 中(尽管当 Redis 的磁盘存储功能完成时，这会发生变化).Redis 没有这些.你必须自己实现索引才能搜索，除了字符串你不能存储任何东西(有时这真的很不方便)，除了平面哈希你不能存储任何东西(不诉诸实现或使用某种映射层像 Ohm).

There's actually very few cases where Redis would be a better option for what I think your use case is (not that there's anything wrong with Redis, I often use both Redis and Mongo, but for different things). It sounds to me like you have objects that can be represented as hashes. Both Mongo and Redis can store hashes, but Mongo can do much more. With Mongo you can search for a document on any of its fields, you can add an index to speed it up, and the field doesn't even have to be a string, it can be a number, date, list, even a document (or a list of documents), and all of the documents don't have to fit in RAM (although that will change when Redis' diskstore feature is finished). Redis doesn't have any of that. You would have to implement indexes yourself to be able to search, you can't store anything but strings (which is really inconvenient sometimes), and you can't store anything but flat hashes (without resorting to implement or use some kind of mapping layer like Ohm).

你还提到了速度.Redis 非常快，Mongo 也不错，但是，对于您的用例，使用 Mongo 可能更快.注意我说的是使用 Mongo，并不是说Mongo 本身会更快.问题是，如果您使用 Redis 并且仍然希望能够使用不是主键的字段来搜索文档，那么正如我上面提到的，您必须自己实现这一点.然后，搜索必须至少向 Redis 发出两次请求，一次用于查看索引，另一次用于获取文档.如果搜索结果超过一份文件，您必须单独为每份文件提出请求.发出所有这些请求的开销可能会使使用 Redis 比使用 Mongo 更糟糕.根据我的经验，除了最简单的缓存、队列或类似的东西之外，其他任何东西都需要向 Redis 发出多个请求才能获得它需要的一切.

You also mention speed. Redis is blazingly fast, and Mongo isn't bad either, however, for your use case using Mongo may be quicker. Notice I say using Mongo, not that Mongo itself would be quicker. The thing is, if you go with Redis and still want to be able to search for a document using a field that isn't the primary key, you would, as I mentioned above, have to implement this yourself. A search would then have to make at least two requests to Redis, one for looking in the index, and one for getting the document. If a search results in more than one document you would have to make a request for each document individually. The overhead of making all these requests would probably make using Redis worse than using Mongo. In my experience, anything other than the simplest cache, queue, or similar needs to make more than one request to Redis to get everything it needs.

因此，由于我掌握的信息有限，我推荐 MongoDB.

So, with the limited information at my disposal, I recommend MongoDB.

这篇关于存储数千个中型文档的最有效的面向文档的数据库引擎是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！