sorting - Cassandra - 分页解决方案的数据排序？

Question

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

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

例如。

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 |
-------------------------------------

然而，返回的数据变得越来越大:所以我们需要开发某种分页来避免长时间的请求和前端加载时间。
用户最有可能排序的列是 时间 不幸的是它不是集群键的一部分，因此不能使用 ORDER BY命令。

我们提出的一个解决方案是创建一个具有相同数据的“排名”表
例如。

   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回来。分页状态可以保存并在需要时继续。这与物化 View 一起将完成分页。

编辑(2017 年 12 月 19 日)
还没有真正深入 dataframes的坑通过 spark - 一旦设置，它们的排序和过滤速度非常快 - 像 SQL 一样对待它。
关键词:一旦设置。发现他们平均需要大约 7 秒的时间来创建。

编辑(2018 年 3 月 29 日)
使用当前解决方案(物化 View + 限制结果)遇到障碍。物化 View 需要不断更新导致 的垃圾负载墓碑 .这意味着:糟糕的集群性能。
见 Sorting Results by Non-Clustering Key和 Tombstones When Updating .
回到方块 1. 叹息

编辑(2018 年 8 月 22 日)
通过积极的研究:看来要走的路是实现 Solr解决方案。 Solr 允许强大且快速的索引搜索以及分页。这篇博文' Avoid pitfalls in scaling Cassandra ' 是来自 Walmart 开发人员的一个很好的资源，它解释了他们如何使用“分片”进行分页的解决方案。

Answer 1

自从问这个问题以来已经有一段时间了，但想发布一些有关当前解决方案的信息。
分区键是“键”。
设计数据库以便只返回您想要返回的数据。
过滤到确切的分区键而不是同时过滤集群键极大地提高了集群的性能。我们现在只使用 1 个带有单个分区键的表，而不是 100 个带有复合键的表。还实现了分片。
KAFKA 数据流和缓存
我们面临的最大陷阱之一就是数据库对我们不断更新数据的巨大压力，经常插入重复的行。这造成了内存表大小和刷新时间的问题，这些问题经常会导致节点折叠。 https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/dml/dmlHowDataWritten.html
所以我们决定改为流式处理而不是批处理(Spark)。
Kafka 流是如此之快，在主题不再需要保存在内存中之前，不会进行 Cassandra 查询。优化的 Kafka 主题流到中间缓存系统，使用 Linq (C#) 对数据进行排序，并将其保留在那里直到一段时间过去。从此缓存中检索数据以进行分页。
Spark 流也适用于我们，但 Kafka 更适合。这是一篇关于差异以及可能对您更好的文章:
https://www.knowledgehut.com/blog/big-data/kafka-vs-spark