Model relations and tables to microservices, nodes and services

[eperinan]

We need to create the model and relations in Cassandra to our model.

Basically, our approach is the next:

• We have unlimited microservices to monitor.
• Each microservice has to have unless one node.
• Each node will have services to monitoring.
• These services will export the metrics and values.

[eperinan]

This is my first approach as model in Cassandra to our application. Obviously we will have to iterate over this version but I would like to know if I can start to code with this model.

CREATE KEYSPACE IF NOT EXISTS freestyle_opscenter WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 1};

CREATE TABLE IF NOT EXISTS freestyle_opscenter.services (
id_service uuid,
name text,
id_microservice set<uuid>,
PRIMARY KEY(id_service)
);

CREATE TABLE IF NOT EXISTS freestyle_opscenter.microservices (
id_microservice uuid,
added_date timestamp,
name text,
nodes set<text>,
PRIMARY KEY(id_microservice)
);

The only doubt that I have is how I am going to join both tables. I have to compare the performance between make one query to Cassandra by each microservice or store in memory the result of two queries whose retrieve all rows from both tables.

In function of the rows of both tables, I will make a decision.

What do you think @juanpedromoreno @FPerezP @raulraja ?

[juanpedromoreno]

I don't have enough background on this, however, my initial perception would be that we shouldn't configure one uuid as primary/partition key.

[raulraja]

Since nodes may be elastic on a MS I'm not sure we can rely on embedding them and keeping them up to date on an actual property. I'd prefer if Nodes were modeled in a different table in the same way you have modeled freestyle_opscenter.services

[raulraja]

The right people to review this is @fedefernandez and @FPerezP

[fedefernandez]

At first glance, I would say that the information of these two tables could be defined in a single table. In Cassandra, joins are discouraged.

On the other hand, the tables should be defined to satisfy queries, therefore we should define all queries we want to support and then model the tables.

That makes sense?

[FPerezP]

Agree with Fede, inserts in Cassandra are really fast, so even we can consider inserting in 2 different tables if we need to extract information in 2 different ways rather than having 2 tables to join them later.

Related to having a UUID as a primary key, it's gonna depend on how we want to partition our data in the cluster. With the current definition, and considering we are gonna have more than one row per service/microservice, defining the UUID as PK will group all rows for the same UUID in the same node, which could make sense depending on the amount of rows per UUID we are gonna have.

But as Fede mentioned, I recommend to define all queries we need to run against cassandra before, and based on those queries we can help you to define the tables ;)

[eperinan]

Makes sense @fedefernandez @FPerezP.

Initially, I only would need define one query.

The main goal of this query would be fetch all the microservices with their nodes and services. This information could be enought so far

I thought two tables because the services are common between microservices, for example, cassandra, kafka, etc .... and for this reason, I made the decision to split the information in two tables and not duplicate the information.

So with this approach, would are your thoughts @fedefernandez @FPerezP ?

In am thinking in something like this

CREATE KEYSPACE IF NOT EXISTS freestyle_opscenter WITH replication = {'class': 'SimpleStrategy', 'replication_factor' : 1};

CREATE TABLE IF NOT EXISTS freestyle_opscenter.microservices (
id_microservice uuid,
added_date timestamp,
name text,
nodes set<text>,
service_name text,
added_service_date timestamp
PRIMARY KEY(id_microservice)
);

[FPerezP]

@eperinan sounds good. 2 more comments:

• For production we should move from SimpleStrategy to NetworkTopologyStrategy
• Do we need these rows sorted in any way? PrimaryKey can be defined as a tuple of 3 elements, where the first one is the PartitionKey and the others are for ordering purposes: https://www.datastax.com/dev/blog/the-most-important-thing-to-know-in-cassandra-data-modeling-the-primary-key