對于CC攻擊，其防御必須采用多種方法，而這些方法本質上也是在提高服務器的并發(fā)能力。
成都創(chuàng)新互聯(lián)2013年開創(chuàng)至今，先為汕城等服務建站，汕城等地企業(yè)，進行企業(yè)商務咨詢服務。為汕城企業(yè)網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。
1、服務器垂直擴展和水平擴容
資金允許的情況下，這是最簡單的一種方法，本質上講，這個方法并不是針對CC攻擊的，而是提升服務本身處理并發(fā)的能力，但確實提升了對CC攻擊的承載能力。垂直擴展：是指增加每臺服務器的硬件能力，如升級CPU、增加內存、升級SSD固態(tài)硬盤等。水平擴容：是指通過增加提供服務的服務器來提升承載力。上述擴展和擴容可以在服務的各個層級進行，包括：應用服務器、數(shù)據庫服務器和緩存服務器等等。
2、數(shù)據緩存
對于服務中具備高度共性，多用戶可重用，或單用戶多次可重用的數(shù)據，一旦從數(shù)據庫中檢索出，或通過計算得出后，最好將其放在緩存中，后續(xù)請求均可直接從緩存中取得數(shù)據，減輕數(shù)據庫的檢索壓力和應用服務器的計算壓力，并且能夠快速返回結果并釋放進程，從而也能緩解服務器的內存壓力。要注意的是，緩存不要使用文件形式，可以使用redis、mem-cached等基于內存的nosql緩存服務，并且與應用服務器分離，單獨部署在局域網內。局域網內的網絡IO肯定比起磁盤IO要高。為了不使局域網成為瓶頸，千兆網絡也是有必要的。
3、頁面靜態(tài)化
與數(shù)據緩存一樣，頁面數(shù)據本質上也屬于數(shù)據，常見的手段是生成靜態(tài)化的html頁面文件，利用客戶端瀏覽器的緩存功能或者服務端的緩存服務，以及CDN節(jié)點的緩沖服務，均可以降低服務器端的數(shù)據檢索和計算壓力，快速響應結果并釋放連接進程。
4、用戶級別的調用頻率限制
不管服務是有登陸態(tài)還是沒登陸態(tài)，基于session等方式都可以為客戶端分配唯一的識別ID，服務端可以將sid存到緩存中。當客戶端請求服務時，如果沒有帶SID，則由服務端快速分配一個并返回。可以的話，本次請求可以不返回數(shù)據，或者將分配SID獨立出業(yè)務服務。當客戶端請求時帶了合法SID，便可以依據SID對客戶端進行頻率限制。而對于SID非法的請求，則直接拒絕服務。相比根據IP進行的頻率限制，根據SID的頻率限制更加精準可控，可最大程度地避免誤殺情況。
5、IP限制
最后，IP限制依然可以結合上述規(guī)則一起使用，但是可以將其前置至)JCb層的防火墻或負載均衡器上去做，并且可以調大限制的閾值，防止惡意訪問穿透到應用服務器上，造成應用服務器壓力。
NewSQL是對一類現(xiàn)代關系型數(shù)據庫的統(tǒng)稱，這類數(shù)據庫對于一般的OLTP讀寫請求提供可橫向擴展的性能，同時支持事務的ACID保證。這些系統(tǒng)既擁有NoSQL數(shù)據庫的擴展性，又保持傳統(tǒng)數(shù)據庫的事務特性。NewSQL重新將“應用程序邏輯與數(shù)據操作邏輯應該分離”的理念帶回到現(xiàn)代數(shù)據庫的世界，這也驗證了歷史的發(fā)展總是呈現(xiàn)出螺旋上升的形式。
在21世紀00年代中，出現(xiàn)了許多數(shù)據倉庫系統(tǒng) (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請求為設計目標的系統(tǒng)并不在本文定義的NewSQL范圍內。OLAP 數(shù)據庫更關注針對海量數(shù)據的大型、復雜、只讀的查詢，查詢時間可能持續(xù)秒級、分鐘級甚至更長。
NoSQL的擁躉普遍認為阻礙傳統(tǒng)數(shù)據庫橫向擴容、提高可用性的原因在于ACID保證和關系模型，因此NoSQL運動的核心就是放棄事務強一致性以及關系模型，擁抱最終一致性和其它數(shù)據模型?(如 key/value，graphs 和Documents)。
兩個最著名的NoSQL數(shù)據庫就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創(chuàng)業(yè)公司也加入到這場NoSQL運動中，它們不一定是受BigTable和Dynamo的啟發(fā)，但都響應了NoSQL的哲學，其中最出名的就是MongoDB。
在21世紀00年代末，市面上已經有許多供用戶選擇的分布式數(shù)據庫產品。使用NoSQL的優(yōu)勢在于應用開發(fā)者可以更關注應用邏輯本身，而非數(shù)據庫的擴展性問題；但與此同時許多應用，如金融系統(tǒng)、訂單處理系統(tǒng)，由于無法放棄事務的一致性要求被拒之門外。
一些組織，如Google，已經發(fā)現(xiàn)他們的許多工程師將過多的精力放在處理數(shù)據一致性上，這既暴露了數(shù)據庫的抽象、又提高了代碼的復雜度，這時候要么選擇回到傳統(tǒng)DBMS時代，用更高的機器配置縱向擴容，要么選擇回到中間件時代，開發(fā)支持分布式事務的中間件。這兩種方案成本都很高，于是NewSQL運動開始醞釀。
NewSQL數(shù)據庫設計針對的讀寫事務有以下特點：
1、耗時短。
2、使用索引查詢，涉及少量數(shù)據。
3、重復度高，通常使用相同的查詢語句和不同的查詢參考。
也有一些學者認為NewSQL系統(tǒng)是特指實現(xiàn)上使用Lock-free并發(fā)控制技術和share-nothing架構的數(shù)據庫。所有我們認為是NewSQL的數(shù)據庫系統(tǒng)確實都有這樣的特點。
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ù)據，成千上萬臺機器組成的集群是很常見的，所以說分布式系統(tǒng)比單機系統(tǒng)要復雜得多呀。
這是一張HDFS的架構簡圖：
client通過nameNode了解數(shù)據在哪些DataNode上，從而發(fā)起查詢。此外，不僅是查詢文件，寫入文件的時候也是先去請教NameNode，看看應該往哪個DateNode中去寫。
為了某一份數(shù)據只寫入到一個Datanode中，而這個Datanode因為某些原因出錯無法讀取的問題，需要通過冗余備份的方式來進行容錯處理。因此，HDFS在寫入一個數(shù)據塊的時候，不會僅僅寫入一個DataNode，而是會寫入到多個DataNode中，這樣，如果其中一個DataNode壞了，還可以從其余的DataNode中拿到數(shù)據，保證了數(shù)據不丟失。
實際上，每個數(shù)據塊在HDFS上都會保存多份，保存在不同的DataNode上。這種是犧牲一定存儲空間換取可靠性的做法。
接下來我們來看一下完整的文件寫入的流程：
大文件要寫入HDFS，client端根據配置將大文件分成固定大小的塊，然后再上傳到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ù)據寫到他們上面
出于容錯的考慮，每個數(shù)據塊有3個備份，但是3個備份快都直接由client端直接寫入勢必會帶來client端過重的寫入壓力，這個點是否有更好的解決方案呢？回憶一下mysql主備之間是通過binlog文件進行同步的，HDFS當然也可以借鑒這個思想，數(shù)據其實只需要寫入到一個datanode上，然后由datanode之間相互進行備份同步，減少了client端的寫入壓力，那么至于是一個datanode寫入成功即成功，還是需要所有的參與備份的datanode返回寫入成功才算成功，是可靠性配置的策略，當然這個設置會影響到數(shù)據寫入的吞吐率，我們可以看到可靠性和效率永遠是“魚和熊掌不可兼得”的。
潛在問題
NameNode確實會回放editlog，但是不是每次都從頭回放，它會先加載一個fsimage，這個文件是之前某一個時刻整個NameNode的文件元數(shù)據的內存快照，然后再在這個基礎上回放editlog，完成后，會清空editlog，再把當前文件元數(shù)據的內存狀態(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ù)據要時刻保持一致，在寫入數(shù)據的時候，兩個NameNode內存中都要記錄數(shù)據的元信息，并保持一致。這個JournalNode就是用來在兩個NameNode中同步數(shù)據的，并且standby NameNode實現(xiàn)了SecondNameNode的功能。
進行數(shù)據同步操作的過程如下：
active NameNode有操作之后，它的editlog會被記錄到JournalNode中，standby NameNode會從JournalNode中讀取到變化并進行同步，同時standby NameNode會監(jiān)聽記錄的變化。這樣做的話就是實時同步了，并且standby NameNode就實現(xiàn)了SecondNameNode的功能。
優(yōu)點：
缺點：
一、分庫分表的必要性
分庫分表技術的使用，主要是數(shù)據庫產生了瓶頸，如單庫的并發(fā)訪問或單表的查詢都超出了閾值。對系統(tǒng)使用造成一定的影響，不得已而產生的技術。
通過分庫分表技術來解決此類問題，但正因為使用此技術，會產生ACID一系列的問題，各類中間件解決此類問題各有各的優(yōu)勢。
提示：如場景無必要，千萬不要使用分庫分表。
二、分庫分表的思路
1、垂直區(qū)分
垂直分庫：從業(yè)務角度，一個庫分成多個庫，如把訂單和用戶信息分成兩個庫來存儲。這樣的好處就是可以微服務了。每塊的業(yè)務單獨部署，互不影響，通過接口去調用。
垂直分表：把大表分成多個小表，如熱點數(shù)據和非熱點數(shù)據分開，提高查詢速度。
2、水平區(qū)分
水平分表：同一業(yè)務如數(shù)據量大了以后，根據一定的規(guī)則分為不同的表進行存儲。
水平分庫：如訂單分成多個庫存儲，分解服務器壓力。
以上一般來說，垂直分庫和水平分表用的會多些。
三、分庫分表的原理分析
分庫分表常用的方案：Hash取模方案和range范圍方案；
路由算法為最主要的算法，指得是把路由的Key按照指定的算法進行存放；
1、Hash取模方案
根據取余分配到不同的表里。要根據實際情況確認模的大小。此方案由于平均分配，不存在熱點問題，但數(shù)據遷移很復雜。
2、Range范圍方案
range根據范圍進行劃分，如日期，大小。此方案不存在數(shù)據遷移，但存在熱點問題。
四、分庫分表的技術選型
1、技術選型
解決方案主要分為4種：MySQL的分區(qū)技術、NoSql、NewSQL、MySQL的分庫分表。
（1）mysql分區(qū)技術：把一張表存放在不同存儲文件。由于無法負載，使用較少。
（2）NoSQL（如MongoDB）：如是訂單等比較重要數(shù)據，強關聯(lián)關系，需約束一致性，不太適應。
（3）NewSql(具有NoSQL對海量數(shù)據的存儲管理能力，還保持了傳統(tǒng)數(shù)據庫支持ACID和SQL等特性):如TiDB可滿足需求。
（4）MySQL的分庫分表：如使用mysql,此種方案為主流方式。
2、中間件
解決此類問題的中間件主要為：Proxy模式、Client模式。
（1）Proxy模式
（2）Client模式
把分庫分表相關邏輯存放在客戶端，一版客戶端的應用會引用一個jar，然后再jar中處理SQL組合、數(shù)據庫路由、執(zhí)行結果合并等相關功能。
（3）中間件的比較
由于Client模式少了一層，運維方便，相對來說容易些。
五、分庫分表的實踐
根據容量（當前容量和增長量）評估分庫或分表個數(shù) - 選key（均勻）- 分表規(guī)則（hash或range等）- 執(zhí)行（一般雙寫）- 擴容問題（盡量減少數(shù)據的移動）。
在這里我們選用中間件share-jdbc。
1、引入maven依賴
2、spring boot規(guī)則配置
行表達式標識符可以使用${...}或$-{...}，但前者與Spring本身的屬性文件占位符沖突，因此在Spring環(huán)境中使用行表達式標識符建議使用$-{...}。
3、創(chuàng)建DataSource
通過ShardingDataSourceFactory工廠和規(guī)則配置對象獲取ShardingDataSource，ShardingDataSource實現(xiàn)自JDBC的標準接口DataSource。然后即可通過DataSource選擇使用原生JDBC開發(fā)，或者使用JPA, MyBatis等ORM工具。
mysql在線擴容和縮容一般涉及到的內容，主要包括三個方面，1.在線也就意味著需要把增量的數(shù)據重新分布到新的拓撲結構中,我們一般稱做增量復制，2.原有的數(shù)據需要一條不漏的掃出來重新分布到新的拓撲結構中,這個一般叫做全量復制，3.全量做完，增量正在同步，把應用的數(shù)據路由拓撲切到新的路由拓撲上來，并且做到無數(shù)據丟失，這個我們叫做停寫切換。做好這三個方面的工作，能夠達到的效果就是應用在最后切換數(shù)據分布拓撲的時刻，只要停寫非常短的時間(秒級別)就能夠做到無數(shù)據丟失的擴容和縮容。
增量同步一般有2種方式，一種是應用端或者數(shù)據庫前端做trigger,記錄變更數(shù)據的特征值log(比如pk,sharding key)，然后異步復制到新的拓撲結構中。另外一種方式是通過分析mysql的binlog再進行不同數(shù)據拓撲的復制。兩者本質上來說應該是一樣的，后者可能更加簡便，并且對應用無侵入，前者雖然也能夠做到，實際實現(xiàn)或者推廣和操作上都有不少阻力，最起碼解析binlog方式是mysql一上去，更新的log已經天然存在與binlog中了。
增量同步的兩種方式如果要考慮到同步的可伸縮性(也就是多臺機器可以同時消費相同的變更日志)，需要在原數(shù)據中添加數(shù)據的版本信息防止更新亂序，或者通過唯一鍵進行復制機器的sharding,也就是不同進程(線程)同時消費相同的更新日志，必須讓同一條記錄的更新落在同一個線程里面，如果還需要保證復制的事務，那么實現(xiàn)會非常復雜，一般不會去支持多線程下復制的事務。
全量復制，也就是掃描需要復制的表的數(shù)據進行重新分布，主要存在的問題是復制速度和對數(shù)據庫的寫入壓力的矛盾，其實能夠做到整個拓撲連數(shù)據庫都全部換掉，來達到對正在使用數(shù)據庫的0影響，這個是一種可行的方案，另外是分時段調整復制線程數(shù)，一般單線程復制對于數(shù)據庫的影響不會很大，在凌晨再轉換成多線程方式達到提速的目標。
擴容或者縮容在最后階段如何切換，這個涉及到的問題主要是如何避免新更新進來以至于增量沒完沒了，方式有很多，最簡單的方法就是停掉應用，一般時間只有幾分鐘是可以接受的。另外一種是邏輯停寫，因為我們遷移的時候是有一個規(guī)則去重新散列數(shù)據，也就是如果新的規(guī)則和舊的規(guī)則兩者算出來的結果不一致，那么這個數(shù)據就是需要被遷移的，如果在停寫的時刻，向前端拋錯即可。邏輯停寫最大的好處就是避免PE的介入，并且配合動態(tài)的數(shù)據路由數(shù)據推送，可以完全避免重新發(fā)布達到擴容或者縮容，這個就是真正的在線擴容，停寫不可避免（等待延遲的增量同步完成），但是不影響讀。
數(shù)據擴容或者縮容，我們覺得不應該排入業(yè)務的開發(fā)日程中，而是由數(shù)據管理團隊對應用透明地進行這種操作，最后介入的人員只是DBA而已。但是不像一些nosql一樣按容量或者完全透明的split,數(shù)據庫的sharding還是按照應用的數(shù)據特性（pk,user_id,gmt_create等等不同字段，自選策略）進行sharding,應用知道他們的某條數(shù)據具體存在哪個機器哪張表上，這個無論對于開發(fā)還是測試或者DBA都是一件不錯的事情。
通常數(shù)據庫分為關系型數(shù)據庫和非關系型數(shù)據庫，關系型數(shù)據庫的優(yōu)勢到現(xiàn)在也是無可替代的，比如MySQL、SQL Server、Oracle、DB2、SyBase、Informix、PostgreSQL以及比較小型的Access等等數(shù)據庫，這些數(shù)據庫支持復雜的SQL操作和事務機制，適合小量數(shù)據讀寫場景；但是到了大數(shù)據時代，人們更多的數(shù)據和物聯(lián)網加入的數(shù)據已經超出了關系數(shù)據庫的承載范圍。
大數(shù)據時代初期，隨著數(shù)據請求并發(fā)量大不斷增大，一般都是采用的集群同步數(shù)據的方式處理，就是將數(shù)據庫分成了很多的小庫，每個數(shù)據庫的數(shù)據內容是不變的，都是保存了源數(shù)據庫的數(shù)據副本，通過同步或者異步方式保證數(shù)據的一致性，每個庫設定特定的讀寫方式，比如主數(shù)據庫負責寫操作，從數(shù)據庫是負責讀操作，等等根據業(yè)務復雜程度以此類推，將業(yè)務在物理層面上進行了分離，但是這種方式依舊存在一定的負載壓力的問題，企業(yè)數(shù)據在不斷的擴增中，后面就采用分庫分表的方式解決，對讀寫負載進行分離，但是這種實現(xiàn)依舊存在不足，且需要不斷進行數(shù)據庫服務器擴容。
NoSQL數(shù)據庫大致分為5種類型
1、列族數(shù)據庫：BigTable、HBase、Cassandra、Amazon SimpleDB、HadoopDB等，下面簡單介紹幾個
（1）Cassandra：Cassandra是一個列存儲數(shù)據庫，支持跨數(shù)據中心的數(shù)據復制。它的數(shù)據模型提供列索引，log-structured修改，支持反規(guī)范化，實體化視圖和嵌入超高速緩存。
（2）HBase：Apache Hbase源于Google的Bigtable，是一個開源、分布式、面向列存儲的模型。在Hadoop和HDFS之上提供了像Bigtable一樣的功能。
（3）Amazon SimpleDB：Amazon SimpleDB是一個非關系型數(shù)據存儲，它卸下數(shù)據庫管理的工作。開發(fā)者使用Web服務請求存儲和查詢數(shù)據項
（4）Apache Accumulo：Apache Accumulo的有序的、分布式鍵值數(shù)據存儲，基于Google的BigTable設計，建立在Apache Hadoop、Zookeeper和Thrift技術之上。
（5）Hypertable：Hypertable是一個開源、可擴展的數(shù)據庫，模仿Bigtable，支持分片。
（6）Azure Tables：Windows Azure Table Storage Service為要求大量非結構化數(shù)據存儲的應用提供NoSQL性能。表能夠自動擴展到TB級別，能通過REST和Managed API訪問。
2、鍵值數(shù)據庫：Redis、SimpleDB、Scalaris、Memcached等，下面簡單介紹幾個
（1）Riak：Riak是一個開源，分布式鍵值數(shù)據庫，支持數(shù)據復制和容錯。（2）Redis：Redis是一個開源的鍵值存儲。支持主從式復制、事務，Pub/Sub、Lua腳本，還支持給Key添加時限。
（3）Dynamo：Dynamo是一個鍵值分布式數(shù)據存儲。它直接由亞馬遜Dynamo數(shù)據庫實現(xiàn)；在亞馬遜S3產品中使用。
（4）Oracle NoSQL Database：來自Oracle的鍵值NoSQL數(shù)據庫。它支持事務ACID（原子性、一致性、持久性和獨立性）和JSON。
（5）Oracle NoSQL Database：具備數(shù)據備份和分布式鍵值存儲系統(tǒng)。
（6）Voldemort：具備數(shù)據備份和分布式鍵值存儲系統(tǒng)。
（7）Aerospike：Aerospike數(shù)據庫是一個鍵值存儲，支持混合內存架構，通過強一致性和可調一致性保證數(shù)據的完整性。
3、文檔數(shù)據庫：MongoDB、CouchDB、Perservere、Terrastore、RavenDB等，下面簡單介紹幾個
（1）MongoDB：開源、面向文檔，也是當下最人氣的NoSQL數(shù)據庫。
（2）CounchDB：Apache CounchDB是一個使用JSON的文檔數(shù)據庫，使用Javascript做MapReduce查詢，以及一個使用HTTP的API。
（3）Couchbase：NoSQL文檔數(shù)據庫基于JSON模型。
（4）RavenDB：RavenDB是一個基于.NET語言的面向文檔數(shù)據庫。
（5）MarkLogic：MarkLogic NoSQL數(shù)據庫用來存儲基于XML和以文檔為中心的信息，支持靈活的模式。
4、圖數(shù)據庫：Neo4J、InfoGrid、OrientDB、GraphDB，下面簡單介紹幾個
（1）Neo4j：Neo4j是一個圖數(shù)據庫；支持ACID事務（原子性、獨立性、持久性和一致性）。
（2）InfiniteGraph：一個圖數(shù)據庫用來維持和遍歷對象間的關系，支持分布式數(shù)據存儲。
（3）AllegroGraph：AllegroGraph是結合使用了內存和磁盤，提供了高可擴展性，支持SPARQ、RDFS++和Prolog推理。
5、內存數(shù)據網格：Hazelcast、Oracle Coherence、Terracotta BigMemorry、GemFire、Infinispan、GridGain、GigaSpaces，下面簡單介紹幾個
（1）Hazelcast：Hazelcast CE是一個開源數(shù)據分布平臺，它允許開發(fā)者在數(shù)據庫集群之上共享和分割數(shù)據。
（2）Oracle Coherence：Oracle的內存數(shù)據網格解決方案提供了常用數(shù)據的快速訪問能力，一致性支持事務處理能力和數(shù)據的動態(tài)劃分。
（3）Terracotta BigMemory：來自Terracotta的分布式內存管理解決方案。這項產品包括一個Ehcache界面、Terracotta管理控制臺和BigMemory-Hadoop連接器。
（4）GemFire：Vmware vFabric GemFire是一個分布式數(shù)據管理平臺，也是一個分布式的數(shù)據網格平臺，支持內存數(shù)據管理、復制、劃分、數(shù)據識別路由和連續(xù)查詢。
（5）Infinispan：Infinispan是一個基于Java的開源鍵值NoSQL數(shù)據存儲，和分布式數(shù)據節(jié)點平臺，支持事務，peer-to-peer 及client/server 架構。
（6）GridGain：分布式、面向對象、基于內存、SQL+NoSQL鍵值數(shù)據庫。支持ACID事務。
（7）GigaSpaces：GigaSpaces內存數(shù)據網格能夠充當應用的記錄系統(tǒng)，并支持各種各樣的高速緩存場景。
重慶分公司
重慶分公司
