4 ms·
Apache CouchDB 0.9 has been released
- coconutrandom 18y agoHmmm, if only there was a database-as-a-service provider for CouchDB. I, for one, would subscribe to our distributed, document based overlords.
- geuis 18y agoSo you're thinking of a database-in-the-cloud concept?
- coconutrandom 18y agoSpecifically CouchDB. Not SimpleDB or Google's Big Table. I've played with CouchDB and Python and I like it but it's overkill for my tiny just for fun projects, but if it turned out more cost effective to host in-house in the future, not having the lock-in is super attractive.
- Tichy 18y agoIf CouchDB is overkill, how simple are your projects? I thought CouchDB is supposed to be as simple as it gets?
- coconutrandom 18y agoto clarify: too simple to justify upgrading my host and installing when mysql is a button push away.
- geuis 18y agoI like the concept. There could be an interesting business idea here. One of the problems that concerns me is speed of data access. If I'm running the service on AWS, your app will need fast access to your data. If you are hosting your app on AWS, why not run couchDB yourself? You will get much better speeds utilizing the cloud service's internal infrastructure rather than accessing your data via the internet. If you are hosting your web service somewhere else, then why not use the database solutions provided there? I'm just trying to understand the need for this kind of service.
- olegp 18y agoYou could run standalone apps made up of static JavaScript, HTML and CSS where the browser clients talk directly to CouchDB. Check this out: http://books.couchdb.org/relax/hosted-applications http://books.couchdb.org/relax/hosted-applications
- olegp 18y agoWhat would you use it for? Also, how would one go about implementing something like this in practice? CouchDB isn't truly distributed, so one would need to run multiple isolated instances which would in turn impose restrictions on the size of a single database as well as the number of concurrent writes. I've been toying with the idea of writing a CouchDB interface on top of HBase (or possibly some other column oriented DBMS) to overcome these issues and am wondering if anyone else has considered doing the same thing.
- coconutrandom 18y agoWhat ~couldn't~ you use it for? I'm not so sure about the isolated part. If I recall correctly, all instances should have the same data. Hence the size of a given database should match on all instances. And why restrict the size? ...just charge per mb and put the onus on the user.
- reconbot 18y agoI thought you could write a javascript function to filter out datasets for each server, the client then queries multiple servers looking for what it wants?
- old-gregg 18y agoCan anyone point me to a good technical review/discussion which is favorable to CouchDB? I've spent a lot of time reading their documentation and I didn't "get it". I am afraid I'm not smart enough to understand why running your queries in a form of two JavaScript functions can be faster or more convenient than mighty SQL. Frankly, I am also not into "distributed" thing either since I haven't seen a startup (with my own eyes) that had such insane load requirements $1K MySQL hardware couldn't easily handle. However, I realize that authors didn't spend all that time implementing something without a real need for, I just haven't discovered it yet - most of CouchDB stuff I was able to find was mostly tutorials, docs, etc but I wish I could find a systems architect blog post titled "How CouchDB saved our ass".
- evgen 18y agoThis is mostly an "it depends" sort of issue. Most people/sites don't really need a big SQL engine to store their data but follow the path of least-resistance in that general direction. CouchDB is a part of a growing movement away from general-purpose RDBMs towards task-specific data engines and from the world where ACID was all that mattered to one where the BASE model can provide an alternative set of benefits. What CouchDB gives you are 1) schema-less data storage (so you can change your data schema on the fly), 2) built-in map-reduce that lets you perform some queries faster (at the cost of needing to re-think how you perform certain SQL JOIN queries), 3) an easy path towards data distribution, and 4) a database that is accessed via HTTP using REST principles. Running your queries in a couple of Javascript functions (or python functions, or ruby functions, or any other language that has a view server) is not necessarily faster than SQL and in fact is probably slower. What makes it faster and more scalable is the built-in map/reduce primitives that these functions are using. Since the db is accessed via HTTP, the data format is JSON, and you can create queries using Javascript this system also introduces the intriguing possibility that you can cut the app server out of the picture and write web apps that interact directly with the data. Different strokes and all that.
- charlesju 18y agoHere is the simple answer: SQL does not scale out to multiple databases easily, CloudDB does. And I know many startups where the above is not true, in fact, any successful startup hits a major bottleneck when they have to distribute MySQL. It's not a function of money, it's a function of the time and expertise to implement sharding well.
- fizx 18y agoPlease tell me that this release of CouchDB isn't slllloooowwwww. Like 2-3 orders of magnitude slower than MySQL that it's been.