常见 Cassandra 数据类型的字节大小是多少 - 计算分区磁盘使用量时要使用?
What is the byte size of common Cassandra data types - To be used when calculating partition disk usage?
我正在尝试使用 Datastax Academy 数据建模课程中的公式计算具有任意数量的列和类型的 table 中每一行的分区大小。
为此,我需要了解一些常见 Cassandra 数据类型的 "size in bytes"。我尝试 google 这个,但我收到了很多建议,所以我很困惑。
我想知道字节大小的数据类型是:
- 一个 Cassandra TEXT 字符(我 googled 从 2 - 4 个字节回答)
- 卡桑德拉十进制
- 一个Cassandra INT(我想是4个字节)
- 一个Cassandra BIGINT(我想是8个字节)
- 一个 Cassandra BOOELAN(我想它是 1 个字节,.. 或者它是一个位)
关于 Cassandra 中数据类型大小的任何其他考虑当然也会受到赞赏。
添加更多信息,因为我只是想估计 "worst scenario disk usage" 数据在没有 Cassandra 在幕后完成的任何压缩和其他优化的情况下会占用多少,这似乎令人困惑。
我正在学习 Datastax Academy 课程 DS220(请参阅末尾的 link)并实施公式,并将使用此处答案中的信息作为该公式中的变量。
https://academy.datastax.com/courses/ds220-data-modeling/physical-partition-size
估计与某事相关的开销的唯一可靠方法是实际执行措施。真的,您不能对 单一 数据类型进行概括。如果您有 4 bigint
列并且您假设您的开销是 X,如果您有 400 bigint
列,您的开销可能不会是 100 倍。这是因为 Cassandra 在将数据存储到磁盘之前压缩(默认情况下,每个列族的设置 tunable)。
尝试在集群中加载一些数据,我的意思是生产数据,然后让我们知道您的结果和压缩配置。你会发现一些惊喜。
了解您的数据。
我认为,从务实的角度来看,在设计时使用 ds220 课程 up-front 中的公式对最坏情况进行 back-of-the-envelope 估计是明智的。压缩效果通常因数据中的算法和模式而异。来自 ds220 和 http://cassandra.apache.org/doc/latest/cql/types.html:
uuid: 16 bytes
timeuuid: 16 bytes
timestamp: 8 bytes
bigint: 8 bytes
counter: 8 bytes
double: 8 bytes
time: 8 bytes
inet: 4 bytes (IPv4) or 16 bytes (IPV6)
date: 4 bytes
float: 4 bytes
int 4 bytes
smallint: 2 bytes
tinyint: 1 byte
boolean: 1 byte (hopefully.. no source for this)
ascii: equires an estimate of average # chars * 1 byte/char
text/varchar: requires an estimate of average # chars * (avg. # bytes/char for language)
map/list/set/blob: an estimate
希望对您有所帮助
我正在尝试使用 Datastax Academy 数据建模课程中的公式计算具有任意数量的列和类型的 table 中每一行的分区大小。
为此,我需要了解一些常见 Cassandra 数据类型的 "size in bytes"。我尝试 google 这个,但我收到了很多建议,所以我很困惑。
我想知道字节大小的数据类型是:
- 一个 Cassandra TEXT 字符(我 googled 从 2 - 4 个字节回答)
- 卡桑德拉十进制
- 一个Cassandra INT(我想是4个字节)
- 一个Cassandra BIGINT(我想是8个字节)
- 一个 Cassandra BOOELAN(我想它是 1 个字节,.. 或者它是一个位)
关于 Cassandra 中数据类型大小的任何其他考虑当然也会受到赞赏。
添加更多信息,因为我只是想估计 "worst scenario disk usage" 数据在没有 Cassandra 在幕后完成的任何压缩和其他优化的情况下会占用多少,这似乎令人困惑。
我正在学习 Datastax Academy 课程 DS220(请参阅末尾的 link)并实施公式,并将使用此处答案中的信息作为该公式中的变量。
https://academy.datastax.com/courses/ds220-data-modeling/physical-partition-size
估计与某事相关的开销的唯一可靠方法是实际执行措施。真的,您不能对 单一 数据类型进行概括。如果您有 4 bigint
列并且您假设您的开销是 X,如果您有 400 bigint
列,您的开销可能不会是 100 倍。这是因为 Cassandra 在将数据存储到磁盘之前压缩(默认情况下,每个列族的设置 tunable)。
尝试在集群中加载一些数据,我的意思是生产数据,然后让我们知道您的结果和压缩配置。你会发现一些惊喜。
了解您的数据。
我认为,从务实的角度来看,在设计时使用 ds220 课程 up-front 中的公式对最坏情况进行 back-of-the-envelope 估计是明智的。压缩效果通常因数据中的算法和模式而异。来自 ds220 和 http://cassandra.apache.org/doc/latest/cql/types.html:
uuid: 16 bytes
timeuuid: 16 bytes
timestamp: 8 bytes
bigint: 8 bytes
counter: 8 bytes
double: 8 bytes
time: 8 bytes
inet: 4 bytes (IPv4) or 16 bytes (IPV6)
date: 4 bytes
float: 4 bytes
int 4 bytes
smallint: 2 bytes
tinyint: 1 byte
boolean: 1 byte (hopefully.. no source for this)
ascii: equires an estimate of average # chars * 1 byte/char
text/varchar: requires an estimate of average # chars * (avg. # bytes/char for language)
map/list/set/blob: an estimate
希望对您有所帮助