Question

您好我正在尝试理解这个问题，我正在使用cql3将数据插入到具有地图类型的表中。通常我可以插入数据平均每个cql3线程1000个iops，没有问题。一旦我添加了地图类型，插入在约100,000个条目之后超时并出现此错误：无法完成请求：一个或多个节点不可用。在多个节点上（甚至跨数据中心），我注意到插入过程中cpu负载异常高。

每个节点上的规范是： Cpu：16核心内存：64GB

这是我设置的测试表模式。

CREATE TABLE test (
    id text,
    q text,
    g text,
    gt text,
    gi map<text,text>,
    ts timestamp,
    PRIMARY KEY (id, ts)
) WITH CLUSTERING ORDER BY (ts DESC);

CREATE KEYSPACE testkeyspace WITH replication = {
    'class': 'NetworkTopologyStrategy',
    'DC1': '2',
    'DC2': '2'
};

Cassandra版本1.2.4

更新：目前我们只是从其他rdbms导入数据。大约100％的时间，我们要么添加新行，要么在地图列中添加新元素。我知道地图列可以拥有的元素数量的限制。

Answer 1

我最近看到一些报告说使用CQL3集合时的性能非常糟糕，它解释了我自己看到的一些问题。我不知道究竟是什么导致了这个问题，如果它是集合本身或其他东西。

人们遇到的最常见的事情是他们的模式创建了热点。如果这是你的问题，很难看出只看CREATE TABLE语句，但如果你的分区键（主键中的第一项）的不同值的数量很少，你就会经常写信给同一个节点。而且，即使Cassandra在理论上处理数十亿行的行，当Cassandra不断地压缩它们时，具有宽的高流量行会导致大量的开销。如果你还混合读写，Cassandra必须通过SSTables进行大量挖掘才能实现一行。

如果您要一直编写新行，修改现有行，尤其是如何使用这些地图列，请发布有关正在运行的插入的更多信息 - 您是在添加新元素，删除元素吗？在任何给定时间，其中一个地图列中预计会有多少个元素？

您可以做的另一件事是通过跟踪运行一个或几个操作，看看Cassandra正在做什么（请参阅http://www.datastax.com/dev/blog/tracing-in-cassandra-1-2了解如何启用跟踪并分析结果）。

Answer 2

在向我的CF添加地图类型列时遇到了一个非常类似的问题（Theo链接了我上面的相关问题）。我使用了一种解决方法，因为避免使用map列类型。另一位用户报告了this issue on the cassandra mailing list，但问题仍未得到解决。

一些注意事项：

主键子句中给出的“uvrid”在列定义中不存在。
您可以考虑更换时间戳with timeuuids to avoid collisions

Answer 3

实际上，将条目插入Map类型实际上是一种更新。集合上的插入会对性能产生影响。

Cassandra将性能问题插入到具有地图类型的表中

3 个答案: