仅使用 Graph DB 存储用户活动数据是个好主意吗？答案

【问题标题】：Using Graph DB to store user activity data only is a good idea?仅使用 Graph DB 存储用户活动数据是个好主意吗？
【发布时间】：2018-01-30 09:37:59
【问题描述】：

有很多问题和答案涵盖了类似的概念，但没有一个与我们的概念相近。

我们的应用程序建立在 Java (API)、AngularJs（前端）上，使用 MySql 作为数据库。到目前为止，还没有在我们的应用程序中存储用户活动的概念。

但是现在，我们必须捕获所有用户活动（这几乎包括所有内容）。其中一些活动是“用户已查看约会#”、“用户已更新事件信息”、“用户已激活/停用其他用户”等...

以下是我们需要考虑的事项：

我们最初的数据会少很多（每天可能有 10 万条记录）。
所有这些用户活动几乎都是写繁重的，读部分非常少。
我们设计的审计表 (MySql) 将保存跟踪用户的每一项活动所需的关键信息。

对以下方面感到困惑：

我们的一些同事和老板对 MySql 不满意，因为他们预计我们的应用程序活动会突然激增，因为它正在受到关注。
还有建议使用 Graph DB，我认为这完全没有必要。因为按照设计，它是一个三重存储数据库，用于使用节点和边存储关系数据。

建议的背景知识：有一个建议将整个应用程序数据从 MySql 迁移到 GraphDB 作为未来的实现（这将在我们开始迁移部分之前有一段时间，而且我们的员工都不熟悉图数据库知识）。所以我们的老板坚持要我们从这个开始。

我的问题和我需要您的意见的问题是：

仅将 Graph DB 用于用户活动是个好主意吗？
如果我们要使用 Graph DB，哪个是最好的免费 Graph DB？
我们是否可以为此使用 NoSQL DB（例如 mongoDB）？

【问题讨论】：

我刚刚意识到这是一个老问题，你刚刚修改了所以我的答案现在可能有点无关紧要了。

标签： mysql graphdb user-activity

【解决方案1】：

在不知道系统是什么以及要求是什么的情况下，很难说更改数据库是否是一个好主意。此外，根据系统是什么以及它的增长方式，您可能需要一个混合解决方案。随着系统的增长，您可能会意识到 MySQL 可能不适合特定场景。

你必须回答的几个问题：

您打算如何处理要收集的数据？
它们是否纯粹用于审计目的？
您要分析这些数据吗？
这些要求在未来有多大可能发生变化？

如果纯粹出于审计目的，那么将它们存储在 Cassandra 或 DynamoDB 等数据库中（如果您使用 AWS）可能更合适。如果假设您想分析用户在您的系统中的进展情况。在这种情况下，您可能希望有一个进程将数据从 Cassandra 或 DynamoDB 摄取到 Redshift 或 Hadoop 等数据仓库系统，在那里进行分析并公开结果。

还有几个问题：

您计划迁移整个系统以使用 Graph DB 的原因是什么？是什么触发了这个提议？
您是否有许多正在遍历的关系/层次结构并正在杀死 MySQL 服务器？
为整个系统切换数据库感觉有点激进。为什么不只针对 MySQL 无法应对的特定概念合并 Graph DB，而不是改变整个系统的 DB？

图形数据库适用于社交网络、推荐系统、欺诈检测和其他一些东西。

我建议阅读这篇文章： https://www.infoworld.com/article/3251829/why-you-should-use-a-graph-database.html

【讨论】：