Damien Katz

2. Guy Kawasaki

2. http://ycombinator.com/

I'm not sure about ycombinator. Don't they specialize in funding college kids?

Hmmm... just checked their site, sounds like they *might* be interested in a project like mine. Worth a look.

Good suggestions guys.

What about data partitioning? At the simplest level, can I split the DB itself across multiple machine, with a single HTTP access point?

how about: http://www.simulalabs.com/

Harry, that's something I *really* want to do (it's the thing I'm most interested in long term).

BUT, first I need to build a compelling and solid single machine storage model and API, then replication. And I need to validate this thing solves real problems. It's a process, I learn as I go. And If I push too far ahead without validation, I risk building something brilliantly useless. (I've done it before ;)

So for now, I'm leaving it off the list, but not because I think it's unimportant, but because I think its too early. The design as a whole is built with massive scalability in mind, and will continue to adhere to design principles to allow for partitioning, failover and map reduce style distributed querying.

CouchDb is very much a long term project, I fully expect to be working on this for the next 5 to 10 years of my life. (hopefully it won't take near that long to introduce partitioning :)

John, thanks for simulalabs link. I hadn't heard of them.

Understood - where's my time machine ;)

"And I need to validate this thing solves real problems. It's a process, I learn as I go. And If I push too far ahead without validation, I risk building something brilliantly useless. (I've done it before ;)"

How about mediawiki? Their code is relatively clean - believe db access / queries is more or less centralized behind APIs - might be something you'd find people will to help with that doesn't require Erlang. Plus there's a real problem to solve here ( http://dammit.lt/tech/mysqluc-wikipedia-domas.pdf ) - get the feeling there's a limit to how far you can go with MySQL replication.

Partitioning should be relatively trivial, i think?

If have a central master server, and then web proxies distributing the read load.

When the write load becomes too great, hashing the document name, and treating your master servers like hash buckets.

I think wikipedia could go this route, hashing article names, which should evenly distribute the write load across multiple master servers.

I believe this is what flickr does. Binding a top level object to a particular master object, which I think in flickrs' case is the user.

Using CouchDb as a large scale, distibuted Wiki is a very cool idea I'd like to flesh out. I'm going write about that someday...