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

【问题标题】：Cassandra - Sorting data for pagination solution?Cassandra - 为分页解决方案排序数据？
【发布时间】：2018-05-26 20:11:56
【问题描述】：

所以我们有一个使用 .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 的东西，它似乎能够将非键控列作为集群键排序。这对于获取 top number of rows 和 sorting 非常有用，但不能用于分页。

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

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

编辑（2018 年 3 月 29 日） 使用当前解决方案遇到障碍（物化视图 + 限制结果）。物化视图需要不断更新，导致墓碑大量出现。这意味着：集群性能不佳。
请参阅Sorting Results by Non-Clustering Key 和Tombstones When Updating。
回到方块 1。叹息

编辑（2018 年 8 月 22 日） 通过大力研究：看来要实施Solr 解决方案。 Solr 允许强大且快速的索引搜索以及分页。这篇博文“Avoid pitfalls in scaling Cassandra”是沃尔玛开发人员的一个很好的资源，它解释了他们如何使用“分片”进行分页的解决方案。

【问题讨论】：

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

【解决方案1】：

自从提出这个问题以来已经有一段时间了，但想发布一些有关当前解决方案的信息。

分区键是'key'。

设计数据库，以便只返回您想要返回的数据。
过滤到确切的分区键而不是过滤集群键极大地提高了集群的性能。我们现在只使用 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

【讨论】：