Store conversation and chat history in Graph database

Hi, How can I store the conversation/chat between multiple persons and it's history in the Graph database and is it recommended. Please consider the conversation may be long.
I would like to store and fetch in order of timestamp, the individual's name, comment and the timestamp. An example below -

Person1: What are your observations about this experiment?
Person2: I have observed something x...
Person3: I have observed something y and also,
something z
Person1: Thanks! both for your inputs. I have a follow-up question.
Person2 can you please share any evidence in support to your observation z? Thanks!

I can think of storing each comment as a separate node but it will exponentially increase the size of the database.

Hi @meetmayankdixit

It is advisable to only have in your graph the business model of your application or what has a meaning in terms of relationships for your project, the rest such as medias, conversations and others can be passed to other databases like mongo or postgresql.

Always remember that the more nodes and relationships you have, the more your database will scale and therefore the more expensive your queries can be.

The point in the graph is the relationships, there is no place to store data that does not have a real and logical meaning for your algorithms.

Greetings

Thanks! Dairon, this is my understanding too. However, as per the use case that I have, the conversation needs to be pulled together along with other elements already stored in the neo4j db and it needs to be surfaced on the UI.
So, if I store conversation in another DB, while pulling up other details from neo4j, the other layers (i.e. API/UI) will have to extract details from two different databases, club together and show on the UI (and similar logic when storing the information). Any suggestion in this regard. Thanks again!

Hi @meetmayankdixit

If you are forced to have the chat in neo4j, which I do not recommend, you will see a very exponential growth in your database.
You have two ways to put it:

  1. Create a Chat Label node that has a property per chat instance and in it store a dictionary that is the conversation. For example:
    (a:User {name: 'Maria'})-[:HAVE]->(c:Chat)-[:WITH]->(b:User {name:'Jhon'})
    then in c you will have a list of json elements which would be the conversation with the following values:
    origin: id or name of the person who wrote the message
    moment: time of the message
    message: text written at that moment by the user

  2. The other way that would be very heavy for the database would be to have a node or chat relationship between users for each text message.

So, to optimize, I would recommend that at the time of scaling the database, you take everything related to the chat to another computer and thus segment your graph.

In my humble opinion, these two are the most common ways I see to have a chat in neo4j, which I don't recommend, but someone with much more experience than me could give you a better opinion.

Greetings

Thanks again, one way of storing it as I am thinking is, to store the conversation/chat using a coalesce operation within a single property of a 'Chat' node. Need some testing though. I would also explore the option of pulling up data (e.g. Chat from Postgres and Other related data from Neo4j) from two different DBs before surfacing it on the UI in one go - there has to be an optimized way to do this which I am not aware as of now.
Thank you!

just only store in other database the id of the user and his conversation, then with the id of user you can do the work easy.

I recommend you analyze the project well and segment the logics, create an endpoint for each topic and your answer will come by itself.

@meetmayankdixit

in some ways we already do this here at Neo4j with a data set whereby we import our support ticket data into a Neo4j Graph.

the model is such that we have and in short the model for example is
(:Ticket)- [:UPDATE]->(:TicketUpdate)-[:IS_AUTHORED]->(author:TicketAuthor)

and where the :UPDATE rel has a property named date_created. which is used so as to build a chronological order of the update to the ticke. And each TicketUpdate has a relationship to the author of said update

i presume you could use this same design model to address your conversation / chat history