『壹』 千萬別用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 或者 央企 那樣對錢不在乎。