二级索引的Cassandra性能变慢

Question

我们有一个测试代码架构，它使用java客户端来执行Cassandra INSERT / READ / QUERY操作。我们使用具有以下配置的物理服务器构建了单节点设置。

• 操作系统是Linux SuSE 11.SP2
• 物理服务器上的内存为32GB
• 交换内存为32GB
• CPU有4核，每个2GHz
• 提交日志驻留在100GB的SSD磁盘上（RAID-0和本地到系统）
• 数据日志驻留在具有7TB的SAS磁盘上（5个SAS磁盘配置为RAID-0，本地配置为系统）。
• JRE版本1.7.0.25
• Cassandra版本1.2.5（默认分区）
• MAX HEAP SIZE 8GB
• HEAP_NEW_SIZE 400MB（根据Cassandra建议，每个核心100MB）。

注意将CPU从4核增加到8核有助于提高性能但非常低。

我们正在使用下面的测试架构，它有5个二级索引。

"CREATE TABLE test_table (
  hash_key text PRIMARY KEY,
  ctime timestamp,
  ctime_bucket bigint,
  extension text,
  filename text,
  filename_frag text,
  filesize bigint,
  filesize_bucket bigint,
  hostname text,
  mtime timestamp,
  mtime_bucket bigint
) WITH
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.000000 AND
  gc_grace_seconds=864000 AND
  read_repair_chance=0.100000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'SnappyCompressor'};

CREATE INDEX test_table_ctime_bucket_idx ON test_table (ctime_bucket);
CREATE INDEX test_table_extension_idx ON test_table (extension);
CREATE INDEX test_table_filename_frag_idx ON test_table (filename_frag);
CREATE INDEX test_table_filesize_bucket_idx ON test_table (filesize_bucket);
CREATE INDEX test_table_mtime_bucket_idx ON test_table (mtime_bucket);"

我们正在尝试使用默认调整参数进行INSERT和READ测试，但是我们看到读写性能非常慢。与写入性能相比，读取速度非常慢。当我们从上面的模式中删除二级索引时，我们可以获得大约2倍的性能，但是我们仍然认为通过调整Cassandra参数可以提高性能。但是对于二级索引，性能非常差。

• 1M INSERT提供大约7k Ops / sec
• 10M INSERT提供大约5K Ops / sec（略微降低性能）
• 100M INSERT提供大约5K Ops / sec
• 1000MM INSERT提供约4.5K Ops / sec

如果我们删除二级索引，我们会为上面列出的所有工作负载提供大约11K Ops /秒的性能。

• 1M READ提供：4.5k Ops / sec
• 10M READ仅提供：225 ops / sec（大幅降低性能）

我们希望从您的专家团队了解有关WRITE和READ操作应用哪些特定调整参数以获得更好的性能。我们如何推迟压缩和GC以避免在这些操作中可能发挥作用的性能瓶颈。如果要应用任何特定于系统的调整，我们希望您的专家团队了解。

我们正在尝试使用以下调整参数（在Cassandra.yaml和Cassandra-env.sh中），但是我们在写入和读取性能方面没有太大改进。

Answer 1

这是一个非常受教科书限制的案例，特别是随着较大数据集的性能下降。 iostat可以证实这一点。

您需要切换到SSD，将计算机添加到群集或减少工作负载的随机性（提高缓存效率）。

编辑：我注意到你在SSD上有commitlog。 commitlog是纯粹的顺序写入，因此不会受益于非常多的SSD。将commitlog放在你的一个硬盘上，而将数据文件放在SSD上。