6 ms·

Why is it a bad idea to use a DB for a chat?

by juliend2 17y ago

axod 17y ago
Chat is a messaging system. Sending messages from one user, to other users. A database is a ridiculous way to do that.
- juliend2 17y ago
  Good point. But i wonder how some services like GoogleTalk does the storing of the chat conversations. Maybe flat-files i guess?
- daleharvey 17y ago
  rmdb's are a ridiculous way to run a chat application, other databases like mnesia (used heavily for ejabberd) work pretty well. storage and querying are pretty typical functional requirements, I dont know how much more suited couchdb would be for chat than mysql, but you cant dismiss it because of the same preconceptions you have with other "databases"
  - moe 17y ago
    You are missing the point. If your messages hit the disk, ever, then you are either not implementing a "real-time chat" or you're doing it horribly wrong.
    - daleharvey 17y ago
      hit the desk? I havent heard that phrase before (and neither has google), guessing it means go into a database if querying history is a functional requirement then your data has to be stored somewhere, filesystem is an easy win, but if something can provide distribution, replication and querying without breaking your other requirements then how exactly are you "doing it wrong"? My point wasnt even that couch would be particularly great at these, it was just that most of this "common wisdom" applies towards traditional rbdms, databases can be built with exactly realtime messaging in mind
      - moe 17y ago
        hit the desk? I havent heard that phrase before (and neither has google), guessing it means go into a database Disk. And it means your data is being written to the disk. if querying history is a functional requirement then your data has to be stored somewhere The stated functional requirement was "real-time chat". If you want to record all messages ever exchanged then you are not talking about a chat system anymore but rather about an archival system. For the latter a database can indeed make sense but the two should not be mixed together due to the fundamentally different requirements. but if something can provide distribution, replication and querying without breaking your other requirements then how exactly are you "doing it wrong"? By hitting the disk for each message. databases can be built with exactly realtime messaging in mind And cars can be built with air-travel in mind. It just makes no sense because it's a different domain with different requirements. A database stores data, a messaging system (especially a realtime one) routes messages. Doh.
        daleharvey 17y ago
        "The stated functional requirement was "real-time chat". I didnt see anyone list a functional requirement specification, I at least, was talking hypothetically. ITs worth noting that chat applications are almost(always?) never real time, they are soft realtime. " two should not be mixed together due to the fundamentally different requirements." Message routing and persistence are not mutually exclusive, they have competing requirements but that does not mean they cannot and do not exist. see twitter, banking, telecoms, campfire, ejabberd. "By hitting the disk for each message." If not hitting this disk is a a functional requirement then fair enough, I have never heard of this being a requirement outside of embedded systems. "And cars can be built with air-travel in mind. It just makes no sense because it's a different domain with different requirements. A database stores data, a messaging system (especially a realtime one) routes messages. Doh." I wouldnt mind knowing exactly what makes "messages" seperate from data. a database is just an abstraction layer over a set data that can provide several completely different benefits for storing and accessing that data, it isnt even required that a database "hits the disk" in the slightest, and there is no part of the definition of "database" that prevents it from being absolutely perfect for messaging systems, it just so happens that all the examples you can think of arent.
- CalmQuiet 17y ago
  What's a better way to keep a log, if desired?
  - moe 17y ago
    open( 'log', O_CREAT|O_APPEND );
  - axod 17y ago
    Chat history should be a separate, non-critical path.
    - daleharvey 17y ago
      chat history for you should be on a seperate, non critical path, sometimes the auditability of being able to say you sent the message is as important as sending the message itself, banking / telecoms etc. sometimes you want to search your logs in "real time", ala twitter search and as I alluded to above, more than often message delivery should be done seperate to persistence, but that doesnt strictly mean outside of a database.
      - moe 17y ago
        sometimes the auditability of being able to say you sent the message is as important as sending the message itself, banking / telecoms etc. You keep intermixing a user-to-user chitchat system (which the submitter presented) with banking and telco applications. They are not the same, they are not even closely related. ISO 15022 does not apply to twitter.
- jbarciauskas 17y ago
  Exactly. The trick of real-time chat is the real-time part, i.e. getting the message as close to when the user sent it as possible. Storing chat history is not interesting, we all understand how to post a form to a DB table. The solution to this problem is related to persistent connections to the server or polling the server... Whether the chat is persisted is completely besides the point in the context of a real-time chat demo. So the interesting part of this demo is not CouchDB but the refreshView() function, which uses the long-polling AJAX messaging technique - see http://cometdaily.com/2007/11/15/the-long-polling-technique/ http://cometdaily.com/2007/11/15/the-long-polling-technique/ or just google "Long polling"

Why is it a bad idea to use a DB for a chat?

axod 17y ago

Chat is a messaging system. Sending messages from one user, to other users. A database is a ridiculous way to do that.

juliend2 17y ago
Good point. But i wonder how some services like GoogleTalk does the storing of the chat conversations. Maybe flat-files i guess?
daleharvey 17y ago
rmdb's are a ridiculous way to run a chat application, other databases like mnesia (used heavily for ejabberd) work pretty well. storage and querying are pretty typical functional requirements, I dont know how much more suited couchdb would be for chat than mysql, but you cant dismiss it because of the same preconceptions you have with other "databases"
- moe 17y ago
  You are missing the point. If your messages hit the disk, ever, then you are either not implementing a "real-time chat" or you're doing it horribly wrong.
  - daleharvey 17y ago
    hit the desk? I havent heard that phrase before (and neither has google), guessing it means go into a database if querying history is a functional requirement then your data has to be stored somewhere, filesystem is an easy win, but if something can provide distribution, replication and querying without breaking your other requirements then how exactly are you "doing it wrong"? My point wasnt even that couch would be particularly great at these, it was just that most of this "common wisdom" applies towards traditional rbdms, databases can be built with exactly realtime messaging in mind
    - moe 17y ago
      hit the desk? I havent heard that phrase before (and neither has google), guessing it means go into a database Disk. And it means your data is being written to the disk. if querying history is a functional requirement then your data has to be stored somewhere The stated functional requirement was "real-time chat". If you want to record all messages ever exchanged then you are not talking about a chat system anymore but rather about an archival system. For the latter a database can indeed make sense but the two should not be mixed together due to the fundamentally different requirements. but if something can provide distribution, replication and querying without breaking your other requirements then how exactly are you "doing it wrong"? By hitting the disk for each message. databases can be built with exactly realtime messaging in mind And cars can be built with air-travel in mind. It just makes no sense because it's a different domain with different requirements. A database stores data, a messaging system (especially a realtime one) routes messages. Doh.
      - daleharvey 17y ago
        "The stated functional requirement was "real-time chat". I didnt see anyone list a functional requirement specification, I at least, was talking hypothetically. ITs worth noting that chat applications are almost(always?) never real time, they are soft realtime. " two should not be mixed together due to the fundamentally different requirements." Message routing and persistence are not mutually exclusive, they have competing requirements but that does not mean they cannot and do not exist. see twitter, banking, telecoms, campfire, ejabberd. "By hitting the disk for each message." If not hitting this disk is a a functional requirement then fair enough, I have never heard of this being a requirement outside of embedded systems. "And cars can be built with air-travel in mind. It just makes no sense because it's a different domain with different requirements. A database stores data, a messaging system (especially a realtime one) routes messages. Doh." I wouldnt mind knowing exactly what makes "messages" seperate from data. a database is just an abstraction layer over a set data that can provide several completely different benefits for storing and accessing that data, it isnt even required that a database "hits the disk" in the slightest, and there is no part of the definition of "database" that prevents it from being absolutely perfect for messaging systems, it just so happens that all the examples you can think of arent.
CalmQuiet 17y ago
What's a better way to keep a log, if desired?
- moe 17y ago
  open( 'log', O_CREAT|O_APPEND );
- axod 17y ago
  Chat history should be a separate, non-critical path.
  - daleharvey 17y ago
    chat history for you should be on a seperate, non critical path, sometimes the auditability of being able to say you sent the message is as important as sending the message itself, banking / telecoms etc. sometimes you want to search your logs in "real time", ala twitter search and as I alluded to above, more than often message delivery should be done seperate to persistence, but that doesnt strictly mean outside of a database.
    - moe 17y ago
      sometimes the auditability of being able to say you sent the message is as important as sending the message itself, banking / telecoms etc. You keep intermixing a user-to-user chitchat system (which the submitter presented) with banking and telco applications. They are not the same, they are not even closely related. ISO 15022 does not apply to twitter.
jbarciauskas 17y ago
Exactly. The trick of real-time chat is the real-time part, i.e. getting the message as close to when the user sent it as possible. Storing chat history is not interesting, we all understand how to post a form to a DB table. The solution to this problem is related to persistent connections to the server or polling the server... Whether the chat is persisted is completely besides the point in the context of a real-time chat demo. So the interesting part of this demo is not CouchDB but the refreshView() function, which uses the long-polling AJAX messaging technique - see http://cometdaily.com/2007/11/15/the-long-polling-technique/ http://cometdaily.com/2007/11/15/the-long-polling-technique/ or just google "Long polling"