问题标签 [multikey]

我正在尝试实现类似的地图

地图应包含 2 个键，对应的值将是一个列表。如果 alteast 一个键值相等，我想在同一个列表中添加记录 例如考虑以下记录

都应该插入到同一个列表中

我不能使用Guava 表或commons MulitKeyMap（不想为此包含整个库）。

我试图实现一个类（我可以将其用作键），它将同时具有key1和key2作为属性，但实现不考虑 key1 和 key2 的有效哈希码似乎有点（或可能很多）棘手

如果我对所有人使用相同的哈希码，它会起作用，但它会影响性能，因为我有数千条记录。

编辑：我
不能使用嵌套地图

因为有些记录可能只有一个键。

这里 R3 没有 key1，因此不能插入到与 R1 和 R2 相同的位置

编辑 2：

我也希望维持交警秩序。

我正在考虑将时间序列数据捆绑在会话文档中。在每个会话中，都会有一系列事件。每个事件都有一个时间戳。我知道我可以在这些事件的时间戳上创建一个多键索引，但我很好奇 MongoDB 使用什么机制来防止同一文档在一个查询中出现两次。

为了澄清，想象一组包含以下文档的会话：

如果我添加一个带有 的多键索引db.sessions.ensureIndex({'events.time' : 1})，我希望该索引的 b-tree 看起来像这样：

如果我使用 查询集合{'events.time': {$gte: '10:00'}}，MongoDB 会扫描 b-tree 并返回：

Mongo如何防止文档A第二次显示为光标中的第三个结果？对于小型索引扫描，它可以只跟踪已经查看过哪些文档，但是如果索引很大，会发生什么？是否存在同一个文档在单个光标中多次出现的情况？

我的假设是它不会。Mongo 可以查看它正在扫描的文档，并通过检查索引数组中较早的条目来检测它已经在扫描中较早地匹配。但是，我在 MongoDB 文档中找不到任何提及此行为的内容，并且实际知道会发生什么很重要。

（注意：我确实知道，如果在扫描光标时修改了文档，则文档可能会多次出现在单个查询中。这不应该对时间序列数据的查询造成问题，其中时间戳永远不会被编辑。即使在扫描期间将新事件添加到会话中，如果 Mongo 使用类似于我上面提到的检测机制，它应该能够从查询结果中忽略移动的文档。）

我在从 MongoDB 的集合中读取数据时尝试仅使用索引，因为我有一些大文档，而对于这个查询，我只需要一个字段。

事实证明，如果索引是多键索引，我不能让 indexOnly = true 。

这是我做的测试：

-> indexOnly = true，isMultiKey = false

-> indexOnly = false，isMultiKey = true

该文档提到了多键索引的一些限制，但没有提到这一点。有人知道如何同时使用多键和 indexonly 吗？

假设我有一个简单的 Java 对象，我们称之为 DefinedData。它将包含许多不同类型的最终字段，例如字符串、整数、枚举，甚至可能是一组或两个字符串。总而言之，它只是一个相对简单的数据容器。其中可能有 1k 到 2k 个，所有静态最终对象。这些字段中的大多数将是唯一的，因为没有其他 DefinedData 对象对该字段具有相同的值。

这些将被放置到 (DefinedData, Object) 的 Map 中。现在，如果您有 DefinedData 对象，您可以轻松地将该对象从 Map 中取出，但如果您只有一个唯一字段值怎么办？您不能只将其传递给地图。您必须遍历键并检查，这意味着使用 DefinedData 中每个字段的查找方法包装地图。可行，但不是最漂亮的东西，特别是如果 Map 中有很多值和很多查找，这是可能的。要么是这样，要么需要查找 DefinedData 对象，这又是一堆地图......

这几乎听起来像是数据库的工作（根据任何列查找），但这不是解决这个特定问题的好方法。我还宁愿避免使用十几个不同的 Map，每个 Map 都将一个字段从 DefinedData 映射到 Object。我见过的多键映射不适用，因为它们需要所有键值，而不仅仅是一个。是否有可以处理此特定问题的 Map、Collections 或其他实现？

在查询同一文档的两个字段时，我创建了 4 个索引来测试我的集合中的查询性能，其中一个是数组（需要多键索引）。其中两个索引是单一的和两个复合的。

我很惊讶，因为使用单个索引之一比使用复合索引获得更好的性能。我期望使用复合索引获得最佳性能，因为我知道它索引两个字段允许更快的查询。

这些是我的索引：

我的查询和性能指标是（提示参数显示每个查询使用的索引）：

问题 1：

毫：237

已扫描：101226

问题 2：

米斯：1131

已扫描：306715

问题 3：

毫：935

已扫描：306715

问题 4：

毫：1165

已扫描：306715

QUERY 1 扫描的文档更少，可能是什么原因会更快。有人可以帮我理解为什么它比使用复合索引的查询执行得更好吗？因此，什么时候使用复合索引比使用单一索引更好？

我正在阅读 mongo 文档，但这些概念让我难以消化。

提前致谢。

更新的问题（回应 Sammaye 和 Philipp）

这是一个完整的解释（）的结果

对于以下查询：

I want to design a model for profiles interaction, for example A <-> interact <-> B , the interaction contains common fields for A and B.
Lets say I have collection called Interactions, I have few thoughts in mind and I am looking for the best practice solution.

1. separate the interaction to two different documents, one for each profile
   

   pros: fast read
   cons: each update for the common field should be performed on both of the documents

2. maintain one document for the interaction

   pros: update the common field only once
   cons: tricky read

The thing is there are a lot of reading but also a lot of updating and this collection should be designed for a lot of millions of documents.

common queries in my scenarios:

• retrieve profile interactions
• update specific profile interaction

I am leaning to the second choice where I will be relying on Multikey index on the pids for fast document lookup and I will be enjoying in single update in each frequent change.

I have no experience in sharded collections but I have noticed Multikey index is not supported as sharding key, should it be a show stopper for the second choice?
does the reads will be fast enough with that kind of index? and are they any other choices for my use case?

your answer is highly appreciated.

我正在尝试做的事情对我来说听起来合乎逻辑，但我不确定。

我正在尝试通过使用 Multikeys 来改进 MongoDB 集合的一部分。

例如：我有多个具有以下格式的文档：

文档：

查询：
到目前为止，我一直在使用以下查询来匹配该tags字段。

这一直运作良好，但是我认为在这种情况下应该使用 Multikeys 来提高速度和性能。如果我错了，请纠正我！

索引：
我发出了以下命令，试图索引tags.

ensureIndex那是成功的。

结果：
但是在explain上述查询中使用 RockMongo 的功能时，结果是：

问题：

1. 为什么索引不起作用，我还有其他事情要做吗？
2. 在这种情况下，多键索引是否有益？（我假设是的。）
3. 是否有另一种形式的索引会更有益？

编辑：
我刚刚注意到在 RockMongoexplain数据中有一个字段： "isMultiKey": true,
是否正在使用 Multikeys 并且我完全误解了它正在被索引？

我有一个像下面这样的集合。我想索引“位置”和“product_list.id”。MongoDB 似乎只允许在文档中使用单个多键索引。任何可能的解决方法？

我正在使用 pygame 制作游戏，但遇到以下代码问题：

当我按住 TOP 箭头或 DOWN 箭头时，如果我按任何左右键，什么都不会发生，elif 不会解析。为什么 ？我应该这样做吗？

如果我用“if”替换所有“elif”，则会发生相反的情况。如果我按住左或右，上下将永远无法解决。

我想了解那个奇怪的机制。

我有一组具有两个属性的元素，名称（字符串，非唯一）和ID（整数，唯一）。所有具有相同名称的元素都存储在一起，并根据某些标准进行排序。

插入只需完成一次，因为所有元素都是预先知道的，因此可以轻松完成。删除是根据顺序（第一个）或最终的 id 完成的。读取这些值将是最常见（和相关）的操作。

性能是对数据结构的最高要求。我认为多键、链接数据结构或混合哈希图/堆栈是理想的，但我知道不是。我考虑的一些选项是： - Guava 表（多个键），但它们没有推送/弹出行为。- LinkedHashMaps，但它们只有一个键。

当然，对于必须根据 id 删除元素的情况，我可以使用 LinkedHasMaps 并迭代删除。我只是想知道是否有一些已经实现了高性能的东西。

有什么建议么？

谢谢大家