2

我有一个 40 列的 RDBMS 表，我将其移植到 Cassandra。

在http://docs.datastax.com/en/cassandra/2.1/cassandra/planning/architecturePlanningUserData_t.html使用估算器

我创建了一个包含列名、数据类型、每列大小等的 Excel 表。当实际数据只有 192 字节时，每个 RDBMS 行的 Cassandra 特定开销高达 1KB。

由于开销与列数成正比，我认为如果我只为不属于主键的字段创建一个 UDT 会更好。这样，我只会产生一次列开销。

另外，我不打算对 UDT 的内部字段运行查询。即使我确实想要，Cassandra 在非 PK 字段上的查询功能也非常有限。

这是一个很好的策略吗？有什么陷阱吗？所有这些开销都可以通过压缩或其他一些内部操作轻松消除吗？

4

1 回答 1

2

从表面上看，这根本不是一个坏主意。您本质上是在另一个层次上抽象您的数据，但在某种程度上它仍然可以满足您的需求。其实是很好的想法。

我有一个 40 列的 RDBMS 表

这部分让我有点担心。本质上，您将创建一个具有 40 个属性的 UDT。本身并没有什么大不了的。Cassandra 应该处理得很好。

但是，虽然您可能不会查询 UDT 的内部字段，但您需要问自己计划多久更新一次它们。Cassandra 将 UDT 作为“冻结”类型存储在单个列中。理解这一点很重要，原因有两个：

  1. 如果不读取 UDT 的所有属性，则无法读取 UDT 的单个属性。
  2. 同样，您也无法在不重写所有属性的情况下更新 UDT 中的单个属性。

因此，您在设计应用程序时应牢记这一点。只要您不会频繁更新 UDT 的各个属性，这对您来说应该是一个很好的解决方案。

于 2015-10-20T20:14:17.397 回答