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 freeze);

通常不是很明智，因为您失去了更新 v.a 而不更新 v.b 的能力.这样直接做实际上更灵活:

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 freeze 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:

创建类型地址(数字整数，街头文字，城市文字，手机设置<文本>)

在主键中使用这样的类型几乎肯定不是很有用，因为 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 并不总是不好，只是在该上下文中不经常有用，因此用户不应该仅仅因为它允许.

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屋！