『壹』 千万别用MongoDB真的吗
Mongo DB 是目前在IT行业非常流行的一种非关系型数据库(NoSql),其灵活的数据存储方式备受当前IT从业人员的青睐。Mongo DB很好的实现了面向对象的思想(OO思想),在Mongo DB中 每一条记录都是一个Document对象。Mongo DB最大的优势在于所有的数据持久操作都无需开发人员手动编写SQL语句,直接调用方法就可以轻松的实现CRUD操作。
他有自己的适用环境而已
Mongo适合用于以下场景：
◆网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
◆缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源过载。
◆大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。
◆高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapRece引擎的内置支持。
◆用于对象及JSON数据的存储：Mongo的BSON数据格式非常适合文档化格式的存储及查询。
自然，MongoDB的使用也会有一些限制，例如它不适合：
◆高度事务性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
◆传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
『贰』 MongoDB 如何使定制电子商务变得简单
这些平台经常用作定制电子商务软件的基础，都要求使用一个 SQL 数据库。由于开源软件在适应定制功能时存在固有的挑战，现在看来 MongoDB 将在电子商务的下一轮发展进化中扮演着重要角色。Kyle Banker 是 2010 年 4 月第一批就 MongoDB 和电子商务 发表博客的人，自那以后就令人意外地很少出来此类文章。在博客中，Kyle 写到了 Magento 及其他基于 SQL 的平台：“您将看到的是，大量表格共同作用，在数据库系统基础不太灵活的型式上提供灵活的结构。”对此我们必须问，灵活的结构在电子商务中为什么如此重要？开源平台意味着可以适应许多不同的设计、折算流和商业流程。灵活的结构可以通过为开发者提供一种将自定义数据结构与平台现有模型相关联的方法，从而带来帮助。如果没有灵活的结构，开发者就必须跨越重重障碍来实现某种特殊功能。当建立和维持自定义功能的成本过高时，可以作出的选择有：放弃功能，以另一平台重新开始，或按草案建立一个平台。这些都是昂贵的提案。还有更好的方法过支几年来，我们一直在开发 Forward，这是一种与 MongoDB 相配合的新开源电子商务平台 。自 2012 年 3 月以来，它就已经投入了生产使用中，并最终印证了一点，即我们可以展示 MongoDB 的无结构设计为自定义功能开发带来的优势。以下示例展示了 Forward 与其他平台类似的 ORM 惯例，它仅在平台本身中提供，但其基本理念直接映射到了 MongoDB 的文件结构。在此情况下，考虑将 get() 作为 db.collection.find() — put() 作为 insert/update() — post() 作为 insert() — delete() 作为… delete()。更快原型化大多数电子商务网站都代表着小公司，在这里，高效执行是网络平台的最重要方面。当 MongoDB 的灵活文件结构通过平台的模型界面执行时，添加自定义字段变得比以往任何时候都更简单。例如，让我们假设您需要一种在向产品中添加多项自定义属性时进行管理的简单视图。下面是为实现该目的的基本示例，以 Forward 的模板语法编写：{args $proct_id} {if $request.post} {$proct = put("/procts/$proct_id", [ spec => $params.spec, usage => $params.usage ])} {flash notice="Saved" refresh=true} {else} {$proct = get("/procts/$proct_id")} {/if} Proct specification {$proct.spec|escape} Proct usage instructions {$proct.usage|escape} Save proct 该模板有什么作用可能很明显，但不明显的是平台对于 “spec” 或“usage” 字段一无所知，但对待它们的方式却好象电子商务数据模型专为它们而设计。数据库完全无需迁移，只有代码需要。您可能反驳称，这可以通过模糊 SQL 数据库结构来实现，您也可能是对的，但它对于标准数据库工具来说不完美，或者说无法读取。在自定义字段上的 Ad-hoc 查询会变得很困难。自定义字段上的查询如果我们所需要的是自定义密钥/价值存储，那么您可能不会从灵活结构中受益太多。MongoDB 真正耀眼之处是其在任何文件字段（甚至包括嵌入式文件）上查询的能力。 {get $oversized_procts from "/procts" [ oversized => true, active => true ]} 这里有 {$oversized_procts.count} 活动的超大产品这些字段可能也可能不为电子商务 API 所知，但在此情况下，MongoDB 的查询语法只能找到具有匹配字段的文件。不再有关系复杂性对于那些花费数年时间编写关系 SQL 查询的人，这是一大改变。没有连接我们如何创建数据关系？有很多种不同的战略，但 Forward 将一个字段定义为静态值或回拨方法。这允许一个字段根据查询返回另一个文件或集合。结果便是一个能够无需连接便浏览关系的数据模型。例如 (PHP)：// class Accounts extends AppModel ... $this->fields => array( ... 'orders' => function ($order) { return get("/orders", array('account_id' => $account['id'])); } ); 该关系可用以类似以下的模板中：{get $account from "/accounts/$session.account_id"} 您已处理 {foreach $account.orders as $order} #{$order.id} ${$order.sub_total} ${$order.grand_total} {$order.items|count} item(s) {/foreach} 关系可通过简单或复杂的查询来定义。结果为延迟载入，使该示例成为可能：{get $order from "/orders/123"} {$order.account.name} placed {$order.account.orders.count} orders since {$order.account.orders.first.date_created|date_format} // Output: John Smith placed 3 orders since Jun 14, 2012 事务怎么样？许多人提出 MongoDB 在集合中缺少原子性事务作为证据，不适合电子商务应用。迄今为止，这一直不是我们经验中的重要障碍。还有其他方法可以实现数据完整性。在具有中低数据冲突的系统中，乐观锁很充分。我们会在随后分享有关这些战略的更多细节。总结有了MongoDB，电子商务软件的未来一片光明。是时候另辟蹊径了，回旋式结构、复杂关系查询和令人恐惧的数据库迁移都已成为过去。
『叁』 使用nodejs+mongodb开发的比较著名的网站有哪些
题主的问题本身存在一些问题，首先“比较著名”的网站往往就已经有一定体量了，而具备了一定体量的网站很难只用一种语言或一种方案就能开发了，基本是多个语言互相配合。只能说是“主体”是某个语言开发的，这里的“主体”还很可能并不指占多数。
如果是这样的话，国内的很多网站都已经应用了 Node.js+MongoDB，像 BAT（现在应该叫 AT？）这种级别的公司不只一个产品线，很多产品线的主要开发都是这样的技术选型。
国外的 Uber（优步）、LinkedIn（领英）有较大规模的应用部署该方案。
『肆』 mongoDB适用什么场合呢
根据官方网站的描述，Mongo适合用于以下场景：
◆网站数据：Mongo非常适合实时的插入，更新与查询，并具备网站实时数据存储所需的复制及高度伸缩性。
◆缓存：由于性能很高，Mongo也适合作为信息基础设施的缓存层。在系统重启之后，由Mongo搭建的持久化缓存层可以避免下层的数据源过载。
◆大尺寸，低价值的数据：使用传统的关系型数据库存储一些数据时可能会比较昂贵，在此之前，很多时候程序员往往会选择传统的文件进行存储。
◆高伸缩性的场景：Mongo非常适合由数十或数百台服务器组成的数据库。Mongo的路线图中已经包含对MapRece引擎的内置支持。
◆用于对象及JSON数据的存储：Mongo的BSON数据格式非常适合文档化格式的存储及查询。
自然，MongoDB的使用也会有一些限制，例如它不适合：
◆高度事务性的系统：例如银行或会计系统。传统的关系型数据库目前还是更适用于需要大量原子性复杂事务的应用程序。
◆传统的商业智能应用：针对特定问题的BI数据库会对产生高度优化的查询方式。对于此类应用，数据仓库可能是更合适的选择。
『伍』 一个大型的SNS网站，是否适合数据库全部用mongodb来做，为什么
我才疏学浅，稍微给点拙见。
1、如果是突出“大型”，mongodb3确实适合。mongodb3改善了集群的能力。
2、从服务器稳定性方面来说，mongodb3确实不错。
3、安全性方面的考虑，mongodb3是能控制安全性的。不一定全部都先存内存，也可以强制存盘的。
凡事有好必有坏，以上3点的代价是成本也相对增加。
SNS虽然总体比不过MMORPG，但是也有相当大的用户群。作为游戏来讲，做得好的话，应该很容易达到大数据级别。所以从这个角度来看，mongodb3还是很必要的。
不过，我看你的意思是想部分使用mongodb来做。如果使用2种以上数据库。
1、在技术方面，数据不好统一维护，势必拖慢开发效率。
2、成本也相对提高，如果是mongodb和sql一起的话，那么在大数据方面，sql将无法承受为了应付大数据而付出的高昂费用。或者sql只承担少部分任务，但是sql很可能要另外配置机器，这也是提高了成本。因为mongodb偏重内存，而sql很可能偏重磁盘容量。
『陆』 用mongodb作为数据库服务器访问时非常慢
你查看一下，如果数据文件大于系统内存，查询速度会下降几个数量级，因为mongodb是内存数据库。我以前测试过，1000万数据的时候没有索引情况下查询可能会几秒钟甚至更久。
这种情况，你最好给经常查询的项创建索引，有索引以后查询速度会非常非常非常的快。
另外一点是数据索引如果大于内存，速度也会下降很多。而且对于多条件查询，如果你查询的顺学和索引顺序不同，也不能使用索引。这个要慢慢摸索
如果你使用了replica set，这个会影响写入速度的，三个replica set，速度会降低到三分之一。
大概主要影响速度的就是这几点吧，如果你需求不是非常复杂，我以前测试mongodb速度方面优化好的情况下还是可以接受的。希望能帮到你
『柒』 各位大哥能借一个csdn账号吗，需要下载一个基于nodejs+mongodb/mysql完成一个电子商务系统
你还不如自己注册一个账号快点，不会有人出借账号的，毕竟下载积分都是要钱充值，攒的不容易。
『捌』 用php+mysql 还是 nodejs+mongodb 开发网站好
看项目和客户的要求了，哪个合适用哪个。php+mysql也可以搭配angular，NodeJS照样能用Mysql，没有什么东西是必须的。PHP和NodeJS的最大差别在于NodeJS的非阻塞模式，不过不是所有的应用对于阻塞的要求都那么极端。
『玖』 mongodb数据库有哪些优势
1. 文档存储
数据存储以BSON/JSON文档，这对于Web应用程序有很大的意义。开发者API喜欢以JSON形式传输，这使得整个项目的数据表示可采用统一的模型。所有这一切都无需任何前期架构设计。
2. 可扩展性
MongoDB被用在一些规模庞大的环境中，FourSquare/Craiglist都在使用它。通过分片数据缩放处理理论上可实现更高的吞吐量。
3. 简单的复制
就像分片技术一样，MongoDB范围内复制过程同样简单好用，在副本机器上还有大量的复制选项。灵活的功能可满足用户应用的需求。
4. 易于查询
MongoDB以文档的形式存储数据，不支持事务和表连接。因此查询的编写、理解和优化都容易得多。简单查询设计思路不同于SQL模式，嵌入文档在特定的环境下可得到更好的查询，然而这需要先加入集合。如果需要执行多个请求到数据库则需要加入其到客户端。在MongoDB时ODM工具（如Doctrine2）将发挥自身的优势。
5. 安全性
由于MongoDB客户端生成的查询为BSON对象，而不是可以被解析的字符串，所以可降低受到SQL注入的攻击的危险。最常见的攻击类型为针对Web应用程序的攻击，在MongoDB上使用Doctrine2 ODMs 查询语言可减轻攻击风险。
6. 支持
用户在选择数据库时总是喜欢积极和充满活力的，这点非常重要。MongoDB在业界有非常大的影响力，用户也会定期的组织活动。MongoDB的标签在StackOverFlow是非常活跃的。你永远不会陷入困境，因为总有人与你讨论并解决问题。
7. 价格
MongoDB是免费的！
当然远不止这些优势，但是也有很多劣势。
『拾』 一个互联网在线电子商务网站用到MongoDB,Redis,Oracle三种数据库是否可行
个人推荐你使用 MongoDB，现在架构相比较以前是齐全了很多，结构上与PG不相伯仲。
Redis 做分布式架构虽然也适合用于 Web 的Inno DB 架构形式的业务系统，但使用的效果会在业务量增大之后 显得动力不足。
不推荐你用Oracle 因为电子商务这种商务公司 根本就买不起Oracle，不像ZF 或者 央企 那样对钱不在乎。