当行只写一次时，分层压缩策略对读取仍然有益吗

Question

在其他情况下，这篇数据税帖子说，当行只写一次时，压缩可能不是一个好的选择:

如果您的行总是一次完全写入，并且从未更新，那么在使用大小分层压缩时，它们自然总是包含在一个SSTable中。因此，平整压实实际上没有任何好处。

此外，在演讲《水平压实策略的缺失手册》(Wei Deng和Ryan Svihla)幻灯片30中，它说LCS最适合的地方

需要具有更高读写比的非常一致的读取性能的用例

宽分区数据模型，总分区数量有限(或增长缓慢)，但有大量更新和删除，或完全TTL'ed数据集

我知道，如果频繁更新或删除一行，它可能会出现在多个SST表中，因此这将影响读取性能。从Apache Cassandra 中的水平压缩

性能可能不一致，因为无法保证一行可以分布多少个sstable：在最坏的情况下，我们可能在每个sstable中都有来自给定行的列。

但是，在行写一次的情况下，当按分区键的所有行读取时，此策略也不代表什么好处？

因为如果我理解正确的话，使用此策略，具有相同分区键的行往往位于同一个SSTables中，因为合并重叠的SSTables与合并具有相似大小的SSTables的Size Tiered Compact形成对比。

Answer 1

当行被严格写入一次时，在读取性能方面，选择LeveledCompactionStrategy而不是SizeTieredCompactionStrategy没有影响(还有其他影响，例如LCS需要更多IO)

关于问题的以下评论

使用此策略，具有相同分区键的行往往位于相同的SSTable，因为合并了与大小分层压缩，将具有类似大小的SSTables合并在一起

当具有相同分区键的行只写一次时，就不存在合并SSTables的情况，因为它最初并没有分布在不同的SSTables中。

当我们谈论更新时，它不需要是正在更新的行中的现有列。在这种情况下，我们可能会为已经存在的分区键添加一组完整的新集群列以及相关列。

这是的样品表

CREATE TABLE tablename(
emailid text,
sent-date date,
column3 text,
PRIMARY KEY (emailid,sent-date)
)

现在对于给定的电子邮件ID(比如[e-mail])一个分区键，可以在两次或多次插入不同的"发送日期"。尽管它们是对同一分区键的插入(本质上是追加)，因此LeveledCompact在这里会受益。

但假设同一个表只有emailid作为主键，并且只写一次。然后，无论SSTables是如何压缩的，无论是SizeTieredCompactionStrategy还是LeveledCompactionStrategy，都没有任何优势，因为行总是只存在于一个SSTables上。

Answer 2

我认为，当博客谈论一行时，它指的是Thrift行，而不是CQL行。(我不是唯一混淆这些术语的人)

当我们说Thrift行时，我们谈论的是一个分区(或一组具有相同分区键的CQL行)。来自CQL是否支持动态列/宽行？

+--------------------------------------------------+-----------+
|                   Thrift term                    | CQL term  |
+--------------------------------------------------+-----------+
| row                                              | partition |
| column                                           | cell      |
| [cell name component or value]                   | column    |
| [group of cells with shared component prefixes]  | row       |
+--------------------------------------------------+-----------+

从理解CQL3如何映射到Cassandra的内部数据结构使用以下模式

CREATE TABLE tweets (
... user text,
... time timestamp,
... tweet text,
... lat float,
... long float,
... PRIMARY KEY (user, time)
... );

(记住分区密钥是第一个出现在主键中的，在这种情况下是"用户")

以下CQL行

user         | time                     | lat    | long    | tweet
--------------+--------------------------+--------+---------+---------------------
softwaredoug | 2013-07-13 08:21:54-0400 | 38.162 | -78.549 |  Having chest pain.
softwaredoug | 2013-07-21 12:15:27-0400 | 38.093 | -78.573 |   Speedo self shot.
jnbrymn | 2013-06-29 20:53:15-0400 | 38.092 | -78.453 | I like programming.
jnbrymn | 2013-07-14 22:55:45-0400 | 38.073 | -78.659 |     Who likes cats?
jnbrymn | 2013-07-24 06:23:54-0400 | 38.073 | -78.647 |  My coffee is cold.

像这个一样在Thrift内部持久存在

RowKey: softwaredoug
=> (column=2013-07-13 08:21:54-0400:, value=, timestamp=1374673155373000)
=> (column=2013-07-13 08:21:54-0400:lat, value=4218a5e3, timestamp=1374673155373000)
=> (column=2013-07-13 08:21:54-0400:long, value=c29d1917, timestamp=1374673155373000)
=> (column=2013-07-13 08:21:54-0400:tweet, value=486176696e67206368657374207061696e2e, timestamp=1374673155373000)
=> (column=2013-07-21 12:15:27-0400:, value=, timestamp=1374673155407000)
=> (column=2013-07-21 12:15:27-0400:lat, value=42185f3b, timestamp=1374673155407000)
=> (column=2013-07-21 12:15:27-0400:long, value=c29d2560, timestamp=1374673155407000)
=> (column=2013-07-21 12:15:27-0400:tweet, value=53706565646f2073656c662073686f742e, timestamp=1374673155407000)
-------------------
RowKey: jnbrymn
=> (column=2013-06-29 20:53:15-0400:, value=, timestamp=1374673155419000)
=> (column=2013-06-29 20:53:15-0400:lat, value=42185e35, timestamp=1374673155419000)
=> (column=2013-06-29 20:53:15-0400:long, value=c29ce7f0, timestamp=1374673155419000)
=> (column=2013-06-29 20:53:15-0400:tweet, value=49206c696b652070726f6772616d6d696e672e, timestamp=1374673155419000)
=> (column=2013-07-14 22:55:45-0400:, value=, timestamp=1374673155434000)
=> (column=2013-07-14 22:55:45-0400:lat, value=42184ac1, timestamp=1374673155434000)
=> (column=2013-07-14 22:55:45-0400:long, value=c29d5168, timestamp=1374673155434000)
=> (column=2013-07-14 22:55:45-0400:tweet, value=57686f206c696b657320636174733f, timestamp=1374673155434000)
=> (column=2013-07-24 06:23:54-0400:, value=, timestamp=1374673155485000)
=> (column=2013-07-24 06:23:54-0400:lat, value=42184ac1, timestamp=1374673155485000)
=> (column=2013-07-24 06:23:54-0400:long, value=c29d4b44, timestamp=1374673155485000)
=> (column=2013-07-24 06:23:54-0400:tweet, value=4d7920636f6666656520697320636f6c642e, timestamp=1374673155485000)

我们清楚地看到，带有用户软件bug的2个CQL行是一个单独的Thrift行。

单个CQL行对应于单个Thrift行的情况(例如，当分区密钥==主键时)是Deng和Svihla所指示的，类似于LCS 的反模式用例

所有唯一分区的重写

然而，我会将dilsingi的答案标记为正确的，因为我认为他已经知道这种关系。