特點：
我們提供的服務有：成都做網(wǎng)站、網(wǎng)站制作、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、魚臺ssl等。為成百上千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的魚臺網(wǎng)站制作公司
它們可以處理超大量的數(shù)據(jù)。
它們運行在便宜的PC服務器集群上。
PC集群擴充起來非常方便并且成本很低，避免了“sharding”操作的復雜性和成本。
它們擊碎了性能瓶頸。
NoSQL的支持者稱，通過NoSQL架構可以省去將Web或Java應用和數(shù)據(jù)轉換成SQL友好格式的時間，執(zhí)行速度變得更快。
“SQL并非適用于所有的程序代碼，” 對于那些繁重的重復操作的數(shù)據(jù)，SQL值得花錢。但是當數(shù)據(jù)庫結構非常簡單時，SQL可能沒有太大用處。
沒有過多的操作。
雖然NoSQL的支持者也承認關系數(shù)據(jù)庫提供了無可比擬的功能集合，而且在數(shù)據(jù)完整性上也發(fā)揮絕對穩(wěn)定，他們同時也表示，企業(yè)的具體需求可能沒有那么多。
Bootstrap支持
因為NoSQL項目都是開源的，因此它們缺乏供應商提供的正式支持。這一點它們與大多數(shù)開源項目一樣，不得不從社區(qū)中尋求支持。
優(yōu)點：
易擴展
NoSQL數(shù)據(jù)庫種類繁多，但是一個共同的特點都是去掉關系數(shù)據(jù)庫的關系型特性。數(shù)據(jù)之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。
大數(shù)據(jù)量，高性能
NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無關系性，數(shù)據(jù)庫的結構簡單。一般MySQL使用 Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的 Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了。
靈活的數(shù)據(jù)模型
NoSQL無需事先為要存儲的數(shù)據(jù)建立字段，隨時可以存儲自定義的數(shù)據(jù)格式。而在關系數(shù)據(jù)庫里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡直就是一個噩夢。這點在大數(shù)據(jù)量的web2.0時代尤其明顯。
高可用
NoSQL在不太影響性能的情況，就可以方便的實現(xiàn)高可用的架構。比如Cassandra，HBase模型，通過復制模型也能實現(xiàn)高可用。
主要應用：
Apache HBase
這個大數(shù)據(jù)管理平臺建立在谷歌強大的BigTable管理引擎基礎上。作為具有開源、Java編碼、分布式多個優(yōu)勢的數(shù)據(jù)庫，Hbase最初被設計應用于Hadoop平臺，而這一強大的數(shù)據(jù)管理工具，也被Facebook采用，用于管理消息平臺的龐大數(shù)據(jù)。
Apache Storm
用于處理高速、大型數(shù)據(jù)流的分布式實時計算系統(tǒng)。Storm為Apache Hadoop添加了可靠的實時數(shù)據(jù)處理功能，同時還增加了低延遲的儀表板、安全警報，改進了原有的操作方式，幫助企業(yè)更有效率地捕獲商業(yè)機會、發(fā)展新業(yè)務。
Apache Spark
該技術采用內存計算，從多迭代批量處理出發(fā)，允許將數(shù)據(jù)載入內存做反復查詢，此外還融合數(shù)據(jù)倉庫、流處理和圖計算等多種計算范式，Spark用Scala語言實現(xiàn)，構建在HDFS上，能與Hadoop很好的結合，而且運行速度比MapReduce快100倍。
Apache Hadoop
該技術迅速成為了大數(shù)據(jù)管理標準之一。當它被用來管理大型數(shù)據(jù)集時，對于復雜的分布式應用，Hadoop體現(xiàn)出了非常好的性能，平臺的靈活性使它可以運行在商用硬件系統(tǒng)，它還可以輕松地集成結構化、半結構化和甚至非結構化數(shù)據(jù)集。
Apache Drill
你有多大的數(shù)據(jù)集？其實無論你有多大的數(shù)據(jù)集，Drill都能輕松應對。通過支持HBase、Cassandra和MongoDB，Drill建立了交互式分析平臺，允許大規(guī)模數(shù)據(jù)吞吐，而且能很快得出結果。
Apache Sqoop
也許你的數(shù)據(jù)現(xiàn)在還被鎖定于舊系統(tǒng)中，Sqoop可以幫你解決這個問題。這一平臺采用并發(fā)連接，可以將數(shù)據(jù)從關系數(shù)據(jù)庫系統(tǒng)方便地轉移到Hadoop中，可以自定義數(shù)據(jù)類型以及元數(shù)據(jù)傳播的映射。事實上，你還可以將數(shù)據(jù)（如新的數(shù)據(jù)）導入到HDFS、Hive和Hbase中。
Apache Giraph
這是功能強大的圖形處理平臺，具有很好可擴展性和可用性。該技術已經(jīng)被Facebook采用，Giraph可以運行在Hadoop環(huán)境中，可以將它直接部署到現(xiàn)有的Hadoop系統(tǒng)中。通過這種方式，你可以得到強大的分布式作圖能力，同時還能利用上現(xiàn)有的大數(shù)據(jù)處理引擎。
Cloudera Impala
Impala模型也可以部署在你現(xiàn)有的Hadoop群集上，監(jiān)視所有的查詢。該技術和MapReduce一樣，具有強大的批處理能力，而且Impala對于實時的SQL查詢也有很好的效果，通過高效的SQL查詢，你可以很快的了解到大數(shù)據(jù)平臺上的數(shù)據(jù)。
Gephi
它可以用來對信息進行關聯(lián)和量化處理，通過為數(shù)據(jù)創(chuàng)建功能強大的可視化效果，你可以從數(shù)據(jù)中得到不一樣的洞察力。Gephi已經(jīng)支持多個圖表類型，而且可以在具有上百萬個節(jié)點的大型網(wǎng)絡上運行。Gephi具有活躍的用戶社區(qū)，Gephi還提供了大量的插件，可以和現(xiàn)有系統(tǒng)完美的集成到一起，它還可以對復雜的IT連接、分布式系統(tǒng)中各個節(jié)點、數(shù)據(jù)流等信息進行可視化分析。
MongoDB
這個堅實的平臺一直被很多組織推崇，它在大數(shù)據(jù)管理上有極好的性能。MongoDB最初是由DoubleClick公司的員工創(chuàng)建，現(xiàn)在該技術已經(jīng)被廣泛的應用于大數(shù)據(jù)管理。MongoDB是一個應用開源技術開發(fā)的NoSQL數(shù)據(jù)庫，可以用于在JSON這樣的平臺上存儲和處理數(shù)據(jù)。目前，紐約時報、Craigslist以及眾多企業(yè)都采用了MongoDB，幫助他們管理大型數(shù)據(jù)集。（Couchbase服務器也作為一個參考）。
十大頂尖公司：
Amazon Web Services
Forrester將AWS稱為“云霸主”，談到云計算領域的大數(shù)據(jù)，那就不得不提到亞馬遜。該公司的Hadoop產品被稱為EMR（Elastic Map Reduce），AWS解釋這款產品采用了Hadoop技術來提供大數(shù)據(jù)管理服務，但它不是純開源Hadoop，經(jīng)過修改后現(xiàn)在被專門用在AWS云上。
Forrester稱EMR有很好的市場前景。很多公司基于EMR為客戶提供服務，有一些公司將EMR應用于數(shù)據(jù)查詢、建模、集成和管理。而且AWS還在創(chuàng)新，F(xiàn)orrester稱未來EMR可以基于工作量的需要自動縮放調整大小。亞馬遜計劃為其產品和服務提供更強大的EMR支持，包括它的RedShift數(shù)據(jù)倉庫、新公布的Kenesis實時處理引擎以及計劃中的NoSQL數(shù)據(jù)庫和商業(yè)智能工具。不過AWS還沒有自己的Hadoop發(fā)行版。
Cloudera
Cloudera有開源Hadoop的發(fā)行版，這個發(fā)行版采用了Apache Hadoop開源項目的很多技術，不過基于這些技術的發(fā)行版也有很大的進步。Cloudera為它的Hadoop發(fā)行版開發(fā)了很多功能，包括Cloudera管理器，用于管理和監(jiān)控，以及名為Impala的SQL引擎等。Cloudera的Hadoop發(fā)行版基于開源Hadoop，但也不是純開源的產品。當Cloudera的客戶需要Hadoop不具備的某些功能時，Cloudera的工程師們就會實現(xiàn)這些功能，或者找一個擁有這項技術的合作伙伴。Forrester表示：“Cloudera的創(chuàng)新方法忠于核心Hadoop，但因為其可實現(xiàn)快速創(chuàng)新并積極滿足客戶需求，這一點使它不同于其他那些供應商。”目前，Cloudera的平臺已經(jīng)擁有200多個付費客戶，一些客戶在Cloudera的技術支持下已經(jīng)可以跨1000多個節(jié)點實現(xiàn)對PB級數(shù)據(jù)的有效管理。
Hortonworks
和Cloudera一樣，Hortonworks是一個純粹的Hadoop技術公司。與Cloudera不同的是，Hortonworks堅信開源Hadoop比任何其他供應商的Hadoop發(fā)行版都要強大。Hortonworks的目標是建立Hadoop生態(tài)圈和Hadoop用戶社區(qū)，推進開源項目的發(fā)展。Hortonworks平臺和開源Hadoop聯(lián)系緊密，公司管理人員表示這會給用戶帶來好處，因為它可以防止被供應商套牢（如果Hortonworks的客戶想要離開這個平臺，他們可以輕松轉向其他開源平臺）。這并不是說Hortonworks完全依賴開源Hadoop技術，而是因為該公司將其所有開發(fā)的成果回報給了開源社區(qū)，比如Ambari，這個工具就是由Hortonworks開發(fā)而成，用來填充集群管理項目漏洞。Hortonworks的方案已經(jīng)得到了Teradata、Microsoft、Red Hat和SAP這些供應商的支持。
IBM
當企業(yè)考慮一些大的IT項目時，很多人首先會想到IBM。IBM是Hadoop項目的主要參與者之一，F(xiàn)orrester稱IBM已有100多個Hadoop部署，它的很多客戶都有PB級的數(shù)據(jù)。IBM在網(wǎng)格計算、全球數(shù)據(jù)中心和企業(yè)大數(shù)據(jù)項目實施等眾多領域有著豐富的經(jīng)驗?！癐BM計劃繼續(xù)整合SPSS分析、高性能計算、BI工具、數(shù)據(jù)管理和建模、應對高性能計算的工作負載管理等眾多技術?！?/p>
Intel
和AWS類似，英特爾不斷改進和優(yōu)化Hadoop使其運行在自己的硬件上，具體來說，就是讓Hadoop運行在其至強芯片上，幫助用戶打破Hadoop系統(tǒng)的一些限制，使軟件和硬件結合的更好，英特爾的Hadoop發(fā)行版在上述方面做得比較好。Forrester指出英特爾在最近才推出這個產品，所以公司在未來還有很多改進的可能，英特爾和微軟都被認為是Hadoop市場上的潛力股。
MapR Technologies
MapR的Hadoop發(fā)行版目前為止也許是最好的了，不過很多人可能都沒有聽說過。Forrester對Hadoop用戶的調查顯示，MapR的評級最高，其發(fā)行版在架構和數(shù)據(jù)處理能力上都獲得了最高分。MapR已將一套特殊功能融入其Hadoop發(fā)行版中。例如網(wǎng)絡文件系統(tǒng)（NFS）、災難恢復以及高可用性功能。Forrester說MapR在Hadoop市場上沒有Cloudera和Hortonworks那樣的知名度，MapR要成為一個真正的大企業(yè)，還需要加強伙伴關系和市場營銷。
Microsoft
微軟在開源軟件問題上一直很低調，但在大數(shù)據(jù)形勢下，它不得不考慮讓Windows也兼容Hadoop，它還積極投入到開源項目中，以更廣泛地推動Hadoop生態(tài)圈的發(fā)展。我們可以在微軟的公共云Windows Azure HDInsight產品中看到其成果。微軟的Hadoop服務基于Hortonworks的發(fā)行版，而且是為Azure量身定制的。
微軟也有一些其他的項目，包括名為Polybase的項目，讓Hadoop查詢實現(xiàn)了SQLServer查詢的一些功能。Forrester說：“微軟在數(shù)據(jù)庫、數(shù)據(jù)倉庫、云、OLAP、BI、電子表格（包括PowerPivot）、協(xié)作和開發(fā)工具市場上有很大優(yōu)勢，而且微軟擁有龐大的用戶群，但要在Hadoop這個領域成為行業(yè)領導者還有很遠的路要走?！?/p>
Pivotal Software
EMC和Vmware部分大數(shù)據(jù)業(yè)務分拆組合產生了Pivotal。Pivotal一直努力構建一個性能優(yōu)越的Hadoop發(fā)行版，為此，Pivotal在開源Hadoop的基礎上又添加了一些新的工具，包括一個名為HAWQ的SQL引擎以及一個專門解決大數(shù)據(jù)問題的Hadoop應用。Forrester稱Pivotal Hadoop平臺的優(yōu)勢在于它整合了Pivotal、EMC、Vmware的眾多技術，Pivotal的真正優(yōu)勢實際上等于EMC和Vmware兩大公司為其撐腰。到目前為止，Pivotal的用戶還不到100個，而且大多是中小型客戶。
Teradata
對于Teradata來說，Hadoop既是一種威脅也是一種機遇。數(shù)據(jù)管理，特別是關于SQL和關系數(shù)據(jù)庫這一領域是Teradata的專長。所以像Hadoop這樣的NoSQL平臺崛起可能會威脅到Teradata。相反，Teradata接受了Hadoop，通過與Hortonworks合作，Teradata在Hadoop平臺集成了SQL技術，這使Teradata的客戶可以在Hadoop平臺上方便地使用存儲在Teradata數(shù)據(jù)倉庫中的數(shù)據(jù)。
AMPLab
通過將數(shù)據(jù)轉變?yōu)樾畔?，我們才可以理解世界，而這也正是AMPLab所做的。AMPLab致力于機器學習、數(shù)據(jù)挖掘、數(shù)據(jù)庫、信息檢索、自然語言處理和語音識別等多個領域，努力改進對信息包括不透明數(shù)據(jù)集內信息的甄別技術。除了Spark，開源分布式SQL查詢引擎Shark也源于AMPLab，Shark具有極高的查詢效率，具有良好的兼容性和可擴展性。近幾年的發(fā)展使計算機科學進入到全新的時代，而AMPLab為我們設想一個運用大數(shù)據(jù)、云計算、通信等各種資源和技術靈活解決難題的方案，以應對越來越復雜的各種難題。
NewSQL是對一類現(xiàn)代關系型數(shù)據(jù)庫的統(tǒng)稱，這類數(shù)據(jù)庫對于一般的OLTP讀寫請求提供可橫向擴展的性能，同時支持事務的ACID保證。這些系統(tǒng)既擁有NoSQL數(shù)據(jù)庫的擴展性，又保持傳統(tǒng)數(shù)據(jù)庫的事務特性。NewSQL重新將“應用程序邏輯與數(shù)據(jù)操作邏輯應該分離”的理念帶回到現(xiàn)代數(shù)據(jù)庫的世界，這也驗證了歷史的發(fā)展總是呈現(xiàn)出螺旋上升的形式。
在21世紀00年代中，出現(xiàn)了許多數(shù)據(jù)倉庫系統(tǒng) (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請求為設計目標的系統(tǒng)并不在本文定義的NewSQL范圍內。OLAP 數(shù)據(jù)庫更關注針對海量數(shù)據(jù)的大型、復雜、只讀的查詢，查詢時間可能持續(xù)秒級、分鐘級甚至更長。
NoSQL的擁躉普遍認為阻礙傳統(tǒng)數(shù)據(jù)庫橫向擴容、提高可用性的原因在于ACID保證和關系模型，因此NoSQL運動的核心就是放棄事務強一致性以及關系模型，擁抱最終一致性和其它數(shù)據(jù)模型?(如 key/value，graphs 和Documents)。
兩個最著名的NoSQL數(shù)據(jù)庫就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場NoSQL運動中，它們不一定是受BigTable和Dynamo的啟發(fā)，但都響應了NoSQL的哲學，其中最出名的就是MongoDB。
在21世紀00年代末，市面上已經(jīng)有許多供用戶選擇的分布式數(shù)據(jù)庫產品。使用NoSQL的優(yōu)勢在于應用開發(fā)者可以更關注應用邏輯本身，而非數(shù)據(jù)庫的擴展性問題；但與此同時許多應用，如金融系統(tǒng)、訂單處理系統(tǒng)，由于無法放棄事務的一致性要求被拒之門外。
一些組織，如Google，已經(jīng)發(fā)現(xiàn)他們的許多工程師將過多的精力放在處理數(shù)據(jù)一致性上，這既暴露了數(shù)據(jù)庫的抽象、又提高了代碼的復雜度，這時候要么選擇回到傳統(tǒng)DBMS時代，用更高的機器配置縱向擴容，要么選擇回到中間件時代，開發(fā)支持分布式事務的中間件。這兩種方案成本都很高，于是NewSQL運動開始醞釀。
NewSQL數(shù)據(jù)庫設計針對的讀寫事務有以下特點：
1、耗時短。
2、使用索引查詢，涉及少量數(shù)據(jù)。
3、重復度高，通常使用相同的查詢語句和不同的查詢參考。
也有一些學者認為NewSQL系統(tǒng)是特指實現(xiàn)上使用Lock-free并發(fā)控制技術和share-nothing架構的數(shù)據(jù)庫。所有我們認為是NewSQL的數(shù)據(jù)庫系統(tǒng)確實都有這樣的特點。
Membase
Membase 是 NoSQL 家族的一個新的重量級的成員。Membase是開源項目，源代碼采用了Apache2.0的使用許可。該項目托管在GitHub.Source tarballs上，可以下載beta版本的Linux二進制包。該產品主要是由North Scale的memcached核心團隊成員開發(fā)完成，其中還包括Zynga和NHN這兩個主要貢獻者的工程師，這兩個組織都是很大的在線游戲和社區(qū)網(wǎng)絡空間的供應商。
Membase容易安裝、操作，可以從單節(jié)點方便的擴展到集群，而且為memcached（有線協(xié)議的兼容性）實現(xiàn)了即插即用功能，在應用方面為開發(fā)者和經(jīng)營者提供了一個比較低的門檻。做為緩存解決方案，Memcached已經(jīng)在不同類型的領域（特別是大容量的Web應用）有了廣泛的使用，其中 Memcached的部分基礎代碼被直接應用到了Membase服務器的前端。
通過兼容多種編程語言和框架，Membase具備了很好的復用性。在安裝和配置方面，Membase提供了有效的圖形化界面和編程接口，包括可配置 的告警信息。
Membase的目標是提供對外的線性擴展能力，包括為了增加集群容量，可以針對統(tǒng)一的節(jié)點進行復制。 另外，對存儲的數(shù)據(jù)進行再分配仍然是必要的。
這方面的一個有趣的特性是NoSQL解決方案所承諾的可預測的性能，類準確性的延遲和吞吐量。通過如下方式可以獲得上面提到的特性：
◆ 自動將在線數(shù)據(jù)遷移到低延遲的存儲介質的技術（內存，固態(tài)硬盤，磁盤）
◆ 可選的寫操作一一異步，同步（基于復制，持久化）
◆ 反向通道再平衡[未來考慮支持]
◆ 多線程低鎖爭用
◆ 盡可能使用異步處理
◆ 自動實現(xiàn)重復數(shù)據(jù)刪除
◆ 動態(tài)再平衡現(xiàn)有集群
◆ 通過把數(shù)據(jù)復制到多個集群單元和支持快速失敗轉移來提供系統(tǒng)的高可用性。
MongoDB
MongoDB是一個介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的產品，是非關系數(shù)據(jù)庫當中功能最豐富，最像關系數(shù)據(jù)庫的。他支持的數(shù)據(jù)結構非常松散，是類似json的bjson格式，因此可以存儲比較復雜的數(shù)據(jù)類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似于面向對象的查詢語言，幾乎可以實現(xiàn)類似關系數(shù)據(jù)庫單表查詢的絕大部分功能，而且還支持對數(shù)據(jù)建立索引。它的特點是高性能、易部署、易使用，存儲數(shù)據(jù)非常方便。
主要功能特性：
◆ 面向集合存儲，易存儲對象類型的數(shù)據(jù)
“面向集合”（Collenction-Oriented），意思是數(shù)據(jù)被分組存儲在數(shù)據(jù)集中，被稱為一個集合（Collenction)。每個 集合在數(shù)據(jù)庫中都有一個唯一的標識名，并且可以包含無限數(shù)目的文檔。集合的概念類似關系型數(shù)據(jù)庫（RDBMS）里的表（table），不同的是它不需要定 義任何模式（schema)。
◆ 模式自由
模式自由（schema-free)，意味著對于存儲在mongodb數(shù)據(jù)庫中的文件，我們不需要知道它的任何結構定義。如果需要的話，你完全可以把不同結構的文件存儲在同一個數(shù)據(jù)庫里。
◆支持動態(tài)查詢
◆支持完全索引，包含內部對象
◆支持查詢
◆支持復制和故障恢復
◆使用高效的二進制數(shù)據(jù)存儲，包括大型對象（如視頻等）
◆自動處理碎片，以支持云計算層次的擴展性
◆支持RUBY，PYTHON，JAVA，C++，PHP等多種語言
◆文件存儲格式為BSON（一種JSON的擴展）
BSON（Binary Serialized document Format）存儲形式是指：存儲在集合中的文檔，被存儲為鍵-值對的形式。鍵用于唯一標識一個文檔，為字符串類型，而值則可以是各種復雜的文件類型。
◆可通過網(wǎng)絡訪問
MongoDB服務端可運行在Linux、Windows或OS X平臺，支持32位和64位應用，默認端口為27017。推薦運行在64位平臺，因為MongoDB在32位模式運行時支持的最大文件尺寸為2GB。
MongoDB把數(shù)據(jù)存儲在文件中（默認路徑為：/data/db），為提高效率使用內存映射文件進行管理。
Hypertable
Hypertable是一個開源、高性能、可伸縮的數(shù)據(jù)庫，它采用與Google的Bigtable相似的模型。在過去數(shù)年中，Google為在PC集群 上運行的可伸縮計算基礎設施設計建造了三個關鍵部分。第一個關鍵的基礎設施是Google File System（GFS），這是一個高可用的文件系統(tǒng)，提供了一個全局的命名空間。它通過跨機器（和跨機架）的文件數(shù)據(jù)復制來達到高可用性，并因此免受傳統(tǒng) 文件存儲系統(tǒng)無法避免的許多失敗的影響，比如電源、內存和網(wǎng)絡端口等失敗。第二個基礎設施是名為Map-Reduce的計算框架，它與GFS緊密協(xié)作，幫 助處理收集到的海量數(shù)據(jù)。第三個基礎設施是Bigtable，它是傳統(tǒng)數(shù)據(jù)庫的替代。Bigtable讓你可以通過一些主鍵來組織海量數(shù)據(jù)，并實現(xiàn)高效的 查詢。Hypertable是Bigtable的一個開源實現(xiàn)，并且根據(jù)我們的想法進行了一些改進。
Apache Cassandra
Apache Cassandra是一套開源分布式Key-Value存儲系統(tǒng)。它最初由Facebook開發(fā)，用于儲存特別大的數(shù)據(jù)。Facebook在使用此系統(tǒng)。
主要特性：
◆ 分布式
◆ 基于column的結構化
◆ 高伸展性
Cassandra的主要特點就是它不是一個數(shù)據(jù)庫，而是由一堆數(shù)據(jù)庫節(jié)點共同構成的一個分布式網(wǎng)絡服務，對Cassandra 的一個寫操作，會被復制到其他節(jié)點上去，對Cassandra的讀操作，也會被路由到某個節(jié)點上面去讀取。對于一個Cassandra群集來說，擴展性能 是比較簡單的事情，只管在群集里面添加節(jié)點就可以了。
Cassandra是一個混合型的非關系的數(shù)據(jù)庫，類似于Google的BigTable。其主要功能比 Dynomite（分布式的Key-Value存 儲系統(tǒng)）更豐富，但支持度卻不如文檔存儲MongoDB（介于關系數(shù)據(jù)庫和非關系數(shù)據(jù)庫之間的開源產品，是非關系數(shù)據(jù)庫當中功能最豐富，最像關系數(shù)據(jù)庫 的。Cassandra最初由Facebook開發(fā)，后轉變成了開源項目。它是一個網(wǎng)絡社交云計算方面理想的數(shù)據(jù)庫。以Amazon專有的完全分布式的Dynamo為基礎，結合了Google BigTable基于列族（Column Family）的數(shù)據(jù)模型。P2P去中心化的存儲。很多方面都可以稱之為Dynamo 2.0。
CouchDB
所用語言： Erlang
特點：DB一致性，易于使用
使用許可： Apache
協(xié)議： HTTP/REST
雙向數(shù)據(jù)復制，持續(xù)進行或臨時處理，處理時帶沖突檢查，因此，采用的是master-master復制
MVCC – 寫操作不阻塞讀操作
可保存文件之前的版本
Crash-only（可靠的）設計
需要不時地進行數(shù)據(jù)壓縮
視圖：嵌入式 映射/減少
格式化視圖：列表顯示
支持進行服務器端文檔驗證
支持認證
根據(jù)變化實時更新
支持附件處理
因此， CouchApps（獨立的 js應用程序）
需要 jQuery程序庫
最佳應用場景：適用于數(shù)據(jù)變化較少，執(zhí)行預定義查詢，進行數(shù)據(jù)統(tǒng)計的應用程序。適用于需要提供數(shù)據(jù)版本支持的應用程序。
例如：CRM、CMS系統(tǒng)。 master-master復制對于多站點部署是非常有用的。
和其他數(shù)據(jù)庫比較，其突出特點是：
◆ 模式靈活 ：使用Cassandra，像文檔存儲，你不必提前解決記錄中的字段。你可以在系統(tǒng)運行時隨意的添加或移除字段。這是一個驚人的效率提升，特別是在大型部 署上。
◆ 真正的可擴展性 ：Cassandra是純粹意義上的水平擴展。為給集群添加更多容量，可以指向另一臺電腦。你不必重啟任何進程，改變應用查詢，或手動遷移任何數(shù)據(jù)。
◆ 多數(shù)據(jù)中心識別 ：你可以調整你的節(jié)點布局來避免某一個數(shù)據(jù)中心起火，一個備用的數(shù)據(jù)中心將至少有每條記錄的完全復制。
◆ 范圍查詢 ：如果你不喜歡全部的鍵值查詢，則可以設置鍵的范圍來查詢。
◆ 列表數(shù)據(jù)結構 ：在混合模式可以將超級列添加到5維。對于每個用戶的索引，這是非常方便的。
◆ 分布式寫操作 ：有可以在任何地方任何時間集中讀或寫任何數(shù)據(jù)。并且不會有任何單點失敗。
問度娘，啥都有。
NoSQL，指的是非關系型的數(shù)據(jù)庫。隨著互聯(lián)網(wǎng)web2.0網(wǎng)站的興起，傳統(tǒng)的關系數(shù)據(jù)庫在應付web2.0網(wǎng)站，特別是超大規(guī)模和高并發(fā)的
SNS類型的web2.0純動態(tài)網(wǎng)站已經(jīng)顯得力不從心，暴露了很多難以克服的問題，而非關系型的數(shù)據(jù)庫則由于其本身的特點得到了非常迅速的發(fā)展。
NoSQL(NoSQL
= Not Only SQL
)，意即“不僅僅是SQL”，是一項全新的數(shù)據(jù)庫革命性運動，早期就有人提出，發(fā)展至2009年趨勢越發(fā)高漲。NoSQL的擁護者們提倡運用非關系型的數(shù)
據(jù)存儲，相對于鋪天蓋地的關系型數(shù)據(jù)庫運用，這一概念無疑是一種全新的思維的注入。
從這一新興技術中選擇一款正確的NoSQL數(shù)據(jù)庫是非常具有挑戰(zhàn)性的。比一下網(wǎng)建議在選擇時考慮以下因素：
并發(fā)控制
并
發(fā)控制指的是當多個用戶同時更新運行時，用于保護數(shù)據(jù)庫完整性的各種技術。并發(fā)機制不正確可能導致臟讀、幻讀和不可重復讀等此類問題。并發(fā)控制的目的是保
證一個用戶的工作不會對另一個用戶的工作產生不合理的影響。在某些情況下，這些措施保證了當用戶和其他用戶一起操作時，所得的結果和她單獨操作時的結果是
一樣的。在另一些情況下，這表示用戶的工作按預定的方式受其他用戶的影響。
封鎖
就是事務T在對某個數(shù)據(jù)對象（例如表、記錄等）操作之前，先向系統(tǒng)發(fā)出請求，對其加鎖。加鎖后事務T就對該數(shù)據(jù)對象有了一定的控制，在事務T釋放它的鎖之前，其它的事務不能更新此數(shù)據(jù)對象。
封鎖是一次只允許一個用戶讀取或修改的一種機制，是實現(xiàn)并發(fā)控制的一個非常重要的技術。
MVCC
Multi-Version Concurrency Control多版本并發(fā)控制，維持一個數(shù)據(jù)的多個版本使讀寫操作沒有沖突。MVCC優(yōu)化了數(shù)據(jù)庫并發(fā)系統(tǒng)，使系統(tǒng)在有大量并發(fā)用戶時得到最高的性能，并且可以不用關閉服務器就直接進行熱備份。
ACID
指
數(shù)據(jù)庫事務正確執(zhí)行的四個基本要素的縮寫。包含：原子性(Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久
性（Durability）。一個支持事務（Transaction）的數(shù)據(jù)庫系統(tǒng)，必需要具有這四種特性，否則在事務過程（Transaction
processing）當中無法保證數(shù)據(jù)的正確性，交易過程極可能達不到交易方的要求。
None
一些系統(tǒng)不提供原子性。
鏡像
數(shù)據(jù)庫鏡像是DBMS根據(jù)DBA的要求，自動把整個數(shù)據(jù)庫或其中的關鍵數(shù)據(jù)復制到另一個磁盤上，每當主數(shù)據(jù)庫更新時，DBMS會自動把更新后的數(shù)據(jù)復制過去，即DBMS自動保證鏡像數(shù)據(jù)與主數(shù)據(jù)的一致性。
鏡像分為同步和異步。
數(shù)據(jù)存儲
指的是數(shù)據(jù)的物理特性怎樣被存儲在數(shù)據(jù)庫中。
磁盤 數(shù)據(jù)被存儲在硬盤驅動器里；
GFS或谷歌文件系統(tǒng)是一個由谷歌開發(fā)的專有的分布式文件系統(tǒng)；
Hadoop是Apache軟件框架，免費許可下支持數(shù)據(jù)密集型分布式應用程序；
RAM隨機存儲器；
插件 可以添加外部插件；
Amazon S3通過Web服務接口提供存儲；
BDB：BDB
全稱是 “Berkeley DB”，它是MySQL具有事務能力的表類型，由Sleepycat
Software開發(fā)。BDB表類型提供了MySQL用戶長久期盼的功能，即事務控制能力。在任何RDBMS中，事務控制能力都是一種極其重要和寶貴的功
能。事務控制能力使得我們能夠確保一組命令確實已經(jīng)全部執(zhí)行成功，或者確保當任何一個命令出現(xiàn)錯誤時所有命令的執(zhí)行結果均被退回。
實現(xiàn)語言
實現(xiàn)語言會影響數(shù)據(jù)庫的發(fā)展速度。典型的NoSQL數(shù)據(jù)庫是用低級語言如C / C + +編寫的。另一方面，那些更高層次的語言如Java，使自定義更容易。
實現(xiàn)語言有：C, C++, Erlang, Java, Python
特性
考慮下列哪一個特點對你的數(shù)據(jù)庫是最重要的：
持久性
可用性
一致性
分區(qū)容忍性
證書類型
下面這些許可證是一個不同的開放源碼許可的形式：
GPL：通用公共許可證
BSD：伯克利軟件分發(fā)
MPL：Mozilla公共許可證
EPL：Eclipse公共許可證
IDPL：最初的開發(fā)者的公共許可證
LGPL：較寬松通用公共許可證
存儲類型
存儲類型是NoSQL數(shù)據(jù)庫最大的不同，是決定使用哪款數(shù)據(jù)庫的一個首要指標。
關鍵字：支持get、put和刪除操作
按列存儲：相對于傳統(tǒng)的按行存儲，數(shù)據(jù)集成容易多了
面向文件系統(tǒng)：存儲像是JSON或XML這樣的結構化文件，很容易就能從面向對象軟件中獲取數(shù)據(jù)。
Hadoop
文件系統(tǒng)：文件系統(tǒng)是用來存儲和管理文件，并且提供文件的查詢、增加、刪除等操作。
直觀上的體驗：在shell窗口輸入 ls 命令，就可以看到當前目錄下的文件夾、文件。
文件存儲在哪里？硬盤
一臺只有250G硬盤的電腦，如果需要存儲500G的文件可以怎么辦？先將電腦硬盤擴容至少250G，再將文件分割成多塊，放到多塊硬盤上儲存。
通過 hdfs dfs -ls 命令可以查看分布式文件系統(tǒng)中的文件，就像本地的ls命令一樣。
HDFS在客戶端上提供了查詢、新增和刪除的指令，可以實現(xiàn)將分布在多臺機器上的文件系統(tǒng)進行統(tǒng)一的管理。
在分布式文件系統(tǒng)中，一個大文件會被切分成塊，分別存儲到幾臺機器上。結合上文中提到的那個存儲500G大文件的那個例子，這500G的文件會按照一定的大小被切分成若干塊，然后分別存儲在若干臺機器上，然后提供統(tǒng)一的操作接口。
看到這里，不少人可能會覺得，分布式文件系統(tǒng)不過如此，很簡單嘛。事實真的是這樣的么？
潛在問題
假如我有一個1000臺機器組成的分布式系統(tǒng)，一臺機器每天出現(xiàn)故障的概率是0.1%，那么整個系統(tǒng)每天出現(xiàn)故障的概率是多大呢？答案是(1-0.1%)^1000=63%，因此需要提供一個容錯機制來保證發(fā)生差錯時文件依然可以讀出，這里暫時先不展開介紹。
如果要存儲PB級或者EB級的數(shù)據(jù)，成千上萬臺機器組成的集群是很常見的，所以說分布式系統(tǒng)比單機系統(tǒng)要復雜得多呀。
這是一張HDFS的架構簡圖：
client通過nameNode了解數(shù)據(jù)在哪些DataNode上，從而發(fā)起查詢。此外，不僅是查詢文件，寫入文件的時候也是先去請教NameNode，看看應該往哪個DateNode中去寫。
為了某一份數(shù)據(jù)只寫入到一個Datanode中，而這個Datanode因為某些原因出錯無法讀取的問題，需要通過冗余備份的方式來進行容錯處理。因此，HDFS在寫入一個數(shù)據(jù)塊的時候，不會僅僅寫入一個DataNode，而是會寫入到多個DataNode中，這樣，如果其中一個DataNode壞了，還可以從其余的DataNode中拿到數(shù)據(jù)，保證了數(shù)據(jù)不丟失。
實際上，每個數(shù)據(jù)塊在HDFS上都會保存多份，保存在不同的DataNode上。這種是犧牲一定存儲空間換取可靠性的做法。
接下來我們來看一下完整的文件寫入的流程：
大文件要寫入HDFS，client端根據(jù)配置將大文件分成固定大小的塊，然后再上傳到HDFS。
讀取文件的流程：
1、client詢問NameNode，我要讀取某個路徑下的文件，麻煩告訴我這個文件都在哪些DataNode上？
2、NameNode回復client，這個路徑下的文件被切成了3塊，分別在DataNode1、DataNode3和DataNode4上
3、client去找DataNode1、DataNode3和DataNode4，拿到3個文件塊，通過stream讀取并且整合起來
文件寫入的流程：
1、client先將文件分塊，然后詢問NameNode，我要寫入一個文件到某個路徑下，文件有3塊，應該怎么寫？
2、NameNode回復client，可以分別寫到DataNode1、DataNode2、DataNode3、DataNode4上，記住，每個塊重復寫3份，總共是9份
3、client找到DataNode1、DataNode2、DataNode3、DataNode4，把數(shù)據(jù)寫到他們上面
出于容錯的考慮，每個數(shù)據(jù)塊有3個備份，但是3個備份快都直接由client端直接寫入勢必會帶來client端過重的寫入壓力，這個點是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進行同步的，HDFS當然也可以借鑒這個思想，數(shù)據(jù)其實只需要寫入到一個datanode上，然后由datanode之間相互進行備份同步，減少了client端的寫入壓力，那么至于是一個datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當然這個設置會影響到數(shù)據(jù)寫入的吞吐率，我們可以看到可靠性和效率永遠是“魚和熊掌不可兼得”的。
潛在問題
NameNode確實會回放editlog，但是不是每次都從頭回放，它會先加載一個fsimage，這個文件是之前某一個時刻整個NameNode的文件元數(shù)據(jù)的內存快照，然后再在這個基礎上回放editlog，完成后，會清空editlog，再把當前文件元數(shù)據(jù)的內存狀態(tài)寫入fsimage，方便下一次加載。
這樣，全量回放就變成了增量回放，但是如果NameNode長時間未重啟過，editlog依然會比較大，恢復的時間依然比較長，這個問題怎么解呢？
SecondNameNode是一個NameNode內的定時任務線程，它會定期地將editlog寫入fsimage，然后情況原來的editlog，從而保證editlog的文件大小維持在一定大小。
NameNode掛了， SecondNameNode并不能替代NameNode，所以如果集群中只有一個NameNode，它掛了，整個系統(tǒng)就掛了。hadoop2.x之前，整個集群只能有一個NameNode，是有可能發(fā)生單點故障的，所以hadoop1.x有本身的不穩(wěn)定性。但是hadoop2.x之后，我們可以在集群中配置多個NameNode，就不會有這個問題了，但是配置多個NameNode，需要注意的地方就更多了，系統(tǒng)就更加復雜了。
俗話說“一山不容二虎”，兩個NameNode只能有一個是活躍狀態(tài)active，另一個是備份狀態(tài)standby，我們看一下兩個NameNode的架構圖。
兩個NameNode通過JournalNode實現(xiàn)同步editlog，保持狀態(tài)一致可以相互替換。
因為active的NameNode掛了之后，standby的NameNode要馬上接替它，所以它們的數(shù)據(jù)要時刻保持一致，在寫入數(shù)據(jù)的時候，兩個NameNode內存中都要記錄數(shù)據(jù)的元信息，并保持一致。這個JournalNode就是用來在兩個NameNode中同步數(shù)據(jù)的，并且standby NameNode實現(xiàn)了SecondNameNode的功能。
進行數(shù)據(jù)同步操作的過程如下：
active NameNode有操作之后，它的editlog會被記錄到JournalNode中，standby NameNode會從JournalNode中讀取到變化并進行同步，同時standby NameNode會監(jiān)聽記錄的變化。這樣做的話就是實時同步了，并且standby NameNode就實現(xiàn)了SecondNameNode的功能。
優(yōu)點：
缺點：
重慶分公司
重慶分公司
