在 Cassandra 中使用 UUID 作为 URL 表的辅助键的可行性答案

【问题标题】：Feasability of using UUID as a secondary key for a table of URL's in Cassandra在 Cassandra 中使用 UUID 作为 URL 表的辅助键的可行性
【发布时间】：2017-08-26 02:49:31
【问题描述】：

给定一个分布式系统，它使用主键为“url”来持久化记录。鉴于多个服务器正在收集数据，“url”是一种方便/方便且准确的保证唯一性的方法。目前，我们的系统每分钟查询文档的频率高达 10,000 次。

我们想添加另一个唯一键，作为“uuid”，以便我们可以将资源称为：

http://example.com/fju98hfhsiu

而不是，例如：

http://example.com/?u=http%3A%2F%2Fthis.is.a.long.url.com%2Fthis_is%2Fa%2Fpagewitha%2Flong-url.html

似乎创建了 UUID 的is not ideal in cassandra 的二级索引。有什么方法可以避免在 cassandra 中创建 UUID 的二级索引？

【问题讨论】：

标签： database database-design cassandra

【解决方案1】：

让我们从一个事实开始，Cassandra 的最佳实践和主要模式是为查询创建表，而不是为表查询，如果您需要在表上创建索引，这是“自动”反模式。基于此，最简单的解决方案就是使用 2 个表和 2 个键。

在您的情况下，“uuid”不是 UUID，它是域和哈希的一些串联，我相信 URL 的其余部分。如果您的应用程序可以在请求时生成此密钥，您可以将其用作分区键，并将完整 URL 用作集群键。

另外，如果没有热域（例如http://example.com），您可以使用域作为分区键，将哈希和长url作为集群键，创建物化视图以支持不同的查询。

最后，只需添加二级索引并查看特定情况下的性能影响。如果它适合您，并且您不想处理 2 个表格、物化视图等，请使用它。

【讨论】：