Top Reasons to Take A Closer Look at CouchDB for Your Next Project
I had been looking at MySQL alternatives for some time, and have been watching the “No SQL” movement grow. About a month ago I finally decided to take the plunge and selected CouchDB as the default storage mechanism for my applications moving forward.
I was originally drawn to CouchDB because of its use of JSON directly and its amazing replication. As I started migrating my code I quickly discovered what web-dev life was like without SQL. And I liked it.
[raw]What I Realized About SQL
Here are some issues I have with SQL, a lot of which I never really thought about because I had always used it for web applications:
- I was spending a lot of time managing the DB schema. This includes setting data types and sizes, table structures, constraints, and so forth. Adding and removing new fields and indexes to match my code. Journaling any changes during development so when I pushed the code live I made them on the live db as well.
- I was normalizing all pieces of data as if it was scientific in nature, sometimes comically so. This is because all content must be type casted into specific definitions and limitations. VARCHAR(30) needs to become VARCHAR(255) or TEXT, etc. Doing this incorrectly can yield headaches and performance issues.
- I realized how tedious the act of cramming multidimensional data (ie; real life) into SQL’s two dimensional “row vs. col” system was. Not only was it tedious, it was also time consuming due to the need for linking tables, JOIN statements and so forth.
What I Like About CouchDB
- Once you get the knack of it, web development is simplified. To add a field to an existing document or create a new document type entirely, I just start saving it that way.
- CouchDB trades off consistency in return for vastly superior availability and partition tolerance. The CouchDB Guide has a great diagram showing how this compares to SQL/RDBMS.
- I do not have to perform any data normalization unless I want to in my code. There I can do it in a consistent, automatic and modular way that is user friendly. Nothing is less user friendly than a SQL error.
- Why constrain the data in 3 places: the browser (JavaScript), the app server (PHP), and the DB (DB constraints and stored procedures)? Using JSON and AJAX I can do it all on the app server, with the best possible user experience.
- CouchDB documents are stored and managed as JSON documents. Being able to load and store nested arrays directly is awesome. This is doubly true since I use JSON between the server and browser. This uniformity greatly simplifies all aspects of development.
- Performance is great. CouchDB trades slower writing for fast reading which is ideal for a huge range of applications: from web CMS to data warehousing.
- Not only is CouchDB ACID compliant, but it uses a ‘crash-only’ design where the data on disk is always consistent. You can read more about this on the CouchDB overview page. If you’ve ever had to recover a SQL DB after a server crash you know how time consuming and hair raising that can be. This avoids it entirely.
- CouchDB is designed from the ground up to do multi-master replication. It will become consistent even if peers are disconnected for long periods of time and working independently. For simplier apps no extra work is needed to scale it across multiple servers.
- You can set up PHP to use CouchDB as the storage medium for session information, allowing you to cluster PHP app servers even over long distances and fail users over seamlessly.
- It’s licensed under the Apache 2.0 License and is not owned by a corporation. It places minimal burden on me as a developer to use and distribute with my software.
Retooling to use CouchDB instead of SQL was not a quick process, but the rewards of easier development and greatly improved scalability and reliability made it hugely worth it. I highly recommend checking it out!
[/raw]
Hi,
Great article… I was really searching for this…
however, I have some doubts…
1. In MySQL we use to have multiple databases like db_dev, db_trial, db_live and each database use to contain several tables…
but here in Couch DB – creating database is nothing but creating mysql equivalant table
and creting documents is nothing but creating mysql-table-rows…
So, is it possible in Couch DB to have multile environments (dev, trial, live etc.) ?
how can we acheive such multiple environment is Couch DB
2. In mysql –
tbl_user -> id, name, age, job_id
tbl_jobs -> id, name
in case of couch db –
tbl_user would save id, name, and job_name directly
so while we update any job name from job table … it will be very difficult to change the job names for existing users…
How to handle this….
-Nilesh
Hey Nilesh,
Yes for dev/staging/live we use a similar system of separate databases (and accounts) for each, such as applicationname_dev for dev, application_beta, etc. The “futon” CouchDB interface lets you easily create new DBs and accounts and then assign the accounts so they can only access their respective DBs.
Regarding #2 you’d want to look at generating a view to retrieve the information but yes there is a much looser relationship between data elements and it requires a different way of thinking, you can’t just do a SELECT/JOIN to merge the data together on the fly. On the other hand creating a view to do the equivalent is going to be much, much faster when reading.
hi, I’m looking for a hosting company I can host couchdb on with extra servers for application processing. Have you found any good ones that you are able to configure as you want running FreeBSD with the possibility of scaling up the database and servers.
Cheers Ben
Hey Ben, we can definitely help and have a number of datacenter / hosting providers we work with regularly. Give us a shout via our contact form: https://www.ateamsystems.com/contact/ and we can see what makes the most sense!