什么是存储数千个中型文档的最有效的面向文档的数据库引擎? [英] What's the most efficient document-oriented database engine to store thousands of medium sized documents?
问题描述
MongoDB或Redis吗?
我听说我应该在MongoDB中保持较小的集合，以实现更好的索引编制(并使索引适合RAM)，并且听说redis很快就可以实现，但是如果您有更大的集合，MongoDB会更好. /p>
如果我有成千上万的哈希值，比如说几千个哈希值，那是最有效的方法呢?
之所以问这个问题，是因为在我的项目中尚无法提供可用的数据进行基准测试，而且我可能会设计不良的基准测试脚本，因为我对这两个数据库引擎(特别是Redis)的理论概念不太了解. /p>
感谢所有回答此问题的人.
这在很大程度上取决于特定的用例.如果您希望能够查询除其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.
MongoDB or Redis ?
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 ?
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.
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.
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).
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.
So, with the limited information at my disposal, I recommend MongoDB.
这篇关于什么是存储数千个中型文档的最有效的面向文档的数据库引擎?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
