4

因此，我们有一个使用 .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# 驱动程序允许对返回的结果进行分页。分页状态可以被保存并在需要时继续。这与物化视图一起将完成分页。

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

编辑（2018 年 3 月 29 日） 使用当前解决方案遇到障碍（物化视图 + 限制结果）。物化视图需要不断更新，导致大量墓碑。这意味着：集群性能不佳。
请参阅更新时按非聚类键和墓碑排序结果。
回到广场 1.叹息

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

4

1 回答 1

0

Been a good while since asking this question but wanted to post some information about the current solution.

Partition keys are 'key'.

Designing the database so only the data you want returned is returned.
Filtering to the exact partitionkey instead of also filtering on clustering keys improved performance of the cluster tremendously. We now only use 1 table with a single partition key instead of 100s of tables with composite keys. Sharding was also implemented.

KAFKA Data Streaming & Caching

One of the largest pitfalls we faced was just the huge amount of pressure the database had with our constant updating data, often inserting duplicate rows. This created problems with the size of memtables and flushing times which often saw nodes falling over. https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/dml/dmlHowDataWritten.html
So we decided to change to streaming instead of batch processing (Spark).

Kafka streaming is so fast, no Cassandra querying is done until topics no longer need to kept in memory. Optimised Kafka topics stream to an intermediate caching system, sorts the data using Linq (C#), and keeps it there until a certain period of time has passed. Data is retrieved from this cache for paging.

Spark streaming would have also worked for us, but Kafka just fit better. Here's a good article on the difference and what might be better for you:
https://www.knowledgehut.com/blog/big-data/kafka-vs-spark

于 2020-07-09T02:34:28.057 回答