问题标签 [secondary-indexes]

我浏览了 Mnesia 文档和 3 本流行的 Erlang 书籍。似乎只能创建和使用单列主索引和二级索引。或者也许这正是示例所涵盖的内容？如果我在每一列上创建一个单独的索引，Mnesia 是否能够智能地一起使用它们来模拟多列键索引搜索？如果是这样，性能会比简单的表扫描好得多吗？

如果 Mnesia 不支持多列索引，那么考虑到它的原生 dbms 是否有人在 Erlang 中模拟了这个功能。

第二个问题：如何模拟约束（引用、检查）、触发器和基于事件的通知？

我正在关注如何使用 Thrift API 在 cassandra db 中的新列或现有列上创建二级索引的任何示例。围绕 Thrift 的文档非常稀少。有谁能帮帮兄弟吗？

我想知道的第二个问题是：使用 phpcassa 作为 cassandra 的接口是否有任何负面影响。我的理解是它位于 Thrift 之上，所以这种情况是否存在任何性能缺陷？

我正在使用 Cassandra 0.8、Thrift 2.0 和 php 5.2.9。

我正在使用由 2 个字符串 Name1、Name2 和时间戳组成的复合主键（例如，'Joe:Smith:123456'）。我想查询给定相等条件的时间戳范围Name1或Name2。

例如，在 SQL 中：

SELECT * FROM testcf WHERE (timestamp > 111111 AND timestamp < 222222 and Name2 = 'Brown');

和

SELECT * FROM testcf WHERE (timestamp > 111111 AND timestamp < 222222 and Name1 = 'Charlie);

据我了解，复合键的第一部分是分区键，所以第二个查询是可能的，但第一个查询需要 Name2 上的某种索引。

是否可以在复合键的组件上创建单独的索引？或者我在这里误解了什么？

我们知道在传统的 RDBMS 系统中有主键的概念。此主键基本上用于在此特定键上为表中的记录建立索引，以便更快地检索。我知道有像 Cassandra 这样的 NOSQL 存储提供辅助键索引，但是有一种方法或现有的 DB 遵循与传统 RDBMS 系统完全相同的模式（即，将 DB 拆分为各种表以保存不同类型的数据）但是提供 2 个或更多键的索引。

一个用例的例子是：

10 个不同的人的姓名和年龄之间存在一对一的映射关系。现在，如果我将这些信息保存在一个以人名作为主键的表中，那么检索给定人名的年龄比检索给定人年龄的姓名要快。如果我可以索引这两列，那么第二种情况也会更快。使用传统 RDBMS 执行此操作的另一种方法是让 2 个表具有相同的数据，不同之处在于其中一个中的主键是名称，而另一个中的主键是年龄，但这会浪费在大量记录的情况下占用大量空间。

有没有办法在 OrientDB 中指定二级索引？

我需要具有所有具有指定字段（例如indexable=true）的文档引用的东西。

我想制作一个有效的复合键来处理WHERE具有多个条件的查询，例如：

对于这个查询，制作专辑、艺术家和标题二级索引是否有意义？使其中的 3 个二级索引是多余的吗？一个二级索引（在这种情况下最常见的是艺术家列）就足够了吗？

我需要创建一个表，其中包含由连续运行的进程生成的数据片段。此过程生成包含两个必需组件的消息，其中包括：全局唯一消息 UUID 和消息时间戳。

这些消息稍后将由 UUID 检索。

此外，我需要定期从该表中删除所有太旧的消息，即时间戳与当前时间相差超过 X 的消息。

我一直在阅读 DynamoDB v2 文档（例如Local Secondary Indexes），试图弄清楚如何组织我的表以及是否需要二级索引来搜索要删除的消息。我的问题可能有一个简单的答案，但我有点困惑......

那么我是否应该创建一个表，其中 UUID 作为哈希，messageTimestamp 作为范围键（连同包含实际消息的“消息”属性），然后不创建任何二级索引？在我看到的示例中，哈希值不是唯一的（例如，上述链接下的 ForumName）。在我的情况下，哈希将是唯一的。我不确定这是否有任何区别。

如果我按照所述创建具有哈希和范围的表，并且没有二级索引，那么我将如何查询特定时间范围内的所有消息，而不管它们的 UUID 是什么？

我正在将我的持久层从 Riak 迁移到 DynamoDB。我的数据模型包含一个可选的业务标识符字段，希望能够作为键的替代项进行查询。

似乎 DynamoDB 二级索引不能null并且需要范围键，因此尽管名称与 Riak 的二级索引相似，但它看起来是完全不同的野兽。

有没有一种优雅的方法可以有效地查询我的可选字段，而不是将数据放入外部搜索索引中？

我想知道 Cassandra 的二级索引与 DSE 放在 CF 上的 solr 索引的性能差异。

我们有一些没有放置二级索引的 CF，因为我们的印象是二级索引会（最终）导致重读/写 CF 的重大性能问题。我们正试图转向 Solr 以允许搜索这些 CF，但看起来加载索引模式会修改 CF 以在感兴趣的列上具有二级索引。

想知道 Solr 索引是否不同于 Cassandra 的二级索引？并且，它最终是否会导致带有大型数据集和大量读/写的 CF 的缓慢查询（插入/读取）？如果是这样，您会建议自定义索引（我们想避免）吗？顺便说一句——我们也在使用（尝试使用）Solr 进行空间搜索。

感谢您提供的任何建议/链接。

更新：为了更好地理解我为什么要问这些问题，并看看我是否在问正确的问题——我们用例的描述：

我们正在收集传感器事件——很多！我们将它们存储在时间序列 CF (EventTL) 和瘦 CF (Event) 中。因为我们在 Event CF 中大量写入（插入和更新），所以我们没有放置任何二级索引。我们现在的查询仅限于通过 Event 的单个事件或通过 EventTL 的事件时间范围（除非我们创建额外的胖 CF 以允许对事件的其他属性进行范围查询）。

这就是 DSE (Solr+Cassandra) 可以帮助我们的地方。我们认为利用 Solr 搜索将允许我们避免创建额外的胖 CF 以允许搜索事件的其他属性，并允许我们一次搜索多个属性（位置 + 文本/属性）。但是，通过 Solr 添加 Event 的索引模式后，查看 Event CF 的定义如何变化表明二级索引已创建。这导致了这些索引是否会为在 Event 中插入/更新行（最终）产生问题的问题。我们需要能够“快速”插入新事件——因为事件可能以每秒 1000+ 的速度进入。

我们有一个大约 40k 行的表，查询二级索引很慢（生产时需要 30 秒）。我们的 cassandra 是 1.2.8。表架构如下：

当我打开跟踪时，我注意到有很多行如下：

只有 40k 行，看起来 usertask_ts_idx 上有数千个查询。可能是什么问题呢？谢谢

更多调查

我在我们的测试服务器上尝试相同的查询，它要快得多（产品上 30 秒，测试服务器上 1-2 秒）。比较跟踪日志后，差异是在数据文件中寻找分区索引部分所花费的时间。在我们的生产环境中，每次搜索需要 1000-3000 微秒，在开发服务器上需要 100 微秒。我猜我们的生产服务器没有足够的内存来缓存数据文件，因此在数据文件中查找速度很慢。