Cassandra UDT作为主键 [英] Cassandra UDTs as primary key

问题描述

官方文档告诉我们不要为主键使用UDT。这有什么特别的原因吗？这样做的潜在缺点是什么？

The official documentation tells us to not use UDTs for primary keys. Is there a particular reason for this? What would the potential downsides be in doing this?

推荐答案

这句话旨在阻止用户不加区别地使用UDT的PK列。 UDT在其当前化身（也就是说，Cassandra支持冻结UDT）的主要动机是在集合中存储更复杂的值。外部集合，UDT可以有它的用途，但它是值得问自己两次，如果你需要它。例如：

That sentence was intended to discourage users from using UDT for PK columns indiscriminately. The main motivation for UDT in it's current incarnation (that is, given that Cassandra supports the "frozen" UDT) is for storing more complex values inside collections. Outside collections, UDT can have it's uses, but it's worth asking yourself twice if you need it. For example:

CREATE TYPE myType（a text，b int）;

CREATE TABLE myTable（id uuid PRIMARY KEY，v frozen< myType>）;

通常不是很明智，因为你失去更新va而不更新vb的能力所以它实际上更灵活直接做：

is often not very judicious in that you lose the ability of updating v.a without also updating v.b. So that it's actually more flexible to directly do:

CREATE TABLE myTable（id uuid PRIMARY KEY，a text，b int）;

这个简单的例子指出，集合之外的UDT不一定是好事，这也扩展到主键列。这不一定更好：

This trivial example points out that UDT outside of collections is not necessarily a good thing, and this also extends to primary key columns. It's not necessarily better to do:

CREATE TYPE myType（a text，b int）;

CREATE TABLE myTable（id frozen< myType> PRIMARY KEY）;

CREATE TABLE myTable（a text，b int，PRIMARY KEY（（a，b）））

此外，关于主键，任何复杂的UDT都可能没有意义。甚至考虑一个中等复杂的类型，如：

Furthermore, regarding the primary key, any complex UDT probably doesn't make sense. Consider even a moderately complex type like:

CREATE TYPE地址（
数字int，
街道文本，
city text，
phones set< text>
）

不是非常有用，因为PK识别行，因此除了电话的集合将不识别相同的行之外的相同的2个地址是相同的。没有很多情况下这是可取的。更一般来说，PK往往相对简单，并且您可能希望对聚簇列进行精细控制，因此UDT很少是很好的候选者。

Using such a type inside a primary key almost surely isn't very useful since the PK identifies rows and so 2 addresses that are the same except for the set of phones wouldn't identify the same row. There are not many situations where that would be desirable. More generally, a PK tends to be relatively simple, and you might want to have fine-grained control over the clustering columns, and so UDT are rarely good candidates.

在摘要，PK列中的UDT不总是错误的，只是在上下文中不常用，因此用户不应仅仅因为允许而对使用UDT的PKT列的方法进行努力。

In summary, UDT in PK columns are not always a bad, just not often useful in that context, and so users should not be looking hard at ways to use UDT for PK columns just because it's allowed.

这篇关于Cassandra UDT作为主键的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！