cassandra，时序表性能不佳答案

【问题标题】：cassandra, bad performance of time series tablecassandra，时序表性能不佳
【发布时间】：2014-04-18 04:56:53
【问题描述】：

我有一个 3x 节点集群（在同一个 16 核机器上，通过 lxc 在虚拟机器中，但每个节点都在它自己的 3TB 磁盘上）。

我的桌子是这样的：

CREATE TABLE history (
 id text,
 idx bigint,
 data bigint,
 PRIMARY KEY (id, idx)
) WITH CLUSTERING ORDER BY (idx DESC)

id 将存储一个字符串 id ， idx 是以毫秒为单位的时间， data 是我的数据。根据我发现的所有示例，这似乎是时间序列数据的正确模式。

我的查询是：

select idx,data from history where id=?限制2

这将返回最近的 2 行（基于 idx）。

由于 id 是分区键而 idx 是集群键，我发现的文档声称这对 cassandra 非常有效。但我的基准测试却不然。

我总共填充了 400GB（分成这 3 个节点），现在我正在从第二个框运行查询。使用 16 或 32 个线程，我正在运行上述查询，但对于在 3 个独立磁盘上运行的 3 个节点，性能确实很低：

throughput: 61         avg time: 614,808 μs
throughput: 57         avg time: 519,651 μs
throughput: 52         avg time: 569,245 μs

因此，每秒约 55 个查询，每个查询需要半秒（有时需要 200 毫秒）

我觉得这真的很低。

谁能告诉我我的架构是否正确，如果不建议架构？如果我的架构是正确的，我怎样才能找到问题所在？

16核机箱上的磁盘IO：

Device:            tps    MB_read/s    MB_wrtn/s    MB_read    MB_wrtn
sda               0.00         0.00         0.00          0          0
sdb             135.00         6.76         0.00          6          0
sdc             149.00         6.99         0.00          6          0
sdd             124.00         7.21         0.00          7          0

每个 cassandra 使用的 CPU 核心不超过 1 个。

编辑：当我对 1 个 id 运行一个简单查询时，我得到很多类似下面的行：

                                            Key cache hit for sstable 33259 | 20:16:26,699 | 127.0.0.1 |           5830
                                 Seeking to partition beginning in data file | 20:16:26,699 | 127.0.0.1 |           5833
                                  Bloom filter allows skipping sstable 33256 | 20:16:26,699 | 127.0.0.1 |           5923
                                  Bloom filter allows skipping sstable 33255 | 20:16:26,699 | 127.0.0.1 |           5932
                                  Bloom filter allows skipping sstable 33252 | 20:16:26,699 | 127.0.0.1 |           5938
                                             Key cache hit for sstable 33247 | 20:16:26,699 | 127.0.0.1 |           5948
                                 Seeking to partition beginning in data file | 20:16:26,699 | 127.0.0.1 |           5951
                                  Bloom filter allows skipping sstable 33246 | 20:16:26,699 | 127.0.0.1 |           6072
                                  Bloom filter allows skipping sstable 33243 | 20:16:26,699 | 127.0.0.1 |           6081
                                             Key cache hit for sstable 33242 | 20:16:26,699 | 127.0.0.1 |           6092
                                 Seeking to partition beginning in data file | 20:16:26,699 | 127.0.0.1 |           6095
                                  Bloom filter allows skipping sstable 33240 | 20:16:26,699 | 127.0.0.1 |           6187
                                             Key cache hit for sstable 33237 | 20:16:26,699 | 127.0.0.1 |           6198
                                 Seeking to partition beginning in data file | 20:16:26,699 | 127.0.0.1 |           6201
                                             Key cache hit for sstable 33235 | 20:16:26,699 | 127.0.0.1 |           6297
                                 Seeking to partition beginning in data file | 20:16:26,699 | 127.0.0.1 |           6301
                                  Bloom filter allows skipping sstable 33234 | 20:16:26,699 | 127.0.0.1 |           6393
                                             Key cache hit for sstable 33229 | 20:16:26,699 | 127.0.0.1 |           6404
                                 Seeking to partition beginning in data file | 20:16:26,699 | 127.0.0.1 |           6408
                                  Bloom filter allows skipping sstable 33228 | 20:16:26,699 | 127.0.0.1 |           6496
                                             Key cache hit for sstable 33227 | 20:16:26,699 | 127.0.0.1 |           6508
                                 Seeking to partition beginning in data file | 20:16:26,699 | 127.0.0.1 |           6511
                                             Key cache hit for sstable 33226 | 20:16:26,699 | 127.0.0.1 |           6601
                                 Seeking to partition beginning in data file | 20:16:26,699 | 127.0.0.1 |           6605
                                             Key cache hit for sstable 33225 | 20:16:26,700 | 127.0.0.1 |           6692
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           6696
                                             Key cache hit for sstable 33223 | 20:16:26,700 | 127.0.0.1 |           6785
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           6789
                                             Key cache hit for sstable 33221 | 20:16:26,700 | 127.0.0.1 |           6876
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           6880
                                  Bloom filter allows skipping sstable 33219 | 20:16:26,700 | 127.0.0.1 |           6967
                                             Key cache hit for sstable 33377 | 20:16:26,700 | 127.0.0.1 |           6978
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           6981
                                             Key cache hit for sstable 33208 | 20:16:26,700 | 127.0.0.1 |           7071
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           7075
                                             Key cache hit for sstable 33205 | 20:16:26,700 | 127.0.0.1 |           7161
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           7166
                                  Bloom filter allows skipping sstable 33201 | 20:16:26,700 | 127.0.0.1 |           7251
                                  Bloom filter allows skipping sstable 33200 | 20:16:26,700 | 127.0.0.1 |           7260
                                             Key cache hit for sstable 33195 | 20:16:26,700 | 127.0.0.1 |           7276
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           7279
                                  Bloom filter allows skipping sstable 33191 | 20:16:26,700 | 127.0.0.1 |           7363
                                             Key cache hit for sstable 33190 | 20:16:26,700 | 127.0.0.1 |           7374
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           7377
                                  Bloom filter allows skipping sstable 33189 | 20:16:26,700 | 127.0.0.1 |           7463
                                             Key cache hit for sstable 33186 | 20:16:26,700 | 127.0.0.1 |           7474
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           7477
                                             Key cache hit for sstable 33183 | 20:16:26,700 | 127.0.0.1 |           7563
                                 Seeking to partition beginning in data file | 20:16:26,700 | 127.0.0.1 |           7567
                                  Bloom filter allows skipping sstable 33182 | 20:16:26,701 | 127.0.0.1 |           7663
                                  Bloom filter allows skipping sstable 33180 | 20:16:26,701 | 127.0.0.1 |           7672
                                  Bloom filter allows skipping sstable 33178 | 20:16:26,701 | 127.0.0.1 |           7679
                                  Bloom filter allows skipping sstable 33177 | 20:16:26,701 | 127.0.0.1 |           7686

也许最重要的是跟踪的结束：

                                Merging data from memtables and 277 sstables | 20:21:29,186 | 127.0.0.1 |         607001
                                          Read 3 live and 0 tombstoned cells | 20:21:29,186 | 127.0.0.1 |         607205
                                                            Request complete | 20:21:29,186 | 127.0.0.1 |         607714

【问题讨论】：

查看TRACING 进行查询
在我对 400GB in 1 box 的最新测试中，cassandra 甚至无法及时回复简单的查询。 select * from history where id='some_valid_id' limit 2 。跟踪给出了很多行，例如：为 sstable 32752 找到 0 个条目的分区索引 | 20:16:30,952 | 127.0.0.1 | 4258690 寻求从数据文件开始的分区 | 20:16:30,952 | 127.0.0.1 | 4258708 为 sstable 32751 找到 0 个条目的分区索引 | 20:16:31,019 | 127.0.0.1 | 4326069 寻求分区...
我在我的问题中添加了追踪信息
在我看来，cassandra 必须在几个 sstables 中查找密钥。另一方面，它不会压缩 sstable，文件系统中有几十个。
cassandra 的行为真的很奇怪。昨天 data/history 文件夹下有 5000 个文件。让 cassandra 闲置 10 多个小时后，今天有 9000 个文件！所以它压缩了，但不是减少 sstable 文件的数量，而是看起来更多！

标签： cassandra

【解决方案1】：

请查看跟踪以确认，但如果 sdb、sdc 和 sdd 是旋转磁盘，您会看到正确的 tps 数量级，并且很可能是随机磁盘 I/O 绑定在读取端。

如果是这样，那么你只有两个选择（任何系统，不特定于 Cassandra）：

切换到 SSD。我的个人测试表明，当工作负载完全受磁盘 tps 约束时，随机读取性能提高了 3 个数量级。
确保很大比例的读取被缓存。如果您要对 400GB 的数据进行随机读取，那可能是不可行的。\

Cassandra 每个 CPU 内核大约可以执行 3k-5K 操作（读取或写入），但前提是磁盘子系统不是限制因素。

【讨论】：

我打算使用固态硬盘，但目前我没有足够大的固态硬盘。所以看起来确实有很多寻求，我已经在问题中添加了跟踪信息。关于缓存，我确实需要在没有缓存的情况下查看性能，因为我的应用程序将对其大部分内容进行缓存，而我预计对 cassandra 的查询将错过缓存。