CODEWITHSUNDEEP
phpmysqlnode.jsmongodbcouchdb
Nyxynyx
Nyxynyx

Reputation: 63687

Mongodb/Couchdb instead of MySQL (Switching from PHP to Node)

I've done most of my web development using PHP/MySQL/Solr on the backend and Javascript/jQuery/Backbone on the frontend.

I've already written some Node apps, but using MySQL instead of Mongodb/Couchdb which many Node tutorials/books uses. Would you start using Mongo/Couch instead of MySQL because most people developing Node is using it? MySQL seems to work fine for me and I'm unclear of the advantages of switching to Mongo/Couch.

Right now I am starting a site where the "frontend" app server is PHP/MySQL, and the number crunching server is in Node. My reason for sticking to PHP to serve the "frontned" is because I'm extremely comfortable developing in my PHP framework.

Reason for choosing Node is because there will be alot of simultaneous tasks with idle/wait times in the order of seconds. And this has to be highly scalable.

Things that will be stored in the database are like the usual stuff you would store in a MySQL table

Upvotes: 5

Views: 1406

Answers (2)

Srikar Appalaraju
Srikar Appalaraju

Reputation: 73678

Some of the things you need to consider -

  1. Scaling is one of the most important reason we have moved to mongoDB. To shard & replicate MongoDB is a breeze. So if your application needs to scale horizontally then mongoDB is the way to go. Scaling vertically can only go so far as you will hit hardware limitations soon...Plus sharding on mysql is a real pain.
  2. Second being DB schema. In most startups like ours, requirements & features change very rapidly. So over a period of time, mysql schema based DB can be more of a bondage than a "good practice". Nobody cares about "good practices" in such situations. So if you are in need of a no-schema DB that scales then consider mongoDB.
  3. All this comes with a disclaimer that mongoDB (& other NoSql solutions) are shiny new toys in DB world. They are no where near as mature as MySQL. Most of them including mongo dont handle transactions well. So lets say you are building a financial transaction system, then I would tell you to blindly go with mysql as its ACID compliant (read innodb engine). So again lot of these decisions depend on what you are trying to accomplish...

Conclusion: Paraphrasing from NoSQL

The real thing to point out is that if you are being held back from making something super awesome because you can’t choose a database, you are doing it wrong. If you know mysql, just used it. Optimize when you actually need to. Use it like a k/v store, use it like a rdbms, but for god sake, build your killer app! None of this will matter to most apps. Facebook still uses MySQL, a lot. Wikipedia uses MySQL, a lot. FriendFeed uses MySQL, a lot. NoSQL is a great tool, but it’s certainly not going to be your competitive edge, it’s not going to make your app hot, and most of all, your users won’t give a shit about any of this.

What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe. I might also use Hadoop and Hive. I might keep everything in flat files. Maybe I’ll start hacking on Maglev. I’ll use whatever is best for the job. If I need reporting, I won’t be using any NoSQL. If I need caching, I’ll probably use Tokyo Tyrant. If I need ACIDity, I won’t use NoSQL. If I need a ton of counters, I’ll use Redis. If I need transactions, I’ll use Postgres. If I have a ton of a single type of documents, I’ll probably use Mongo. If I need to write 1 billion objects a day, I’d probably use Voldemort. If I need full text search, I’d probably use Solr. If I need full text search of volatile data, I’d probably use Sphinx.

Too Funny & too relavent to NOT Post Again - MongoDb is Web Scale

enter image description here

Upvotes: 8

Jit B
Jit B

Reputation: 1246

Unless you are heavily normalizing your data such that IO on multiple tables becomes a bottleneck, MySQL will work fine. There is no reason to switch just because most people are using mongo with node.js..

Mongodb/Couchdb/Orientdb are best suited for storing a large number of "document" objects. If your data can fit in RDBMS schema you dont need to create documents. From what I have seen the main latency in creating objects comes while populating the data fields. With NoSQL DBs you get all the data in one go while in a normalized RDBMS the data fields will be populated from different sources, resulting in a slight delay. Of course you could use caching to improve on that. If you want scalability in RDBMS, you could take a look at NuoDB.

Since your back-end app server needs scalability, you could also look into vertx. As per the benchmarks it seems to out-perform node, but it is still very new.

Upvotes: 0

Related Questions