2

There are many question & answers out there covering the similar concepts, but none were came close to our concept.

We have our application built on Java (APIs), AngularJs (Front End) using MySql as database. Till now, there is no concept of storing user's activity in our application.

But now, we have to capture all the users activities (this consists of pretty much everything). Some of these activities are "User has viewed the appointment #", "User has updated the event information", "User has activated / deactivated other user", etc...

Below are the things that we need to consider:

  1. We will have pretty much of less data initially (may be 100 thousand records per day).
  2. All of these user activities are pretty much of write heavy and very very low on read part.
  3. We have designed the audit tables (MySql) in such a way that, they will hold the key information required to track each and every activity of the user.

Confused of below aspects:

  1. Some of our colleagues and boss are not comfortable with MySql as they are expecting a sudden surge of activity in our application as it is getting traction.
  2. Also there is suggestion of using Graph DB for it, which I think absolutely unnecessary. Because by design it is a triple store DB used for storing relational data using the nodes and edges.

Little Background for the suggestion: There is a proposal of migrating the entire application data from MySql to GraphDB as a future implementation (Which will be a while before we start off with the migration part and also none of our employees are acquainted with Graph DB knowledge). So our boss insisting us to start of with this.

Questions I have and on which I need your views are:

  1. Using Graph DB only for user activity is a good idea?
  2. If we are ever to use a Graph DB, which is the best free Graph DB?
  3. Alternatively can we use a NoSQL DB such as mongoDB for this purpose?
Kiran
  • 1,177
  • 4
  • 18
  • 35

1 Answers1

0

It's a bit difficult to say if changing the database is going to be a good idea without knowing what the system is and what are the requirements. Also, depending on what the system is and how it grows, you might want to have a hybrid solution. As the system grows, you might realise that MySQL might not be suitable for a specific scenario.

A few questions that you have to answer:

  • What are you going to do with the data that you're going to collect?
  • Are they purely for auditing purposes?
  • Are you going to analyse this data?
  • How possible is these requirements to change in the future?

If it's purely for auditing purposes, then storing them in a database like Cassandra or DynamoDB (if you use AWS) might be a better fit. If suppose you want to analyse how the user progressed in your system. In that case, you might want to have a process that will ingest the data from Cassandra or DynamoDB to a data warehouse system like Redshift or Hadoop, do the analysis there and expose the results.

A few more questions:

  • What's the reason that you're planning to migrate the whole system to use Graph DB and what triggered this proposal?
  • Do you have many relationships/hierarchies that you're traversing and is killing the MySQL server?
  • It feels a bit aggressive to go and switch the database for the whole system. Why don't you incorporate the Graph DB only for the specific concept that MySQL can't cope rather than changing the DB of the entire system?

A graph database is suitable for Social networks, recommendation systems, fraud detection and a few other things.

I'd recommend reading this article: https://www.infoworld.com/article/3251829/why-you-should-use-a-graph-database.html

Stavros Zavrakas
  • 3,045
  • 1
  • 17
  • 30