CODEWITHSUNDEEP
node.jsmongodb
Muhammed Neswine
Muhammed Neswine

Reputation: 2047

mongodb + nodejs save chat history

Am developing a chat system in node.js and mongoose. Is it good to use mongodb to store entire chat history in it? Or should we use ant alternative?

Upvotes: 2

Views: 2709

Answers (2)

Sammaye
Sammaye

Reputation: 43884

Ok so I have converted this question a little using the comment content:

But few of my friends suggested that its better not to use mongoDB collection that grows. Thats why am little bit confused. What would you do if you were doing this project??

Into a recommendation on how to use MongoDB effectively.

I am unsure of what reference your friends were quoting but MongoDB is very good at chat like applications whose initial data is never updated, a.k.a you never send an update statement to the server, only an insert() and a remove() (possibly an update to say when it was seen but that should be a in place update).

MongoDB wouldn't be so good if you was updating the rows (documents) however, in recent versions that too has got a lot better. The introduction of powerof2sizes by default means that you can actually grow the message to closer a power of 2 of its original size before the document would be required to move to a new disk sector, making disk reuse also easier. Non-inplace updates are, of course, expensive to both IO and CPU.

As for seaching, SQL does possess FTS, however, as Stack Exchange themselves found out: databases are nto very good at searching. They soon replaced MS SQL FTS with Elastic Search.

As for ordering: I am unsure why SQL would b better here. MongoDB can sort on an index, an sorting on a non-inex would be very bad practice in any database in this case. Imagine having to load every comment from the database to peform sorts. So both are equal when it comes to sorting.

With grouping MongoDB now has the aggregation framework but currently lacks the capacity, due to a regression, to use covered queries for it. This means that a group will load from disk currently and not use only an index. This does make SQL better on this front...currently. However, I struggle to see how you woul group on anything, you would have two tables:

  • Conversation
  • Messages

One screen showing the first table and the second table showing...the second.

You would be filtering by user_id on the first table and convo_id on the second.

Logs are an extremely commonly requested feaure of a chat application so unlike @Rax I won't ty and use that in my justification; I am unsure how that changes anything except, maybe, space requirements between MongoDB and other technologies. That being said: quite a few technologies actually use MVCC by default which will take a lot more space than MongoDB would ever (good to note that SQL techs do not but a lot of databases, like CouchDB etc which are taken by chat companies do).

I would also say you will read more than you write. Everytime someone sends a message there will be a read of it, not only on the original side to say "It has been send!!!" but also on the recieving end to say "Get the next message". So every message triggers double its reads. MongoDB is opitmised for those kinds of workflows.

Anyway, that should give you some pointers. I would try out MongoDB and se how it works for you.

Upvotes: 2

Rax Wunter
Rax Wunter

Reputation: 2777

For my opinion, mongodb is not perfect for logging anything, because:

  • your data structure (message, userId etc) will not be changed likely
  • you should select it somehow, group, order etc. SQL is better for it
  • In common, logs are not often requested thing, so you needn't to key-value it.
  • You will write more than read

In out project we store most recent chat history in redis lists (for fast simple getting) and other logs in postgres.

Upvotes: 0

Related Questions