未加星标

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

字体大小 | |
[开发(php) 所属分类 开发(php) | 发布者 店小二04 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏

I've done most of my web development usingphp/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

Problem courtesy of: Nyxynyx

Solution

Some of the things you need to consider -

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. 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. 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


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

Solution courtesy of: Srikar Appalaraju

Discussion

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.

Discussion courtesy of: Jit B

This recipe can be found in it's original form on Stack Over Flow .

本文开发(php)相关术语:php代码审计工具 php开发工程师 移动开发者大会 移动互联网开发 web开发工程师 软件开发流程 软件开发工程师

tags: use,MySQL,need,If,your
分页:12
转载请注明
本文标题:Mongodb/Couchdb instead of MySQL (Switching from PHP to Node)
本站链接:https://www.codesec.net/view/604965.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 开发(php) | 评论(0) | 阅读(13)