在 3.0 之前，sstable2json 是一个有用的实用程序，可用于了解数据在 SSTables 中的组织方式。此功能目前在 cassandra 3.0 中不存在，但最终会有替代方案。在那之前，我和 Chris Lohfink 已经为 Cassandra 3.0 开发了 sstable2json (sstable-tools) 的替代方案，您可以使用它来了解数据的组织方式。在 CASSANDRA-7464 中有一些关于将其引入 cassandra 的讨论。
旧版本 Cassandra 和 Cassandra 3.0 的存储格式之间的一个关键区别在于，SSTable 以前是分区及其单元格（由它们的集群和列名标识）的表示，而在 Cassandra 3.0 中，SSTable 现在表示分区和他们的行。
您可以通过访问blog post 来更详细地了解这些更改，这些更改的主要开发人员在详细解释这些更改方面做得很好。
您将看到的最大好处是，在一般情况下，您的数据大小会缩小（在某些情况下会缩小很多），因为 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 个非集群列。
这里没有显示许多其他改进（例如存储行级范围墓碑的能力）。