You can do it with MySql, or with files in append mode with "message_id - message", and everything else.
I think that KV stores are great, but if you create a false sense of coolness this is going to hurt in the long run. It is important to show people why really new forms of DBs can be useful and important.
edit: If the point is instead the fact that the DB talks directly HTTP, the w.ebchat.com chat PHP layer is ridiculous, just a wrapper that takes parameters from the HTTP side and run a query returning back the data. I can only see the HTTP protocol as interface to KV DB as a good way to lost a lot of performances without a reason.
@antirez the thing is that CouchDB is designed for replication. Every CouchApp is a p2p web app. This is different from the web we've known before.
CouchDB will never be as fast as some other k/v stores, but http based peer replication gives us a robust offline mode (and portable api) so that applications can run at the Edge.
the scripting layer has very little concern in the traditional web model, there are clear advantages to having that work done in the browser, hence the popularity of things like ajax and jquery.
why is creating any trivial website backed by a cms that isnt cuttie cooker blogger template still the domain of the ruby / phpist, we have had plenty of time to solve these problems with the traditional browser > php/ruby > mysql model, time for someone to come along with something new.
Yes, it is good thing. But will that method perfect for every use case.
Think about maintaining DB(Mysql, Sql language), Web server(Crazy config files), application server (Ruby or PHP), Client side(Javascript) just for personal blog/site.
Here layers are less and Languages(only one) and config files are less.
EDIT: "And less is good" , Arguments are endless unless you are talking about specific use case.
I can create a chat application in just ruby, that stores everything in a flat text file and serves everything directly from mongrel, with no apache or nginx in the way.
Just because it has "fewer moving parts" doesn't make it good or special.
Separating unrelated layers is supposed to be a good thing. I seriously doubt that CouchDB is as good a general purpose HTTP server as Apache.
UPDATE:
This is what I think of when you say "It's got one less moving part":
First thing comes to mind is CouchDB should not be general purpose HTTP server.
You will agree that you can't create real time chat in under 100 lines of Ruby code alone (still you need javascript)
This chat application author coded application in 100 lines of Javascript including validation that run on server.
I can clearly see the benefits of approach CouchDB took with CouchApps. I also know its not answer to all needs of Webapps.
Totally possible. Set up a MySQL server with a public username and password, define some stored procedures to keep the API simple. Share the procedures and invite people to connect using any MySQL client.
That the HTTP-powered Web browser is a universally popular piece of software has no relevance on its effectiveness. Chatting through a Web browser is as formally arbitrary as chatting through any other sort of client.
Does this mean CouchDB already supports Comet? That would really excite me. I am not aware of any established Comet frameworks, and custom solutions in Erlang seem to become a common way to go at the problem (because of the cheap threads, useful to listen to all the connections). Since CouchDB is written in Erlang, I was hoping that it would support Comet eventually.
Edit: in the chat it was claimed that CouchDB supports COMET. If true, this would be way cool!
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"
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
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.
"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.
Ever wondered why those routers at your ISP don't have harddisks in them?
Anyways, you lost me the moment you mentioned twitter in a line with banking and telco systems. That's like bringing up the bobbycar in a discussion about jet engines.
*(sorry the reply button wasnt under your comment before)
just because they dont have harddisks doesnt mean they dont run a database, remember when I said databases dont need to touch the disk.
mnesia for example was built with exactly high throughput in mind, it can sit in memory only, I do believe mnesia is used inside various routers and switches, is it not a database?
and wow, twitter isnt cool so I guess my argument sucks, the point was different people have wildly varying requirements, and while we are talking about apples vs orange, a web chat vs a router, really?
"x isnt fast enough", "y isnt scalable enough" are inane statements, there isnt enough information to possibly make that distinction, as I said in my first post, if a database gives me extra functionality while satisfying every other of my constraints, its by definition "not doing it wrong"
repeating myself again, but we were arguing a hypothetical specification and the general statement "but using a DB for chat is a really bad idea."
that aside, the authors requirements for the application were pretty obviously to build something kinda fun using couchdb, he satisfied those requirement, and is obviously not "doing it wrong"
but next time you get into a discussion / argument like this, its usually a good idea to look at all points that have contradicted what you have just said, and say why they are wrong, or admit you were wrong.
saying twitter is not cool, some guys 100 lines of code isnt replacing irc tomorrow, or that routers arent using mysql are not arguments.
You were arguing for the sake of the argument, that's why I ignored most of your bullets as unrelated. You broadened the scope to "but what if his chat system needs to record all messages, brew coffee and babysit my dog, too"? Well in that case, yes, you'll need a database and lots of other things, too.
But as long as you're looking at a chat system with functionality like the one the original submitter presented, then there are good reasons for datastores (aka databases) and message brokers to remain separate entities.
I can only repeat: Twitter is not cool (it's an anti-pattern), people who don't understand IRC will keep reinventing it poorly, and a messaging system that hits the disk for each individual message needlessly (i.e. without being held to strong delivery guarantee requirements, which would be quite uncommon for a chat-system) is a waste of ressources.
We can't stop people from peeling their eyes out with forks, but we should at least refrain from defending such idiocy.
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.
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.
http://w.ebchat.com/channel/hackernews
You can do it with MySql, or with files in append mode with "message_id - message", and everything else.
I think that KV stores are great, but if you create a false sense of coolness this is going to hurt in the long run. It is important to show people why really new forms of DBs can be useful and important.
edit: If the point is instead the fact that the DB talks directly HTTP, the w.ebchat.com chat PHP layer is ridiculous, just a wrapper that takes parameters from the HTTP side and run a query returning back the data. I can only see the HTTP protocol as interface to KV DB as a good way to lost a lot of performances without a reason.