在 3.0 之前,sstable2json是一个有用的实用程序,可用于了解数据在 SSTable 中的组织方式。此功能目前在 cassandra 3.0 中不存在,但最终会有替代方案。在那之前,我和 Chris Lohfink 已经为 Cassandra 3.0 开发了 sstable2json ( sstable-tools ) 的替代方案,您可以使用它来了解数据的组织方式。在CASSANDRA-7464中有一些关于将其引入 cassandra 的讨论。
Cassandra 和 Cassandra 3.0 的旧版本之间的存储格式之间的一个关键区别在于,SSTable 以前是分区及其单元格(由它们的集群和列名标识)的表示,而在 Cassandra 3.0 中,SSTable 现在表示分区及其行。
您可以通过访问这些更改的主要开发人员的这篇博客文章来更详细地了解这些更改,他在详细解释这些更改方面做得很好。
您将看到的最大好处是,在一般情况下,您的数据大小会缩小(在某些情况下会缩小很多),因为 CQL 引入的许多开销已被一些关键增强功能消除。
这是一个显示 C* 2 和 3 之间差异的示例。
架构:
create keyspace demo with replication = {'class': 'SimpleStrategy', 'replication_factor': 1};
use demo;
create table phonelists (user text, person text, phonenumbers text, primary key (user, person));
insert into phonelists (user, person, phonenumbers) values ('scott', 'bill', '555-7382');
insert into phonelists (user, person, phonenumbers) values ('scott', 'jane', '555-8743');
insert into phonelists (user, person, phonenumbers) values ('scott', 'patricia', '555-4326');
insert into phonelists (user, person, phonenumbers) values ('john', 'doug', '555-1579');
insert into phonelists (user, person, phonenumbers) values ('john', 'patricia', '555-4326');
sstable2json C* 2.2 输出:
[
{"key": "scott",
"cells": [["bill:","",1451767903101827],
["bill:phonenumbers","555-7382",1451767903101827],
["jane:","",1451767911293116],
["jane:phonenumbers","555-8743",1451767911293116],
["patricia:","",1451767920541450],
["patricia:phonenumbers","555-4326",1451767920541450]]},
{"key": "john",
"cells": [["doug:","",1451767936220932],
["doug:phonenumbers","555-1579",1451767936220932],
["patricia:","",1451767945748889],
["patricia:phonenumbers","555-4326",1451767945748889]]}
]
sstable-tools toJson C* 3.0 输出:
[
{
"partition" : {
"key" : [ "scott" ]
},
"rows" : [
{
"type" : "row",
"clustering" : [ "bill" ],
"liveness_info" : { "tstamp" : 1451768259775428 },
"cells" : [
{ "name" : "phonenumbers", "value" : "555-7382" }
]
},
{
"type" : "row",
"clustering" : [ "jane" ],
"liveness_info" : { "tstamp" : 1451768259793653 },
"cells" : [
{ "name" : "phonenumbers", "value" : "555-8743" }
]
},
{
"type" : "row",
"clustering" : [ "patricia" ],
"liveness_info" : { "tstamp" : 1451768259796202 },
"cells" : [
{ "name" : "phonenumbers", "value" : "555-4326" }
]
}
]
},
{
"partition" : {
"key" : [ "john" ]
},
"rows" : [
{
"type" : "row",
"clustering" : [ "doug" ],
"liveness_info" : { "tstamp" : 1451768259798802 },
"cells" : [
{ "name" : "phonenumbers", "value" : "555-1579" }
]
},
{
"type" : "row",
"clustering" : [ "patricia" ],
"liveness_info" : { "tstamp" : 1451768259908016 },
"cells" : [
{ "name" : "phonenumbers", "value" : "555-4326" }
]
}
]
}
]
虽然输出更大(这更多是工具的结果)。您可以看到的主要区别是:
- 数据现在是分区及其行(包括单元格)的集合,而不是分区及其单元格的集合。
- 时间戳现在位于行级别 (liveness_info) 而不是单元级别。如果某些行单元格的时间戳不同,则新的存储引擎会执行增量编码以节省空间并在单元格级别关联差异。这也包括 TTL。正如您可以想象的那样,如果您有很多非键列,因为不需要重复时间戳,这会节省大量空间。
- 聚类信息(在这种情况下,我们在“人”上进行聚类)现在出现在行级别而不是单元级别,这节省了一堆开销,因为聚类列值不必在单元级别。
我应该注意到,在这个特定的示例数据案例中,新存储引擎的好处并没有完全实现,因为只有 1 个非集群列。
此处未显示许多其他改进(例如存储行级范围墓碑的能力)。