Cassandra - 为分页解决方案排序数据?

时间:2017-12-13 02:18:36

标签: sorting apache-spark cassandra pagination clustering-key

因此,我们有一个使用.NET和Cassandra / Spark组合的Web应用程序来生成在线报告。

目前,我们从Cassandra获取所有相关数据并通过JavaScript插件将其呈现在表中,该插件也对其进行排序(取决于单击的列)。

E.g。

PK = PARTITION KEY | CK = CLUSTERING KEY

   PK     PK         CK
-------------------------------------
| user | date  | application | time |
-------------------------------------
| A    | 17500 | app1        | 3000 |
| A    | 17500 | calc        | 1000 |
| A    | 17500 | word        | 5000 |
-------------------------------------

然而,回来的数据变得越来越大:所以我们需要开发某种分页以避免长时间请求和前端加载时间。
用户最常选择的列是时间,遗憾的是,它不是Clustering键的一部分,因此无法使用ORDER BY命令。

我们提出的解决方案是创建一个包含相同数据的“排名”表 E.g。

   PK     PK      CK
--------------------------------------------
| user | date  | rank | application | time |
--------------------------------------------
| A    | 17500 | 1    | word        | 5000 |
| A    | 17500 | 2    | app1        | 3000 |
| A    | 17500 | 3    | calc        | 1000 |
--------------------------------------------

...但是这会给Spark带来更多的负担,因为为'时间'收集的数据会不断增加,从而改变排名。

我们也可以通过ajax调用来命令结果服务器端,缓存和检索有限数据,但是这种方法会显着增加服务器上的内存负载(特别是如果许多用户一次使用系统)。

也许我正在思考这个问题,而且可以使用简单的cassandra表构造。 什么是解决这个问题的最佳方法?

编辑(2017年12月15日): 来自Cassandra的名为Materialized Views的东西似乎能够将非键列作为聚类键。这对于抓取行数排序而非分页非常有用。

编辑(2017年12月18日): Datastax C#驱动程序允许返回pagination of results。可以保存分页状态并在需要时继续。这与物化视图一起将完成分页。

编辑(2017年12月19日) 没有真正通过火花深入研究dataframes的陷阱 - 一旦设置它们就非常快速地进行排序和过滤 - 将其视为SQL。 关键词:一旦设置。发现他们平均花了大约7秒来创建。

编辑(2018年3月29日) 使用当前解决方案(物化视图+限制结果)遇到麻烦。物化视图需要不断更新,从而产生墓碑的垃圾邮件。这意味着:集群性能不佳 请参阅Sorting Results by Non-Clustering KeyTombstones When Updating 回到原点1. 叹息

编辑(2018年8月22日) 通过积极的研究:似乎要走的是实施Solr解决方案。 Solr允许强大的&快速索引搜索以及分页。这篇博客文章“Avoid pitfalls in scaling Cassandra”是沃尔玛开发人员的一个很好的资源,它解释了他们如何使用“分片”进行分页的解决方案。

1 个答案:

答案 0 :(得分:0)

问了这个问题以来已经有好一段时间了,但是想发布一些有关当前解决方案的信息。

分区键是“ ”。

设计数据库,以便仅返回要返回的数据
过滤到确切的分区键,而不是也过滤群集键,极大地提高了群集的性能。现在,我们仅使用1个具有单个分区键的表,而不是100个具有复合键的表。分片也已实现。

KAFKA数据流和缓存

我们面临的最大陷阱之一就是数据库不断更新数据带来的巨大压力,这些数据经常插入重复的行。这带来了内存表大小和刷新时间的问题,这些问题经常使节点崩溃。 https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/dml/dmlHowDataWritten.html
因此,我们决定改用流式处理,而不是批量处理(Spark)。

Kafka流是如此之快,直到不再需要将主题保留在内存中之前,才进行Cassandra查询。经过优化的Kafka主题流式传输到中间缓存系统,使用Linq(C#)对数据进行排序,并将其保留在那里,直到经过一定时间。从该缓存中检索数据以进行分页。

火花流也可以为我们工作,但Kafka恰好适合。这是一篇很好的文章,介绍了两者之间的区别以及可能对您更有利的内容:
https://www.knowledgehut.com/blog/big-data/kafka-vs-spark