元數(shù)據(jù)nosql,元數(shù)據(jù)標準

elasticsearch可以代替NoSQL嗎

我們使用Elasticsearch存儲的文檔數(shù)量接近50億（算上1份復制，接近100億文檔），總共10個數(shù)據(jù)節(jié)點和2個元數(shù)據(jù)節(jié)點（48GB內(nèi)存，8核心CPU，ES使用內(nèi)存達到70%），每天的文檔增量大概是3000W條（速度持續(xù)增加中）。目前來看，單個文檔的查詢效率基本處于實時狀態(tài)；對于1到2周的數(shù)據(jù)的聚合統(tǒng)計操作也可以在10秒之內(nèi)返回結果。

專注于為中小企業(yè)提供成都網(wǎng)站建設、做網(wǎng)站服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)保定免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了近千家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

但是，還有提升的空間：

1. 對于查詢單條數(shù)據(jù)的應用場景來說，我們可以使用ES的路由機制，將同一索引內(nèi)的具有相同特征（比如具有相同的userid）的文檔全部存儲于一個節(jié)點上，這樣我們之后的查詢都可以直接定位到這個節(jié)點上，而不用將查詢廣播道所有的節(jié)點上；

2. 隨著數(shù)據(jù)節(jié)點的增加，適當增加分片數(shù)量，提升系統(tǒng)的分布水平，也可以通過分而治之的方式優(yōu)化查詢性能；

個人以為Elasticsearch作為內(nèi)部存儲來說還是不錯的，效率也基本能夠滿足，在某些方面替代傳統(tǒng)DB也是可以的，前提是你的業(yè)務不對操作的事性務有特殊要求；而權限管理也不用那么細，因為ES的權限這塊還不完善。由于我們對ES的應用場景僅僅是在于對某段時間內(nèi)的數(shù)據(jù)聚合操作，沒有大量的單文檔請求（比如通過userid來找到一個用戶的文檔，類似于NoSQL的應用場景），所以能否替代NoSQL還需要各位自己的測試。如果讓我選擇的話，我會嘗試使用ES來替代傳統(tǒng)的NoSQL，因為它的橫向擴展機制太方便了。

在我的工作過程中，我深切體會到：經(jīng)驗固然是一個很重要的東西，因為它能夠幫助我們少走很多彎路，但同時也應該看到經(jīng)驗的另一面——它會變成一個籠子，將我們閉塞其中，使我們錯過一些可能更好的解決方案，關鍵是我們要學會嘗試，接觸新的世界。

NoSQL-HDFS-基本概念

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ù)的內(nèi)存快照，然后再在這個基礎上回放editlog，完成后，會清空editlog，再把當前文件元數(shù)據(jù)的內(nèi)存狀態(tài)寫入fsimage，方便下一次加載。

這樣，全量回放就變成了增量回放，但是如果NameNode長時間未重啟過，editlog依然會比較大，恢復的時間依然比較長，這個問題怎么解呢？

SecondNameNode是一個NameNode內(nèi)的定時任務線程，它會定期地將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內(nèi)存中都要記錄數(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)點：

缺點：

目前哪些NoSQL數(shù)據(jù)庫應用廣泛，各有什么特點

特點：

它們可以處理超大量的數(shù)據(jù)。

它們運行在便宜的PC服務器集群上。

PC集群擴充起來非常方便并且成本很低，避免了“sharding”操作的復雜性和成本。

它們擊碎了性能瓶頸。

NoSQL的支持者稱，通過NoSQL架構可以省去將Web或Java應用和數(shù)據(jù)轉(zhuǎn)換成SQL友好格式的時間，執(zhí)行速度變得更快。

“SQL并非適用于所有的程序代碼，” 對于那些繁重的重復操作的數(shù)據(jù)，SQL值得花錢。但是當數(shù)據(jù)庫結構非常簡單時，SQL可能沒有太大用處。

沒有過多的操作。

雖然NoSQL的支持者也承認關系數(shù)據(jù)庫提供了無可比擬的功能集合，而且在數(shù)據(jù)完整性上也發(fā)揮絕對穩(wěn)定，他們同時也表示，企業(yè)的具體需求可能沒有那么多。

Bootstrap支持

因為NoSQL項目都是開源的，因此它們?nèi)狈烫峁┑恼街С?。這一點它們與大多數(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

該技術采用內(nèi)存計算，從多迭代批量處理出發(fā)，允許將數(shù)據(jù)載入內(nèi)存做反復查詢，此外還融合數(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)方便地轉(zhuǎn)移到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產(chǎn)品被稱為EMR（Elastic Map Reduce），AWS解釋這款產(chǎn)品采用了Hadoop技術來提供大數(shù)據(jù)管理服務，但它不是純開源Hadoop，經(jīng)過修改后現(xiàn)在被專門用在AWS云上。

Forrester稱EMR有很好的市場前景。很多公司基于EMR為客戶提供服務，有一些公司將EMR應用于數(shù)據(jù)查詢、建模、集成和管理。而且AWS還在創(chuàng)新，F(xiàn)orrester稱未來EMR可以基于工作量的需要自動縮放調(diào)整大小。亞馬遜計劃為其產(chǎn)品和服務提供更強大的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，但也不是純開源的產(chǎn)品。當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的客戶想要離開這個平臺，他們可以輕松轉(zhuǎn)向其他開源平臺）。這并不是說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指出英特爾在最近才推出這個產(chǎn)品，所以公司在未來還有很多改進的可能，英特爾和微軟都被認為是Hadoop市場上的潛力股。

MapR Technologies

MapR的Hadoop發(fā)行版目前為止也許是最好的了，不過很多人可能都沒有聽說過。Forrester對Hadoop用戶的調(diào)查顯示，MapR的評級最高，其發(fā)行版在架構和數(shù)據(jù)處理能力上都獲得了最高分。MapR已將一套特殊功能融入其Hadoop發(fā)行版中。例如網(wǎng)絡文件系統(tǒng)（NFS）、災難恢復以及高可用性功能。Forrester說MapR在Hadoop市場上沒有Cloudera和Hortonworks那樣的知名度，MapR要成為一個真正的大企業(yè)，還需要加強伙伴關系和市場營銷。

Microsoft

微軟在開源軟件問題上一直很低調(diào)，但在大數(shù)據(jù)形勢下，它不得不考慮讓Windows也兼容Hadoop，它還積極投入到開源項目中，以更廣泛地推動Hadoop生態(tài)圈的發(fā)展。我們可以在微軟的公共云Windows Azure HDInsight產(chǎn)品中看到其成果。微軟的Hadoop服務基于Hortonworks的發(fā)行版，而且是為Azure量身定制的。

微軟也有一些其他的項目，包括名為Polybase的項目，讓Hadoop查詢實現(xiàn)了SQLServer查詢的一些功能。Forrester說：“微軟在數(shù)據(jù)庫、數(shù)據(jù)倉庫、云、OLAP、BI、電子表格（包括PowerPivot）、協(xié)作和開發(fā)工具市場上有很大優(yōu)勢，而且微軟擁有龐大的用戶群，但要在Hadoop這個領域成為行業(yè)領導者還有很遠的路要走。”

Pivotal Software

EMC和Vmware部分大數(shù)據(jù)業(yè)務分拆組合產(chǎn)生了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ù)轉(zhuǎn)變?yōu)樾畔?，我們才可以理解世界，而這也正是AMPLab所做的。AMPLab致力于機器學習、數(shù)據(jù)挖掘、數(shù)據(jù)庫、信息檢索、自然語言處理和語音識別等多個領域，努力改進對信息包括不透明數(shù)據(jù)集內(nèi)信息的甄別技術。除了Spark，開源分布式SQL查詢引擎Shark也源于AMPLab，Shark具有極高的查詢效率，具有良好的兼容性和可擴展性。近幾年的發(fā)展使計算機科學進入到全新的時代，而AMPLab為我們設想一個運用大數(shù)據(jù)、云計算、通信等各種資源和技術靈活解決難題的方案，以應對越來越復雜的各種難題。

為什么不用NoSQL

當為大家描述我們的整體服務架構時，最常見的兩個問題是：

為什么采用結構化方式將數(shù)據(jù)存儲在SQL數(shù)據(jù)庫中，而不使用NoSQL平臺？

為什么自己維護數(shù)據(jù)中心，而不將Evernote托管到云服務提供商？

這兩個問題都很有趣，我們先來探討第一個。

對特定的應用而言，相比一個單一的SQL實例，一個現(xiàn)代的鍵值存儲引擎具備顯著的性能優(yōu)勢和可擴展性。

CREATE TABLE notebooks ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, name varchar(100) COLLATE utf8_bin NOT NULL, ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8; CREATE TABLE notes ( id int UNSIGNED NOT NULL PRIMARY KEY, guid binary(16) NOT NULL, user_id int UNSIGNED NOT NULL, notebook_id int UNSIGNED NOT NULL, title varchar(255) NOT NULL, ... FOREIGN KEY (notebook_id) REFERENCES notebooks(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

如果你在Windows客戶端上創(chuàng)建了一個名為“Cooking”的記事本，并立即在其中粘貼了一個名為“Quick Tomato Sauce”的食譜，客戶端會立刻進行如下同步：

調(diào)用NoteStore.createNotebook() 請求服務器創(chuàng)建記事本，并返回以創(chuàng)建記事本的GUID。

通過指定記事本的GUID，調(diào)用NoteStore.createNote()在記事本中創(chuàng)建筆記。

每次API調(diào)用都通過SQL事物予以實現(xiàn)，可以讓客戶端完全信任服務器的任何提示。ACID兼容的數(shù)據(jù)庫可以做到這些：

原子性（Atomicity）：如果API調(diào)用成功，那么所有的改動都會保存；如果API調(diào)用失敗，所有的改動都不會提交。

一致性（Consistency）： 在API調(diào)用完成后，所有的賬戶都可用，并能保證內(nèi)部狀態(tài)的一致性。每篇筆記都與記事本相關聯(lián)，以避免出現(xiàn)孤立項。數(shù)據(jù)庫不允許刪除關聯(lián)有記事的記事本，這得感謝FOREIGN KEY約束。

持久性（Durability）：當服務器發(fā)送記事本已創(chuàng)建完畢的回執(zhí)后，客戶端會認為它的存在具有持久性，以便進行后續(xù)的操作。變更的持久性，可以讓客戶端知道在任何時刻對服務狀態(tài)的影響都能保持一致性。

對我們的同步協(xié)議而言，持久性最為重要。如果客戶端不能確定服務器端的變更具有持久性，那么協(xié)議將會變得復雜而低效。

“大數(shù)據(jù)”問題

得益于事務處理的數(shù)據(jù)庫的ACID屬性，同樣使得數(shù)據(jù)集非常難以擴展，以超出單臺服務器的范圍。數(shù)據(jù)庫集群和多主復制技術并不理想，鍵值存儲為實現(xiàn)可擴展性提供了一條捷徑。

所幸，Evernote暫時不需要考慮這個問題。即便是我們有近10億的筆記，和近20億的資源文件，這也并不能稱得上是一個大數(shù)據(jù)集。通過按用戶分區(qū)，它被劃分成了2千萬個獨立的數(shù)據(jù)集。

我們尚未遇到所謂“大數(shù)據(jù)”引發(fā)的問題，倒是遇到了許多“中數(shù)據(jù)”的存儲問題，這就是通過規(guī)整分區(qū)形成的分片存儲架構。

也許以后……

我們對新的存儲系統(tǒng)非常感興趣，非常樂意應用在哪些對ACID要求不強，但確實需要橫向擴展的新項目中。例如，我們的報告分析系統(tǒng)已經(jīng)逐漸超出了MySQL平臺的承受力，需要被更快、更先進的系統(tǒng)所取代。

我們現(xiàn)在對以Evernote用戶元數(shù)據(jù)為基礎的MySQL分片存儲頗為滿意，盡管這不會引起那些IT弄潮兒的興趣。

nosql數(shù)據(jù)庫有哪些

1. CouchDB

所用語言： Erlang

特點：DB一致性，易于使用

使用許可： Apache

協(xié)議： HTTP/REST

雙向數(shù)據(jù)復制，

持續(xù)進行或臨時處理，

處理時帶沖突檢查，

因此，采用的是master-master復制（見編注2）

MVCC – 寫操作不阻塞讀操作

可保存文件之前的版本

Crash-only（可靠的）設計

需要不時地進行數(shù)據(jù)壓縮

視圖：嵌入式 映射/減少

格式化視圖：列表顯示

支持進行服務器端文檔驗證

支持認證

根據(jù)變化實時更新

支持附件處理

因此， CouchApps（獨立的 js應用程序）

需要 jQuery程序庫

最佳應用場景：適用于數(shù)據(jù)變化較少，執(zhí)行預定義查詢，進行數(shù)據(jù)統(tǒng)計的應用程序。適用于需要提供數(shù)據(jù)版本支持的應用程序。

例如： CRM、CMS系統(tǒng)。 master-master復制對于多站點部署是非常有用的。

（編注2：master-master復制：是一種數(shù)據(jù)庫同步方法，允許數(shù)據(jù)在一組計算機之間共享數(shù)據(jù)，并且可以通過小組中任意成員在組內(nèi)進行數(shù)據(jù)更新。）

2. Redis

所用語言：C/C++

特點：運行異?？?/p>

使用許可： BSD

協(xié)議：類 Telnet

有硬盤存儲支持的內(nèi)存數(shù)據(jù)庫，

但自2.0版本以后可以將數(shù)據(jù)交換到硬盤（注意， 2.4以后版本不支持該特性?。?/p>

Master-slave復制（見編注3）

雖然采用簡單數(shù)據(jù)或以鍵值索引的哈希表，但也支持復雜操作，例如 ZREVRANGEBYSCORE。

INCR co （適合計算極限值或統(tǒng)計數(shù)據(jù)）

支持 sets（同時也支持 union/diff/inter）

支持列表（同時也支持隊列；阻塞式 pop操作）

支持哈希表（帶有多個域的對象）

支持排序 sets（高得分表，適用于范圍查詢）

Redis支持事務

支持將數(shù)據(jù)設置成過期數(shù)據(jù)（類似快速緩沖區(qū)設計）

Pub/Sub允許用戶實現(xiàn)消息機制

最佳應用場景：適用于數(shù)據(jù)變化快且數(shù)據(jù)庫大小可遇見（適合內(nèi)存容量）的應用程序。

例如：股票價格、數(shù)據(jù)分析、實時數(shù)據(jù)搜集、實時通訊。

（編注3：Master-slave復制：如果同一時刻只有一臺服務器處理所有的復制請求，這被稱為

Master-slave復制，通常應用在需要提供高可用性的服務器集群。）

3. MongoDB

所用語言：C++

特點：保留了SQL一些友好的特性（查詢，索引）。

使用許可： AGPL（發(fā)起者： Apache）

協(xié)議： Custom, binary（ BSON）

Master/slave復制（支持自動錯誤恢復，使用 sets 復制）

內(nèi)建分片機制

支持 javascript表達式查詢

可在服務器端執(zhí)行任意的 javascript函數(shù)

update-in-place支持比CouchDB更好

在數(shù)據(jù)存儲時采用內(nèi)存到文件映射

對性能的關注超過對功能的要求

建議最好打開日志功能（參數(shù) –journal）

在32位操作系統(tǒng)上，數(shù)據(jù)庫大小限制在約2.5Gb

空數(shù)據(jù)庫大約占 192Mb

采用 GridFS存儲大數(shù)據(jù)或元數(shù)據(jù)（不是真正的文件系統(tǒng)）

最佳應用場景：適用于需要動態(tài)查詢支持；需要使用索引而不是 map/reduce功能；需要對大數(shù)據(jù)庫有性能要求；需要使用

CouchDB但因為數(shù)據(jù)改變太頻繁而占滿內(nèi)存的應用程序。

例如：你本打算采用 MySQL或 PostgreSQL，但因為它們本身自帶的預定義欄讓你望而卻步。

4. Riak

所用語言：Erlang和C，以及一些Javascript

特點：具備容錯能力

使用許可： Apache

協(xié)議： HTTP/REST或者 custom binary

可調(diào)節(jié)的分發(fā)及復制(N, R, W)

用 JavaScript or Erlang在操作前或操作后進行驗證和安全支持。

使用JavaScript或Erlang進行 Map/reduce

連接及連接遍歷：可作為圖形數(shù)據(jù)庫使用

索引：輸入元數(shù)據(jù)進行搜索（1.0版本即將支持）

大數(shù)據(jù)對象支持（ Luwak）

提供“開源”和“企業(yè)”兩個版本

全文本搜索，索引，通過 Riak搜索服務器查詢（ beta版）

支持Masterless多站點復制及商業(yè)許可的 SNMP監(jiān)控

最佳應用場景：適用于想使用類似 Cassandra（類似Dynamo）數(shù)據(jù)庫但無法處理

bloat及復雜性的情況。適用于你打算做多站點復制，但又需要對單個站點的擴展性，可用性及出錯處理有要求的情況。

例如：銷售數(shù)據(jù)搜集，工廠控制系統(tǒng)；對宕機時間有嚴格要求；可以作為易于更新的 web服務器使用。

5. Membase

所用語言： Erlang和C

特點：兼容 Memcache，但同時兼具持久化和支持集群

使用許可： Apache 2.0

協(xié)議：分布式緩存及擴展

非?？焖伲?00k+/秒），通過鍵值索引數(shù)據(jù)

可持久化存儲到硬盤

所有節(jié)點都是唯一的（ master-master復制）

在內(nèi)存中同樣支持類似分布式緩存的緩存單元

寫數(shù)據(jù)時通過去除重復數(shù)據(jù)來減少 IO

提供非常好的集群管理 web界面

更新軟件時軟無需停止數(shù)據(jù)庫服務

支持連接池和多路復用的連接代理

最佳應用場景：適用于需要低延遲數(shù)據(jù)訪問，高并發(fā)支持以及高可用性的應用程序

例如：低延遲數(shù)據(jù)訪問比如以廣告為目標的應用，高并發(fā)的 web 應用比如網(wǎng)絡游戲（例如 Zynga）

6. Neo4j

所用語言： Java

特點：基于關系的圖形數(shù)據(jù)庫

使用許可： GPL，其中一些特性使用 AGPL/商業(yè)許可

協(xié)議： HTTP/REST（或嵌入在 Java中）

可獨立使用或嵌入到 Java應用程序

圖形的節(jié)點和邊都可以帶有元數(shù)據(jù)

很好的自帶web管理功能

使用多種算法支持路徑搜索

使用鍵值和關系進行索引

為讀操作進行優(yōu)化

支持事務（用 Java api）

使用 Gremlin圖形遍歷語言

支持 Groovy腳本

支持在線備份，高級監(jiān)控及高可靠性支持使用 AGPL/商業(yè)許可

最佳應用場景：適用于圖形一類數(shù)據(jù)。這是 Neo4j與其他nosql數(shù)據(jù)庫的最顯著區(qū)別

例如：社會關系，公共交通網(wǎng)絡，地圖及網(wǎng)絡拓譜

7. Cassandra

所用語言： Java

特點：對大型表格和 Dynamo支持得最好

使用許可： Apache

協(xié)議： Custom, binary (節(jié)約型)

可調(diào)節(jié)的分發(fā)及復制(N, R, W)

支持以某個范圍的鍵值通過列查詢

類似大表格的功能：列，某個特性的列集合

寫操作比讀操作更快

基于 Apache分布式平臺盡可能地 Map/reduce

我承認對 Cassandra有偏見，一部分是因為它本身的臃腫和復雜性，也因為 Java的問題（配置，出現(xiàn)異常，等等）

最佳應用場景：當使用寫操作多過讀操作（記錄日志）如果每個系統(tǒng)組建都必須用 Java編寫（沒有人因為選用

Apache的軟件被解雇）

例如：銀行業(yè)，金融業(yè)（雖然對于金融交易不是必須的，但這些產(chǎn)業(yè)對數(shù)據(jù)庫的要求會比它們更大）寫比讀更快，所以一個自然的特性就是實時數(shù)據(jù)分析

8. HBase

（配合 ghshephard使用）

所用語言： Java

特點：支持數(shù)十億行X上百萬列

使用許可： Apache

協(xié)議：HTTP/REST （支持 Thrift，見編注4）

在 BigTable之后建模

采用分布式架構 Map/reduce

對實時查詢進行優(yōu)化

高性能 Thrift網(wǎng)關

通過在server端掃描及過濾實現(xiàn)對查詢操作預判

支持 XML, Protobuf, 和binary的HTTP

Cascading, hive, and pig source and sink modules

基于 Jruby（ JIRB）的shell

對配置改變和較小的升級都會重新回滾

不會出現(xiàn)單點故障

堪比MySQL的隨機訪問性能

最佳應用場景：適用于偏好BigTable:)并且需要對大數(shù)據(jù)進行隨機、實時訪問的場合。

例如： Facebook消息數(shù)據(jù)庫（更多通用的用例即將出現(xiàn)）

編注4：Thrift

是一種接口定義語言，為多種其他語言提供定義和創(chuàng)建服務，由Facebook開發(fā)并開源。

當然，所有的系統(tǒng)都不只具有上面列出的這些特性。這里我僅僅根據(jù)自己的觀點列出一些我認為的重要特性。與此同時，技術進步是飛速的，所以上述的內(nèi)容肯定需要不斷更新。我會盡我所能地更新這個列表。

網(wǎng)頁題目：元數(shù)據(jù)nosql,元數(shù)據(jù)標準
本文網(wǎng)址：http://m.jiaotiyi.com/article/hogsgg.html