雖然NoSQL的流行與火起來才短短一年的時間，但是不可否認，現在已經開始了第二代運動。盡管早期的堆棧代碼隻能算是一種實驗，然而現在的系統已經更加的成熟、穩定。不過現在也面臨着一個嚴酷的事實：技術越來越成熟——以至于原來很好的NoSQL資料存儲不得不進行重寫，也有少數人認為這就是所謂的2.0版本。該工具可以為大資料建立快速、可擴充的存儲庫。
MongoDB
MongoDB是一個基于分布式檔案存儲的資料庫。由C++語言編寫。主要解決的是海量資料的通路效率問題，為WEB應用提供可擴充的高性能資料存儲解決方案。當資料量達到50GB以上的時候，MongoDB的資料庫通路速度是MySQL的10倍以上。MongoDB的并發讀寫效率不是特别出色，根據官方提供的性能測試表明，大約每秒可以處理0.5萬~1.5萬次讀寫請求。MongoDB還自帶了一個出色的分布式檔案系統GridFS，可以支援海量的資料存儲。
MongoDB也有一個Ruby的項目MongoMapper，是模仿Merb的DataMapper編寫的MongoDB接口，使用起來非常簡單，幾乎和DataMapper一模一樣，功能非常強大。
MongoDB是一個介于關系資料庫和非關系資料庫之間的産品，是非關系資料庫當中功能最豐富，最像關系資料庫的。他支援的資料結構非常松散，是類似json的bjson格式，是以可以存儲比較複雜的資料類型。Mongo最大的特點是他支援的查詢語言非常強大，其文法有點類似于面向對象的查詢語言，幾乎可以實作類似關系資料庫單表查詢的絕大部分功能，而且還支援對資料建立索引。
所謂“面向集合”（Collenction-Orented），意思是資料被分組存儲在資料集中，被稱為一個集合（Collenction)。每個 集合在資料庫中都有一個唯一的辨別名，并且可以包含無限數目的文檔。集合的概念類似關系型資料庫（RDBMS）裡的表（table），不同的是它不需要定義任何模式（schema)。
模式自由（schema-free)，意味着對于存儲在mongodb資料庫中的檔案，我們不需要知道它的任何結構定義。如果需要的話，你完全可以把不同結構的檔案存儲在同一個資料庫裡。
存儲在集合中的文檔，被存儲為鍵-值對的形式。鍵用于唯一辨別一個文檔，為字元串類型，而值則可以是各中複雜的檔案類型。我們稱這種存儲形式為BSON（Binary Serialized dOcument Format）。
MongoDB服務端可運作在 Linux 、Windows或OS X平台，支援32位和64位應用，預設端口為27017。推薦運作在64位平台，因為MongoDB在32位模式運作時支援的最大檔案尺寸為2GB。
MongoDB把資料存儲在檔案中（預設路徑為：/data/db），為提高效率使用記憶體映射檔案進行管理。
它的特點是高性能、易部署、易使用，存儲資料非常友善。
主要功能特性有：
面向集合存儲，易存儲對象類型的資料。
基于文檔的資料庫系統，格式是以BSON（JSON，半結構化資料）存儲。
性能的保證，基于C++研發，速度快。
支援完全索引（資料讀取全靠索引）
不支援事務，意味每一個操作都是原子的且是強一緻性。
操作在記憶體中進行，定義同步到磁盤。
支援很好的擴充性，比如複制，auto_sharding。
能基于複制自動完整故障轉移。
支援文檔的查詢，可以傳回一個文檔也可以傳回一個遊标（結果集）。
支援查詢性能分析。
支援動态查詢，就是可以像MySQL那樣自己書寫查詢條件，而有些NoSQL這不行。
支援使用Map Redure做分組聚合操作，處理大資料極強。
支援空間索引，用于地理資料表述的場景，如地圖。
自動處理碎片，以支援雲計算層次的擴充性。
Hbase
HBase是一個分布式的、面向列的開源資料庫，該技術來源于Chang et al所撰寫的Google論文“Bigtable：一個結構化資料的分布式存儲系統”。就像Bigtable利用了Google檔案系統（File System）所提供的分布式資料存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。HBase是Apache的Hadoop項目的子項目。HBase不同于一般的關系資料庫,它是一個适合于非結構化資料存儲的資料庫.另一個不同的是HBase基于列的而不是基于行的模式。
HBase – Hadoop Database，是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統，利用HBase技術可在廉價PC Server上搭建起大規模結構化存儲叢集。 HBase是Google Bigtable的開源實作，類似Google Bigtable利用GFS作為其檔案存儲系統，HBase利用Hadoop HDFS作為其檔案存儲系統；Google運作MapReduce來處理Bigtable中的海量資料，HBase同樣利用Hadoop MapReduce來處理HBase中的海量資料；Google Bigtable利用 Chubby作為協同服務，HBase利用Zookeeper作為對應。
HBase通路接口
Native Java API，最正常和高效的通路方式，适合Hadoop MapReduce Job并行批處理HBase表資料
HBase Shell，HBase的指令行工具，最簡單的接口，适合HBase管理使用
Thrift Gateway，利用Thrift序列化技術，支援C++，PHP，Python等多種語言，适合其他異構系統線上通路HBase表資料
REST Gateway，支援REST 風格的Http API通路HBase, 解除了語言限制
Pig，可以使用Pig Latin流式程式設計語言來操作HBase中的資料，和Hive類似，本質最終也是編譯成MapReduce Job來處理HBase表資料，适合做資料統計
Hive，目前Hive的Release版本尚沒有加入對HBase的支援，但在下一個版本Hive 0.7.0中将會支援HBase，可以使用類似SQL語言來通路HBase
主要功能特性有：
支援數十億行X上百萬列
采用分布式架構 Map/reduce
對實時查詢進行優化
高性能 Thrift網關
通過在server端掃描及過濾實作對查詢操作預判
支援 XML, Protobuf, 和binary的HTTP
基于 Jruby（ JIRB）的shell
對配置改變和較小的更新都會重新復原
不會出現單點故障
堪比MySQL的随機通路性能
Redis
Redis是一個開源（BSD許可）的記憶體中的資料結構存儲系統，它可以用作資料庫、緩存和消息中間件。由于Redis采用運作在記憶體中的資料集工作方式，其性能卓越，能支援超過100K+每秒的讀寫頻率。它支援多種類型的資料結構，如字元串（strings）， 散列（hashes），清單（lists），集合（sets），有序集合（sorted sets）與範圍查詢和地理空間（geospatial）索引半徑查詢。Redis内置了複制（replication）， LUA腳本（Lua scripting），LRU淘汰機制，事務實作（transactions），釋出訂閱（publish/subscribe）和不同級别的磁盤持久化（persistence）等能力， 并通過Redis哨兵（Sentinel）和自動分區（Cluster）提供高可用性（high availability）。
Redis的主要功能都是基于單線程網絡模型實作，也就是說Redis使用一個線程來服務所有的用戶端請求，同時Redis采用了非阻塞式IO，并精細地優化各種指令的算法和時間複雜度，大部分指令的算法都是O(1)的，具體可以看Redis指令參考。
另外Redis的大部分操作都是原子性的（簡單的單線程模型），同時Redis還支援對幾個操作全并後的原子性執行。列如：字元串（strings）的append指令；散列（hashes）的hincrby指令；清單（lists）的lpush指令；集合（sets）計算交集sinter指令，計算并集union指令和計算差集sdiff指令；或者在有序集合（sorted sets）裡面擷取成員的最高排名zrangebyscore指令等。
官方站點：http://redis.io
Memcachedb
MemcacheDB是一個分布式、key-value形式的持久存儲系統。它不是一個緩存元件，而是一個基于對象存取的、可靠的、快速的持久存儲引擎。協定跟memcache一緻（不完整），是以很多memcached用戶端都可以跟它連接配接。MemcacheDB采用Berkeley DB作為持久存儲元件，故很多Berkeley DB的特性的他都支援
MemcacheDB是一個分布式、key-value形式的持久存儲系統。它不是一個緩存元件，而是一個基于對象存取的、可靠的、快速的持久存儲引擎。 協定跟memcache一緻（不完整），是以很多memcached用戶端都可以跟它連接配接。MemcacheDB采用Berkeley DB作為持久存儲元件，故很多Berkeley DB的特性的他都支援。我們是站在巨人的肩膀上的。MemcacheDB的前端緩存是Memcached 。
前端：memcached的網絡層
後端：BerkeleyDB存儲
寫速度：從本地伺服器通過memcache用戶端（libmemcache）set2億條16位元組長的key，10位元組長的Value的記錄，耗時 16572秒，平均速度12000條記錄/秒。
讀速度：從本地伺服器通過memcache用戶端（libmemcache）get100萬條16位元組長的key，10位元組長的Value的記錄，耗 時103秒，平均速度10000條記錄/秒。支援的memcache指令。
官方站點：http://memcachedb.org
Hypertable
Hypertable是一個開源、高性能、可伸縮的資料庫，它采用與Google的Bigtable相似的模型。在過去數年中，Google為在 PC叢集 上運作的可伸縮計算基礎設施設計建造了三個關鍵部分。第一個關鍵的基礎設施是Google File System（GFS），這是一個高可用的檔案系統，提供了一個全局的命名空間。它通過跨機器（和跨機架）的檔案資料複制來達到高可用性，并是以免受傳統 檔案存儲系統無法避免的許多失敗的影響，比如電源、記憶體和網絡端口等失敗。第二個基礎設施是名為Map-Reduce的計算架構，它與GFS緊密協作，幫 助處理收集到的海量資料。第三個基礎設施是Bigtable，它是傳統資料庫的替代。Bigtable讓你可以通過一些主鍵來組織海量資料，并實作高效的 查詢。Hypertable是Bigtable的一個開源實作，并且根據我們的想法進行了一些改進。
主要功能特點：
負載均衡的處理
版本控制和一緻性
可靠性
分布為多個節點
CouchDB
Apache CouchDB是一個面向文檔的資料庫管理系統。它提供以 JSON 作為資料格式的 REST 接口來對其進行操作，并可以通過視圖來操縱文檔的組織和呈現。 CouchDB 是 Apache 基金會的頂級開源項目。
CouchDB是用Erlang開發的面向文檔的資料庫系統，其資料存儲方式類似Lucene的Index檔案格式。CouchDB最大的意義在于它是一個面向Web應用的新一代存儲系統，事實上，CouchDB的口号就是：下一代的Web應用存儲系統
主要功能特性有：
CouchDB是分布式的資料庫，他可以把存儲系統分布到n台實體的節點上面，并且很好的協調和同步節點之間的資料讀寫一緻性。這當然也得以于Erlang無與倫比的并發特性才能做到。對于基于web的大規模應用文檔應用，然的分布式可以讓它不必像傳統的關系資料庫那樣分庫拆表，在應用代碼層進行大量的改動。
CouchDB是面向文檔的資料庫，存儲半結構化的資料，比較類似lucene的index結構，特别适合存儲文檔，是以很适合CMS，電話本，位址本等應用，在這些應用場合，文檔資料庫要比關系資料庫更加友善，性能更好。
CouchDB支援REST API，可以讓使用者使用JavaScript來操作CouchDB資料庫，也可以用JavaScript編寫查詢語句，我們可以想像一下，用AJAX技術結合CouchDB開發出來的CMS系統會是多麼的簡單和友善。其實CouchDB隻是Erlang應用的冰山一角，在最近幾年，基于Erlang的應用也得到的蓬勃的發展，特别是在基于web的大規模，分布式應用領域，幾乎都是Erlang的優勢項目。
cassandra
Cassandra是一個混合型的非關系的資料庫，類似于Google的BigTable。其主要功能比Dynomite（分布式的Key-Value存儲系統）更豐富，但支援度卻不如文檔存儲MongoDB（介于關系資料庫和非關系資料庫之間的開源産品，是非關系資料庫當中功能最豐富，最像關系資料庫的。支援的資料結構非常松散，是類似json的bjson格式，是以可以存儲比較複雜的資料類型。）Cassandra最初由Facebook開發，後轉變成了開源項目。它是一個網絡社交雲計算方面理想的資料庫。以Amazon專有的完全分布式的Dynamo為基礎，結合了Google BigTable基于列族（Column Family）的資料模型。P2P去中心化的存儲。很多方面都可以稱之為Dynamo 2.0
特性和其他資料庫比較，有幾個突出特點：模式靈活 ：使用Cassandra，像文檔存儲，你不必提前解決記錄中的字段。你可以在系統運作時随意的添加或移除字段。這是一個驚人的效率提升，特别是在大型部 署上。
真正的可擴充性 ：Cassandra是純粹意義上的水準擴充。為給叢集添加更多容量，可以指向另一台電腦。你不必重新開機任何程序，改變應用查詢，或手動遷移任何資料。
多資料中心識别 ：你可以調整你的節點布局來避免某一個資料中心起火，一個備用的資料中心将至少有每條記錄的完全複制。
一些使Cassandra提高競争力的其他功能：
範圍查詢 ：如果你不喜歡全部的鍵值查詢，則可以設定鍵的範圍來查詢
清單資料結構 ：在混合模式可以将超級列添加到5維。對于每個使用者的索引，這是非常友善的
分布式寫操作 ：有可以在任何地方任何時間集中讀或寫任何資料。并且不會有任何單點失敗
Tokyo Cabinet/Tokyo Tyant
Tokyo Cabinet（TC）和Tokyo Tyrant（TT）的開發者是日本人Mikio Hirabayashi，主要用于日本最大的SNS網站mixi.jp。TC出現的時間最早，現在已經是一個非常成熟的項目，也是Key-Value資料庫領域最大的熱點，現在廣泛應用于網站。TC是一個高性能的存儲引擎，而TT提供了多線程高并發伺服器，性能也非常出色，每秒可以處理4萬~5萬次讀寫操作。
TC除了支援Key-Value存儲之外，還支援Hashtable資料類型，是以很像一個簡單的資料庫表，并且還支援基于Column的條件查詢、分頁查詢和排序功能，基本上相當于支援單表的基礎查詢功能，是以可以簡單地替代關系資料庫的很多操作，這也是TC受到大家歡迎的主要原因之一。有一個Ruby項目miyazakiresistance将TT的Hashtable的操作封裝成和ActiveRecord一樣的操作，用起來非常高效
TC/TT在Mixi的實際應用當中，存儲了2000萬條以上的資料，同時支撐了上萬個并發連接配接，是一個久經考驗的項目。TC在保證了極高的并發讀寫性能的同時，還具有可靠的資料持久化機制，同時還支援類似關系資料庫表結構的Hashtable以及簡單的條件、分頁和排序操作，是一個很優越的NoSQL資料庫。
TC的主要缺點是，在資料量達到上億級别以後，并發寫資料性能會大幅度下降，開發人員發現在TC裡面插入1.6億條2KB~20KB資料的時候，寫入性能開始急劇下降。即當資料量達到上億條的時候，TC性能便開始大幅度下降，從TC作者自己提供的Mixi資料來看，至少上千萬條資料量的時候還沒有遇到這麼明顯的寫入性能瓶頸
Flare
TC是日本第一大SNS網站mixi.jp開發的，而Flare是日本第二大SNS網站green.jp開發的。簡單地說，Flare就是給TC添加了scale（可擴充）功能。它替換了TT部分，自己另外給TC寫了網絡伺服器。Flare的主要特點就是支援scale能力，它在網絡服務端之前添加了一個Node Server，用來管理後端的多個伺服器節點，是以可以動态添加資料庫服務節點、删除伺服器節點，也支援Failover。如果你的使用場景必須讓TC可以scale，那麼可以考慮Flare。
flare唯一的缺點就是他隻支援memcached協定，是以當你使用flare的時候，就不能使用TC的table資料結構了，隻能使用TC的key-value資料結構存儲。
Berkeley DB
Berkeley DB (DB)是一個高性能的，嵌入資料庫程式設計庫，和C語言，C++，Java，Perl，Python，PHP，Tcl以及其他很多語言都有綁定。Berkeley DB可以儲存任意類型的鍵/值對，而且可以為一個鍵儲存多個資料。Berkeley DB可以支援數千的并發線程同時操作資料庫，支援最大256TB的資料，廣泛 用于各種作業系統包括大多數Unix類作業系統和Windows作業系統以及實時作業系統。
Berkeley DB最初開發的目的是以新的HASH通路算法來代替舊的hsearch函數和大量的dbm實作（如AT&T的dbm，Berkeley的 ndbm，GNU項目的gdbm），Berkeley DB的第一個發行版在1991年出現，當時還包含了B+樹資料通路算法。在1992年，BSD UNIX第4.4發行版中包含了Berkeley DB1.85版。基本上認為這是Berkeley DB的第一個正式版。在1996年中期，Sleepycat軟體公司成立，提供對Berkeley DB的商業支援。在這以後，Berkeley DB得到了廣泛的應用，成為一款獨樹一幟的嵌入式資料庫系統。2006年Sleepycat公司被Oracle 公司收購，Berkeley DB成為Oracle資料庫家族的一員，Sleepycat原有開發者繼續在Oracle開發Berkeley DB，Oracle繼續原來的授權方式并且加大了對Berkeley DB的開發力度，繼續提升了Berkeley DB在軟體行業的聲譽。Berkeley DB的目前最新發行版本是4.7.25。
Memlink
Memlink 是天涯社群開發的一個高性能、持久化、分布式的Key-list/queue資料引擎。正如名稱中的memlink所示，所有資料都建構在記憶體中，保證了 系統的高性能 (大約是redis幾倍)，同時使用了redo-log技術保證資料的持久化。Memlink還支援主從複制、讀寫分離、List過濾操作等功能。
與Memcached不同的是，它的value是一個list/queue。并且提供了諸如持久化，分布式的功能。聽起來有點像Redis，但它号稱比Redis更好，在很多Redis做得還不好的地方進行了改進和完善。提供的用戶端開發包包括 c,python,php,java 四種語言
特點：
記憶體資料引擎，性能極為高效
List塊鍊結構，精簡記憶體，優化查找效率
Node資料項可定義，支援多種過濾操作
支援redo-log，資料持久化，非Cache模式
分布式，主從同步
db4o
“利用表格存儲對象，就像是将汽車開回家，然後拆成零件放進車庫裡，早晨可以再把汽車裝配起來。但是人們不禁要問，這是不是泊車的最有效的方法呢。” – Esther Dyson db4o 是一個開源的純面向對象資料庫引擎，對于 Java 與 .NET 開發者來說都是一個簡單易用的對象持久化工具，使用簡單。同時，db4o 已經被第三方驗證為具有優秀性能的面向對象資料庫， 下面的基準測試圖對 db4o 和一些傳統的持久方案進行了比較。db4o 在這次比較中排名第二，僅僅落後于JDBC。通過圖 1 的基準測試結果，值得我們細細品味的是采用 Hibernate/HSQLDB 的方案和 JDBC/HSQLDB 的方案在性能方面有着顯著差距，這也證明了業界對 Hibernate 的擔憂。而 db4o 的優異性能，讓我們相信： 更 OO 并不一定會犧牲性能。
同時，db4o 的一個特點就是無需 DBA 的管理，占用資源很小，這很适合嵌入式應用以及 Cache 應用， 是以自從 db4o 釋出以來，迅速吸引了大批使用者将 db4o 用于各種各樣的嵌入式系統，包括流動軟體、醫療裝置和實時控制系統。 db4o 由來自加州矽谷的開源資料庫公司 db4objects 開發并負責商業營運和支援。db4o 是基于 GPL 協定。db4objects 于 2004 年在 CEO Christof Wittig 的上司下組成，資金背景包括 Mark Leslie 、 Veritas 軟體公司 CEO 、 Vinod Khosla （ Sun 公司創始人之一）、 Sun 公司 CEO 在内的矽谷高層投資人組成。毫無疑問，今天 db4objects 公司是矽谷炙手可熱的技術創新者之一
db4o 的目标是提供一個功能強大的，适合嵌入的資料庫引擎，可以工作在裝置，移動産品，桌面以及伺服器等各種平台。主要特性如下：開源模式。與其他 ODBMS 不同，db4o 為開源軟體，通過開源社群的力量驅動開發 db4o 産品。原生資料庫。db4o 是 100% 原生的面向對象資料庫，直接使用程式設計語言來操作資料庫。程式員無需進行 OR 映射來存儲對象，大大節省了程式員在存儲資料的開發時間。高性能。 下圖為 db4o 官方公布的基準測試資料，db4o 比采用 Hibernate/MySQL 方案在某些測試線路上速度高出 44 倍之多！并且安裝簡單，僅僅需要 400Kb 左右的 .jar 或 .dll 庫檔案。在接下來的系列文章中，我們将隻關注在 Java 平台的應用，但是實際上 db4o 毫無疑問會很好地在 .NET平台工作
易嵌入，使用 db4o 僅需引入 400 多 k 的 jar 檔案或是 dll 檔案，記憶體消耗極小。零管理。使用 db4o 無需 DBA，實作零管理。支援多種平台。db4o 支援從 Java 1.1 到 Java 5.0，此外還支援 .NET 、 CompactFramework 、 Mono 等 .NET 平台，也可以運作在 CDC 、 PersonalProfile 、 Symbian 、 Savaje 以及 Zaurus 這種支援反射的 J2ME 方言環境中，還可以運作在 CLDC 、 MIDP 、 RIM/Blackberry 、 Palm OS 這種不支援反射的 J2ME 環境中。 或許開發者會問，如果現有的應用環境已經有了關系型資料庫怎麼辦？沒關系，db4o 的 dRS（db4o Replication System）可實作 db4o 與關系型資料庫的雙向同步（複制），如圖 3 。 dRS 是基于 Hibernate 開發，目前的版本是 1.0 ，并運作在 Java 1.2 或更高版本平台上，基于 dRS 可實作 db4o 到 Hibernate/RDBMS 、 db4o 到 db4o 以及 Hibernate/RDBMS 到 Hibernate/RDBMS 的雙向複制。dRS 模型如圖
Versant
Versant Object Database (V/OD) 提供強大的資料管理，面向 C++, Java or .NET 的對象模型，支援大并發和大規模資料集合。
Versant對象資料庫是一個對象資料庫管理系統(ODBMS：Object Database Management System)。它主要被用在複雜的、分布式的和異構的環境中，用來減少開發量和提高性能。尤其當程式是使用Java和（或）C＋＋語言編寫的時候，尤其有用。
它是一個完整的，電子基礎設施軟體，簡化了事務的建構和部署的分布式應用程式。
作為一個卓越的資料庫産品，Versant ODBMS在設計時的目标就是為了滿足客戶在異類處理平台和企業級資訊系統中對于高性能、可量測性、可靠性和相容性方面的需求。
Versant對象資料庫已經在為企業業務應用提供可靠性、完整性和高性能方面獲得了建樹，Versant ODBMS所表現出的高效的多線程架構、internal parallelism 、平穩的Client－Server結構和高效的查詢優化，都展現了其非常卓越的性能和可擴充性。
Versant對象資料庫包括Versant ODBMS，C++和Java語言接口，XML工具包和異步複制架構
Versant Object Database8.0，适用于應用環境中包含複雜對象模型的資料庫，其設計目标是能夠處理這些應用經常需要的導航式通路，無縫的資料分發，和企業級的規模。
對于很多應用程式而言，最具挑戰性的方面是控制業務模型本身的内在複雜性。 電信基礎設施，交通運輸網絡，仿真，金融工具以及其它領域的複雜性必須得到支援， 而且這種支援複雜性的方式還要能夠随着環境和需求變化而不斷地改進應用程式。 這些應用程式的重點是領域和這些領域的邏輯。 複雜的設計應當以對象模型為基礎。将技術需求例如持久性（和SQL）與領域模型混合在一起的架構會帶來災難性的後果。
Versant對象資料庫使您可以使用那些隻含有域行為資訊的對象，而不用考慮持久性。同時，Versant對象資料庫還能提供跨多個資料庫的無縫的資料分發，高并發性，細粒度鎖，頂級性能， 以及通過複制和其它技術提供的高可用性。現代Java中的對象關系映射工具已經簡化了很多映射的問題， 但是它們還不能提供Versant所能提供的無縫資料分發的功能和高性能
主要特性
C++、Java及.NET 的透明對象持久
支援對象持久标準，如JDO
跨多資料庫的無縫資料分發
企業級的高可用性選項
動态模式更新
管理工作量少（或不需要）
端到端的對象支援架構
細粒度并發控制
多線程，多會話
支援國際字元集
高速資料采集
Neo4j
Neo4j是一個嵌入式，基于磁盤的，支援完整事務的Java持久化引擎，它在圖像中而不是表中存儲資料。Neo4j提供了大規模可擴充性，在一台機器上可以處理數十億節點/關系/屬性的圖像，可以擴充到多台機器并行運作。相對于關系資料庫來說，圖形資料庫善于處理大量複雜、互連接配接、低結構化的資料，這些資料變化迅速，需要頻繁的查詢——在關系資料庫中，這些查詢會導緻大量的表連接配接，是以會産生性能上的問題。Neo4j重點解決了擁有大量連接配接的傳統RDBMS在查詢時出現的性能衰退問題。通過圍繞圖形進行資料模組化，Neo4j會以相同的速度周遊節點與邊，其周遊速度與構成圖形的資料量沒有任何關系。此外，Neo4j還提供了非常快的圖形算法、推薦系統和OLAP風格的分析，而這一切在目前的RDBMS系統中都是無法實作的。
Neo是一個網絡——面向網絡的資料庫——也就是說，它是一個嵌入式的、基于磁盤的、具備完全的事務特性的Java持久化引擎，但是它将結構化資料存儲在網絡上而不是表中。網絡（從數學角度叫做圖）是一個靈活的資料結構，可以應用更加靈活和快速的開發模式。
你可以把Neo看作是一個高性能的圖引擎，該引擎具有成熟和健壯的資料庫的所有特性。程式員工作在一個面向對象的、靈活的網絡結構下而不是嚴格、靜态的表中——但是他們可以享受到具備完全的事務特性、企業級的資料庫的所有好處。
由于使用了“面向網絡的資料庫”，人們對Neo充滿了好奇。在該模型中，以“節點空間”來表達領域資料——相對于傳統的模型表、行和列來說，節點空間是很多節點、關系和屬性（鍵值對）構成的網絡。關系是第一級對象，可以由屬性來注解，而屬性則表明了節點互動的上下文。網絡模型完美的比對了本質上就是繼承關系的問題域，例如語義Web應用。Neo的建立者發現繼承和結構化資料并不适合傳統的關系資料庫模型：
1.對象關系的不比對使得把面向對象的“圓的對象”擠到面向關系的“方的表”中是那麼的困難和費勁，而這一切是可以避免的。
2.關系模型靜态、剛性、不靈活的本質使得改變schemas以滿足不斷變化的業務需求是非常困難的。由于同樣的原因，當開發小組想應用靈活軟體開發時，資料庫經常拖後腿。
3.關系模型很不适合表達半結構化的資料——而業界的分析家和研究者都認為半結構化資料是資訊管理中的下一個重頭戲。
4.網絡是一種非常高效的資料存儲結構。人腦是一個巨大的網絡，網際網路也同樣構造成網狀，這些都不是巧合。關系模型可以表達面向網絡的資料，但是在周遊網絡并抽取資訊的能力上關系模型是非常弱的。
雖然Neo是一個比較新的開源項目，但它已經在具有1億多個節點、關系和屬性的産品中得到了應用，并且能滿足企業的健壯性和性能的需求：
完全支援JTA和JTS、2PC分布式ACID事務、可配置的隔離級别和大規模、可測試的事務恢複。這些不僅僅是口頭上的承諾：Neo已經應用在高請求的24/7環境下超過3年了。它是成熟、健壯的，完全達到了部署的門檻
Neo4j是一個用Java實作、完全相容ACID的圖形資料庫。資料以一種針對圖形網絡進行過優化的格式儲存在磁盤上。Neo4j的核心是一種極快的圖形引擎，具有資料庫産品期望的所有特性，如恢複、兩階段送出、符合XA等。
Neo4j既可作為無需任何管理開銷的内嵌資料庫使用；也可以作為單獨的伺服器使用，在這種使用場景下，它提供了廣泛使用的REST接口，能夠友善地內建到基于PHP、.NET和JavaScript的環境裡。但本文的重點主要在于讨論Neo4j的直接使用。
Neo4j的典型資料特征：
資料結構不是必須的，甚至可以完全沒有，這可以簡化模式變更和延遲資料遷移。
可以友善模組化常見的複雜領域資料集，如CMS裡的通路控制可被模組化成細粒度的通路控制表，類對象資料庫的用例、TripleStores以及其他例子。
典型使用的領域如語義網和RDF、LinkedData、GIS、基因分析、社交網絡資料模組化、深度推薦算法以及其他領域。
圍繞核心，Neo4j提供了一組可選的元件。其中有支援通過元模型構造圖形結構、SAIL – 一種SparQL相容的RDF TripleStore實作或一組公共圖形算法的實作。
高性能？
要給出确切的性能基準資料很難，因為它們跟底層的硬體、使用的資料集和其他因素關聯很大。自适應規模的Neo4j無需任何額外的工作便可以處理包含數十億節點、關系和屬性的圖。它的讀性能可以很輕松地實作每毫秒（大約每秒1-2百萬周遊步驟）周遊2000關系，這完全是事務性的，每個線程都有熱緩存。使用最短路徑計算，Neo4j在處理包含數千個節點的小型圖時，甚至比MySQL快1000倍，随着圖規模的增加，差距也越來越大。
這其中的原因在于，在Neo4j裡，圖周遊執行的速度是常數，跟圖的規模大小無關。不象在RDBMS裡常見的聯結操作那樣，這裡不涉及降低性能的集合操作。Neo4j以一種延遲風格周遊圖 – 節點和關系隻有在結果疊代器需要通路它們的時候才會被周遊并傳回，對于大規模深度周遊而言，這極大地提高了性能。
寫速度跟檔案系統的查找時間和硬體有很大關系。Ext3檔案系統和SSD磁盤是不錯的組合，這會導緻每秒大約100,000寫事務操作
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31524109/viewspace-2637135/，如需轉載，請注明出處，否則将追究法律責任。
轉載于:http://blog.itpub.net/31524109/viewspace-2637135/
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)