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

Roo*_*ehn 1 cassandra datastax-enterprise

我有 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
Run Code Online (Sandbox Code Playgroud)

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

Bri*_*ice 5

关于@BryceAtNetwork23 提供的答案,它将与 Cassandra 2.1 或 Cassandra 2.2 相同(但 Cassandra 3.0 可能是一个不同的故事,因为团队目前正在重写存储引擎,请参阅CASSANDRA-8099)。存储的数据仍然以二进制形式存储。

然而,还有更多要说的。并且您可能需要考虑存储的实际数据,以及您的项目需要实现的性能、每秒查询等。

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

  • 如果数据是一个数字,例如longJava 中的 a 大小为 8 字节,则大小与 cassandrabigint类型匹配,这意味着序列化时没有相关成本,纯副本就可以。这还有一个好处,即密钥足够小,因此不会给cassandra 密钥缓存带来压力

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

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

    注意 cassandra 提供ascii遵循 US-ASCII 字符集的类型,并且每个字符始终使用1 个字节

  • 如果数据是一个 UUID(一个 128 位的值),在 Java 中该UUID类型使用 2 longs,所以它是 16 个字节长,并且 Cassandra 也将它们存储为 16 个字节(它们使用 Java UUID 类型)。

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

  • 如果必须插入的数据总是在长范围内的数字[?9,223,372,036,854,775,808 ; +9,223,372,036,854,775,807],我会得到一个bigint类型
  • UUID 没问题
  • 如果集群负载不高(比如每秒 100k 查询)并且空间不是问题,那么text这不是问题,但如果是,或者使用量可能会增长,我会text尽可能避免使用 key。

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