您好，我來為您解答：
網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、成都微信小程序、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了涿鹿免費(fèi)建站歡迎大家使用！
最好能換下
郵件服務(wù)器
試試看，很有可能源頭是郵件服務(wù)器的處理有問題。
如果我的回答沒能幫助您，請繼續(xù)追問。
NoSQL，泛指非關(guān)系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關(guān)系數(shù)據(jù)庫在應(yīng)付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關(guān)系型的數(shù)據(jù)庫則由于其本身的特點(diǎn)得到了非常迅速的發(fā)展。NoSQL數(shù)據(jù)庫的產(chǎn)生就是為了解決大規(guī)模數(shù)據(jù)集合多重數(shù)據(jù)種類帶來的挑戰(zhàn)，尤其是大數(shù)據(jù)應(yīng)用難題。
雖然NoSQL流行語火起來才短短一年的時間，但是不可否認(rèn)，現(xiàn)在已經(jīng)開始了第二代運(yùn)動。盡管早期的堆棧代碼只能算是一種實驗，然而現(xiàn)在的系統(tǒng)已經(jīng)更加的成熟、穩(wěn)定。不過現(xiàn)在也面臨著一個嚴(yán)酷的事實：技術(shù)越來越成熟——以至于原來很好的NoSQL數(shù)據(jù)存儲不得不進(jìn)行重寫，也有少數(shù)人認(rèn)為這就是所謂的2.0版本。這里列出一些比較知名的工具，可以為大數(shù)據(jù)建立快速、可擴(kuò)展的存儲庫。
NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，是一項全新的數(shù)據(jù)庫革命性運(yùn)動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護(hù)者們提倡運(yùn)用非關(guān)系型的數(shù)據(jù)存儲，相對于鋪天蓋地的關(guān)系型數(shù)據(jù)庫運(yùn)用，這一概念無疑是一種全新的思維的注入。
對于NoSQL并沒有一個明確的范圍和定義，但是他們都普遍存在下面一些共同特征：
不需要預(yù)定義模式：不需要事先定義數(shù)據(jù)模式，預(yù)定義表結(jié)構(gòu)。數(shù)據(jù)中的每條記錄都可能有不同的屬性和格式。當(dāng)插入數(shù)據(jù)時，并不需要預(yù)先定義它們的模式。
無共享架構(gòu)：相對于將所有數(shù)據(jù)存儲的存儲區(qū)域網(wǎng)絡(luò)中的全共享架構(gòu)。NoSQL往往將數(shù)據(jù)劃分后存儲在各個本地服務(wù)器上。因為從本地磁盤讀取數(shù)據(jù)的性能往往好于通過網(wǎng)絡(luò)傳輸讀取數(shù)據(jù)的性能，從而提高了系統(tǒng)的性能。
彈性可擴(kuò)展：可以在系統(tǒng)運(yùn)行的時候，動態(tài)增加或者刪除結(jié)點(diǎn)。不需要停機(jī)維護(hù)，數(shù)據(jù)可以自動遷移。
分區(qū)：相對于將數(shù)據(jù)存放于同一個節(jié)點(diǎn)，NoSQL數(shù)據(jù)庫需要將數(shù)據(jù)進(jìn)行分區(qū)，將記錄分散在多個節(jié)點(diǎn)上面。并且通常分區(qū)的同時還要做復(fù)制。這樣既提高了并行性能，又能保證沒有單點(diǎn)失效的問題。
異步復(fù)制：和RAID存儲系統(tǒng)不同的是，NoSQL中的復(fù)制，往往是基于日志的異步復(fù)制。這樣，數(shù)據(jù)就可以盡快地寫入一個節(jié)點(diǎn)，而不會被網(wǎng)絡(luò)傳輸引起遲延。缺點(diǎn)是并不總是能保證一致性，這樣的方式在出現(xiàn)故障的時候，可能會丟失少量的數(shù)據(jù)。
BASE：相對于事務(wù)嚴(yán)格的ACID特性，NoSQL數(shù)據(jù)庫保證的是BASE特性。BASE是最終一致性和軟事務(wù)。
NoSQL數(shù)據(jù)庫并沒有一個統(tǒng)一的架構(gòu)，兩種NoSQL數(shù)據(jù)庫之間的不同，甚至遠(yuǎn)遠(yuǎn)超過兩種關(guān)系型數(shù)據(jù)庫的不同?？梢哉f，NoSQL各有所長，成功的NoSQL必然特別適用于某些場合或者某些應(yīng)用，在這些場合中會遠(yuǎn)遠(yuǎn)勝過關(guān)系型數(shù)據(jù)庫和其他的NoSQL。
1. CouchDB
所用語言： Erlang
特點(diǎn)：DB一致性，易于使用
使用許可： Apache
協(xié)議： HTTP/REST
雙向數(shù)據(jù)復(fù)制，
持續(xù)進(jìn)行或臨時處理，
處理時帶沖突檢查，
因此，采用的是master-master復(fù)制（見編注2）
MVCC – 寫操作不阻塞讀操作
可保存文件之前的版本
Crash-only（可靠的）設(shè)計
需要不時地進(jìn)行數(shù)據(jù)壓縮
視圖：嵌入式 映射/減少
格式化視圖：列表顯示
支持進(jìn)行服務(wù)器端文檔驗證
支持認(rèn)證
根據(jù)變化實時更新
支持附件處理
因此， CouchApps（獨(dú)立的 js應(yīng)用程序）
需要 jQuery程序庫
最佳應(yīng)用場景：適用于數(shù)據(jù)變化較少，執(zhí)行預(yù)定義查詢，進(jìn)行數(shù)據(jù)統(tǒng)計的應(yīng)用程序。適用于需要提供數(shù)據(jù)版本支持的應(yīng)用程序。
例如： CRM、CMS系統(tǒng)。 master-master復(fù)制對于多站點(diǎn)部署是非常有用的。
（編注2：master-master復(fù)制：是一種數(shù)據(jù)庫同步方法，允許數(shù)據(jù)在一組計算機(jī)之間共享數(shù)據(jù)，并且可以通過小組中任意成員在組內(nèi)進(jìn)行數(shù)據(jù)更新。）
2. Redis
所用語言：C/C++
特點(diǎn)：運(yùn)行異?？?/p>
使用許可： BSD
協(xié)議：類 Telnet
有硬盤存儲支持的內(nèi)存數(shù)據(jù)庫，
但自2.0版本以后可以將數(shù)據(jù)交換到硬盤（注意， 2.4以后版本不支持該特性?。?/p>
Master-slave復(fù)制（見編注3）
雖然采用簡單數(shù)據(jù)或以鍵值索引的哈希表，但也支持復(fù)雜操作，例如 ZREVRANGEBYSCORE。
INCR co （適合計算極限值或統(tǒng)計數(shù)據(jù)）
支持 sets（同時也支持 union/diff/inter）
支持列表（同時也支持隊列；阻塞式 pop操作）
支持哈希表（帶有多個域的對象）
支持排序 sets（高得分表，適用于范圍查詢）
Redis支持事務(wù)
支持將數(shù)據(jù)設(shè)置成過期數(shù)據(jù)（類似快速緩沖區(qū)設(shè)計）
Pub/Sub允許用戶實現(xiàn)消息機(jī)制
最佳應(yīng)用場景：適用于數(shù)據(jù)變化快且數(shù)據(jù)庫大小可遇見（適合內(nèi)存容量）的應(yīng)用程序。
例如：股票價格、數(shù)據(jù)分析、實時數(shù)據(jù)搜集、實時通訊。
（編注3：Master-slave復(fù)制：如果同一時刻只有一臺服務(wù)器處理所有的復(fù)制請求，這被稱為
Master-slave復(fù)制，通常應(yīng)用在需要提供高可用性的服務(wù)器集群。）
3. MongoDB
所用語言：C++
特點(diǎn)：保留了SQL一些友好的特性（查詢，索引）。
使用許可： AGPL（發(fā)起者： Apache）
協(xié)議： Custom, binary（ BSON）
Master/slave復(fù)制（支持自動錯誤恢復(fù)，使用 sets 復(fù)制）
內(nèi)建分片機(jī)制
支持 javascript表達(dá)式查詢
可在服務(wù)器端執(zhí)行任意的 javascript函數(shù)
update-in-place支持比CouchDB更好
在數(shù)據(jù)存儲時采用內(nèi)存到文件映射
對性能的關(guān)注超過對功能的要求
建議最好打開日志功能（參數(shù) –journal）
在32位操作系統(tǒng)上，數(shù)據(jù)庫大小限制在約2.5Gb
空數(shù)據(jù)庫大約占 192Mb
采用 GridFS存儲大數(shù)據(jù)或元數(shù)據(jù)（不是真正的文件系統(tǒng)）
最佳應(yīng)用場景：適用于需要動態(tài)查詢支持；需要使用索引而不是 map/reduce功能；需要對大數(shù)據(jù)庫有性能要求；需要使用
CouchDB但因為數(shù)據(jù)改變太頻繁而占滿內(nèi)存的應(yīng)用程序。
例如：你本打算采用 MySQL或 PostgreSQL，但因為它們本身自帶的預(yù)定義欄讓你望而卻步。
4. Riak
所用語言：Erlang和C，以及一些Javascript
特點(diǎn)：具備容錯能力
使用許可： Apache
協(xié)議： HTTP/REST或者 custom binary
可調(diào)節(jié)的分發(fā)及復(fù)制(N, R, W)
用 JavaScript or Erlang在操作前或操作后進(jìn)行驗證和安全支持。
使用JavaScript或Erlang進(jìn)行 Map/reduce
連接及連接遍歷：可作為圖形數(shù)據(jù)庫使用
索引：輸入元數(shù)據(jù)進(jìn)行搜索（1.0版本即將支持）
大數(shù)據(jù)對象支持（ Luwak）
提供“開源”和“企業(yè)”兩個版本
全文本搜索，索引，通過 Riak搜索服務(wù)器查詢（ beta版）
支持Masterless多站點(diǎn)復(fù)制及商業(yè)許可的 SNMP監(jiān)控
最佳應(yīng)用場景：適用于想使用類似 Cassandra（類似Dynamo）數(shù)據(jù)庫但無法處理
bloat及復(fù)雜性的情況。適用于你打算做多站點(diǎn)復(fù)制，但又需要對單個站點(diǎn)的擴(kuò)展性，可用性及出錯處理有要求的情況。
例如：銷售數(shù)據(jù)搜集，工廠控制系統(tǒng)；對宕機(jī)時間有嚴(yán)格要求；可以作為易于更新的 web服務(wù)器使用。
5. Membase
所用語言： Erlang和C
特點(diǎn)：兼容 Memcache，但同時兼具持久化和支持集群
使用許可： Apache 2.0
協(xié)議：分布式緩存及擴(kuò)展
非?？焖伲?00k+/秒），通過鍵值索引數(shù)據(jù)
可持久化存儲到硬盤
所有節(jié)點(diǎn)都是唯一的（ master-master復(fù)制）
在內(nèi)存中同樣支持類似分布式緩存的緩存單元
寫數(shù)據(jù)時通過去除重復(fù)數(shù)據(jù)來減少 IO
提供非常好的集群管理 web界面
更新軟件時軟無需停止數(shù)據(jù)庫服務(wù)
支持連接池和多路復(fù)用的連接代理
最佳應(yīng)用場景：適用于需要低延遲數(shù)據(jù)訪問，高并發(fā)支持以及高可用性的應(yīng)用程序
例如：低延遲數(shù)據(jù)訪問比如以廣告為目標(biāo)的應(yīng)用，高并發(fā)的 web 應(yīng)用比如網(wǎng)絡(luò)游戲（例如 Zynga）
6. Neo4j
所用語言： Java
特點(diǎn)：基于關(guān)系的圖形數(shù)據(jù)庫
使用許可： GPL，其中一些特性使用 AGPL/商業(yè)許可
協(xié)議： HTTP/REST（或嵌入在 Java中）
可獨(dú)立使用或嵌入到 Java應(yīng)用程序
圖形的節(jié)點(diǎn)和邊都可以帶有元數(shù)據(jù)
很好的自帶web管理功能
使用多種算法支持路徑搜索
使用鍵值和關(guān)系進(jìn)行索引
為讀操作進(jìn)行優(yōu)化
支持事務(wù)（用 Java api）
使用 Gremlin圖形遍歷語言
支持 Groovy腳本
支持在線備份，高級監(jiān)控及高可靠性支持使用 AGPL/商業(yè)許可
最佳應(yīng)用場景：適用于圖形一類數(shù)據(jù)。這是 Neo4j與其他nosql數(shù)據(jù)庫的最顯著區(qū)別
例如：社會關(guān)系，公共交通網(wǎng)絡(luò)，地圖及網(wǎng)絡(luò)拓譜
7. Cassandra
所用語言： Java
特點(diǎn)：對大型表格和 Dynamo支持得最好
使用許可： Apache
協(xié)議： Custom, binary (節(jié)約型)
可調(diào)節(jié)的分發(fā)及復(fù)制(N, R, W)
支持以某個范圍的鍵值通過列查詢
類似大表格的功能：列，某個特性的列集合
寫操作比讀操作更快
基于 Apache分布式平臺盡可能地 Map/reduce
我承認(rèn)對 Cassandra有偏見，一部分是因為它本身的臃腫和復(fù)雜性，也因為 Java的問題（配置，出現(xiàn)異常，等等）
最佳應(yīng)用場景：當(dāng)使用寫操作多過讀操作（記錄日志）如果每個系統(tǒng)組建都必須用 Java編寫（沒有人因為選用
Apache的軟件被解雇）
例如：銀行業(yè)，金融業(yè)（雖然對于金融交易不是必須的，但這些產(chǎn)業(yè)對數(shù)據(jù)庫的要求會比它們更大）寫比讀更快，所以一個自然的特性就是實時數(shù)據(jù)分析
8. HBase
（配合 ghshephard使用）
所用語言： Java
特點(diǎn)：支持?jǐn)?shù)十億行X上百萬列
使用許可： Apache
協(xié)議：HTTP/REST （支持 Thrift，見編注4）
在 BigTable之后建模
采用分布式架構(gòu) Map/reduce
對實時查詢進(jìn)行優(yōu)化
高性能 Thrift網(wǎng)關(guān)
通過在server端掃描及過濾實現(xiàn)對查詢操作預(yù)判
支持 XML, Protobuf, 和binary的HTTP
Cascading, hive, and pig source and sink modules
基于 Jruby（ JIRB）的shell
對配置改變和較小的升級都會重新回滾
不會出現(xiàn)單點(diǎn)故障
堪比MySQL的隨機(jī)訪問性能
最佳應(yīng)用場景：適用于偏好BigTable:)并且需要對大數(shù)據(jù)進(jìn)行隨機(jī)、實時訪問的場合。
例如： Facebook消息數(shù)據(jù)庫（更多通用的用例即將出現(xiàn)）
編注4：Thrift
是一種接口定義語言，為多種其他語言提供定義和創(chuàng)建服務(wù)，由Facebook開發(fā)并開源。
當(dāng)然，所有的系統(tǒng)都不只具有上面列出的這些特性。這里我僅僅根據(jù)自己的觀點(diǎn)列出一些我認(rèn)為的重要特性。與此同時，技術(shù)進(jìn)步是飛速的，所以上述的內(nèi)容肯定需要不斷更新。我會盡我所能地更新這個列表。
您好
雖然關(guān)系數(shù)據(jù)庫已有諸多不便，但以NoSQL目前的發(fā)展?fàn)顩r要代替他還為時過早，并且至少從目前來看，他們也各有所長，誰也替代不了誰。SQL語句的方便在許多情況下還是相當(dāng)實用，SQL數(shù)據(jù)庫軟件的強(qiáng)壯程度度也是NoSQL數(shù)據(jù)庫軟件目前無法達(dá)到的。NoSQL在許多領(lǐng)域，比如高速緩存，高速消息隊列方面有著傳統(tǒng)關(guān)系數(shù)據(jù)庫無法比擬的優(yōu)勢，他們將在今后一些年并駕齊驅(qū)，至于未來的方向還得看在實際使用和進(jìn)一步開發(fā)中遇到的問題。這里有一篇譯自Redis（一種近年來發(fā)展迅速的NoSQL數(shù)據(jù)庫）官方網(wǎng)站的介紹文章，對NoSQL的特性可窺一斑。
這個要看你的應(yīng)用范圍、場景
關(guān)系數(shù)據(jù)庫經(jīng)過幾十年的發(fā)展，已經(jīng)非常成熟，但同時也存在不足：
表結(jié)構(gòu)是強(qiáng)約束的，業(yè)務(wù)變更時擴(kuò)充很麻煩。
如果對大數(shù)據(jù)量的表進(jìn)行統(tǒng)計運(yùn)算，I/O會很高，因為即使只針對某列進(jìn)行運(yùn)算，也需要將整行數(shù)據(jù)讀入內(nèi)存。
全文搜索只能使用 Like 進(jìn)行整表掃描，性能非常低。
針對這些不足，產(chǎn)生了不同的 NoSQL 解決方案，在某些場景下比關(guān)系數(shù)據(jù)庫更有優(yōu)勢，但同時也犧牲了某些特性，所以不能片面的迷信某種方案，應(yīng)將其作為 SQL 的有利補(bǔ)充。
NoSQL != No SQL，而是：
NoSQL = Not Only SQL
典型的 NoSQL 方案分為4類：
Redis 是典型，其 value 是具體的數(shù)據(jù)結(jié)構(gòu)，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被稱為數(shù)據(jù)結(jié)構(gòu)服務(wù)器。
以 list 為例：
LPOP key 是移除并返回隊列左邊的第一個元素。
如果用關(guān)系數(shù)據(jù)庫就比較麻煩了，需要操作：
Redis 的缺點(diǎn)主要體現(xiàn)在不支持完成的ACID事務(wù)，只能保證隔離性和一致性，無法保證原子性和持久性。
最大的特點(diǎn)是 no-schema，無需在使用前定義字段，讀取一個不存在的字段也不會導(dǎo)致語法錯誤。
特點(diǎn)：
以電商為例，不同商品的屬性差異很大，如冰箱和電腦，這種差異性在關(guān)系數(shù)據(jù)庫中會有很大的麻煩，而使用文檔數(shù)據(jù)庫則非常方便。
文檔數(shù)據(jù)庫的主要缺點(diǎn)：
關(guān)系數(shù)據(jù)庫是按行來存儲的，列式數(shù)據(jù)庫是按照列來存儲數(shù)據(jù)。
按行存儲的優(yōu)勢：
在某些場景下，這些優(yōu)勢就成為劣勢了，例如，計算超重人員的數(shù)據(jù)，只需要讀取體重這一列進(jìn)行統(tǒng)計即可，但行式存儲會將整行數(shù)據(jù)讀取到內(nèi)存中，很浪費(fèi)。
而列式存儲中，只需要讀取體重這列的數(shù)據(jù)即可，I/O 將大大減少。
除了節(jié)省I/O，列式存儲還有更高的壓縮比，可以節(jié)省存儲空間。普通行式數(shù)據(jù)庫的壓縮比在 3:1 到 5:1 左右，列式數(shù)據(jù)庫在 8:1 到 30:1，因為單個列的數(shù)據(jù)相似度更高。
列式存儲的隨機(jī)寫效率遠(yuǎn)低于行式存儲，因為行式存儲時同一行多個列都存儲在連續(xù)空間中，而列式存儲將不同列存儲在不連續(xù)的空間。
一般將列式存儲應(yīng)用在離線大數(shù)據(jù)分析統(tǒng)計場景，因為這時主要針對部分列進(jìn)行操作，而且數(shù)據(jù)寫入后無須更新。
關(guān)系數(shù)據(jù)庫通過索引進(jìn)行快速查詢，但在全文搜索的情景下，索引就不夠了，因為：
假設(shè)有一個交友網(wǎng)站，信息表如下：
需要匹配性別、地點(diǎn)、語言列。
需要匹配性別、地點(diǎn)、愛好列。
實際搜索中，各種排列組合非常多，關(guān)系數(shù)據(jù)庫很難支持。
全文搜索引擎是使用 倒排索引 技術(shù)，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：
所以特別適合根據(jù)關(guān)鍵詞來查詢文檔內(nèi)容。
上面介紹了幾種典型的NoSQL方案，及各自的適用場景和特點(diǎn)，您可以根據(jù)實際需求進(jìn)行選擇。
重慶分公司
重慶分公司
