【问题标题】:Does Cassandra replication degrades Analytics performance in other DC or vice versa?Cassandra 复制是否会降低其他 DC 中的分析性能,反之亦然?
【发布时间】:2018-06-19 14:44:26
【问题描述】:

我们提出了一种利用 Cassandra-Spark 组合的解决方案,该组合通过工作负载分离架构实现。也就是说,Operations DC 主要进行繁重的写入操作,而 Analytics DC 处理 Analytics 作业。我读过here

"一旦在其他集群上收到这些异步提示,它们就会经历正常的写入过程并被同化到该数据中心。这样,任何正在运行的分析作业都可以轻松简单地访问这些新数据,而无需一个耗时的 ETL 过程。"

我们担心的是,由于所有数据都近乎实时地从 Operations DC 复制到 Analytics DC,我们如何确保复制过程不会影响 Analytics DC 上发生的分析处理?

或者,分析作业的繁重处理是否会影响数据中心之间的数据复制?

我知道我可能遗漏了一些东西,但一个方向会有所帮助。还将感谢任何有关基准测试或理论分析的相关文档以解决此问题。

【问题讨论】:

    标签: apache-spark cassandra datastax-enterprise


    【解决方案1】:

    这实际上取决于您将在 Analytics DC 中进行的数据处理类型。您需要调整服务器大小,使其能够处理来自事务 DC 复制的标准写入流量,以及分析作业的负载。但是您可以为分析型 DC 设置更小的复制因子,因此对分析型 DC 中的服务器的写入会稍微减少。

    DSE 架构在corresponding guide 中描述。您需要查看有关数据复制和读/写路径的信息...

    我建议对您的集群执行负载测试,并测量 Analytical DC 中服务器上的负载,例如,那里的服务器上读取和写入的第 99 个百分位数。

    您可以使用DSE Gatling plugin 或相关项目(在 DataStax 存储库中按单词 gatling 搜索)模拟事务 DC 的负载。使用 Gatling 可以更轻松地开发更多类似于真实世界的负载模拟器。

    【讨论】:

    • 评论部分:1谢谢你,亚历克斯。我已经浏览了相应的指南,但无法找到答案。目前,我们正在研究归档解决方案的架构。 Gatling 和其他原型设计活动的使用将在稍后阶段进行。我看到工作负载分离架构通过部署两个 DC 有助于隔离读取和写入。但是,将数据从 Operations DC 复制到 Analytics DC 将在 Analytics DC 上引入异步写入。因此,Analytics DC 将有来自 Operations DC 的写入以及其中的分析处理。
    • 评论部分:2 我正在搜索 Cassandra-Spark 内部架构如何处理复制和分析处理之间的冲突。架构中的哪些选项被考虑用来处理这些问题?有什么架构最佳实践可以避免此类问题吗?我已阅读在线 Datastax 文档,但无法找到上述问题的答案。
    • 在冲突解决中,最后一个时间戳获胜——这很简单。虽然您可以在写入数据时手动设置时间戳。或者您可以编写数据子集,仅覆盖某些列,这些列可能不存在于“操作”数据中。但是无论如何,如果您要写入在 DC 之间复制的同一个表/键空间,数据将被复制到另一个...我看到人们将数据复制到 Analytics DC、分析并将结果写入另一个键空间t 复制到“Operations DC”中……但这始终取决于任务。您可以联系 DataStax 以获取更多信息。
    • 我想在这里补充一点,如果您担心复制会在您的节点上造成过多的负载,那么听起来您并没有考虑其他基本操作,例如修复、节点故障容错等。您的节点需要有操作空间,你需要进行负载测试,然后再进行一些负载测试。
    猜你喜欢
    • 1970-01-01
    • 2013-05-22
    • 2011-12-25
    • 1970-01-01
    • 1970-01-01
    • 2016-11-25
    • 1970-01-01
    • 2015-12-30
    • 1970-01-01
    相关资源
    最近更新 更多