postgresql - Cassandra 如何处理磁盘 IO

Question

我想比较 PostgreSQL 和 Cassandra 在单个节点上 的读取性能。

我有一个 8 列、150000 行的表格。为了将其转换为列族，我将主键设为 Cassandra 中的行键，其余列与 PostgreSQL 中的一样。此外，我将数据批量加载到 Cassandra SSTables 中，因此两者的数据都在磁盘上。

从 PostgreSQL 读取表:

 select * from tableName;

耗时 200 毫秒左右。

为了读取列族(启用 keycache 和 rowcache)，我尝试了 thrift API(get_range_slices 方法)和 CQL2.0。前者平均耗时 7000ms 左右，后者则达到了难以忍受的 100000ms。

我知道如果从 Cassandra Memtables 读取数据会非常快。但既然它们都从磁盘读取，为什么 Cassandra 慢得多？

哪些底层机制至关重要？

编辑:

客户专栏族

CREATE COLUMN FAMILY customer
WITH comparator = UTF8Type
AND key_validation_class = UTF8Type
AND caching = all
AND column_metadata = 
[
 {column_name: C_NAME, validation_class: UTF8Type},
 {column_name: C_ADDRESS, validation_class: UTF8Type},
 {column_name: C_NATIONKEY, validation_class: UTF8Type},
 {column_name: C_PHONE, validation_class: UTF8Type},
 {column_name: C_ACCTBAL, validation_class: UTF8Type},
 {column_name: C_MKTSEGMENT, validation_class: UTF8Type},
 {column_name: C_COMMENT, validation_class: UTF8Type}
];

这是我的节俭查询

   // customer is that column family of 150000 rows
   ColumnParent cf1 = new ColumnParent("customer");
   // all columns
   SlicePredicate predicate = new SlicePredicate();
   predicate.setSlice_range(new SliceRange(ByteBuffer.wrap(new byte[0]), ByteBuffer.wrap(new byte[0]), false, 100));
   // all keys
   KeyRange keyRange = new KeyRange(150000);
   keyRange.setStart_key(new byte[0]);
   keyRange.setEnd_key(new byte[0]);
   List<KeySlice> cf1_rows = client.get_range_slices(cf1, predicate, keyRange, ConsistencyLevel.ONE);   

还有我的 CQL2.0 查询:

   select * from customer limit 150000;

编辑:

怪我标题误导，提供的数据可能会带来更多的争议。我不是在这里挑选赢家。

它们都在进行磁盘 I/O(这不是 Cassandra 的典型用例)并且它们的时间不同，所以一定是有原因的。我很好奇他们处理这个问题的方式。因此，如果你们能阐明基 native 制，我将不胜感激。

这不是苹果对苹果的比较，但我关心的是味道。一种可能更酸，因为它含有更多的维生素 C。这对我来说很重要。

谢谢。

Answer 1

这不是针对 Cassandra 的有效测试，因为 Postgres 和 Cassandra 并非旨在解决相同的问题。完整的 CF 扫描不是真实世界的查询，如果您在生产系统中执行此操作，您将使用 Hadoop 而不是通过 Thrift 执行此操作。用于检索大量数据的更现实的 Cassandra 测试是列切片，您可以在其中检索给定键集的从 A 到 n 的一系列列。这是一种更高效的操作，也是更适合 Cassandra 的数据模型选择。此外，没有人在单个节点上运行 Cassandra； 3 个节点是最低配置。

如果你想测试完整的扫描功能，使用 Thrift(在你的情况下通过 CQL)不是这样做的方法，因为你的所有结果都必须适合 RAM 并立即通过线路序列化(即有没有游标)。如果您的所有数据都可以放入 RAM，那么 Cassandra 不是您的正确选择。将 Hadoop 与 Cassandra 结合使用，您可以并行化完整扫描并在几秒钟内回答有关理论上无限量数据的问题——这是 Postgres 无法做到的。如果您想详细了解其工作原理，请查看 Cassandra 的 Hadoop 包中的 RangeClient。还值得注意的是，完整扫描需要磁盘读取，而许多常见的读取模式使用缓存并且从不访问磁盘。

相比之下，Cassandra 在列范围查询或按键获取方面非常快。这是因为键被散列到特定节点，然后在写入时按列名排序。因此，如果您知道您的键和/或想要一系列连续的列(一种非常常见的 Cassandra 读取模式)，那么最坏的情况下您将获得顺序 I/O，最好的情况下获得缓存数据——没有锁定或间接(即索引)。