Cassandra 中的数据建模，列可以是文本或数字

Posted 2023-04-18

【中文标题】Cassandra 中的数据建模，列可以是文本或数字

【英文标题】：data modeling in Cassandra with columns that can be text or numbers

【发布时间】：2015-06-20 19:26:16

【问题描述】：

我有 5 列的表格。

    1. ID -  number but it can stored as text or number
    2. name - text
    3. date - date value but can stored as date or text
    4. time - number but it can stored as text or number
    5. rating - number but it can stored as text or number

我想找出哪种数据类型可以让我的表更快地写入。我怎么能找到。那里有任何 Cassandra 压力 yaml 吗？

【问题讨论】：

查看这些类似问题的答案：***.com/questions/28191761/… 和 ***.com/questions/21360688/…

任何 cassandra 压力 2.1 示例？一年前的帖子。

【参考方案1】：

关于@BryceAtNetwork23 提供的answer，它与Cassandra 2.1 或Cassandra 2.2 中的情况相同（但Cassandra 3.0 可能会有所不同，因为团队目前正在重写存储引擎，请参阅CASSANDRA-8099）。存储的数据仍然以二进制形式存储。

但是还有更多要说的。您可能需要考虑存储的实际数据、项目需要达到的性能、每秒查询次数等。

根据这些目标或约束，一个有趣的方法是查看给定type on cassandra 的序列化数据的大小。

1234563一个普通的副本就可以了。这还有一个好处是密钥足够小，因此它不会强调 cassandra 密钥缓存。

如果数据是一段文本，例如 Java 中的 String，它在运行时以 UTF-16 编码，但在 Cassandra 中以 text 类型序列化时，则使用 UTF-8。 每个字符 UTF-16 总是使用 2 个字节，有时使用 4 个字节，但 UTF-8 节省空间，并且根据字符可以是 1、2、3 或 4 个字节长。

这意味着有 CPU 工作来序列化此类数据以用于编码/解码目的。同样取决于文本，例如158786464563，数据将以 12 个字节存储。这意味着使用更多空间和更多 IO。

注意 cassandra 提供遵循 US-ASCII 字符集的 ascii 类型，并且始终使用 1 byte per character。

1234563 987654325@)。

同样，这始终取决于您的项目的里程、目标是什么、现有的限制。但这是我的未受过教育选项：

如果要插入的数据始终是一个在[−9,223,372,036,854,775,808 ; +9,223,372,036,854,775,807] 范围内的数字，我将得到bigint 类型 UUID 没问题 如果集群不是处于重负载（例如每秒 100k 查询）并且空间不是问题，那么 text 不是问题，但如果是或者如果使用量可能增加，我会避免使用 text如果可能，请输入密钥。

另一种选择是使用blob 类型，即二进制类型，可以根据软件的业务以您想要的方式使用任何数据。这可以实现空间高效、IO 高效存储，以及 CPU 高效。但是根据需要，可能需要在客户端代码中管理很多事情，例如排序、序列化、比较、映射等......